仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話

7/28にファインディ株式会社主催で開催された「プロダクト開発、AIに丸ごと任せられるのか？Meetup Spec/Issue駆動知見を語り尽くす！」にて弊社エンジニア 宮田 大聖（miya-chan）が登壇した際の資料です。

Transcript

1. 仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話 freee株式会社 freee⼈事労務 Engineer | 宮⽥ ⼤聖（miya-chan）
2. プロフィール ⽣年⽉⽇：1993年4⽉12⽇ 出⾝地 ：兵庫県神⼾市 居住地 ：⼤阪最北端 経歴： ⼤学卒業後、地元神⼾の企業に総合職として就職（電⼒ 事業で、営業‧マーケ‧システム連携などなど広く浅 く）→その後ソフトウェアエンジニアとして転職→ 2023 宮田大聖 (miya-chan) 年にfreeeへ転職 freee人事労務 Eng 3年ほどfreee販売の開発に従事 #関西勤務 #チームマネージャー 今は関⻄拠点初のfreee⼈事労務のEngチームを⽴ち上げ X : JavaMouse GitHub : https://github.com/keganokami て、⼤崎のチームと⼀緒に開発中‧‧‧ ⽬標は関⻄チームで⼈事労務で1つコア機能をまるっと開 発すること。 2
3. freeeにおける AI活用の状況 • 社内での主なAI Agent活用変遷 ◦ 2024年：Copilot、 ◦ 2025年前半：Cline＆Roo、 ▪ 後半〜現在：Claude（Codexやgeminiなども併用中） • 全社的にAIネイティブな企業を目指している ◦ freee、2026年7月よりCAIO直下にAIBP（AI Business Partner）部署を新設 • 全社員がAIエージェントツールを使うことができる • AI特区として指定された一部の開発メンバーにて、AIツールの検証的利用を実施 • AIエージェントの能力を安全に拡張するため、社内向けMCPサーバを用意 • freeeの開発フローは、全社的な型がある。 ◦ （ざっくり）要求要件定義 -> DesignDoc作成 -> 実装 -> QA -> リリース ◦ 基本はこの型の中で様々なトライがされている • 社内では多数のSKILLやclaude pluginが公開されノウハウが共有されている。 設計 実装 テスト 仮説定義 課題整理 コード レビュー 効果測定 振り返り QA テスト リリース ※上記は取り組みの⼀部です。 3
4. spec-kitをベースに仕様駆動開発を 1年ほど頑張った • spec-kit を1年前に見つけて、実際に試した ◦ でも、そのままではfreeeのような社内でのプロダクト開発フローが整備されている状態には適合しなかった。 JIRAチケット管理、チーム開発、レビューフロー、サービス間連携に弱いなどなど。 • そこで、spec-kitを開発Repository内で魔改造した。 ◦ 実装時にブランチを作成しないようにした ◦ より厳密なコーディングルールを設定した ◦ 1つのRepositoryで複数のプロジェクトを設定できるようにした ◦ 仕様や設計書を配置するディレクトリを設定した などなど • 実際、10個くらいのプロジェクトで自チーム、他チーム含めて活用してもらい FBを受けた。 • 社内には活用に対して厳しいフィードバックもいただきながら、トライと改善と模索を続けている・・・ そして今年‧‧‧Claude Plugin として社内公開した🎉 「GitHub リポジトリ 1 つで⾃前の Claude Codeプラグインマーケットプレイスをホストできる公式機構。freee はそれで社内 プラグイン(takoyaki-kit 等)を配布している」 4
5. 独自の機能を追加している spec-kit本体のコア機能はリスペクトも含めて活用し、さらに独自で機能を追加 既存機能でも/specifyや/tasksなども改良は加えながらではあるが、かなり使える。 既存改造 追加機能 01 02 03 04 05 仕様の明確化 計画・タスク化 品質自律収束 並列実装 動作検証 （開発中） /specify /plan /analyze /implement /verify /clarify /tasks /autofix /multi-imp spec.md plan.md 自動修正・判定 サブエージェント ブラウザ自動検証 Wave並列実行 GitWorktreeを活用し た並列実装 スクリプト実行 Worktreeからでも自 動動作確認が可能 clarifications.md tasks.md（JIRAチケット作成 機能など、オプションも追加） ハードゲート その他にも既存機能として、checklistやADRを出⼒してくれるような機能があるためその時々で使えるアウトプットは使っている。 5
6. もはや独自ツール - まずは自分たちが使いやすいものを作る • CLI操作だけでなくGUI上でも操作できるようにしている。 • 特にタスクの依存関係や、着手不能なタスクを確認するには可視化できるのが良い。 • WBS機能とかもつけちゃっている。 6
7. 魔改造ポイント - Cmuxを使った仕組み • GUI上からの実行もcmux連携をしていることで、画面から入力したプロンプトもcmuxに送ってClaudeを立ち上げて作業 することができる。 • 並行実装をする際はtasks.mdにWAVE（＝実装Phase）を定義することで、実装単位をまとめることが可能 。WAVEの 中でGitWorktreeを使って、並行実装をし自己レビューから PR作成までするようになっている。 ◦ 社内E2Eテスト基盤（Playwright/CLI）を活用し、動作確認を自動化予定。 引⽤元：https://cmux.com/ja 7
8. 魔改造ポイント - 仕様の明確化と仕様 ↔実装の自動化 • spec-kitではspecifyコマンドは一度のみだが、何度も実行可能にした。 ◦ 差分更新 ◦ 更新内容を人間に確認する etc… • /clarify（仕様の壁打ち）は基本機能だが、本家はSpecファイルに全て記載するスタイル。しかし、それは別ファイル clarifications.mdで管理するようにしている。 • /autofix機能を新設。無人の開発工場を想定して、実装から見つけた仕様変更などに自動対応するようにしている。 し かし、怪しい点があれば作業を止めて確認を入れるようにしている。 8
9. 魔改造ポイント - projectsディレクトリの設置 • projectsディレクトリを新設 。ここに、開発アイテムごとのドキュメント関連を いれる/specify以降のコマンド実行の際に、project名を指定することで常 に参照先を指定できる。複数チームで開発してもバッティングしない。 • project名ごとにspecsディレクトリ（標準機能）に project名と同じディレ クトリが作成されて、その中に、plan.md や tasks.md などtakoyaki-kitが 出力ドキュメント類が保存される。 9
10. ちなみに、名前は takoyaki-kit
11. 運用1年でチームに定着した「 3つの変化」 01 チーム開発のスケール化 02 開発体験と品質の底上げ 03 柔軟なユースケース適応 チーム横展開が容易に 仕様の質と同期の強化 開発内容への最適化 機能実装の横展開を別チームへの依頼 モブレビュー的に仕様の壁打ちをする 必ずしも仕様作成から⾏う必要はな する際に連携がスムーズになる。ま た、新メンバーがプロジェクトにJoin してすぐに実装開始できるようになる など即戦⼒化を実現できた。 ことにより、チーム全体のプロジェク トに対する理解度が向上。結果的に設 計以降の品質に繋がった。 く、詳細設計以降から利⽤可能など、 柔軟な対応ができることもわかった。 また、不具合修正などのチケットベー スの実装コマンドも⽤意している。 11
12. ⽬指す世界と現状の課題（ギャップ） takoyaki-kit が目指す世界 ⚠ 克服すべき技術的・運用的課題 ① 誰もが高品質に開発をリードする ▲ 設計フィードバックの反映 & レビュー負荷 たこ焼きを作るように、型や作り方に沿って誰もが同等の高品質で進められる世界 （早い、安い、美味い、回し方さえ会得すれば良い）。 設計書がGoogleDocsのため反映に課題。社内S3アセットをフル活用し、人力で Docを手動で修正する必要ある。 ▲ ドキュメント品質の「AI感」と可視化の弱さ ② 自律的なプロジェクト推進 出力物がAI特有の羅列で認知負荷が高い。GUIでの可視化、Mermaid記法の最 適化や個別ファイル出力による改善をしていきたい。 誰が使っても高品質な設計・実装となり、ツールが主体となって自律的にプロジェク トを回せる状態。 ▲ 並行動作確認の制限 ③ 図を描きたくなる・可視化による品質貢献 モデリング図、シーケンス図、システムフロー図などを積極的に描写し、可視化が 品質向上に大きく寄与する文化。 単体動作確認は可能だがDBコピー等は未着手。共通DBのポート分割レベルに留 まり、並行開発＆確認環境の実現はまだ遠い。 ▲ ハーネス設計と効果検証の不足 自動昇格機能による学習機能は有するものの、検証自体が未熟であり、具体的な 効果測定まで至っていない。 ④ 職能を超えたシームレスな探索と PoC ▲ 複数レポジトリ調査におけるハードル PMやデザイナーとGUIを通じて、機能開発の手前における仮説探索やPoC検証が 即座に行える環境。 巨大レポジトリやマイクロサービス間の設計・実装漏れの懸念。複数リポジトリ調査 機能は備わっているが、活用難易度が高い。 11
13. まだまだチャレンジしていきます！
14. スモールビジネスを、世界の主役に。