仕様駆動開発 実践入門

＜3/30新刊＞『仕様駆動開発 実践入門』AIが実現する「仕様駆動開発」によって、仕様とコードが常に同期し、仕様とコードが最適なバランスを保てるようになります。その基本から実践方法まで、じっくり解説します。https://bookplus.nikkei.com/atcl/catalog/26/03/13/02529/

• 環境構築やGit/GitHubなど、仕様駆動開発に入る前の説明が全体の1/4ほどある。

• おすすめの壁打ちは「AIに質問させて、人間が答える」こと。

• Issueで合意形成を行い、Pull Requestで承認する運用を取っている。プロジェクトの規模に応じてIssueテンプレートの内容は変わるが、以下の内容で問題ないように思える。

  ## Decision
  
  ## 背景
  
  （なぜこの議題が必要なのか）
  
  ## 提案内容
  
  （何を決めたいのか）
  
  ## 影響範囲
  
  （どのチーム・機能に影響するか）
  
  ## 関係者
  
  （誰の意見が必要か）
  
  ## 決定期限
  
  （いつまでに決めるか）
  
  ## 判断基準
  
  （何を基準に決めるか）
  

• 4つの原則を強く主張している。

  1. 仕様は生きたドキュメント

  2. 仕様は信頼できる唯一の情報源

  3. 仕様は変更と反復が前提

  4. AIでコストを抑える

• これらは相互に関係している。

  • 1. 仕様は生きたドキュメント が、2. 仕様は信頼できる唯一の情報源 として機能する基盤を作る。

  • 2. 仕様は信頼できる唯一の情報源 が、3. 仕様は変更と反復が前提 を安全に進められる環境を提供する。

  • 3. 仕様は変更と反復が前提 が、1. 仕様は生きたドキュメント の必要性を生み出す。

  • 4. AIでコストを抑える が、ほかの3つの原則を支える。

    • 1. 仕様は生きたドキュメント の実現コストを下げる。

    • 2. 仕様は信頼できる唯一の情報源 として機能させるために、仕様をAIにも読める形式にする。

    • 3. 仕様は変更と反復が前提 における影響範囲の分析を支援する。

• AIは支援者であり、最終判断は人間が行う。

• タスクの粒度は、レビューが30分以内に終わる大きさを目安にする。

• 経営層やリーダー層が、自ら仕様を書くことを推奨している。

• 挙げられていた課題の1つに「仕様を書くスキルがない」というものがあった。確かにその通りだと思った。個人のスキル差が顕著に出る部分でもあると思う。どうやってスキルアップしていくかを、今後考えていくことが大事だと思った。

• 仕様の書き方ガイドの作成。

  # 仕様の書き方ガイド
  
  ## 基本原則
  - 仕様は「なぜ」と「何を」を明確にする。「どうやって」はコードに任せる
  - 1つの仕様は、レビューが30分以内に終わる分量にする
  - 専門用語は用語集で定義し、リンクする
  
  ## 構成例
  1. 目的: この機能がなぜ必要なのか
  2. 受入基準: どうなれば完成とみなすのか
  3. 制約条件: 技術的、ビジネス的な制約
  4. 参考情報: 関連する仕様や外部リンク
  

• 練習用リポジトリ: https://github.com/elvezjp/SDD

• 日記, 書籍メモ