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