こんにちは、トレタでVPoEをしている北川です。
この記事はトレタアドベントカレンダー2025 1日目の記事です。
今年のテック業界のトピックといえば、やはりAIを避けて通ることはできませんので、この記事では開発マネージャーとしての自分の日々の業務の中でどのようにAIを活用しているかについて書いていきたいと思います。
開発マネージャーの日常とAI
VPoEという立場になってからプログラミングをする機会はだいぶ少なくなりましたので、今の開発業務の大半は要件定義や仕様作成です。
これまでドキュメント作成のサポートとしてChatGPT、Cursor、ClaudeCodeなど様々なAIツールを試してきましたが、最近特に力を入れて取り組んでいるのが「仕様駆動開発」という手法と、それを支援する「cc-sdd」というツールです。
仕様駆動開発とは
仕様駆動開発(Specification-Driven Development)は、要件定義、設計、タスク作成、実装というプロセスを順にAIが生成するものをレビューしながら進めていく開発手法です。
従来の開発では、要件定義から実装まで一気に進めてしまい、実装内容にある意味ガチャが発生していたものを、仕様駆動開発では各段階でマークダウンでのドキュメントを作り、人が都度レビューを行うことで意図した実装に近い内容を生成させていきます。
この手法が注目を集めるきっかけとなったのが、AWSが公開した「kiro」というツールです。
kiroとは
kiroは、AWSが開発した仕様駆動開発を支援するAIツールです。開発者が要件を入力すると、AIがそれを元に設計書やタスク分解を提案してくれます。
要件定義から設計、タスク分解、そして実装までのワークフローをAIと対話しながら進められる点が画期的で、このツールの登場により、仕様駆動開発というアプローチが広く認知されるようになりました。
cc-sddとは
https://github.com/gotalab/cc-sdd
cc-sddは、好きなAI Agentを使いながらkiroを模した開発ができるようになるオープンソースのツールです。kiroがAWS独自の環境で動作するのに対し、cc-sddは様々な開発環境に統合できる柔軟性があるのと、無料で使える利点があります。
私はClaude Codeを使っていますが、cc-sddをインストールすると/kiroコマンドが使えるようになります。基本的なワークフローは以下の通りです。
/kiro:spec-initで初期構築/kiro:steeringで事前情報のインプット/kiro:spec-requirementsで要件定義書作成/kiro:spec-designで設計書作成
本来はこのあとにタスク作成と実装のステップがありますが、私は設計書作成までで利用しています。実装はそこで生成された仕様書を開発チームに渡して任せます。
仕様駆動開発をやってみてわかったこと
現在、1〜2ヶ月ほど仕様駆動開発を試していますが、まだまだベストプラクティスには全然至っておらず、いくつか課題が見えてきました。
既存プロジェクトへの適用が難しい
これは仕様駆動開発に限った話ではありませんが、既存プロダクトの現在の仕様などをAIにインプットさせるのが非常に難しいです。
1つのプロダクト、リポジトリ単位であればまだ範囲が狭められますが、私たちのサービスはマイクロサービスアーキテクチャを採用しており、複数のサービス間の関係性や依存関係をドキュメントとして網羅しているわけではありません。
さらに、長年運用してきたプロダクトには、コードには書かれていない暗黙知や背景情報が数多く存在します。「なぜこの実装になっているのか」という経緯や、「この部分は将来的にリファクタリングする予定」といった情報をすべてAIに伝えるのは現実的ではありません。
逆に言えば、まったく新しいプロダクトを作る際は、cc-sddの仕組みに沿っていくととてもスムーズに進められました。頭にある要件とおおざっぱな仕様を伝えればそこからきっちりとした要件定義書、仕様書を生成してくれます。
レビューコストが大きい
AIの生成物は真面目すぎるというか、時として必要以上に詳細な提案をしてきます。
特に非機能要件については、求めていないレベルの詳細まで提案してくることがあります。例えば、小規模な社内ツールの仕様を作っているのに、大規模システム並みの可用性やスケーラビリティの要件を提案してきたりします。
もちろん、自分では考慮し忘れていた部分を指摘してくれることもあるので助かる部分もありますが、とにかくレビューが大変です。不要な部分を削除する作業に時間を取られてしまうこともあります。
設計段階でも、インターフェース設計のコーディング例が含まれていたりするので、この辺はどういうアウトプットが必要か、という定義やフォーマットを事前に明示して渡してあげる必要があると感じています。
AIと要件定義していく価値
課題はありつつも、仕様駆動開発には確実な価値があると感じています。
視覚化による思考の整理
設計書に状態遷移図やシーケンス図などの図示(mermaid記法)をしてくれることで、頭の中にあった曖昧なイメージが整理しやすくなります。
例えば、「ユーザーがログインして、注文して、支払いをする」という要件を口頭で説明するだけでは、細かな分岐やエラーハンドリングが抜け落ちがちです。しかし、AIがシーケンス図に起こしてくれると、「あ、ここで在庫切れの場合の処理が抜けている」といった気づきが得られます。
この視覚化のプロセスは、思考の整理に大いに役立っています。
要件と仕様の往復での磨き込み
そこから設計方針を変えたい、要件を修正したい、となったときの要件定義への修正をAIがスピーディに行なってくれるのが地味に助かります。
網羅的にも行ってくれるので書いたドキュメントの修正はAIに任せて、本筋のどういう要件・仕様にすべきか、という部分に集中できます。
そうして仕様と要件の往復を繰り返して、より良い要件と仕様を作り上げていく工程が非常に有効だと感じていて、一度で完璧な仕様を作るのではなく、何度も往復しながら徐々に精度を上げていくアプローチが、AIとの協働では特に効果的に感じています。
AIとの付き合い方
今のAIは「入社したての、何も知らない中堅社員」と表現されるのを耳にします。この例えは的を射ていると思います。
人の場合はどうかとあらためて考えてみると、要件定義や仕様作成を大まかなオンボーディングをさせただけの入社したばかりの人に任せるか、というとおそらくしないでしょう。
現実の職場では、OJTとしてまず先輩が手本としての仕様までは作って、詳細のドキュメント作りを伴走しながら任せて少しずつ慣れてもらうという進め方をします。そして、その人は経験を積むことで徐々に成長し、いずれは独力で要件定義ができるようになっていきます。
とはいえ、AIは人と違って少しずつ慣れて上達することはありません。明日にはまた何も知らない状態になっているわけです。この特性を理解し、AIへの期待値はその辺に設定しておくのがよさそうです。
0→1の部分はまず自分がやる、大まかな方向性、コアとなる要件、譲れない制約条件などは自分の頭で考え、ある程度の形にします。そして、それを文書に起こしたり図にして他の人にわかりやすいように整形させるのがAIの役目です。
それを人よりも高速でやってもらうことで、要件と仕様の往復を何度も行い、精度を上げていく。この反復のスピードが、AIを使う最大のメリットだと感じています。
まとめ
仕様駆動開発を使った開発は、まだ完璧ではなくまだまだ課題もあります。
しかし、要件と仕様の往復がスムーズになり、視覚化による思考の整理ができるようになったことは、大きな価値があります。
重要なのは、AIに丸投げするのではなく、自分の思考を補助するパートナーとして使うこと。0→1は自分が考え、1→10をAIに高速で回してもらう。この距離感が、現時点では最も効果的だと感じています。
AI技術の進化は速いので、また新しい使い方が見つかるかもしれませんが、AIの知能が人を超えない限りは人との付き合い方の延長線上くらいに考えて、これからも試行錯誤を続けたいと思います。
明日のアドベントカレンダーもお楽しみに!
