Spec Kitを用いたチーム開発（1）：スクラム開発での実用開始

2026年08月21日 09時00分更新

文● ちゅんのすけ／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Spec Kitを用いたチーム開発記録 - part 1 スクラム開発での実用開始」を再編集したものです。

はじめに

　こんにちは、FIXERの中です。久しぶりに記事を書くので緊張しています。（テキストなのに...）

　今回のチームで私はスクラムマスターを担っています。

　前回から連載が始まった【Spec Kitというツールを使ったチーム開発の取り組み】ですが、今回のpart 1ではスクラム開発でSpec Kitの実用を開始して感じた「これまでのスクラム開発と比べて良くなった点」「まだ少し不便な点」あたりを中心にお伝えしたいと思います！

　スクラム開発を推進している方や仕様駆動開発を検討されている方の参考になれば幸いです。

前回の記事 → Spec Kitを用いたチーム開発記録 - part 0 導入のきっかけと所感 | cloud.config Tech Blog

Spec Kitを用いたスクラム開発の進め方

　タイトルの通り、アジャイル開発の一つである『スクラム』と呼ばれる手法を用いて開発を進めています。

　スクラムとは、短い期間(1〜4週間)で開発と振り返りを繰り返しながら、少しずつプロダクトを作り上げていくアジャイル開発の手法の一つです。各スプリントの終わりには必ずレビューを行い、動くものを実際に見て確認しながらフィードバックを取り入れて次のスプリントに進みます。こうしてレビューと改善を重ねるたびに機能が少しずつ積み上がり、最終的に大きな価値あるプロダクトへと成長していくのが特徴です。

　これまでの開発もスクラムで進めており、ある程度の進め方はできていますが、テストの網羅性や手戻りを減らすため仕様駆動開発を試したく、またAIを用いた新技術を推進したいという理由からSpec Kitを導入しました。

　part0でも説明していましたが、Spec Kitには4つのフェーズがあります。

　各フェーズの間には Clarify（明確化）というステップが用意されています。これはAIが仕様や設計の内容を読み解き、曖昧な点について対話的に質問を投げかけてくれるステップです。Clarify は一度だけでなく繰り返し実行でき、セキュリティやパフォーマンスなど特定の領域に焦点を当てて深掘りすることもできます。各フェーズの出力を次に進める前に精度を上げる仕組みが組み込まれているわけです。

　開発者一人当たりに対して複数のPBIを割り当てて、以下の要領で開発を進めています。

1．1つ目のPBIについて、フェーズを進める。
2．Clarifyまで実施し、完了したらPRのレビューを依頼する。
3．レビューを待っている間に、次のPBIについてフェーズを進める。（この際、他開発者のPRがあればレビューを行う）
4．自分のレビューが返却され、指摘があれば修正し、問題なければ次のフェーズに進む。

これまでのスクラム開発と比べて良くなった点

　スクラムマスターの立場でチームを見ていて、Spec Kitを導入したことでこれまでのスクラム開発と比べて良くなったと感じている点を3つ紹介します。

1．先に仕様を細かく整理することで、完成物をより鮮明にイメージできること
2．詰まりきっていない仕様についてAIが質問してくれるため、考慮漏れを防ぐことができること
3．開発スピードが速くなったこと

1. 先に仕様を細かく整理することで、完成物をより鮮明にイメージできること

　これまでは実装を進めながら仕様を詰めていく場面も多く、「作ってみたら認識と少しズレていた」という手戻りが発生することが少なくありませんでした。

　Spec Kitでは最初のSpecifyフェーズで仕様を文書化することが必須になっているため、実装に入る前の段階で開発者・レビュアー・PMOの間で完成物のイメージが揃います。"何を作るか" がクリアになった状態で実装に入れることで、迷いや手戻りが大きく減ったと感じています。

2. 詰まりきっていない仕様についてAIが質問してくれるため、考慮漏れを防ぐことができること

　Specifyフェーズで仕様を作成する際に、AIが「この条件のときの挙動は？」「このケースは含めますか？」といった形で、曖昧な部分を能動的に指摘してくれます。

　人間同士のレビューだけでは見落としがちなエッジケースや前提条件が浮き彫りになるため、結果的に仕様の網羅性が上がり、実装後に "考慮漏れ" が発覚するケースが激減しました。AIを "仕様の壁打ち相手" として使えるのは、想像以上に大きな恩恵だと感じています。

　さらに、開発者には2つの意識を持ちながら着手してもらっています。

　1つ目は、 "思い込みを無くす" ということです。

　具体的に言うと、『おそらくここはこんな仕様になるだろう』といった、わからないことを自身の中で完結させるようなことは無くしています。

　なぜ思い込みを無くすのか。→ 認識齟齬を無くすためです。

　冒頭でも書いたように、手戻りを減らしたいという課題があり、その手戻りの原因の一つとしてお客様との認識がずれていることがありました。

　今回Spec Kitを導入して最も認識齟齬が発生しそうなタイミングが、AIからの質問に開発者が答える時だと考えました。AIの質問に対して開発者が思い込みで回答してしまうと、それがお客様の意図と違った場合には手戻りとなってしまいます。

　そのため、思い込みを無くす意識を持ってもらい、答えられない質問はPMOやお客様に確認することを徹底しています。

　かといって、逐一お客様に仕様を聞いていると時間も手間もかかりますし、現実的ではありません。

　ではどうしているか。それが開発者に意識してもらっていることの2つ目です。

　2つ目は、 "仮説を持って確認する" ということです。

　1つ目の通り、仕様が決まっていない箇所はお客様に確認しますが、逐一「どのような仕様にしますか？」と聞いているとキリがありません。

　そのため、「どのような仕様にしますか」といった単純にお客様に丸投げする質問ではなく、「A･Bという仕様が考えられますが、Xという観点・設計からAの仕様といたしました」といった仮説をもって判断しお客様に提示するようにしています。

　このメリットは、「システムの完成度がより高くなること」や「開発スピードが低下しないこと」です。

　「勝手に決めてしまって手戻りが多くなるのではないか」と思う方もいるかもしれませんが、UI/UXや技術設計の観点が根拠となり説得力も生まれるため手戻りはほとんど発生していません。また、技術的な実装方針や直感で使えるようなUI/UXの観点はお客様よりも開発者の方が持ち得ているため、より質の高いシステムを完成させられると考えています。

　さらに、提案した仕様と別の仕様になったとしてもSpec Kitに依頼すると仕様書から実装コードまでを書き換えてくれるためそこまで時間はかかりません。

　以上の2つを開発者には意識してもらっています。

　AIを導入して使うだけでなく、人間も意識を変えることが重要だと考えています。

3. そもそもの開発スピードが速くなったこと

　Specifyに時間をかける分、序盤は「むしろ遅くなるのでは？」と思っていましたが、蓋を開けてみるとトータルの開発スピードは速くなったと感じています。

　仕様が固まった状態でTasks → Implementに進めるため、AIが生成する実装コードの精度が高く手戻りや作り直しが減ったことや、複数PBIを並行して進められることも相まって、これまでのSpec Kitを用いていないときのチームと比べると、スプリント内で消化できるPBIの量は増えたと感じています。

まだ少し不便な点

　逆に、スクラムマスター・PMOの立場でチームを見ていて「ここはまだ難しいな」と感じた点を2つ紹介します。

1．スプリント計画・PBI粒度の見積もりが難しくなったこと
2．チームへのオンボーディングコストが想像以上に大きいこと

1. スプリント計画・PBI粒度の見積もりが難しくなったこと

　スクラム開発ではPBIをタスクの「大きさ」や「複雑さ」を表す "ストーリーポイント" と呼ばれる数値で見積もることが多いのですが、Spec Kitを導入してからは Specify → Plan → Tasks → Implement という4フェーズ全てに時間がかかるため、実装（Implement）以外のフェーズにどれくらい時間を割けばよいかの感覚がまだチームに蓄積されておらず、着手するPBIがスプリント内に収まりきらない、というケースが起きやすくなりました。

　さらに、複数のPBIを並行して着手しているため、一つのPBIが完成するのにどれだけ時間を要したのか正確に見積もることが難しくなりました。

　現在は「PBIを細かく分けすぎず、同じPRで実装が出来そうなPBI同士を統合する」「スプリント内で『Specifyは何日目まで』のような中間マイルストーンを置く」といった運用上の工夫で対応していますが、最適なバランスを見つけるのはまだ手探りの段階です。

2. チームへのオンボーディングコストが想像以上に大きいこと

　Spec Kit はツール単体の使い方を覚えるだけで済むものではありません。プロンプトテンプレートの活用方法、各フェーズで何をレビューすべきか、お客様への確認のしかた（先述の "提案形式" の話など）まで含めて、"Spec Kit を前提とした開発手法" そのものをチームに浸透させる必要があると感じています。

　事前にオンボーディングの場を設けたものの、最初のスプリントは想定よりベロシティが伸びませんでした。新規メンバーが加わるたびに同等の立ち上げ期間を見込む必要があるため、立ち上げ期の設計はPMOとしての悩みどころです。

　ただ、今回が初めてのSpec Kitの導入だったため模索することが多くなっているとも考えており、今回のチームで土台を構築することで、今後はもっとスムーズにSpec Kitを導入できるのではないかと考えています。そうやって繰り返しSpec Kitを活用することで、オンボーディングコストの問題も解決していけると考えています。