Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for haruotsu haruotsu
February 26, 2026
250

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

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

Avatar for haruotsu

haruotsu

February 26, 2026
Tweet

More Decks by haruotsu

Transcript

  1. 5 ① 設計 ② 分割 ③ 実装 ④ 設計レビュー ⑤

    コードレビュー ⑥ マージ AIで各ステージは速くなるが リリースまでの速度があまり変わらない。 開発サイクルが遅くなる要因はなんでしょうか? 開発サイクル
  2. 6 ボトルネックが全体の速度を決定し、AIの効果がでない。 開発サイクルにおけるボトルネック 多段の承認 プロセス コミュニケーション 権限 タスクの粒度 リソース不足 プラットフォーム

    の違い 開発環境 エンジニアリングで解決できる、構造的な問題はなんだろうか? 「個人の速度向上 × システム全体の並列・高速化」 で初めてAI・自動化が効果を発揮する
  3. エンジニアリングで解決できること 7 ボトルネック なぜ直列になるか 構造的な原因 ❶ 設計が伝わらない 入力が曖昧 → 全下流が手

    戻り パイプライン先頭のストール ❷ タスク分割が遅い 依存グラフが不明 → 並列化 不可 順序実行するしかない ❸ 実装が直列 ポート/volume/DNS衝突 → 1環境のみ 共有リソース競合(mutex) ❹ 設計レビューが遅い 観点が人の頭の中 → 逐次 実行 コード化されていないチェック ❺ コードレビューが属人的 基準がない → 自動化不可 テストスイートがない状態と同じ ❻ レビュー待ちが長い AI実装が速すぎ → 人間が 追いつかない 待ちが発生している 今日は、この❶〜❻を構 造的に排除した話をしま す。
  4. 設計図が機能しない • パターン1: 詳細すぎて陳腐化 ◦ クラス図、メソッド図、ファイルパス全部書いた、⼈間が読むにはハードな⽂章 ◦ 実装始まったら、実はガラッと変わった ◦ AI

    & ⼈間「もう設計書⾒てないです」 • パターン2: 抽象的すぎて伝わらない ◦ 「マイクロサービスで疎結合にします」 ◦ AI 「こうするのがよいでしょう!」 ◦ 並列で動かしてmergeしたら、設計バラバラ... • パターン3: そもそも書かない ◦ 「コードが設計書です」 ◦ AIに⽂脈が渡せない 8 設計図が機能しない
  5. ドキュメントドリブン開発 10 ドキュメントドリブン開発 (DocDD) 書くこと 書かないこと WHY: なぜこの設計にするのか 具体的な実装コードの羅列 WHAT:

    何を作るのか、構造 ファイルパスの詳細リスト 設計決定とトレードオフ ステップバイステップの手順 データ構造・処理フロー概要 メソッドシグネチャの詳細 判断を伝えるのに必要な粒度に留める。 AIも人間も常に再現性を担保して 実装を進めることができる
  6. ドキュメント駆動開発 12 ドキュメント 責務 なぜ分離するか design-doc Why / What(目的・方向性) 頻繁に変わらない。全体のゴールが腐らない

    architecture/ How方針(技術スタック・設計方針) プロジェクト横断で再利用。変えると影響大 ADRs 判断の記録 判断のたび追記 constitution.md 開発原則・品質基準 AIのガードレール。全specに適用される specs 機能の What詳細 / How詳細 最も活発に変わる。ここだけ頻繁に変えてよい 全プロジェクトの「なぜそうしたか」を残す。 新メンバーがきても、新 AIがきても、新セッションでも再現性を担保する
  7. ⼈間とAIの役割を分担する 15 ⼈間とAIの役割を分担する 作業 人間 AI Why/Whatの定義 主担当 - 技術方針の決定

    主担当 提案 要件定義の生成 レビュー 主担当 曖昧さの解消 回答 質問 実装計画・タスク分解 レビュー 主担当 コード実装 レビュー 主担当 品質判断・マージ 主担当 - • AIに丸投げではない、構造化された協業 • 人間がDesignDoc したがって、「何を作るか」 AIが「どう作るか」を実行 • 人間は常にレビュー・判断・承認の責任を持 つ 承認された、要件定義、 PR分割書が design docにmergeされる
  8. 設計図が機能しない • 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環境しか動かせない → 運用で頑張るのではなく、構造的にゼロにする
  9. 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つのスクリプトが連鎖する
  10. 仕組み 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
  11. 仕組み 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パッケージが完全分離して混ざらない
  12. 仕組み 25 仕組み4: 古いコンテナの⾃動停⽌ • docker inspect で「同じディレクトリからマウントされた別ブランチ」を検出 make branch/start

    するだけで、古い環境が自動で片付く。手動管理不要。 makeコマンドでコンテナ停止、 DB分離、ポート分離、名前解決を一撃で完了させる
  13. 設計レビューが遅くて属⼈的 • Aさん (Rails得意): 「Rails観点はOK!」 • Bさん(セキュリティ得意): 「XSSが抜けてるよ~~」 • Cさん(DB得意):

    「インデックス戦略が...」 26 設計レビューが遅くて属⼈的 レビュー観点が人の頭の中にある。直列。属人的
  14. slack-review-notify 32 • GitHubにラベルが付くと通知 • レビュワーのランダムアサイン • スレッドで定期リマインド • レビュワー変更

    • レビュー後⾃動通知 • 定期リマインド • 営業時間考慮 • スラッシュコマンドでの設定変更 slack-review-notify https://github.com/haruotsu/slack-review-notify レビュー依頼、アサイン、リマインド、完了が全自動 特定の人ばかりレビューをする属人化を避ける。やらなければ、リマインドでひたすら叩く
  15. セクションタイトル 34 今⽇紹介したこと = 依存の構造的排除 設計が曖昧で手戻り→ DocDD(判断の記録 要件→タスク分割が遅い→ AI自動分割 実装が1本ずつ直列

    → n並列実装 + gopose環境 設計レビューが属人的 → 12スキル並列レビュー コードレビューが属人的 → CCA + ガイドライン自動選択 レビュー通知が流れる → slack-review-notify 「AIをどう使うか」ではなく「 AIが活きる構造をどう作るか」。