--- blogpost: true title: 仕様駆動開発 実践入門 date: 2026-04-13 tags: - 日記 - 書籍メモ --- # 仕様駆動開発 実践入門 - 環境構築やGit/GitHubなど、仕様駆動開発に入る前の説明が全体の1/4ほどある。 - おすすめの壁打ちは「AIに質問させて、人間が答える」こと。 - Issueで合意形成を行い、Pull Requestで承認する運用を取っている。プロジェクトの規模に応じてIssueテンプレートの内容は変わるが、以下の内容で問題ないように思える。 ```md ## Decision ## 背景 （なぜこの議題が必要なのか） ## 提案内容 （何を決めたいのか） ## 影響範囲 （どのチーム・機能に影響するか） ## 関係者 （誰の意見が必要か） ## 決定期限 （いつまでに決めるか） ## 判断基準 （何を基準に決めるか） ``` - 4つの原則を強く主張している。 1. 仕様は生きたドキュメント 2. 仕様は信頼できる唯一の情報源 3. 仕様は変更と反復が前提 4. AIでコストを抑える - これらは相互に関係している。 - `1. 仕様は生きたドキュメント` が、`2. 仕様は信頼できる唯一の情報源` として機能する基盤を作る。 - `2. 仕様は信頼できる唯一の情報源` が、`3. 仕様は変更と反復が前提` を安全に進められる環境を提供する。 - `3. 仕様は変更と反復が前提` が、`1. 仕様は生きたドキュメント` の必要性を生み出す。 - `4. AIでコストを抑える` が、ほかの3つの原則を支える。 - `1. 仕様は生きたドキュメント` の実現コストを下げる。 - `2. 仕様は信頼できる唯一の情報源` として機能させるために、仕様をAIにも読める形式にする。 - `3. 仕様は変更と反復が前提` における影響範囲の分析を支援する。 - AIは支援者であり、最終判断は人間が行う。 - タスクの粒度は、レビューが30分以内に終わる大きさを目安にする。 - 経営層やリーダー層が、自ら仕様を書くことを推奨している。 - 挙げられていた課題の1つに「仕様を書くスキルがない」というものがあった。確かにその通りだと思った。個人のスキル差が顕著に出る部分でもあると思う。どうやってスキルアップしていくかを、今後考えていくことが大事だと思った。 - 仕様の書き方ガイドの作成。 ```md # 仕様の書き方ガイド ## 基本原則 - 仕様は「なぜ」と「何を」を明確にする。「どうやって」はコードに任せる - 1つの仕様は、レビューが30分以内に終わる分量にする - 専門用語は用語集で定義し、リンクする ## 構成例 1. 目的: この機能がなぜ必要なのか 2. 受入基準: どうなれば完成とみなすのか 3. 制約条件: 技術的、ビジネス的な制約 4. 参考情報: 関連する仕様や外部リンク ``` - 練習用リポジトリ: [https://github.com/elvezjp/SDD](https://github.com/elvezjp/SDD)