SDDとうまく付き合うために 〜試行錯誤して見えてきたチームなりの使い方〜

2026/03/19 仕様駆動開発（Spec-Driven Development） Lunch Talk 登壇資料です

Transcript

1. SDDとうまく付き合うため に 2026/3/19 仕様駆動開発（Spec-Driven Development） Lunch Talk 試行錯誤して見えてきたチームなりの使い方
2. 01 自 己 紹 介
3. SNS Meina Tsujikura ハコベル株式会社 Software Engineer @meimei_kr_ @meimei-kr 運送手配PLUSの開発を担当 Ruby/Rails のイベントによく参加しています 3
4. Copyright © 2026 HACOBELL INC. All Rights Reserved. 会社概要 会社名 沿 ⾰ 所在地 代表者 事業内容 株 主 ハコベル株式会社 2015年12⽉ ラクスル株式会社内でサービス開始 2022年8⽉ ハコベル株式会社設⽴ 狭間 健志 代表取締役社⻑CEO 物流のシェアリングプラットフォーム「ハコベル」の運営 セイノーホールディングス株式会社 ラクスル株式会社 ⼭九株式会社 株式 会社環境エネルギー投資 福⼭通運株式会社 SOMPO Growth Partners株式 会社 ⽇本ロジテム株式会社 ⽇本郵政キャピタル株式会社 ＪＡ三井リース 株式会社 リグロース‧キャピタル‧マネジメント株式会社 紀陽キャピタ ルマネジメント株式会社 しぎんキャピタルパートナーズ株式会社 東京都中央区⼋丁堀2-14-1 住友不動産⼋重洲通ビル1、3階
5. Copyright © 2026 HACOBELL INC. All Rights Reserved.
6. Copyright © 2026 HACOBELL INC. All Rights Reserved. 私たちの提供するソリューション トラックの⼿配に⼿間や時間が膨⼤にかかるというオペレーションに加え、⾮効率な業務が残り続け就業環境が 改善されないなどの現場課題をハコベルが提供するソリューションで解決します。
7. 仕様駆動開発（SDD）導入の背景 01 SDD導入のメリット 02 運用する中で見えてきた課題と改善方法 03 現在のSDDに対する考え 04 [ 本日話すこと ] 7
8. 01 仕 様 駆 動 開 発 （ S D D ） 導 入 の 背 景
9. AIエージェントの台頭 昨年、AIエージェントの飛躍的進化に伴い、コーディングをAIに任せ られる領域が広がった 弊社でもClaude Codeの導入が開始され、使っていく中で、AIエージ ェントを開発プロセスに取り入れる前提での変化が必要だと感じてい た 9
10. 当時の開発における課題 複数のリポジトリを横断する開発が多く、開発チケットの規模が大き く複雑になりがち 実装途中で、こういう場合の仕様はどうする？という論点が発生 考えていた設計でできそうだと思っていたが、作ってみたらその方法 では実現できず方針転換することも 10
11. AI時代の開発スタイルについて考えていたこと スムーズに開発するためには、要件や実装方針をもっと詳細化して固 めておく必要がありそうだな そのプロセスにもっと重点を置ければ、あとはAI/人間どちらでも実 装しやすくなりそう 11
12. そんな時に... SDDを採用したAWSのAI IDE「Kiro」が登場 https://aws.amazon.com/jp/blogs/news/introducing-kiro/ 12
13. Spec-Driven Development（SDD）とは？ Spec とは？ What = 何を作るか Why = なぜ作るか How = どのように作るか　をまとめた一連のドキュメント SDDとは？ Spec ドキュメントをもとに開発する手法 SDDは、まさに考えていた開発スタイルが実現できそうな手段！ 13
14. Claude CodeでKiroを再現 当時はまだSDDをKiro以外で実現できるツールを見つけられなかった Kiroの開発スタイルを再現した方々の記事を参考に自作 基本の流れ 1. requirements.md（要件定義書）作成 2. design.md（設計書）作成 3. tasks.md（タスクリスト）作成 4. Specレビュー（Agent Skills & エンジニア） 5. 実装 14
15. 02 S D D 導 入 の メ リ ッ ト
16. 設計方針が定まっており、各自が迷いなく動きやすい 漏れている仕様を事前に洗い出し、確認しておける 実装前に決めるべき点を固めて合意済みなので、手戻りが激減 AIに精度の高いテストケース観点を出させるためのインプットに 将来の開発者が、 「なぜこの仕様・設計にしたのか」追えるように [ SDD導入のメリット ] 16
17. 03 運 用 す る 中 で 見 え て き た 課 題 と 改 善 方 法
18. 課題① Specドキュメント の膨大さ 課題③ 複数システム連携での 設計の難しさ 課題② 非同期レビュー の難しさ [ 運用する中で見えてきた課題 ] 18
19. 課題① Specドキュメントの膨大さ Specドキュメントは本質的に多くの情報が必要 → レビューが大変になり、後回しにされてしまう 要点だけチェックしようにも、どこを見ればいいかわからない... 19
20. 改善策：要点まとめドキュメント 要件定義書・設計書から要点を抽出したファイル（summary.md） を追加で生成するプロセスを踏むように変更 最低限このファイルをレビューすればチームの方向性がそろう状態に 20
21. 課題② 非同期レビューの難しさ コメントのラリーが長くなり、なかなか方針がまとまらない ざっと見て、 「なんとなく承認」が起きる 21
22. 改善策：モブ作業の定期開催 毎日1時間全員で同期で作業できる時間を確保 基本はSpecドキュメントのレビュー Spec作成者が仕様・実装方針の説明を行う 事前に準備した相談事項や、レビューの中で出た論点を話し合 い、Specに反映する 22
23. 改善策：モブ作業の定期開催 実装の不確定要素が多い場合はモブプログラミングに切り替え 議論しながら 仕様定義 → 設計 → タスク化 → 実装 のFBループ 悩んでいること・詰まっていることを気軽に相談できる場にも 23
24. 課題③ 複数システム連携での設計の難しさ 複数のシステムをマルチリポジトリ構成で管理しているため 各システム間の連携が必要な開発では、Spec作成時にAIに必要なコ ンテキストを渡しづらい 各リポジトリで独立してSpecを作るだけだと、システム間の設計品 質が落ちる 24
25. 改善策：サブモジュールによる統合メタリポジトリ Specを作るための参照用に、各システムのリポジトリをサブモジュ ールとしてまとめたリポジトリを新規作成 生成するSpecの分割 リポジトリ共通で必要なSpec システムごとに必要なSpec 25
26. 　統合リポジトリで作成するSpec 各システム共通で使用するもの 要件定義書（requirements.md） インターフェース定義書（interface.md） システム間の処理の流れ OpenAPI定義の修正・追加内容 26
27. 　各システムのリポジトリで作成するSpec リポジトリ固有で使用するもの 設計書（design.md） 要点まとめ（summary.md） タスクリスト（tasks.md） 各リポジトリからは、統合リポジトリへのシ ンボリックリンクを貼って、参照しやすいよ うに 28
28. 　 　ユビキタス言語などのドキュメントは、 　統合リポジトリ上に置くことで 　各リポジトリからドメイン知識を参照可能 27
29. 04 現 在 の S D D に 対 す る 考 え
30. どのツールを使うか？ 現在様々なSDD用ツールが開発されている Kiro、cc-sdd、OpenSpec、Spec Kit　etc... どれを使ってもプロセスとしてはそこまで大きく変わるものではない 色々使ってみて、気に入ったものでOK 自作してみるのも一つの方法 独自のドキュメント生成プロセスが存在する場合 カスタマイズを大きく加えたい場合 30
31. Specはいつまでメンテナンスするか？ Specは機能開発中における合意形成のためのドキュメント 開発後は、コードが正となる Specファイルは消さない 開発背景がすぐ参照できる コードベース調査の際は読ませない 31
32. Planモードとの使い分けは？ 複雑性の高い開発では、Planでは粒度が粗い / カオスになりがち Planモードで十分な場合も多い 実際、最近の弊チームの開発フェーズとして リポジトリ複数横断の開発が減少 粒度が小さめの開発チケットが増加 → 各自Planを作成し、気になる点があれば認識合わせという場合が多い このような場合にSDDを使うと、負荷だけ増えて逆に生産性が落ちる 32
33. 大事なこと 誰にでも、どんなときでも共通するSDDの正解はない 思考停止でSDDを導入するのではなく、話し合いながら、 チームや開発内容に合った選択と改善を繰り返していくことが大事 自分たちのチームにはどういうSDDのやり方が合うのか？ この開発チケットはSDDでやるべきか？ 33
34. ま と め
35. [ まとめ ] SDDのメリットは、チームの合意形成がしやすくなることで、開発生 産性を高められること ただし課題もあり、弊チームでは3つの工夫で改善した 多すぎるSpecによるレビュー負荷軽減のために、要点を抽出したまとめフ ァイルを作成 レビュー停滞を起こさないために、モブ作業で同期的に認識をそろえた システム間連携仕様を作成しやすくするために統合メタリポジトリを構築 なんとなくでSDDを運用するのではなく、必要性や改善点を問い続け ることが大事 35
36. Copyright © 2026 HACOBELL INC. All Rights Reserved. 採⽤情報 エンジニア 積極採⽤中！ 詳しくは以下QRよりご覧ください 求⼈ポジション⼀覧 エンジニアEntrance Book 詳細ページ 詳細ページ 36
37. ご 清 聴 あ り が と う ご ざ い ま し た ! [ THANK YOU! ]