仕様・実装共進化

仕様と実装を高速に往復しながら、フィードバックループを回し続ける開発アプローチ。バイブコーディングでも仕様駆動開発でもない第三の道。

核心的洞察

コーディングエージェントの本質は、「仕様を先に確定する」ことではなく、**「仕様と実装を高速に往復できる」**こと。

従来は仕様変更から実装更新まで時間がかかったため、「仕様を先に確定する」ことが重視された。しかし今は、仕様→実装の変換コストが劇的に低下した。だからこそ、何度でも往復できる。

ワークフロー

  1. 最小限の仕様から始める - 完璧を目指さない
  2. コードを生成させる - AIに実装させる
  3. 実装を読み、理解する - コードが何をしているか把握する
  4. 問題や改善点を発見する - 実装から学ぶ
  5. 仕様を更新する - 学びを仕様に反映
  6. 再実装 - 改善されたコードを生成
  7. 繰り返し

具体例:認証機能の実装

従来のウォーターフォール的アプローチ

  1. 認証の仕様をすべて確定(OAuth 2.0、JWT、リフレッシュトークン...)
  2. 詳細な設計書を作成
  3. 実装
  4. 実装段階で問題が噴出
  5. 仕様に戻って修正、再実装

仕様・実装共進化

  1. 最小限の仕様(「メールとパスワードでログイン」)
  2. 実装生成
  3. コードを見て「トークンの保存はlocalStorageか。XSS対策でhttpOnlyクッキーにすべきでは?」と気づく
  4. 仕様更新、再実装
  5. 「リフレッシュトークンは?」という新たな疑問
  6. 仕様追加、実装、検証...

高速サイクルを回すことで、仕様とコードが共進化する。

原則

実装からのフィードバックが不可欠

実際に動くコードレベルでなければ理解できない:

これらからのフィードバックがなければ、良い仕様は書けない。

コードこそが真実

コンテキストウィンドウの制約下では、仕様書とコード両方をAIに読ませるのは非効率。

コードに十分な構造と意図が表現されていれば、AIはコードを読むことでユビキタス言語やドメインモデルを理解できる。ドキュメントは補助的存在。

DDDとの親和性

Domain-Driven Designが強調する「コードとモデルの深い結びつき」と整合する。仕様とコードが分離するのではなく、相互に影響を与えながら洗練されていく。

変わったこと vs 変わらないこと

変わったこと

変わらないこと

認知的距離との関係

高速サイクルで仕様と実装を往復することは、較正ループを高頻度で回すことに等しい。各往復で仕様側のスキーマと実装側のスキーマの認知的距離が縮小し、共進化が進む。変換コストの劇的な低下はループ頻度の上昇を意味し、距離の管理がより精密になる。

関連

参照