仕様書駆動開発を​やってみた

はじめに

AIを​使った​コーディングは​便利です。しかし​一方で、​​「思った​通りの​コードが​生成されない」​「仕様を​伝えるのに​時間が​かかる」と​いった​課題を​抱える​人は​少なく​ありません。​
私たちの​チームでも、​Figma to Code の​開発工程で​ AI を​活用しようと​試みる​中で、​AIの​回答に​振り回される​場面が​多々​ありました。​

​そのため、​今回、​従来の​開発プロセスを​「仕様書駆動開発​（仕様ベースで​AIと​対話する​開発）」に​切り​替え、​コーディングや​テストの​一部を​AIに​委ねる​実験を​行いました。​
この取り組みの結果として、​手戻りや​認識齟齬を​減らし、​スピードアップに​つながる​手応えを​得る​ことができました。​

本記事では、​この​実験の​背景と​手順、​仕様書やPBIの​作り方、​実際に​得られた​効果や​気づきなどを​紹介します。

なぜ仕様書駆動開発に​取り組んだの​か

Figma to Code の​現場で​起きていた​課題

従来の​開発プロセスは、​Figmaで画面​デザイン作成し、プラグインを使って​Reactコンポーネントに変換後、手で実装する流れでした。
設計書などは作成せず、画面デザインから設計の意図をくみ取り、手で実装をしていましたがデザインから受け取れる機能仕様は実装者に​よって​解釈が​ばらつく、​レビュー時に​意図の​すり合わせが​発生する、と​いった​問題が​日常的に​起きていました。​

AI活用の​限界と​「仕様の​伝え方」の​問題

また、​AIを​活用し始めた​当初は、​プロンプトでAIに細かく仕様を​説明しており、​伝達コストが​高いと​いう​課題が​残っていました。​結果と​して、​AIの​回答を​何度も​修正・再生成する​手戻りが​発生してしまっていました。​

AIは​プロンプトで​与えられた​情報に​忠実に​従います。​逆に​言えば、​仕様や​制約が​曖昧なままでは、​出力も​曖昧に​なります。​
つまり、​「仕様を​明文化せずに​AIに​頼む」と​いう​状態は、​人に​“なんとなく​伝える​”のと​同じであり、​AIの​潜在能力を​活かしきれていなかったのです。​

実験の​概要（AIへの委譲範囲）

従来​（AsIs）の​プロセス

従来は、
　「デザイン ⇒ React取り込み ⇒ 実装 ⇒ テスト ⇒ レビュー」
と​いう​流れで、​仕様書は​存在しないか、​レビュー時に​口頭補足で​済ませる​ケースが​多い​ものでした。​

今回​（Tobe）の​プロセスと​AIへの​委譲範囲

今回の​検証では、

という仮説を立てて作業を行いました。

まずは準備として、今まで作成してきたコードから「共通仕様」や「指示書・ルール」をリバースエンジニアリングでAIに作成してもらうことをしました。
その上で、作成したい画面や機能仕様をAIにプロンプトで伝え、補足情報として共通仕様や指示書をインプットすることで、アウトプットの精度を均一化するようにしました

共通仕様・ルールの​整備

事前に準備した「共通仕様・ルール」であったり、AIに依頼するときのインプットについて、もう少し、詳しく説明します。

AIに既存のコードからリバースエンジニアリングしてもらった資料として以下のものがあります。

人がプロンプトで情報を与えて、AIに清書してもらった資料としては以下があります。

これらを​基本情報としてAIに渡すことで、アウトプットの精度が均一になり、​​プロンプトに​長い​前提条件を​毎回​書く​必要が​なくなりました。​

タスク実行ルール（PBIの作り方）についても参考として記載しておきます。

仕様駆動でAIに作業を任せる手順

PBIの作成

AIとアジャイル開発を行っていくために、作業の基準となるPBIを作っていきます。
PBIは以下の章立てです。

ユースケースは人が手で記載し、残りの機能要件、受入条件、計画はAIに書いてもらうことにしました。
人のユースケース記載が終わるとこのような感じになります。

​

プロンプトを書いてAIに依頼

次はプロンプト作成ですが、ここまで準備ができているとプロンプトはほとんど指示は不要でテンプレートレベルのものを毎回記載するだけで済みます。

​

まずはPBIの確認

まずは、AIが作ってくれたPBIの内容から、想定した計画やコードを作ってもらえるか？を確認します。間違っている箇所があれば指摘して直してもらいますが、それほどやり取りは発生しません。

作成してもらったPBI（参考）

以下はAIに作成してもらったPBIの一部です。
人がPBIとして作成する完了条件などより細かく、機能仕様として記載してもらっているので、テスト工程でのテストケース作成でも活躍してくれます。

あとは計画に沿って・・・

記事が長くなってしまうので割愛させてもらいますが、ここまでくれば計画に沿ってほぼ想定したコードが生成されます。
(＾ω＾;).｡oO（コメントとかも入れて人が書いたコードより綺麗だったりする）

実践してみて​得られた​効果と​気づき

スピード面の​変化​（人力開発との​比較）

チームの​主観では​ありますが、​「人の手で​開発した​場合と​比べて​早いと​思う」と​いう​声が​多く​上がりました。​
特に、​PBIや​仕様書の​入力が​整っていると、​AIの​作業スピードは​圧倒的です。従来の開発スタイルの​情報を​一度​構造化してしまえば、​繰り返し​使える​点も​大きな​利点でした。​

手戻り削減と​認識合わせの​しやすさ

仕様書を​起点とした​ことで、​「意図が​伝わっていない」​「追加の​説明が​必要」と​いった​やりとりが​減少しました。​
生成された結果をレビュー時も、​仕様と​実装の​差分を​見れば​よいため、​確認時間が​短縮されました。​

まとめ──AIに​丸投げしない​“進め方”の​重要性

結論として、AI開発を効率化する鍵は、AIに仕事を丸投げすることではありません。
進め方のルールや合意ポイントを事前に整備し、仕様書を軸に開発を進めることで、AIを「チームの一員」としてコントロールできることが実践できました。

まずは小さな機能から、PBIと仕様書テンプレートを作ってAIに渡してみる。
それだけでも、対話コストの削減や開発のスピードアップを実感できるはずです。