読んだ本・文献から抽出した概念・フレームワーク・Tipsをまとめています
Astro + Cloudflare Pages で構築したナレッジベースの設計方針。Functional Core, Imperative Shell を Astro コンポーネント設計に適用した実例
ステータス・種別などの区分値を、固有ロジックを持つオブジェクトとして表現しswitch文の散在を防ぐパターン
欠陥予防とは、不具合が発生した後に修正するだけでなく、同種の欠陥が将来にわたって発生しないようにする活動。2つの実践で構成される：
業務ロジックをデータを保持するドメインオブジェクト自身に持たせ、貧血ドメインモデルを避ける設計方針
コレクションを専用クラスでラップし、そのコレクション固有の業務ロジックをメソッドとして持たせるパターン
副作用とドメインロジックを2層に分離し、ビジネスロジックを純粋関数の層に閉じ込める設計方針
システムの外部出力からその内部状態を推測できる度合い。分散システムやAIエージェントの運用に不可欠な能力
プロセス成熟度とは、組織のソフトウェア開発プロセスがどれだけ定義・管理・最適化されているかの段階的な評価基準。CMMI（Capability Maturity Model Integration）が代表的なモデル：
不確実性コーン・ファンクションポイント・プランニングポーカーなど、プロジェクト規模と工数を予測する技法
同じ入力に対して常に同じ出力を返し、副作用を持たない関数
欠陥を防ぐプロセスを構築するSQAの考え方、品質の8側面、レビューとメトリクスによる品質管理
組織が品質目標を達成するための、責任・プロセス・リソースを体系的に管理する仕組み。ISO 9001 や SQuBOK が定義する QMS の核心は3要素：
品質指標とは、品質目標の達成度を数値で判断するための計測可能な尺度。ただし「計測できる」ことより「判断の根拠になる」ことが本質。
エラー処理を2本レールの鉄道として表現し、型安全なエラーハンドリングを実現するパターン
ステークホルダーのニーズを引き出し、検証可能な要件として定義・管理するための活動の総称
プロジェクトに悪影響を与える可能性のある事象を事前に特定・分析・対処する活動
高凝集・低結合・SOLID原則など、変更コストを低く保つための設計の核心的考え方
ウォーターフォール・アジャイル・スパイラルなど、開発活動の順序・構造を定めるフレームワークの比較
ソフトウェアの「品質」を多面的に捉えるための体系的な枠組み。ISO/IEC 25010 では品質を2つの視点で定義する。
テストピラミッド・TDD・ブラック/ホワイトボックステストなど、欠陥を早く安く発見するための体系的アプローチ
トレーサビリティとは、ソフトウェア開発の成果物間の対応関係を追跡可能にする仕組み。「要件 → 設計 → 実装 → テスト」の各工程で生まれる成果物が、どの要件を実現しているかを双方向に辿れる状態を指す。
ドメインの制約・状態・ルールを型システムで表現し、不正な状態をコンパイル時に防ぐ設計手法
ビジネス上の意味を持つ値を専用クラスで表現し、制約・操作を型に閉じ込める設計パターン
ドメイン概念をプリミティブ型で直接表現し続け、業務制約・操作がコード中に散らばるアンチパターン
DBスキーマで状態を複数フラグ列や汎用コードで表現し、不正な状態の組み合わせを許容してしまう設計の問題
ログに記録するのはメタデータ（誰が・いつ・どこで・どのくらい・結果は何か）に限定し、コンテンツ（ユーザー入力・LLMの出力・ファイルの中身）を含めないアプローチ。
リリース可否判定とは、ソフトウェアを本番環境に展開（リリース）してよいかを、事前に定義した基準と実績を照合して意思決定するプロセス。「品質目標を達成しているか」だけでなく「リリース後の準備が整っているか」まで含めて判断する。
ソフトウェア開発におけるレビューとは、成果物（要件書・設計書・コード・テスト計画等）を人間の目で検査し、欠陥・問題・改善点を発見する品質確保活動。レビュー戦略は「何を・誰が・どのように・なぜレビューするか」を体系的に設計すること。
シフトレフト（Shift Left）とは、品質確保活動をソフトウェア開発ライフサイクルの早い工程（「左」）に移動させるアプローチ。従来の「実装後にテストで品質を確保する」モデルから、「要件・設計段階から品質を作り込む」モデルへの転換。
アプリケーションサービスをオーケストレーターに徹させ、業務ロジックを持たせないことでユースケースを読みやすく保つパターン
ソフトウェアをドメイン・アプリ・インフラの3層に分離し、業務ロジックを技術的詳細から独立させるアーキテクチャパターン
ブログ記事・Docsの作成からCloudflare Pagesへのデプロイまでの手順
サービス層を薄いオーケストレーターに保ち、業務ロジックはそのデータを持つドメインオブジェクトに集める行動規範
Astroコンポーネント・Content Collections・レイアウトなど、このブログで使う構文のまとめ
見積もりは予測であり、不確実性の範囲を示した上でコミットメントと区別する
ログに記録するのは以下のメタデータのみとする：
ドメインオブジェクト設計時、存在してはいけない状態をコードで表現できないようにする設計規範
プロセスを「従うもの」ではなく「コンテキストに合わせて調整するもの」として扱う
品質指標を設定するときは「この数値を見れば判断できる」を基準に設計する：
曖昧な言葉を使わず、検証可能な条件として要件を定義する
レビューを実施する際は以下を守る：
プロジェクトリスク管理において以下を守る：
リスクリストの各項目に担当者を割り当て、「全員の問題」を「誰かの問題でもない問題」にしない
DBやAPI設計より先に業務の言葉・ルール・概念を整理し、技術的都合でドメインモデルが歪むことを防ぐ行動規範
業務の言葉・ルールからドメインオブジェクトとその関係を発見し、設計の出発点となるモデルを作る実践手順
読書中に出会った概念を、チームで使えるreference/rules/skillsに変換する実践的な手順
自社ロゴ・課題・あるべき状態を盛り込んだスライドをGensparkで生成する手順と、その裏側のアーキテクチャを多方面から解説
既存コードを壊さずにドメインオブジェクト設計へ移行するための段階的な手順
不具合・インシデントの表面的な修正に留まらず、根本原因を特定し、同種の問題が組織全体で再発しないようにする。
テストの品質はテスト計画で決まる。テスト計画を「やること一覧」ではなく、「品質目標を達成するための戦略文書」として作成するスキルを身につける。