仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development

AIを"使う"から"組み込む"へ / kickflow x HERP合同ミートアップ
2026/09/14

Transcript

1. 仕様駆動開発による爆速プロダクト開発 株式会社kickflow CTO ⼩林 佳祐 @AIを"使う"から"組み込む"へ / kickflow x HERP合同ミートアップ, 2026/09/14
2. 今⽇話すこと • 先週⼀般公開した「Talentify」というタレントマネジメントシステムの新規開発で採⽤した、 仕様駆動開発についてお話します。 • Talentifyのサービスサイトはこちら ◦ • https://www.talentify.jp/ Talentifyの⽴ち上げについて書いたnoteはこちら ◦ © kickflow, Inc. https://note.com/kobakei122/n/nafd821631e91 2
3. 3つの仕様駆動開発 • • ⼀⾔で仕様駆動開発と⾔っても、⾊々ある 1. Spec-first（仕様第⼀） 2. Spec-anchored（仕様連動） 3. Spec-as-source（仕様＝ソースコード） Talentifyでは、3寄りの2を採⽤ © kickflow, Inc. ◦ 仕様とソースコードの両⽅がSource of Truth ◦ ただし、ほとんどのソースコードは仕様を元にAIが⽣成しており、コードを直接書くことは滅多に無い ◦ 仕様書は使い捨てにせず、保守しつづける 3
4. 我々の「仕様書」とは？ • PRDと仕様書の中間くらいの位置づけ • 要求やユースケース、解決したい課題、機能要件、画⾯設計あたりまで網羅 ◦ • テーブル設計やAPI設計など技術的な情報は含まない→これらは設計書（Design doc）のスコープ ⾮エンジニアでも読めるようなフォーマットで、ビジネス側のメンバーも読めるようにしておく ◦ © kickflow, Inc. GitHubでマスターを管理して、esaにも⾃動的に同期 4
5. 仕様駆動開発のためのツール • CodexとClaude Codeのみ ◦ • 基本Codexメインで、仕様書作成やモック開発でClaude Code（Fable）を使う Kiro, Spec Kit, cc-sddなどのツールは使⽤していない © kickflow, Inc. ◦ 仕様書のフォーマットが求めているものと違ったり、⼤量にドキュメントを出⼒しがちなので ◦ ※とはいえ最近これらのツールを触ってないので、今は解決できるのかもしれない 5
6. 典型的な開発フロー • • 新機能開発の場合、⼤体以下のような開発フローになる 1. 要件定義（仕様書の作成） 2. モックUI作成 3. 設計‧実装 4. セルフレビュー‧PR作成 5. QA 6. リリース ※5だけQAエンジニアが担当 各⼯程に特化したハーネス（ルール、スキル、フックなど）を整備 © kickflow, Inc. 6
7. 要件定義 • • /create-spec スキル ◦ 使⽤例: /create-spec 1on1機能のGoogleカレンダー連携 ◦ 曖昧な点はユーザーに質問してから、ドキュメント作成に⼊るようにスキルで指⽰ ◦ 関連する他の仕様書との整合性も⾃動的に保証 ポイント © kickflow, Inc. ◦ ⽂章を書く作業はAIにやらせて、仕様判断のみを⼈間が⾏う ◦ このフェーズの精度が後⼯程のすべての精度に影響するため、ここで集中的にレビューする 7
8. モックUIの作成 • /create-mock-ui スキル ◦ 使⽤例: /create-mock-ui 1on1のGoogleカレンダー連携 ◦ 仕様書では詰めきれていないUIの要件を確定させたり、仕様書ではよさそうだけど実物を⾒ると使いづらいのを 回避するために作成 ▪ • PdMの作成するワイヤーフレームや、デザイナーの作成するモックの代⽤ ポイント © kickflow, Inc. ◦ 要件定義同様、本実装に⼊る前にUI/UXをブラッシュアップする ◦ チーム内でのレビューも⾏う 8
9. 設計‧実装 • • 「仕様書‧モック通りに実装して」などとAIに依頼 ◦ 認証認可や特殊な外部連携の場合のみ、事前に設計書（Design doc）を作ることもある ◦ 実装の過程で仕様を変更した場合は、仕様書もセットで修正するようにルールで定義 ポイント ◦ © kickflow, Inc. AIの性能向上により⼤分マシになったが、まだ開発者テストは必須 9
10. セルフレビュー〜PR作成 • • /self-review、/fix-self-review、/create-pr、/watch-pr ◦ 実装完了後にセルフレビューして修正し、PRを作成し、レビューコメントの修正やCIの修正までを⾏う流れ ◦ セルフレビューは観点別にサブエージェントを起動。この⽅が各観点ごとの精度が⾼い。 ▪ 仕様整合 ▪ UI/UX ▪ セキュリティ ▪ パフォーマンス ▪ 保守性 ポイント ◦ © kickflow, Inc. ⼀連の流れが全部終わってから、⼈間のレビュアーがレビューする 10
11. QA ※ここはQAチームが担当 • 仕様書を元にAIがテスト仕様書を作成 • QAの実施も、まずはAIが実⾏ ◦ • QAエンジニアのPCで、並列でCodexのQAエージェントが起動 QAエージェントが仕様書と挙動に差分を⾒つけると、そのままバグチケットを作成 ◦ 仕様書を100%信⽤していないのが重要。仕様と実装のどっちが正しいか判断が難しい場合は、仕様確認としてチ ケットを作成する • 最後に、⼈間のQAが最終確認を⾏う © kickflow, Inc. 11
12. 仕様駆動開発のメリット • 拠り所となる要件が明確なので、開発規模が⼤きくなっても壊れにくい • 仕様が⾔語化されているため、AIによるレビューで仕様整合までチェックできる ◦ • コードレビューの負荷軽減 開発の過程でドキュメントが作成‧保守されるため、開発以外のチームとのコミュニケーションがしやすい ◦ © kickflow, Inc. 「ドキュメント⾒れば分かる」状態にできる 12
13. 仕様駆動開発のデメリット（というか限界） • ⼈間が最終的に判断しなければいけないのは、従来の開発と変わらない ◦ AIは⼀般的な知識は持っているが、我々のビジネスや⽬の前の顧客を⼗分に理解していない ◦ AIの提案が我々のビジネスやプロダクトにとっての正解かどうかは、⼈間が判断するしかない ◦ 結果、エンジニアの設計‧実装能⼒よりも、ドメイン知識理解やプロダクトマネジメント能⼒で差が出やすく なっている © kickflow, Inc. 13
14. まとめ • Talentifyの仕様駆動開発のプロセスやメリット‧デメリットを共有しました • この1年でもエージェントの性能の向上に伴い、仕様駆動開発はますます導⼊しやすくなっています • これを機に仕様駆動開発を試してみてください © kickflow, Inc. 14