SDD（仕様駆動開発）を考える

2026/11/12 に ZOZO.swift #3 で発表した登壇資料です。
https://zozotech-inc.connpass.com/event/411472/
株式会社ZOZO
ZOZOTOWN開発本部
ディスカバリー開発部
濵田 悠樹
#zozoswift

1. SDD（仕様駆動開発）を考える 株式会社ZOZO ZOZOTOWN開発本部 ディスカバリー開発部 濵田 悠樹 Copyright © ZOZO, Inc. 1
2. 株式会社ZOZO ZOZOTOWN開発本部 ディスカバリー開発部 2 © ZOZO, Inc. 濵田 悠樹 @ios_hamada • 25年新卒でZOZOに入社 • 大学と大学院で AIの研究 • 服でユーザーの人生を変えるためZOZOへ入社
3. 今日お話しすること ◦ AI を使ったサービス開発の進め方にはミスマッチがある ◦ その解消のために、iOSチームで「あんサポ」に取り組んでいる 目次 1. LLMの原理原則について 2. ZOZOTOWN-iOSの開発フロー 3. あんサポ 4. 今後の展望 © ZOZO, Inc. 3
4. LLM の原理原則 ◦ 何十兆トークンのテキストデータから “つながり” を学習 ◦ 学習した脳を使い「A→B→C→？」を規則性から D と答えるようなもの © ZOZO, Inc. 4
5. LLM の原理原則 Q. 日本の首都は？ A. 日本の首都は東京です。東京は〜〜 A. 日本の首都は 生成順 “確率的” に言葉をつないでいき、回答文を生成する A. 日本の首都は東京です。 A. 日本の首都は東京です。東京は〜〜 © ZOZO, Inc. 5
6. LLM は傾向予測機に近い ◦ 「次に使いそうな言葉」を予測している ◦ 正解を知っているわけではない ◦ ただし、数十兆トークンのテキストデータから傾向を学んでいるので精度が良い メリット デメリット - 大量の文書をすぐ読んでまとめられる - 学んでいないことは答えられない - フォーマットの決まった作業を繰り返せる - アウトプットが入力によって大きく異なる © ZOZO, Inc. 6
7. 「LLM = 入社初日の超頭の良い社員」 と考えてみる ◦ 知識は豊富だが、研修前なので会社のルールを理解できていない ◦ 仕事で活躍してもらうために ▪ オンボーディング資料を1つにまとめて渡す ≠ 闇雲に渡す ▪ フォーマットの決まった仕事を任せる ▪ アウトプットの判断は先輩社員（人間）が行う 開発でLLMを使うなら、これらを再現する必要がありそう © ZOZO, Inc. 7
8. 「LLM = 入社初日の超頭の良い社員」 と考えてみる ◦ 知識は豊富だが、研修前なので会社のルールを理解できていない ◦ 仕事で活躍してもらうために ▪ オンボーディング資料を1つにまとめて渡す ≠ 闇雲に渡す ▪ フォーマットの決まった仕事を任せる SSOT ※ を保証して開発を進めるという、 ▪ アウトプットの判断は先輩社員（人間）が行う 「SDD(仕様駆動開発)」の思想と同じ 開発でLLMを使うなら、これらを再現する必要がありそう この思想をもとにiOS開発のフローを再検討 © ZOZO, Inc. ※ SSOT(Single Source of Truth) : 開発における信頼できる唯一の情報源 8
9. Before : ZOZOTOWN-iOSの開発フロー 仕様書 のチェック → ← iOSチーム向けの 案件共有会 → 基本設計レビュー → アーキテクチャ レビュー → 実装 → レビュー → QA・リリース 良い点 ◦ 案件説明で、仕様の漏れを実装前に潰す ◦ 設計レビューで、設計の手戻りを実装前に潰す ◦ メンバーが好きにAIを使い、各々実装を進められる © ZOZO, Inc. 9
10. Before : AI時代における開発フローのミスマッチ 仕様書 のチェック → ← iOSチーム向けの 案件共有会 → 基本設計レビュー → アーキテクチャ レビュー → 実装 → レビュー → QA・リリース 課題 ◦ 各レビュー会で使うドキュメントの作成に時間がかかる ◦ AIを使っているが、AIの使い方がメンバーによってバラバラ ◦ メンバーによって ドキュメント・コード の質が異なる © ZOZO, Inc. 10
11. After : あんサポ（anken-support）の提案 「AI前提の開発フロー」を提案する 仕様書確認〜マージ を1日で終わらせる ※ 現状は 見積もり5人日以下の案件 を対象にしています © ZOZO, Inc. 11
12. あんサポ（anken-support）とは /anken-support : “5つ”のskillsで 仕様書のチェック 〜 チケット作成・実装 ① 仕様書の チェック /spec © ZOZO, Inc. → ② コードベースで 影響範囲調査 /alignment-usingcode → ③ 実装方針 /impl-plan → ④ タスク分割 /tasks → ⑤ 実装 /impl 12
13. あんサポ（anken-support）とは ① 仕様書の チェック /spec → ② コードベースで 影響範囲調査 /alignment-usingcode → ③ 実装方針 → ④ タスク分割 /impl-plan /tasks → ⑤ 実装 /impl iOSチームの観点で仕様書の抜け漏れをチェック • iOSチーム内で ”観点” を言語化してプロンプトを作成 • 抜け漏れ解消に向けて、AIが PMやデザイナー等への”質問項目”を生成してくれる → 属人性を軽減させて、抜け漏れの少ない仕様書に近づける © ZOZO, Inc. 13
14. あんサポ（anken-support）とは ① 仕様書の チェック /spec → ② コードベースで 影響範囲調査 /alignment-usingcode → ③ 実装方針 /impl-plan → ④ タスク分割 → /tasks ⑤ 実装 /impl コードベースでの調査、実装方針の検討、実装 をステップバイステップで実行 • フローや粒度は 「人間が実装する時」 と同様 • 各ステップのアウトプットをConfluenceへ出力し、ドキュメント作成の時間短縮 → 人間がやるべきことに集中できる実装フローで “最短の実装を可能に” © ZOZO, Inc. 14
15. あんサポ（anken-support）の結果 現在の定着ステージ PoC 1件以上実施 → 拡大中 複数案件・複数人で実施 運用段階 → 対象にしている案件タイプ ◦ 見積もり5人日以下の案件 5 件 ◦ 見積もり15人日以上の大規模案件 適用した案件数 ◦ 既存画面の改修や新規画面実装 など © ZOZO, Inc. 5 → 人日 1.5 人日 開発にかかった人日 5人日 : 見積もり 1.5人日 : 実測値 15
16. 今後の展望 ◦ 既存画面へのアーキテクチャ導入での応用 ◦ AIの出力を「検証」するステップ追加を検討 ▪ ユーザーストーリー生成+自動テスト のステップ ① 仕様書の チェック ① 仕様書の チェック → ② コードベースで 影響範囲調査 → ② コードベースで 影響範囲調査 → → ③ 実装方針 ③ 実装方針 → → ④ タスク分割 ④ タスク分割 → ⑤ 起票・実装 → ⑤ テストデータ作成 + UIテスト → ⑥ 起票・実装 ユーザーストーリー生 成 © ZOZO, Inc. 16