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

by haruotsu

Slide 1

Slide 1 text

2 構造が変わらなければ⽣産性は変わらない AIを導⼊することによる開発サイクルにおけるボトルネックを構造的に倒していく仕組みづくり横⼭遥⼄ 2026.02.26 @開発⽣産性のその先へ、AI⽣産性について語りたい

Slide 2

Slide 2 text

3 ⾃⼰紹介ロリポップ‧ムームードメイン事業部ムームードメイングループ横⼭遥⼄るおつ ● GMOペパボ新卒2年⽬エンジニア ● @haruotsu_hy/@haruotsu ● ゾウが好き ● Go、Rubyをよく触ります。 ● ドメインをたくさん買っています。

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

5 今⽇の話「AIをどう使うか」だけでなく、「AIが活きる構造をどう作るか」直列依存を構的に排除し、並列に動けるパイプラインに変える実際にチームでボトルネックを 1つずつ潰していった例を紹介します

Slide 5

Slide 5 text

6 ① 設計 ② 分割 ③ 実装 ④ 設計レビュー ⑤ コードレビュー ⑥ マージ AIで各ステージくなるがリリースまで度があまり変わらない。開発サイクルが遅くなる要因なんでしょうか？開発サイクル

Slide 6

Slide 6 text

7 ボトルネックが全体度を決定し、AI 効果がでない。開発サイクルにおけるボトルネック多段承認プロセスコミュニケーション権限タスク粒度リソース不足プラットフォーム違い開発環境エンジニアリングで解決できる、構的な問題なんだろうか？「個人度向上 × システム全体並列・高化」で初めてAI・自動化が効果を発揮する

Slide 7

Slide 7 text

エンジニアリングで解決できること 8 ボトルネックなぜ直列になるか構的な原因 ❶ 設計が伝わらない入力が曖昧 → 全下流が手戻りパイプライン先頭ストール ❷ タスク分割が遅い依存グラフが不明 → 並列化不可順序実行するしかない ❸ 実装が直列ポート/volume/DNS衝突 → 1環境み共有リソース競合（mutex） ❹ 設計レビューが遅い観点が人頭中 → 逐次実行コード化されていないチェック ❺ コードレビューが属人的基準がない → 自動化不可テストスイートがない状態と同じ ❻ レビュー待ちが長い AI実装がすぎ → 人間が追いつかない待ちが発生している今日、こ ❶〜❻を構的に排除した話をします。

Slide 8

Slide 8 text

設計図が機能しない ● パターン1: 詳細すぎて陳腐化 ○ クラス図、メソッド図、ファイルパス全部書いた、⼈間が読むにはハードな⽂章 ○ 実装始まったら、実はガラッと変わった ○ AI & ⼈間「もう設計書⾒てないです」 ● パターン2: 抽象的すぎて伝わらない ○ 「マイクロサービスで疎結合にします」 ○ AI 「こうするのがよいでしょう！」 ○ 並列で動かしてmergeしたら、設計バラバラ... ● パターン3: そもそも書かない ○ 「コードが設計書です」 ○ AIに⽂脈が渡せない 9 設計図が機能しない

Slide 9

Slide 9 text

ドキュメントドリブン開発 10 Design Doc = 「判断の記録」詳細実装ではなく、「なぜ、どのようにそうするか」

Slide 10

Slide 10 text

ドキュメントドリブン開発 11 ドキュメントドリブン開発 (DocDD) 書くこと書かないこと WHY: なぜこ設計にするか具体的な実装コード羅列 WHAT: 何を作るか、構ファイルパス詳細リスト設計決定とトレードオフステップバイステップ手順データ構・処理フロー概要メソッドシグネチャ詳細判断を伝えるに必要な粒度に留める。 AIも人間も常に再現性を担保して実装を進めることができる

Slide 11

Slide 11 text

実際のムームードメインのドキュメント駆動の様⼦ 12

Slide 12

Slide 12 text

ドキュメント駆動開発 13 ドキュメント責務なぜ分離するか design-doc Why / What（目的・方向性）頻繁に変わらない。全体ゴールが腐らない architecture/ How方針（技術スタック・設計方針）プロジェクト横断で再利用。変えると影響大 ADRs 判断記録判断たび追記 constitution.md 開発原則・品質基準 AI ガードレール。全specに適用される specs 機能 What詳細 / How詳細最も活発に変わる。ここだけ頻繁に変えてよい全プロジェクト「なぜそうしたか」を残す。新メンバーがきても、新 AIがきても、新セッションでも再現性を担保する

Slide 13

Slide 13 text

設計 -> 実装の変換が遅い 14 ● AIが出した、1つの⼤きなPRを作りがち ● レビュワーが読むのに時間がかかる ● 修正、再レビュー、修正、デプロイの速度が遅くなる設計 → 実装の変換が遅い

Slide 14

Slide 14 text

設計 → 実装の変換が遅い 15 Design Doc をベースに要件定義とPR分割をAIと協業してドキュメントに残す

Slide 15

Slide 15 text

⼈間とAIの役割を分担する 16 ⼈間とAIの役割を分担する作業人間 AI Why/What 定義主担当 - 技術方針決定主担当提案要件定義生成レビュー主担当曖昧さ解消回答質問実装計画・タスク分解レビュー主担当コード実装レビュー主担当品質判断・マージ主担当 - ● AIに丸投げでない、構化された協業 ● 人間がDesignDoc したがって、「何を作るか」 AIが「どう作るか」を実行 ● 人間常にレビュー・判断・承認責任を持つ承認された、要件定義、 PR分割書が design docにmergeされる

Slide 16

Slide 16 text

17 実例フェーズごと依存関係大枠を Mermaidで可視化そ後さらに可視化

Slide 17

Slide 17 text

分割 18 Phaseごとにさらに分割 (実際の分割計画書より) 各PR=1日以内でマージ可能。コンフリクトも避けられる。各PRでなにをするかが明確にレビューされた状態で残る。誰が実装しても同じ状態。半自動でAIで分割実装が可能に。

Slide 18

Slide 18 text

⼯数⾒積もりも⾃動化 19 ⼯数⾒積もりも⾃動化 /estimate 設計書.md → Ganttチャート付きスケジュールが自動生成。

Slide 19

Slide 19 text

設計図が機能しない ● git worktreeで複数ブランチを同時起動してそれぞれで別作業をする 20 並列開発の壁「環境がぶつかる」問題ブランチ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環境しか動かせない → 運用で頑張るでなく、構的にゼロにする

Slide 20

Slide 20 text

ドキュメントドリブン開発 21 makeコマンドでコンテナ停⽌、DB分離、ポート分離、名前解決を⼀撃で完了させる

Slide 21

Slide 21 text

make branch/start ⼀発で全部やる 22 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つスクリプトが連鎖する

Slide 22

Slide 22 text

仕組み 23 仕組み1: ワイルドカードDNS + SSL ● dnsmasq + mkcertでブランチごと HTTPアクセスを実現

Slide 23

Slide 23 text

仕組み 24 仕組み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

Slide 24

Slide 24 text

仕組み 25 仕組み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パッケージが完全分離して混ざらない

Slide 25

Slide 25 text

仕組み 26 仕組み4: 古いコンテナの⾃動停⽌ ● docker inspect で「同じディレクトリからマウントされた別ブランチ」を検出 make branch/start するだけで、古い環境が自動で片付く。手動管理不要。 makeコマンドでコンテナ停止、 DB分離、ポート分離、名前解決を一撃で完了させる

Slide 26

Slide 26 text

設計レビューが遅くて属⼈的 ● Aさん (Rails得意): 「Rails観点はOK!」 ● Bさん(セキュリティ得意): 「XSSが抜けてるよ~~」 ● Cさん(DB得意): 「インデックス戦略が...」 27 設計レビューが遅くて属⼈的レビュー観点が人頭中にある。直列。属人的

Slide 27

Slide 27 text

28 レビュー観点をskillとしてコード化

Slide 28

Slide 28 text

レビュー観点をskillとしてコード化 29 レビュー知見がリポジトリに蓄積される。属人化しない。バージョン管理できる

Slide 29

Slide 29 text

レビュー観点をskillとしてコード化 30 蓄積されたレビュー観点を通して、修正が完了してからレビューコマンド1発で12観点が並列で走り出す

Slide 30

Slide 30 text

レビュー待ちが⻑い 31 レビュー待ちが⻑いコードを書くテストするレビューする開発生産性が上がりめっちゃ早くなった大AI時代、超高な仮説検証を行う上で、レビューがボトルネックになっていた。遅い！

Slide 31

Slide 31 text

ドキュメントドリブン開発 32 レビュー依頼に関わる全てを⾃動化する

Slide 32

Slide 32 text

slack-review-notify 33 ● GitHubにラベルが付くと通知 ● レビュワーのランダムアサイン ● スレッドで定期リマインド ● レビュワー変更 ● レビュー後⾃動通知 ● 定期リマインド ● 営業時間考慮 ● スラッシュコマンドでの設定変更 slack-review-notifyhttps://github.com/haruotsu/slack-review-notify レビュー依頼、アサイン、リマインド、完了が全自動特定人かりレビューをする属人化を避ける。やらなけれ、リマインドでひたすら叩く

Slide 33

Slide 33 text

ドキュメントドリブン開発 34 まとめ

Slide 34

Slide 34 text

セクションタイトル 35 今⽇紹介したこと = 依存の構造的排除設計が曖昧で手戻り→ DocDD（判断記録要件→タスク分割が遅い→ AI自動分割実装が1本ずつ直列 → n並列実装 + gopose環境設計レビューが属人的 → 12スキル並列レビューコードレビューが属人的 → CCA + ガイドライン自動選択レビュー通知が流れる → slack-review-notify 「AIをどう使うか」でなく「 AIが活きる構をどう作るか」。

Slide 35

Slide 35 text

36 Thank you! イベントを運営してくださったみなさま、聴講してくださったみなさまに感謝！ Xでいつでも話しかけてください!

Slide 36

Slide 36 text

37 We’re hiring!