はじめに
NTTドコモ データプラットフォーム部の外山です。私たちのミッションは、AIとデータの力を業務オペレーションに組み込み、社員や組織のパフォーマンスを高めることです。
分析結果をレポートとして届けるだけでは、現場の行動は変わりません。データを、日々の業務で実際に使えるプロダクトへ変換する必要があります。そこで私たちは、利用者一人ひとりが抱える課題を解決する内製データプロダクト「Pochi」※を開発してきました。Streamlitを活用し、複雑な操作を覚えなくても使える、業務に溶け込むアプリケーションを提供する取り組みです。
2023年に始めたこの取り組みは、2025年度には163アプリの提供により、5,300人（MAU）にまで成長しました。しかしスケールが進むにつれ、「なぜこの機能が存在するのか」が担当者個人の記憶に依存する場面が増えてきました。開発は速く、機能は動き、コードの品質も決して悪くありません。それでも、機能が生まれた理由——Why——だけが少しずつ失われていく。この違和感こそが、本記事で紹介する仕様駆動開発への出発点でした。
ここでは、私たちがなぜ仕様駆動開発に取り組むのか、その背景と目指す未来をご紹介します。
※Pochiは社内の開発コードネームです
Pochi開発の歩み
最初に取り組んだのは、ExcelやPowerPoint、Miroなどを使って業務フローや画面を設計し、人が実装する「プロセス型」の開発です。開発テンプレートを起点にプロセスを整え、開発者と利用者の間に共通言語を生み出したことで、属人性に頼らない安定した品質を実現しました。関係者と認識を合わせながら着実に進められる一方で、設計にも実装にも相応の時間を要していました。
そこで次に取り組んだのが、生成AIとの対話を通じて実装する Vibe Coding です。実現したいことをAIに伝え、生成されたコードを確認しながら修正を重ねることで、コーディング速度は飛躍的に向上しました。試作とフィードバックのサイクルも短くなり、アイデアをすぐに形にできるようになりました。つまり、「実装」という工程そのものは、もはやボトルネックではなくなったのです。
ところが、実装が速くなればなるほど、プロセス型で一度は排除したはずの属人性が、形を変えて戻ってきました。AIと担当者がインタラクティブに開発を進めると、その会話の中に多くの判断が埋め込まれます。「なぜこの機能が必要なのか」「なぜこの方式を選んだのか」といったWhyが暗黙知となり、完成したコードだけを見ても、その背景を読み取れなくなってしまうのです。
Pochi開発で私たちが大切にしてきたのは、技術から考えるのではなく、利用者の課題から考えることです。利用者は、自分たちの業務や課題を最もよく理解しています。一方で、それをアプリケーションとして実装できるとは限りません。逆に開発者は実装できますが、現場の背景や本当に解くべき課題を、最初から理解しているわけではありません。だからこそ私たちは、事業部門と開発部門が一つのチームになり、利用者との対話を重ねながらプロダクトをつくる「協創型」の開発を続けてきました。
この「課題起点の協創プロセス」こそが、Pochi開発のDNAです。そう考えると、Why（文脈）の喪失は、単なる情報の欠落ではありません。それは、プロダクトのコアコンセプトそのものを見失うことを意味します。
だからこそ私たちは、事業上の課題や意思決定を「仕様」として残し、その仕様を起点に設計・実装・テストを一貫して進められる状態をつくるために、仕様駆動開発（Spec-Driven Development：SDD） に取り組んでいます。
コードではなく、仕様を唯一の情報源にする
仕様駆動開発では、仕様を Single Source of Truth（SSoT） として扱います。仕様がマスターであり、コードは仕様をもとに生成・変更されます。
なぜ仕様をマスターに据えるのか。出発点は、Vibe Codingの速さの裏で見えてきた弊害でした。要望をAIに伝えれば、その場でコードが生成される——この速さは確かな進歩です。しかし運用を重ねるほど、「なぜこの機能が必要なのか」という Why（判断根拠）が会話の中にしか残らない ことが問題になりました。判断根拠が対話ログに埋もれると、間違った方向に走り出しても気づきにくくなります。そこで私たちは、要望から直接コードへ飛ぶのではなく、間に「仕様書」という 合意点 を一つ挟むことにしました。仕様書さえ確定していれば、実装がそれを見て動く限り、判断根拠は会話ログではなく仕様書というドキュメントに残り続けます。
ここでいう仕様は、開発前に一度だけ作成して固定する重厚な文書ではありません。利用者との対話や事業上の判断を取り込みながら更新され、設計・実装・テストをつなぐ「生きた情報源」です。
重要なのは、何を実装するかだけでなく、なぜ必要なのか、どのような条件を満たすべきかを、AIと人が共有できる形で残すことです。プロダクトマネージャーにとっても、これは単なるドキュメント整備ではありません。事業上の意図を実装まで届け、変更が発生した際にも判断の軸を失わないための仕組みです。
理想的には、利用者自身がAIと対話しながら要件を整理できるかもしれません。しかし実際の開発では、利用者と開発者が同一人物とは限りません。事業部門へのヒアリングを開発担当者が行い、その議事録やPRD（プロダクト要求仕様書）をもとに仕様を作成するケースも多くあります。そこで私たちは、対話形式だけでなく、議事録や既存資料も入力として利用できるようにしています。AIが資料から要件候補を抽出し、不足している情報を質問しながら、仕様と計画へと変換していく形です。
さらに、実装だけでなくテストも仕様起点にします。実装されたコードからテストを考えると、実装者の思い込みがそのままテストへ持ち込まれかねません。仕様からテスト条件やテストデータを生成し、そのテストを満たすように実装することで、開発プロセス全体をSSoTにつなげます。この仕組みの詳細は、次回の実践編でお伝えします。
その先に目指す「開発を意識しない開発」
仕様駆動開発は、私たちにとってゴールではありません。
目指しているのは、業務課題の発見から要件整理、設計、開発、テスト、保守まで、プロダクトライフサイクル全体をAIが支援する「AI駆動開発」の世界です。
業務課題を最もよく知る人が、「開発」を強く意識することなく、課題解決に必要なプロダクトを形にできる。人を何人も介して要望を伝達しなくても、業務上の意図が仕様として整理され、実装とテストへつながっていく。そんな状態です。
たとえば、これまで事業部門の担当者が要望を伝え、開発者がヒアリングし、議事録やPRDを起こし、仕様に落とし込む——という何段階もの伝達を経ていたプロセスが、担当者自身がAIと対話しながら課題を整理するだけで、その意図が仕様・実装・テストまで一気通貫でつながる。そうした世界を私たちは目指しています。
これは、開発者が不要になるという意味ではありません。開発者の役割は、すべてのコードを自ら書くことから、AIが安全かつ正確に開発できる環境を整えることへと変わっていくと考えています。具体的には、AIに与えるコンテキスト、制約、ツール、評価方法を設計し、継続的に改善する役割です。
仕様は、事業部門と開発部門の間に置かれた納品物ではなく、人とAIが協働するための インターフェース になります。
次回は、SDDを支えるAgentとSkillの実装へ
ここまで、私たちがなぜ仕様駆動開発に取り組むのか、その背景と目指す未来を紹介しました。次のブログでは、この考え方を実際の開発プロセスへ落とし込むために構築した AgentとSkill を取り上げます。この記事で取り上げた「Whyが会話に埋もれる」問題を、spec.jsonという一つのファイルにWhyを凍結することでどう解いたのか。そして、速さと安全をどう両立させたのか——実装・テスト・Git操作それぞれの"止めどころ"を、具体的な設計とともにお伝えします。
仕様駆動開発は、仕様書を増やす取り組みではありません。生成AIによってコードを書く速度が大きく変わった今、私たちは「何を、なぜつくるのか」を扱う仕組みそのものを、再設計しようとしています。
