構造が変わらなければ生産性は変わらない @開発生産性のその先へ、AI生産性について語りたい

https://forkwell.connpass.com/event/384640/
構造が変わらなければ生産性は変わらない
~AIを導入することによる開発サイクルにおけるボトルネックを構造的に倒していく仕組みづくり~

Transcript

1. 1 構造が変わらなければ ⽣産性は変わらない AIを導⼊することによる開発サイクルにおけるボトルネックを構造的に倒していく仕組みづくり 横⼭遥⼄ 2026.02.26 @開発⽣産性のその先へ、AI⽣産性について語りたい
2. 2 ⾃⼰紹介 ロリポップ‧ムームードメイン事業部ムームードメイングループ 横⼭ 遥⼄ はるおつ • GMOペパボ新卒2年⽬エンジニア • @haruotsu_hy/@haruotsu • ゾウが好き • Go、Rubyをよく触ります。 • ドメインをたくさん買っています。
4. 4 今⽇の話 「AIをどう使うか」 だけでなく、 「AIが活きる構造をどう作るか」 直列依存を構造的に排除し、並列に動けるパイプラインに変える 実際にチームでボトルネックを 1つずつ潰していった例を紹介します
5. 5 ① 設計 ② 分割 ③ 実装 ④ 設計レビュー ⑤ コードレビュー ⑥ マージ AIで各ステージは速くなるが リリースまでの速度があまり変わらない。 開発サイクルが遅くなる要因はなんでしょうか？ 開発サイクル
6. 6 ボトルネックが全体の速度を決定し、AIの効果がでない。 開発サイクルにおけるボトルネック 多段の承認 プロセス コミュニケーション 権限 タスクの粒度 リソース不足 プラットフォーム の違い 開発環境 エンジニアリングで解決できる、構造的な問題はなんだろうか？ 「個人の速度向上 × システム全体の並列・高速化」 で初めてAI・自動化が効果を発揮する
7. エンジニアリングで解決できること 7 ボトルネック なぜ直列になるか 構造的な原因 ❶ 設計が伝わらない 入力が曖昧 → 全下流が手 戻り パイプライン先頭のストール ❷ タスク分割が遅い 依存グラフが不明 → 並列化 不可 順序実行するしかない ❸ 実装が直列 ポート/volume/DNS衝突 → 1環境のみ 共有リソース競合（mutex） ❹ 設計レビューが遅い 観点が人の頭の中 → 逐次 実行 コード化されていないチェック ❺ コードレビューが属人的 基準がない → 自動化不可 テストスイートがない状態と同じ ❻ レビュー待ちが長い AI実装が速すぎ → 人間が 追いつかない 待ちが発生している 今日は、この❶〜❻を構 造的に排除した話をしま す。
8. 設計図が機能しない • パターン1: 詳細すぎて陳腐化 ◦ クラス図、メソッド図、ファイルパス全部書いた、⼈間が読むにはハードな⽂章 ◦ 実装始まったら、実はガラッと変わった ◦ AI & ⼈間「もう設計書⾒てないです」 • パターン2: 抽象的すぎて伝わらない ◦ 「マイクロサービスで疎結合にします」 ◦ AI 「こうするのがよいでしょう！」 ◦ 並列で動かしてmergeしたら、設計バラバラ... • パターン3: そもそも書かない ◦ 「コードが設計書です」 ◦ AIに⽂脈が渡せない 8 設計図が機能しない
9. ドキュメントドリブン開発 9 Design Doc = 「判断の記録」 詳細実装ではなく、「なぜ、どのようにそうするか」
10. ドキュメントドリブン開発 10 ドキュメントドリブン開発 (DocDD) 書くこと 書かないこと WHY: なぜこの設計にするのか 具体的な実装コードの羅列 WHAT: 何を作るのか、構造 ファイルパスの詳細リスト 設計決定とトレードオフ ステップバイステップの手順 データ構造・処理フロー概要 メソッドシグネチャの詳細 判断を伝えるのに必要な粒度に留める。 AIも人間も常に再現性を担保して 実装を進めることができる
11. 実際のムームードメインのドキュメント駆動の様⼦ 11
12. ドキュメント駆動開発 12 ドキュメント 責務 なぜ分離するか design-doc Why / What（目的・方向性） 頻繁に変わらない。全体のゴールが腐らない architecture/ How方針（技術スタック・設計方針） プロジェクト横断で再利用。変えると影響大 ADRs 判断の記録 判断のたび追記 constitution.md 開発原則・品質基準 AIのガードレール。全specに適用される specs 機能の What詳細 / How詳細 最も活発に変わる。ここだけ頻繁に変えてよい 全プロジェクトの「なぜそうしたか」を残す。 新メンバーがきても、新 AIがきても、新セッションでも再現性を担保する
13. 設計 -> 実装の変換が遅い 13 • AIが出した、1つの⼤きなPRを作りがち • レビュワーが読むのに時間がかかる • 修正、再レビュー、修正、デプロイの速度が遅くなる 設計 → 実装の変換が遅い
14. 設計 → 実装の変換が遅い 14 Design Doc をベースに 要件定義とPR分割をAIと協業して ドキュメントに残す
15. ⼈間とAIの役割を分担する 15 ⼈間とAIの役割を分担する 作業 人間 AI Why/Whatの定義 主担当 - 技術方針の決定 主担当 提案 要件定義の生成 レビュー 主担当 曖昧さの解消 回答 質問 実装計画・タスク分解 レビュー 主担当 コード実装 レビュー 主担当 品質判断・マージ 主担当 - • AIに丸投げではない、構造化された協業 • 人間がDesignDoc したがって、「何を作るか」 AIが「どう作るか」を実行 • 人間は常にレビュー・判断・承認の責任を持 つ 承認された、要件定義、 PR分割書が design docにmergeされる
16. 16 実例 フェーズごとの依存関係の大枠を Mermaidで可視化 その後さらに可視化
17. 分割 17 Phaseごとにさらに分割 (実際の分割計画書より) 各PR=1日以内でマージ可能。コンフリクトも避けられる。 各PRでなにをするかが明確にレビューされた状態で残る。誰が実装しても同じ状態。 半自動でAIで分割実装が可能に。
18. ⼯数⾒積もりも⾃動化 18 ⼯数⾒積もりも⾃動化 /estimate 設計書.md → Ganttチャート付きスケジュールが自動生成。
19. 設計図が機能しない • git worktreeで複数ブランチを同時起動してそれぞれで別作業をする 19 並列開発の壁「環境がぶつかる」問題 ブランチA: docker compose up → ポート3000, 4000, 443を占有 ブランチB: docker compose up → ポート3000が衝突。起動失敗 ブランチA: MySQL volume “muu-mysql” を使用中 ブランチB: 同じvolumeを参照 → データが混ざる ブランチA: https://muu.testでアクセス ブランチB: … 同じURLじゃアクセスできない... 並列実装しようにも、1台のマシンで1環境しか動かせない → 運用で頑張るのではなく、構造的にゼロにする
20. ドキュメントドリブン開発 20 makeコマンドで コンテナ停⽌、DB分離、ポート分離、 名前解決 を⼀撃で完了させる
21. make branch/start ⼀発で全部やる 21 make branch/start ⼀発で全部やる • make branch/start ◦ stop-old-branch-containers.sh ← 古いコンテナを自動停止 ◦ normalize-branch-name.sh ← ブランチ名をDNS安全な形に変換 ◦ generate-env.sh ← worktree固有のハッシュで.env生成 ◦ gopose up --config .gopose.yaml ← 動的ポート割り当て ◦ update-muu-url.sh ← 各サービスのURLを動的設定 ◦ docker compose up -d ← 起動 開発者は、 make branch/start だけ。裏で 6つのスクリプトが連鎖する
22. 仕組み 22 仕組み1: ワイルドカードDNS + SSL • dnsmasq + mkcertでブランチごとのHTTPアクセスを実現
23. 仕組み 23 仕組み2: goposeで動的ポート割り当て • ポート衝突をゼロにするツールを開発 harakeishi/gopose gopose up -p "$BRANCH_NAME" の動作： 1. compose.yml の ports 定義を読み取り 2. 8000-9999 の空きポートを探索（予約ポート除外） 3. docker-compose.override.yml を自動生成： proxy: 443 → 8443:443 ← ブランチA rb: 3000 → 8300:3000 php: 4000 → 8400:4000 proxy: 443 → 8543:443 ← ブランチB（衝突しない） rb: 3000 → 8500:3000 php: 4000 → 8600:4000
24. 仕組み 24 仕組み3: worktreeごとのVolume分離 • 絶対パスのMD5ハッシュで完全分離 Worktree A (/Users/dev/muu) → hash: a3f2b1c9 → a3f2b1c9-bundler Worktree B (/Users/dev/muu-feature) → hash: 7e4d8f12 → 7e4d8f12-bundler それぞれ専用の volumeを作成することで DB、node_modules、gem、composerパッケージが完全分離して混ざらない
25. 仕組み 25 仕組み4: 古いコンテナの⾃動停⽌ • docker inspect で「同じディレクトリからマウントされた別ブランチ」を検出 make branch/start するだけで、古い環境が自動で片付く。手動管理不要。 makeコマンドでコンテナ停止、 DB分離、ポート分離、名前解決を一撃で完了させる
26. 設計レビューが遅くて属⼈的 • Aさん (Rails得意): 「Rails観点はOK!」 • Bさん(セキュリティ得意): 「XSSが抜けてるよ~~」 • Cさん(DB得意): 「インデックス戦略が...」 26 設計レビューが遅くて属⼈的 レビュー観点が人の頭の中にある。直列。属人的
27. 27 レビュー観点をskillとしてコード化
28. レビュー観点をskillとしてコード化 28 レビュー知見がリポジトリに蓄積される。属人化しない。 バージョン管理できる
29. レビュー観点をskillとしてコード化 29 蓄積されたレビュー観点を通して、修正が完了してからレビュー コマンド1発で12観点が並列で走り出す
30. レビュー待ちが⻑い 30 レビュー待ちが⻑い コードを書く テストする レビューする 開発生産性が上がりめっちゃ早くなった 大AI時代、超高速な仮説検証 を行う上で、 レビューがボトルネック になっていた。 遅い！
31. ドキュメントドリブン開発 31 レビュー依頼に関わる全てを⾃動化する
32. slack-review-notify 32 • GitHubにラベルが付くと通知 • レビュワーのランダムアサイン • スレッドで定期リマインド • レビュワー変更 • レビュー後⾃動通知 • 定期リマインド • 営業時間考慮 • スラッシュコマンドでの設定変更 slack-review-notify https://github.com/haruotsu/slack-review-notify レビュー依頼、アサイン、リマインド、完了が全自動 特定の人ばかりレビューをする属人化を避ける。やらなければ、リマインドでひたすら叩く
33. ドキュメントドリブン開発 33 まとめ
34. セクションタイトル 34 今⽇紹介したこと = 依存の構造的排除 設計が曖昧で手戻り→ DocDD（判断の記録 要件→タスク分割が遅い→ AI自動分割 実装が1本ずつ直列 → n並列実装 + gopose環境 設計レビューが属人的 → 12スキル並列レビュー コードレビューが属人的 → CCA + ガイドライン自動選択 レビュー通知が流れる → slack-review-notify 「AIをどう使うか」ではなく「 AIが活きる構造をどう作るか」。
35. 35 Thank you! イベントを運営してくださったみなさま、聴講してくださったみなさまに感謝！ Xでいつでも話しかけてください!
36. 36 We’re hiring!