現在参画しているプロジェクトにおいて、仕様駆動開発ととても相性が良さそうでしたので、調べたことをノートとして整理してみました。
「解釈が違う」「誤っている」などございましたら、コメントにてお願いいたしますm(__)m。
概要
「AI駆動開発」とも言う。
実際にコーディングする前に「仕様(Specification)」として、「何を作るのか」「どんな機能を持たせるか」といった機能要件や、「何を解消させたいか」「どんな要望を叶えたいか」といった解決する課題や前提条件を定義し、これを軸に開発を進める手法を指します。
キーワード
ここでいくつか散見されたキーワードについて文章を起こします。
契約・約束
いくつかの文献では、「仕様」のことを「契約」「約束」と表現しているものが多かったです。
この「契約」や「約束」は自チームのエンジニア同士に限らず、他チームの人間、ビジネスサイドの人間、そして、対AIも指します。
開発を進めるにおいては、「仕様」を開発に関わるステークホルダーとAIとの**契約(前提条件)**として固め、これを軸に設計・製造・テスト・ドキュメント化を行っていきます。
明文化
仕様駆動開発で最も肝となるものです。
せっかく定めた約束事や仕様も関わる人が知っていなければ、全く意味がありません。
仕様駆動開発では、定めた仕様をドキュメントとして目で見える形に起こし、チーム内・他チーム・ビジネスサイド等プロジェクトに関わるステークホルダーへ明確に周知させます。
そして、周知させた約束事を軸に、設計や実装を行っていきます。
これにより実装時の急な仕様変更や出戻りを予防できるだけでなく、ビジネスサイドやクライアントとの打ち合わせの指標とすることができます。
開発フローの例
プロジェクトや企業によってフローはあるが、仕様駆動開発（Spec Driven Development）についてで記載されていたフローに沿っているものが多かったです。
1. 事前準備
開発するシステムや機能の目的・概要・ゴール・制約を整理します。
受託開発を例に出すと、クライアントが何で困っているのか、何の課題を解決したいのかを洗い出します。
2. 要件定義
システムが満たすべき条件や仕様（requirements）を詳細に文書化します。
1で洗い出したものをドキュメントとして目に見える形でまとめます。
3. 設計フェーズ
要件に基づいた設計（設計書やAPIスキーマ、各種仕様書）の作成を行います。
2でまとめた条件や仕様を、システムデザインとしてまとめていきます。
4. 実装計画
設計内容に沿ったタスクや開発計画の整理を行います。
5. 実装・検証
仕様・設計に沿ってコーディング、テスト、ドキュメント化など一連のサイクルを回します。
このプロセスは「コードを書く前に"考える"フェーズ」を明確にし、プロジェクトの"前提"や"根拠"を曖昧にせず残すことで一貫性と品質を高めることができます。
導入のメリット
1.要件の策定や他チームとの擦り合わせが円滑になりやすい。
→軸が定められているため、議論や擦り合わせが脱線した時に軌道修正しやすくなります。
2.技術選定がプロダクト視点から執りやすい。
→仕様を明確にすることで、ユーザーやクライアントからの視点と開発者側の視点を照らし合わせやすくなります。
3.業務のシステム化やリプレイスにおいて、既存のドキュメントやソースコードと照らし合わせる指標となる。
→既存のプロダクトで解決すべき課題が見えてきたり、システム化・リプレイスする範囲が見えてきます。
4.機能を共通化・プラットフォーム化する時の指標となる。
→仕様を明確にすることにより、システムのサービス展開や他システムとの連携を図る際の基準となります。
参考文献
書籍
ネット記事
仕様駆動開発（Spec Driven Development）について
仕様駆動開発は、ウォーターフォールへの回帰ではない。
AI時代の開発手法：仕様駆動開発（SDD）完全ガイド