遅いのはコードではなく会話だった / new-bottleneck-conversation

2026-04-22
AgileStudioウェビナー発表資料

Transcript

1. AI × 開発現場 ウェビナー / 登壇 遅いのはコードではなく、 会話だった。 Claude Code で実装は 9 倍速くなった。 その先で、私たちは何に気づいたのか。 2026年4月22日 永和システムマネジメント Agile Studio 岡本 卓也 © 2026 ESM, Inc. 01
2. SPEAKER 受託開発の現場から、 AI との協働について話します。 岡本 卓也 永和システムマネジメント / Agile Studio 受託開発の現場で、スクラムチームのエンジニアとして、AI と人の「協働スタイル」を 試行錯誤しています。ここ数ヶ月は特に Claude Code を中心にガッツリ使い込み、従 来と全く違う開発の感触を日々アップデートしています。 Claude Code Codex GitHub Copilot 岡本 卓也 / Agile Studio 02 / 15
3. TODAY'S TAKEAWAYS 今日、持って帰っていただきたい 4 つのこと。 01 — SPEED 実装は 速くなった Claude Code の活用で、要件定義から試験まで の全フェーズで効率が劇的に向上。 9× 02 — BOTTLENECK ボトルネックは 外側に移動した コードは速くなったのに、プロダクトは速くな らない。詰まりが別の場所に引っ越した。 → 03 — TEAM 2 人 + AI が ちょうど良かった 2ピザサイズでも大きすぎる。少人数 × AI とい う新しい比率が機能した。 2人 04 — BALANCE 本番 と 素振りを 分ける 変化が速い時代は、試し続ける領域と確実に作 る領域を分けることが鍵。 ⚖ 遅いのはコードではなく、会話だった 03 / 15
4. A — WHAT CHANGED 「実装だけ」じゃない。 全フェーズで効率が変わった。 Claude Code が加わって以降、単にコードを書く速度が上がっただけでなく、 上流から下流まで、開発の景色そのものが変わりました。 01 要件定義 壁打ちの質と速度が向上。曖昧さが早 い段階で潰れる。 02 設計 選択肢の比較検討が高速に。たたき台 が常にある状態。 03 実装 主戦場。生産性は桁違いに変化（次ス ライドで詳細） 。 04 試験 テスト観点の網羅性が向上。ケース生 成が自動化。 05 保守 既存コードの読解・把握が早い。属人 性の緩和。 A. 全フェーズで効率が向上 04 / 15
5. A' — THE NUMBER 月平均アウトプットは、約 9 倍になった。 9 月平均の 追加行数 比較。 導入前 3,567 行 / 月 導入後 31,619 行 / 月 導入前 23ヶ月平均 導入後 10ヶ月平均 0 10k 20k 30k 35k ※ 同一開発者による計測。大規模フォルダ構成変更（実質コード変更なし）2件を除外。 ドキュメント、テストコード、設定ファイル等を含む。 × 3,567 31,619 A'. 月平均 9 倍 05 / 15
6. A'' — EVIDENCE 2025年6月、 明らかに「傾斜」が変わった。 0 100k 200k 300k 400k 2025年6月 · Claude Code 本格導入 3,567 行 / 月 31,619 行 / 月 2023/09 2024 2025/06 2025 2026/03 累 計 追 加 行 数 点線は「もし AI がなければ」の延長線。実線との差が、変化の大きさ。 A''. 傾斜が変わった 06 / 15
7. A''' — EVIDENCE 2025年6月 以降、 ほぼ全ての行が AI 支援。 0 20k 40k 60k 80k 64k 45k 手書き中心（23 ヶ月） AI 支援（10 ヶ月） 2025 / 06 ──→ 2023/09 2024 2025 2025/10 2026/03 A'''. ほぼ全て AI 支援 07 / 15
8. B — BUT... でも、プロダクト全体は、 そこまで速くならなかった。 ✓ 速くなった 「書く」速度 ✗ 変わらなかった 「決める」 「届ける」速度 実装が速くなった分、ボトルネックが「外側」に引っ越ししました。 コーディング テスト実装 リファクタリング ドキュメント生成 何を作るかの合意形成 仕様の問い合わせ / 確認 レビュー・承認フロー リリースまでの調整 B. ボトルネックが移動 08 / 15
9. — THE REAL BOTTLENECK — 遅いのは コード ではなく、 会話 だった。 何を作るか、どうリリースするか、誰が決めるか。 B'. 真のボトルネック 09 / 15
10. C — NEW TEAM SHAPE 次のプロジェクトで出会ったのは、 「2 人 + それぞれの AI」という形。 従来 — 2 PIZZA TEAM P PO D DEV D DEV D DEV D DEV D DEV Q QA 5 〜 8 人 同期コストが膨らむ → 新 — HUMAN × AI PAIR A HUMAN AI ASSIST B HUMAN AI ASSIST 2 人 + AI 意思決定が速い / 同期コスト最小 C. 新しいチーム編成 10 / 15
11. C' — WHY SMALLER WINS なぜ 2 ピザでは「大きすぎる」のか。 01 / 生産力 一人あたりの出力が、 劇的に増えた。 AI を使いこなせる人は、従来の数人分のアウトプットを一人で出せる。人数を増やす前提 が崩れた。 02 / 通信コスト 同期コストは、 人数の二乗で増える。 n人チームのコミュニケーション経路は n(n-1)/2。2人→1経路、6人→15経路。 「話す」だけ で時間が溶ける。 03 / 意思決定 少人数は、 決定が速い。 「聞いて、考えて、決めて、動く」の全サイクルが短縮。AIが思考の壁打ち相手になる。 04 / 責任範囲 スコープが、 自然に明確になる。 2人+AIだと、担当の曖昧さが消える。誰が何に責任を持つかが明確なほど、速く動ける。 C'. 少人数 × AI の強さ 11 / 15
12. C'' — CAVEAT ただし、この形には 条件がある。 「2 人 × AI」はパワフルですが、誰と組んでも機能するわけではありません。 私たちが気づいた、必須の条件 はこうでした。 ◦ 機能するペア M+ MID / SENIOR + AI team × M+ MID / SENIOR + AI team × 機能しないペア M+ MID / SENIOR + AI team × J JUNIOR + AI ? → つまりこの体制は、エンジニア 1 人 1 人の「自律して動かし切る力」 を前提にしている。 どちらも 自走できる エンジニア — 各自が AI を指揮し、小さなチームを率いることができる — 意思決定・設計を自分で完結できる — 従来型のミドル × ジュニア の組み合わせ — ジュニア側が AI を指揮しきれない — 結局ミドルが両方を見る構造になる — C''. この形には条件がある 12 / 15
13. PA R T D 実践のバランス ここまでの話とは別軸の、 もう一つの気づき。 Part D 13 / 15
14. D — PRACTICE & PRODUCTIO N 「確実に作る」と「試行錯誤」の 領域を、意識的に分ける。 PRODUCTION — 本番開発 確実に作る領域 7 ※ 時間配分は目安 LAB — 素振り領域 試行錯誤する領域 3 ※ AI時代は少し増やすのが吉 お客様の信頼がかかる本番コード 実績あるプロセス・ツールを使う 検証済みの手法で堅く進める 受託開発では裁量の問題も考慮 新しいツール・手法を自分で試す 失敗しても影響が小さい環境 吸収したものを本番に還元 学び続ける仕組み として運用 D. 本番 と 素振り のバランス 14 / 15
15. WRAP UP 今日のまとめ。 01 AI で開発は 速くなった。 実装は 9 倍。 — しかし — 02 ボトルネックは 外に移動した。遅いのは会話だった。 — だから — 03 チーム構造を見直す。2 人 + AI が、ちょうど良かった。 04 学び続ける仕組みを持つ。素振り領域を確保する。 まとめ 15 / 15
16. Thank. you. → このあと、対談パートへ © 2026 ESM, Inc. —