author
authorDisplayName
Yujiro Shin
category
AI
PM
mainImage
published
published
publishedAt
Feb 24, 2026
slug
pm-sdd
tags
AI
NEWT
Product Management
こんにちは、shin です。令和トラベルでプロダクトマネージャーをやっています。
最近は、旅行・観光業に特化したAIエージェントチャット「NEWT Chat（ニュートチャット）」というサービスにもPMとして関わっています。
そこで、私たちがプロダクト開発に取り入れている仕様駆動開発（SDD）について、PMの視点で紹介してみようと思います。
1. なぜこの話を書くのか
AIコーディングの普及もあり、SDD自体の解説やエンジニア視点の実践記事は増えてきました。
一方で、SDDのプロセスの中でPMがどう関わるかは、まとまった情報があまり見当たりませんでした。たとえば次のような点です。
- PMはSDDにどう関わるのか
- PMはどこまで書くのか（どこから先は書かないのか）
- 要件と実装の「接続」がどうやって成立するのか
実践されているチームはあると思いますが、まだあまり発信がなされていないような状況かと思います。私たちが取り入れる中でも試行錯誤しながら進めているので、今回はその発信をしてみようと思います。
（私たちのやり方がベストだとも思っていないため、SDDでプロダクト開発を進めている場合は、そのやり方をぜひ教えてほしいです！）
2. SDD（仕様駆動開発）とは
Spec Driven Development (SDD) とは、一言で言えば 「コードを書く前に、まず仕様を完成させ、その仕様を中心に開発を進める手法」です。
AWSのKiroの登場もあり、より一般的に知られるようになったと思います（AWSの解説記事）。
SDD自体の詳しい解説は他記事に譲り、ここでは運用の話に集中します。
3. 前提: プロダクト/チーム状況
プロダクトやチーム状況によって適した開発スタイルは変わります。
そのため、ここでは私たちの前提条件を簡単に共有します。
プロダクト状況
- NEWT Chatは、旅行・サービス業界に特化したAIチャットサービス
- 昨年の12月にリリースされたばかり
- AIドリブンな開発がすでに本格化している後に開始されたプロジェクト
- iOSやAndroidといったモバイルアプリへの対応はなく、Webアプリケーションのみ
- 主に存在するのは3つのプロダクト
- ウィジェット: 導入企業様に埋め込まれるチャットウィジェット
- ダッシュボード: 導入企業様にてNEWT Chatの設定や情報を確認・管理するための管理サイト
- アドミン: 私たちがNEWT Chatのサービス状況や設定を確認・管理するための管理サイト
チーム状況
- 専任PM: 1人（私）
- エンジニア: 2人
- この2人がPMの業務も部分的に兼任
- デザイナー: 0人
このような状況のため、基本的な仕様作成は私で行いつつ、エンジニア2人にもレビューをしてもらい議論のうえ仕様を決めていっています。
4. SDDの導入背景
では、なぜSDDを導入したのか。もともとの課題は大きく2つでした。
期待挙動が不明確
- AIコーディングで機能開発されるものの、挙動の認識ズレがおきる
- 仕様がSlack/口頭/Notionの断片に散らばり、「結論としてどうなっているか？」が追えない
- PMとエンジニアで、同じ言葉でも想定している挙動がズレる
仕様とAIによる実装の接続性の悪さ
- Notionなどで仕様を書くと、MCPなどで連携できるとはいえコードベースと遠いためそのままAIに渡しにくい
- 仕様を書くときも、コードベースを参照しにくく、現状の実装を踏まえてAIに書かせにくい
これらを踏まえたときに、SDDが解決策になるのではと考え、導入してみました。
cc-sdd の採用
SDDを利用するためのツールはいくつかあるのですが、私たちは
cc-sdd を採用しました。
cc-sdd は、Kiro-styleのSDDワークフローを、コマンドやテンプレでチーム運用に落とし込むためのツールです。（gotalab/cc-sdd）SDD自体の流れはどのツールでも大きくは変わらないと思いますが、私たちは以下の理由で
cc-sdd を選びました。- カスタマイズ性: カスタマイズでテンプレートを変更したり、独自のコマンドも取り込みやすい
- 日本語リソース: 公式でも日本語のリソースが用意されている
- 必要最低限: ワークフローの型が必要以上固まっていることがなく、チーム開発のなかでも採用しやすい
spec-workflow-mcp も試しましたが、私たちの運用では専用のダッシュボードやMCPであるメリットが相対的に小さかったため見送りました。
5. SDDの基本フロー
では実際のSDDの開発フローについて見てみましょう。
主には4つのフェーズに分かれます。
- Requirements: 要件定義フェーズ
- Design: システムデザインフェーズ
- Tasks: 開発の具体タスクに分解するフェーズ
- Implementation: 分解されたタスクをもとに実装するフェーズ
cc-sddではこの1〜3のフェーズで、それぞれ
requirements.md / design.md / tasks.md が生成されます。フェーズごとに人がレビューを挟むことで、AI実装でも「狙いからズレにくい」形を作ります。6. いつ SDDプロセス を使い、いつ使わないか
ちなみに、SDDは段階を踏む分、よりしっかりしたフローになります。そのため、全てをこのフローでやること自体は必須にしていません。
具体的には、軽微な修正（小さなバグ修正、FEだけの小変更など）ではSDDを使いません。
この規模だと、SDDを挟まなくてもAI実装が大きくブレにくいためです。こういった場合はDevinや、直接AIに修正させて進めます。それ以外（認識齟齬が起きやすい・例外ケースが多い・仕様が散らばりがち）な開発では、SDDを使うようにしています。
7. SDDの中でのPMの関わり方
では実際にどのようにこのSDDのプロセスのなかでPM（私）が動いているかをみていきます。
（PMの定義も色々なので1サンプルとして受け止めてください！）
Step 1. requirementsを作成 (PM)
まずは私が cc-sdd で用意されているコマンド (
/spec-init と /spec-requirements) をどんな機能をつくりたいかの情報をわたしながら発動します。そうすることでソースコードや cc-sdd の仕組みのなかで管理される steering doc（プロジェクトの技術スタックや全体設計方針を記したドキュメント）をもとに requirements.md が生成されます。
これをもとに、私が自分の手元（Cursor）で内容をレビューし、仕様（期待挙動）について決めていきます。手元でのレビューが完了したら、これを要件用のブランチを切ったうえでプルリクエストを出します。
Step 2. requirementsのレビュー (PM/Engineer)
先ほどの1のステップで作ったプルリクエストをGitHub上でエンジニア2名にレビューしてもらいます。議論のうえ必要に応じて修正し、requirementsとして確定させます。
Step 3. design/task/implementation の実施 (Engineer)
ここまでくると、How（どう実装するか）というポイントになってくるため、エンジニアにバトンタッチします。エンジニアが確定した要件をもとに design/tasks に進み、レビュー後に問題なければAIで実装していきます。
8. 良い点
ここからは、実際に運用してみて良かった点です。
AIで仕様作成が精度高く行える
ステップ1で生成される
requirements の精度が高いです。
コードベースや steering doc を参照して作られるため、機能にもよりますが体感では 60〜80%はほぼそのまま採用できる感覚があります。
（この精度は、まだNEWT Chatが比較的小さなコードベースのため精度があがりやすいというのもあると思います。）
ちなみに、最初にAIに渡す作りたい機能の情報は、その機能の複雑さにあわせています。比較的小さいものはコマンド発動時に「XXXをXXXするための機能をつくりたいです」など簡単に渡しています。大きいものの場合は場合によって、Notionで事前にまとめたおおまかな要件や背景情報をコマンド発動時にあわせて渡します。AIはこれをNotion MCP経由で中身を取得したうえで仕様作成を行うことができます。
仕様がコードの近くにあり、更新・参照がラク
仕様を作成/調整する際にソースコードを参照させることが簡単なのは大きなメリットです。
（厳密にはSDDのプロセスのメリットというより、ソースコードをコンテキストにいれて仕様作成できるメリットではありますが）
上述の仕様作成のときにも言えるのですが、一度作成された仕様についても現状の仕様がどうなっているかの確認や、それをもとにした仕様修正がサクッとできるのも非常に便利です。モザイクの内容が多くなってしまいますが、以下の画像のように「XXXも対応したほうがよいのでは？」というような問いかけを仕様作成中に投げ込んだ際も、一般論ではなく既に実装されている内容を踏まえて回答してくれます。
テンプレに沿って詳細度の高い仕様が書ける
仕様を書く際に、テンプレートの形式をもとに仕様が書かれます。そして、EARS形式で書かれるのがデフォルトにもなっているため、システム的に期待値のわかりやすい記述になります。
（※EARS記法とは要求仕様を自然言語で一貫して表現するための記法です。参考記事）
この形式は厳密である分、全て書き出すのが大変ではありますが、AIが作成してくれるため大きな負担なく作成できます。この仕様をレビューすることで、AIがコーディングする際の認識のズレを小さくすることができます。
9. 工夫していること
ここまではデフォルトでのcc-sddのフローについての話でしたが、実際にカスタマイズをしてどのような工夫をしているかについて書いてみます。
AIによる仕様レビュー
仕様を自分で確認/修正を行って完成したものについて、チームにレビューしてもらう前に
/validate-requirements というコマンドを独自作成し、これでAIに仕様をレビューしてもらうようにしています。これはUX/ビジネス/コミュニケーション観点での漏れや曖昧さ、既存仕様との重複などを指摘してくれます。
指摘してくれた事項がすべて的を射ているわけではありませんが、5つの中で2つくらいの指摘は実際にそれを受けて仕様を追記修正している気がします。本来は拾えなかったことが拾えたり、自分の思い込みだった部分を客観的に確認できるため、役に立っています。
ポイントはAI仕様作成直後に発動させるのではなく、人の確認/修正を挟んだあとに発動することです。それは、もちろん自分が追加修正したものについてレビューをしてもらう必要があるためです。
それに加え、そもそも自分が一度仕様を深く考える前ではAIとも対等に会話ができません。
そういう意味でも、まずは自分で生成された仕様に向き合い、自分としてのアウトプットとして完成させたうえで、AIレビューを受けることが大事だと今は感じます。
モックデータを利用したFEのみでのプロトタイプ作成
SDDはビジネスロジックを整理するためには非常に優れたプロセスだと感じます。一方で、実際のUIについて細かく自然言語で書き起こすのは現実的ではありません。そのため、作成した
requirements.mdのみではUIの仕様について細かく定義することはできません。本来はこの部分はデザイナーがFigmaにUIを作ってもらうなどのプロセスになりますが、私たちにはデザイナーのアサインもありません。そこで、requirementsとは別にプロトタイプを作成することにしてみました。
とはいえ「UIの動きを見たいだけ」なのに、BEやDBまで触るとマイグレーション・テストデータ投入・API実装などのコストが一気に上がります。さらにこの段階は、design/tasksのレビュー前に行うため、BEを作っても無駄になりがちです。
そこで今は、モックデータ付きでFEだけ先に実装してプロトタイプを作る運用を試しています（モックデータもAIが仕様から用意します）。私たちはこれをcc-sddのカスタムコマンドとして、
/spec-prototype というものを作成しました。これは「UIの挙動を確認する」という目的のみに特化させているものです。
このコマンドが発動されると、cc-sddの中で作成されたspecファイル（requirements.md）を参照し、BEの実装はせずに、モックデータとともにFEの実装のみを一気に行ってくれます。そして、作成されたものを私がCursor上でレビューしながら、UIを整えます。以下のGIFはウェルカムメッセージやデフォルトのよくある質問を多言語で設定できる機能のデモです。以下のように翻訳中の表示など動きのあるアニメーションやインタラクションを伴うものですが、BEの実装は一切なくきれいにみれます。
そこで出来上がったものは、要件向けに作成したプルリクエストとは別でプロトタイプ用にドラフトPRという形で作成します。私たちはVercelの機能を用いて、プルリクエストごとにプレビュー環境を出すようにしているので、このUIの確認もスムーズに行えます。モックデータ前提なので、誰が開いてもすぐ触れて確認しやすいのも助かっています。（なおこのドラフトPRはあくまでUI確認のprototypeなので、必ずしもこのままエンジニアが引き継いで開発することは想定していません。）
今後、画面遷移を伴うような大きめの機能になってくると、モックデータだけだとうまくいかない可能性はあります。それでも、おおよその機能においては充分にプロトタイプとしてワークしそうな気はしています。まだ試行段階ですが、動くプロトタイプをPM側で用意できるのは今のところ良い感触です。
10. 今後取り組んでいきたい改善
とはいえ、もちろんこのプロセスも全然完璧ではありません。最後に今後取り組んでいきたい改善についてもお話できればと思います。
要件テンプレのフォーマットの拡張
EARS形式で記載されるのはシステムの動きとしては各処理の期待値が明確です。
一方で、私もこれまで仕様書をたくさん書いてきましたが、全てをEARS形式で記載したことはありません。
- 新しい概念に名前をつけて用語定義を記載する
- 表形式で情報を整理する
- スクリーンショットとともにどこになにを表示するかをマッピングする
今後SDDでの仕様作成がより本格化していくなかでは、こういったフォーマットについても拡張させていく必要がでるのではないかと思います。一方で、フォーマットの自由度があがることでAIの出力精度がさがったり、AIが読みにくくなる懸念もあります。このあたりをバランスを取りながら、よりよい要件テンプレを模索していくことになるだろうなと考えています。
requirements ↔ design の行き来
このフローは requirements → design という一方通行のフローを想定しています。
が、やはりシステム開発である以上、どう実装するかのHowに落とし込むことで、仕様を技術的に妥協するなどすることはあります。そのケースをこのフローはあまり想定できていません。今、それが発生した場合は、クリティカルな要件でもなければそのままrequirementsを書き換えることは必須にはせずにそのまま実装していってもらう形にしています。
しっかりやるのであれば、designフェーズで要件を少し変えることになった場合は、requirementsを修正してまたレビューをするのがよいとは思います。一方で、プロセスとして不必要に重くなってしまうとも感じるためそうはしていません。しかし、このあたりもこのプロセスがより本格化すると課題になりそうな点かなと思います。
AIの自律性向上
AIの精度を高めて、より自律性をあげていくこともやりたいです。今でもそれなりの精度にはなっていますが、仕様作成・プロトタイプ作成ともに、人のレビューでの手戻りをどれだけ減らせるかはチャレンジしたいです。そのためにも、rule、skillといったようなファイルの内容をAIとのセッションのあとで更新して育てていくことをよりやっていきたいです。
また、Claude Code の agent team などよりAIの自律性の高い新しい仕組みは次々でてきています。AIの自律性が高まっていくなかで、プロダクト開発というものをどこまでAIに任せるかは、これまでのやり方にとらわれずに考えていく必要があると思います。既存のやり方に固執せずにAIの自律性に対して寛容でありたいと思いつつも、とはいえ目の前できちんと安定的に価値のある機能をつくることをバランシングする重要性を強く感じる今日この頃です。
11. まとめ
LLMが進化するなかで「どうLLMを使って効率的に高品質の仕様作成を、再現性もっておこなえるようにするか？」という点は私も長く模索していました。
完成形ではありませんが、現時点では「仕様→実装」の接続を作り、ズレを減らすうえでしっくりくる形を作れた感覚があります。プロダクトがまだ新しく小さいことによるやりやすさはありつつ、それでもAIにかなりエンパワーされていると感じます。
一方で、まだ改善すべきところや悩む部分も多いので、PMとしてAIで仕様作成をしている/してみた知見がある方はぜひお話させてください！
最後に、cc-sdd を作成してくださっている方々に改めて感謝をお伝えしたいです！
本記事にもある通り、cc-sdd には非常にお世話になっています。OSSとしてこのようなツールを作っていただき、本当にありがとうございます！
令和トラベルでは一緒に働く仲間を募集しています
この記事を読んで会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！お気軽にお問い合わせください！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。
そのほか、毎月開催している技術発信イベントについては、connpass にてメンバー登録して最新情報をお見逃しなく！
それでは次回のブログもお楽しみに！Have a nice trip ✈️
