FIXER Tech Blog - Development

Spec Kitを用いたチーム開発（2）：実装者目線で感じたこと

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Spec Kitを用いたチーム開発記録 - part2 実装者目線で感じたこと」を再編集したものです。

はじめに

　こんにちは、FIXERの開発者です。

　これまでのpart0（導入のきっかけと所感）、part1（スクラム開発での実用）に続き、今回のpart2では、実際にSpec Kitを使って手を動かしている開発者の立場から、日々の開発の中で感じたことをまとめてみたいと思います。

前回までの記事はこちら

→ part0：Spec Kitを用いたチーム開発記録 - part 0 導入のきっかけと所感 | cloud.config Tech Blog
→ part1：Spec Kitを用いたチーム開発記録 - part 1 スクラム開発での実用開始 | cloud.config Tech Blog

　私自身はバックエンド開発を中心に2年ほど携わってきましたが、今回のプロジェクトでは機能単位でフロントエンド・バックエンドの両方を一人の開発者が担当する体制になっており、担当範囲を明確に区切らずに進めています。これまでSpec Kitを使って実装したPBIは17本、画面数でいうと7画面分の機能を作成してきました。この規模感での実感をベースに、実装者目線での気づきをお伝えします。

1. 実際にどう使っているか（自分の1PBIの流れ）

　part1で紹介された「Specify→Clarify→Plan→Clarify→Tasks→Implement」という流れを、実際に手を動かすときの時間配分で表すと、体感でおおよそ次のような割合になっています。

・仕様確認・Specify/Clarify：2割
・Plan/Clarify/Tasks：1割
・Implement：1割
・修正：3割
・レビュー：2割
・テスト：1割

　こう並べてみると、AIが出力を作る工程（Specify〜Implement）自体は全体の4割程度で、残りの6割は「人が確認し、直し、レビューする」時間が占めていることがわかります。Spec Kitは実装を早くするツールというより、この「確認・修正・レビュー」を上流に前倒しして、手戻りの総量を減らすツールだという感覚に近いです。

　各成果物に対する信頼度は工程によってかなり差があります。Specifyは受け入れ条件（AC）を入力として渡しているため、大きく的外れな記載になることはほとんどありません。加えてClarifyの段階で不明瞭な点や検討が必要な点を洗い出してくれるので、そこで認識を揃えられる安心感があります。Planについても、実際のリポジトリを参照させたうえでコーディング規約をしっかり定義しているため、大きな問題を感じることは少ないです。

　一方でImplementについては、機能面（ロジック部分）は一発で完成することが多いのですが、デザイン部分がFigmaのモック通りにならないケースが目立ちました。これは間違いなくこちら側がSpec Kitに渡す情報を十分に用意できていないことが原因で、共通コンポーネントの使用を明記していてもAIが意図しないレイアウトを出力してしまうことがあり、フロント部分は手直しが多く発生しています。FigmaのMCPサーバーのような仕組みも存在しますが、モック作成段階でMCPサーバーの利用を前提とした運用にできていなかったため、今のところうまく活用できていません。ここは今後の改善ポイントだと感じています。

　Clarifyフェーズで「これは自分では判断できない」と切り分けてPMOやリーダーにエスカレーションする場面ももちろんあります。案件固有の内容は詳しくお伝えできませんが、業務ルールの優先度に関わるような、開発者側の裁量では決められない仕様判断がその典型です。

　また、複数PBIを並行して進める中での工夫として、後述する内容とも重なりますが、1つのPBIに対して1本のPRを切るのではなく、意図的にPRを分割するようにしています。これにより、レビュワーやGitHub Copilotによるレビュー・修正依頼の負荷を分散させることができています。

2. 良かったと感じている点

2-1. 仕様が先に文書化されていることの恩恵

　part0・part1でも触れられている通り、仕様が先に文書化されていること自体のメリットはこれまでも語られてきましたが、実装者目線で改めて実感するのは「上の時間配分で仕様確認・Clarifyに割く時間は全体の2割程度で済んでいるのに、実装以降で仕様の認識ズレに起因する手戻りがほとんど発生しない」という点です。ここに時間を使っておくことで、後工程がかなり安定する感覚があります。

2-2. AIの生成コードの質

　tasks.mdをもとにしたImplementの結果は、命名規則やレイヤー分けについてはコーディング規約に忠実で、この観点で問題になったことはほとんどありません。

　一方で気をつけている点もあります。Implementの段階では重複コードは少ないのですが、その後にエージェントへ修正依頼を出すと、かなりの確率で重複コードが発生します。そのため、修正を依頼する際は毎回「重複が発生していないか確認してほしい」という一文をプロンプトに含めるようにしています。

　backend-coding.md・frontend-coding.mdのようなコーディング規約ファイルとAIの相性については、このプロジェクトではかなり良いと感じています。大量の実装を人の目だけですべて確認するのは現実的ではないため、あらかじめ規約が明文化されていることで、実装のブレが起きにくくなっていると思います。

2-3. レビューの質・スピードの変化

　レビューにはGitHub Copilotレビューを採用しています。レビューが出るまでのスピードは以前と比べて段違いに速くなりました。ただし、レビューコメントに対して該当箇所の実装コードを人間側で確認する必要は当然あるため、レビューにかかる負荷そのものが劇的に下がったという実感はそこまでありません。スピードは上がったが、レビューの丁寧さまでは省略できない、というのが正直なところです。

2-4. 実装スピードそのものの速さ

　依存関係がない範囲であれば、バックエンド部分はほぼ一発で実装が完了することが多く、実装スピードの速さは驚くほどです。

3. 大変だった点・まだ課題だと感じている点

　part1では見積もりの難しさやオンボーディングコストがPMO視点で挙がっていましたが、ここでは実装者本人が手を動かす中でのつまずきを中心に書きます。

3-1. 並行PBI開発時のコンフリクト

　10人ほどの開発者が同時に動いているプロジェクトのため、実装完了のタイミングが重なるとコンフリクトが頻発しました。特に厄介だったのは、コンフリクトを解消し終える頃には別の変更が新たにマージされていて、再度コンフリクトが発生するというケースです。

　この点については、チーム内で「コンフリクトしそうな部分は誰か一人が実装し、ファイルを分けてそれぞれの実装を追加する」というルールにすることで、大きく困ることはなくなりました。

3-2. AI出力を鵜呑みにするリスク

　「たたき台」であることは理解していても、あまりの出来の良さにそのままPRを出してしまうことがあります。多くの場合はGitHub上で自動的に走るCIのテストやCopilotレビューでの検知によって、デグレはある程度防げていると感じています。

　ただし、プロジェクト全体で見ると、コンフリクト解消の際に本来残すべき修正が消えてしまい、結果的にデグレが発生したケースが2回ほどありました。コンフリクト解消は人の手作業に依存する部分なので、ここは仕組みだけでは防ぎきれない領域だと感じています。

3-3. フェーズが多い分のリードタイム

　自分のチームでは、割り振られたタスクの仕様調整からPlan作成までを、おおよそ2日間で終えられています。

　もちろん顧客に確認が必要な事項も出てきますが、その場合はPlanの中に仮置きの実装（AパターンとBパターン）を定義したうえで先に進めるようにしています。「たたき台」である以上、そこで手が止まってしまうのは避けたいという考え方です。

　具体的には、顧客に確認する際は「はい／いいえ」の二択に絞れる形に質問を整理し、Planには想定される選択肢（Aパターン・Bパターン）をあらかじめ両方定義してもらっています。そのため、後から回答が変わった場合も「Bパターンにしてください」という一言で差し替えが済み、待ち時間をほとんど発生させずに開発を進められています。

3-4. PRの大きさの問題

　プロジェクト全体で課題になっているのが、PBI単位でPRを切った際の差分の大きさです。AI駆動開発になったことでタスク単位そのものが大きくなりがちですが、AI駆動開発においてはタスクの規模がそのままレビュー負荷に直結するわけではありません。にもかかわらず、PBIに対してそのままPRを切ると、とんでもない差分量になってしまいます。

　これに対してレビューをしようとすると、レビューだけで1日近くかかってしまうこともありますし、コンフリクトが発生した際の対応も非常に大変になります。

　そのため、PBIの中で実装をフェーズ分けし、1つのPRがおおよそ400〜800文字程度の差分に収まるように切るようにしています。これによってレビューのボトルネックはかなり解消されました。もっと良いやり方があるとは思いますが、今のところはこの運用で回せています。

4. 実装者として工夫していること・Tips

　いくつか実践している中で、他のチームでも参考にしてもらえそうな工夫を紹介します。

・ACの正確性を最優先で確認する：spec.md/plan.md/tasks.mdを読む際は、まず受け入れ条件（AC）が間違っていないかを念入りに確認しています。テストはACをベースに組まれるため、ここがズレていると後工程でとんでもない手戻りが発生してしまいます。

・修正依頼には毎回「重複確認」を添える：前述の通り、Implement後の修正依頼では重複コードが発生しやすいため、プロンプトに重複チェックの指示を必ず含めるようにしています。

・顧客確認はYes/Noに絞り、Planには選択肢を両方仮置きする：これにより、確認待ちで実装が止まる時間を最小化しています。

・PRは意図的に小さく分割する：PBI単位ではなくフェーズ単位でPRを切り、400〜800文字程度の差分に収めることで、レビュー負荷とコンフリクト対応の負荷の両方を下げています。

5. まとめ

　今回はpart2として、実装者の立場からSpec Kitを使って感じたことをまとめてみました。一言で言うと、圧倒的に実装が楽になり、品質も上がっているはずだというのが実感です。

　次回は別チームの開発メンバーに記事を書いてもらう予定です。

　最後までお読みいただきありがとうございました。

※本記事は生成AIを利用しています

HP／FIXER
AIに仕事とられました。落ち着きはないです。

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER