先日、「開発が速く安くなった後の話――AI時代のソフトウェアエンジニアリング組織論」を読みました。
AIによって実装が速く、安くなったとき、開発全体のボトルネックはどこへ移るのか。実際の事例を起点に、開発プロセス、アーキテクチャ、組織、そして維持保守まで考察した、とても示唆に富むスライドです。
特に印象に残ったのは、各工程の作業がAIによって速くなっても、工程間の受け渡しは同じようには縮まらず、人間同士のコミュニケーションが次のボトルネックになり得る、という問題提起でした。
これは、私自身がプロジェクトの現場で感じてきたこととも重なります。実装そのものは早く終わっても、背景の共有、認識合わせ、意思決定、承認、依存関係の調整には時間がかかる。しかし、それらをまとめて「コミュニケーションコスト」と呼ぶだけでは、具体的にどこで、なぜプロジェクトが止まっているのかを十分に捉えられません。
そこで本稿では、このスライドから得た問題提起を出発点に、私自身がプロジェクトの現場で感じてきたコミュニケーションのボトルネックをもう少し細かく分解し、「プロジェクトコミュニケーションの構造」 として言語化してみます。スライドの要約ではなく、そこで示された問いを手がかりに、「コミュニケーションがボトルネックになる」とは具体的にどのような状態なのか、その解像度を上げる試みです。
個別案件の紹介ではなく、複数の現場に共通して現れる構造を整理することを目的としているため、以下の議論は意図的に一般化しています。
実装が速くなるほど、なぜプロジェクトは止まるのか
AIが速くするのは、個々の作業である。
プロジェクト全体の速度を決めるのは、文脈・判断・責任を同期する構造である。
生成AIによって、ソフトウェア開発の実装速度は大きく上がりました。
コードを書く。テストを作る。既存コードを調査する。設計案を比較する。移行手順を作る。これまで数日かかっていた作業が、数時間、場合によっては数十分で終わるようになっています。
ところが、実装が速くなったからといって、プロジェクト全体が同じ倍率で速くなったとは限りません。
実装は終わっているのに、顧客確認で止まる。設計案は出ているのに、誰も決められない。レビュー対象が増え、承認待ちが積み上がる。複数人が並行して作業した結果、変更同士が衝突する。運用部門へ引き継ぐ段階になって、前提条件の説明をやり直す。
こうした状況を見ると、AI時代の次のボトルネックは、単に「人間同士が会話すること」ではなく、もう少し正確には次のように表現できると思います。
複数の人間の間で、文脈・判断・責任を同期すること。
以下では、プロジェクトにおけるコミュニケーションを、会議やチャットの量ではなく、仕事を前へ進めるための「同期構造」として考えます。
実装速度とプロジェクト速度は同じではない
では、個々の作業が速くなっても、プロジェクト全体が同じようには速くならないのはなぜでしょうか。工程ごとの時間に分けて考えてみます。
プロジェクトには、実装以外にも多くの工程があります。
要求整理
↓
要件の確認
↓
設計
↓
設計レビュー
↓
実装
↓
テスト
↓
受入確認
↓
リリース判断
↓
運用引継ぎ
AIは、このうち設計案の作成、実装、テスト生成、調査、文書化などを大きく高速化します。
しかし、工程間に存在する次のような活動は、自動的には同じ倍率で速くなりません。
- 背景を理解する
- 用語や前提をそろえる
- 選択肢を比較する
- リスクを受け入れる
- 誰が決めるかを決める
- 誰が責任を持つかを明確にする
- 他チームとの依存関係を調整する
たとえば、以下は単純化した例です。
| 工程 | AI導入前 | AI導入後 |
|---|---|---|
| 要求・要件整理 | 2日 | 2日 |
| 実装 | 5日 | 0.5日 |
| レビュー待ち | 2日 | 2日 |
| 顧客確認・承認 | 3日 | 3日 |
| 合計 | 12日 | 7.5日 |
実装は10分の1になっていますが、プロジェクト全体は10分の1にはなりません。
実装が重かった時代には見えにくかった「待ち時間」が、相対的に大きく見えるようになるからです。
この構造は、製造工程の一部分だけを高速化したときに、仕掛品が次の工程へ滞留する状況と似ています。実装という工程の能力が上がるほど、レビュー、判断、承認、運用といった別の工程が新しい制約になります。
コミュニケーションコストは「話している時間」ではない
コミュニケーションコストと聞くと、会議時間、Slackのメッセージ数、メールの往復回数を思い浮かべがちです。
しかし、プロジェクトを遅らせる本当のコストは、話している時間だけではありません。
たとえば、仕様変更について担当者がチャットへ投稿したとします。情報を送信したという意味では、コミュニケーションは行われています。
しかし、プロジェクト上はまだ完了していません。
- 関係者が投稿の存在に気づく
- 背景と影響範囲を理解する
- 言葉や前提の意味をそろえる
- 選択肢を比較する
- 誰かが方針を決める
- 担当者、期限、受入条件を確定する
- 後続作業が実際に始まる
ここまで進んで、初めてコミュニケーションが仕事を前へ動かしたと言えます。
したがって、プロジェクトにおけるコミュニケーションボトルネックは、次のように定義すると扱いやすくなります。
複数者の認識・判断・責任の同期が完了しないために、後続作業へ待機、手戻り、過剰確認、局所最適が発生している状態。
概念的には、コミュニケーションによる遅延は次の合計として捉えられます。
コミュニケーションによる遅延
= 情報探索時間
+ 文脈再構築時間
+ 意味合わせ時間
+ 判断待ち時間
+ 承認待ち時間
+ 依存関係の調整時間
+ 誤解による手戻り時間
重要なのは、「伝えたか」ではありません。
次の行動が始められる状態になったかです。
プロジェクトを「作業ノード」と「同期エッジ」で見る
プロジェクトをグラフとして考えてみます。
- 要求整理、設計、実装、テストなどの作業を「ノード」
- ノード間で必要になる説明、確認、判断、承認を「エッジ」
とします。
[要求整理] --要件確認--> [設計] --レビュー--> [実装] --受入確認--> [リリース]
従来は、各ノードの作業自体が重かったため、プロジェクト期間の多くを実作業が占めていました。
AIはノードを軽くします。
[要求整理] --要件確認--> [設計] --レビュー--> [実装] --受入確認--> [リリース]
速い 速い とても速い
↑ エッジの待ち時間は残る
すると、エンドツーエンドのリードタイムに占めるエッジの比率が上がります。
この見方をすると、AI時代のプロジェクト改善は、「各担当者をさらに速くすること」だけでは不十分だと分かります。
考えるべきなのは次の三点です。
- どの同期エッジをなくせるか
- どの同期エッジを短くできるか
- どの同期エッジだけを人間に残すべきか
個人の生産性を最大化しても、同期エッジに成果物が滞留すれば、プロジェクト全体のスループットは上がりません。
プロジェクトを止める7つのコミュニケーションボトルネック
「コミュニケーションが悪い」という表現だけでは、問題を改善できません。
どこで同期が止まっているのかを、もう少し細かく分ける必要があります。
1. 情報発見ボトルネック
必要な情報は存在するものの、必要な人が見つけられない状態です。
情報が、チャット、チケット、メール、設計書、会議録、口頭説明へ分散しています。資料を一か所へ集めても、量が多すぎて何を見ればよいか分からなければ、実質的には見えていません。
問題は、情報を保存したかではなく、
必要な情報が、必要なタイミングで、必要な人に浮上するか
です。
2. 文脈再構築ボトルネック
結論は残っているものの、その判断に至った背景が残っていない状態です。
たとえば、次の記録だけがあるとします。
今回はAPI連携を見送る。
後から参加した人が本当に必要とするのは、次の情報です。
- なぜ見送ったのか
- どの案と比較したのか
- 当時どのような制約があったのか
- どのリスクを許容しなかったのか
- どの条件が変われば再検討するのか
- 誰が最終判断したのか
この情報が残っていないと、過去の会議を探し、複数人へ聞き取りを行い、判断の文脈を再構築する必要があります。
3. 意味合わせボトルネック
同じ情報を見ていても、言葉の意味や期待値がそろっていない状態です。
プロジェクトでは、次のような言葉が特に危険です。
- 完成
- テスト済み
- 軽微な変更
- 標準対応
- 本番利用可能
- 対応可能
- 影響なし
たとえば、開発者の「対応可能」は「技術的には実装できる」という意味かもしれません。一方、顧客の「対応可能」は「期限、予算、品質、運用を含めて提供できる」という意味かもしれません。
情報共有量を増やしても、意味がそろわなければ手戻りは減りません。
必要なのは、用語の定義、受入条件、具体例、非該当例です。
4. 意思決定ボトルネック
判断材料はそろっているものの、方針が決まらない状態です。
原因はさまざまです。
- 最終判断者が不明
- 判断者が多忙
- 小さな判断まで上位者へ集中している
- 判断基準が言語化されていない
- 失敗時の責任を誰も引き受けたくない
- 全員の合意を必要としている
- 会議の目的が説明なのか判断なのか不明
AIは、設計案や選択肢を大量に作れます。しかし、何を優先し、何を捨て、どのリスクを受け入れるかは、人間の判断です。
生成能力が増えるほど、判断能力が新しい制約になります。
5. レビュー・承認キューボトルネック
設計レビュー、セキュリティ審査、品質確認、顧客承認などが、特定の人や組織に集中している状態です。
一件のレビュー作業は30分でも、着手されるまで3日待つことがあります。
この場合、問題は作業時間ではなく、キューに並んでいる時間です。
AIによって成果物の生成量が増えれば、レビュー対象も増えます。レビューする側の能力や仕組みを変えなければ、プロジェクト全体はかえって詰まりやすくなります。
6. 依存関係調整ボトルネック
複数のチームが、同じAPI、データ、環境、専門家、リリース日程に依存している状態です。
各チームが個別には速くても、全体では次の問題が起きます。
- 一方の仕様変更によって他方が手戻りする
- リリース順序を決められない
- テスト環境の利用待ちが発生する
- 共通部品の変更に多数の合意が必要になる
- 責任境界で問題が落ちる
これは会話の仕方だけで解消できる問題ではありません。
アーキテクチャ、契約、権限、責任境界といった構造そのものを見直す必要があります。
7. 例外・エスカレーションボトルネック
通常ケースは自動化され、難しい例外だけが人間に集中している状態です。
AI導入後、人間が処理する件数は減っても、一件あたりの難度は上がります。
- 情報が不足している
- 複数の制約が衝突している
- 正解が一つではない
- 影響範囲が広い
- 誰かがリスクを引き受ける必要がある
このとき、件数だけを見て「人間の仕事が減った」と判断すると、実際の認知負荷を見誤ります。
AIはコミュニケーション負荷を減らすだけではない
AIは、情報収集や文章作成を効率化するため、コミュニケーションコストを減らすように見えます。
しかし、同時に別の負荷を増やします。
選択肢が増える
以前は実装が高価だったため、複数案のうち一つを選んでから作っていました。
AIによって試作が安くなると、複数案をすべて作れます。
これは有益ですが、その後には比較と判断が必要です。
作ることが制約ではなくなり、「どれを採用するか」が制約になります。
並行作業が増える
各メンバーがAIを使えば、同時に着手できる変更が増えます。
しかし、並行作業が増えるほど、設計の不整合、重複実装、同一箇所への変更、リリース順序の衝突も増えます。
個人の作業量は増えても、チーム全体の整合性を保つ負荷は高くなります。
成果物が増える
AIはコード、テスト、設計書、調査結果、チケット、議事録を大量に生成します。
しかし、生成できる量と、組織がレビューし、判断し、受け入れられる量は別です。
生成能力が10倍になっても、レビュー能力が2倍にしかならなければ、レビューキューが膨らみます。
局所最適が速くなる
各担当者が、自分の範囲を高速に改善できるようになります。
しかし、プロジェクト全体の目的や設計方針とずれた改善も、同じように速く進みます。
AIは正しい方向への作業だけでなく、誤った方向への作業も加速します。
そのため、全体の目的、判断基準、境界、受入条件を共有する重要性は、むしろ高くなります。
AIは「同期の前後処理」に使う
人間同士のコミュニケーションをAIに置き換えればよい、という話ではありません。
価値観の衝突、優先順位、リスク受容、責任の引受けは、人間が行う必要があります。
AIが特に力を発揮するのは、人間が質の高い判断を短時間で行えるように、同期の前後を整えることです。
判断前にAIへ任せやすいこと
- 関係資料を収集する
- 過去の意思決定を検索する
- 背景と制約を整理する
- 論点を抽出する
- 用語や前提の食い違いを指摘する
- 選択肢と比較軸を作る
- 影響するシステムや関係者を抽出する
- 不足している判断材料を示す
判断後にAIへ任せやすいこと
- 決定事項と理由を構造化する
- 担当者、期限、受入条件を抽出する
- 影響を受ける関係者へ通知する
- 未決事項を追跡する
- 前提条件の変化を監視する
- 過去の判断と矛盾する変更を検出する
- 再検討条件を満たしたときに通知する
人間に残るのは、次のような仕事です。
- 何を問題として扱うか
- 何を優先し、何を捨てるか
- どのリスクを受け入れるか
- 誰が責任を引き受けるか
- 利害対立をどう解消するか
- 例外時に何を守るか
AIの役割は、判断そのものを曖昧に代替することではありません。
人間が判断できる状態を作り、その判断を次回再利用できる形で残すこと。
すべてのコミュニケーションを同じ方法で扱わない
プロジェクト内のコミュニケーションは、少なくとも四つに分けると整理しやすくなります。
| 種類 | 主な内容 | 向いている方法 |
|---|---|---|
| 事実伝達 | 進捗、数値、状態、予定 | 非同期、自動通知、ダッシュボード |
| 文脈共有 | 背景、経緯、制約、影響 | 構造化文書、検索、AI要約 |
| 判断 | 選択肢、トレードオフ、リスク受容 | 論点を絞った同期対話 |
| 関係・責任 | 信頼形成、対立解消、期待調整、責任の引受け | 人間同士の直接対話 |
進捗報告を会議で一人ずつ読み上げる必要はありません。事実伝達は非同期化できます。
一方、利害が衝突する判断や、失敗時の責任を誰が引き受けるかという話を、チャットのリアクションだけで終わらせるのも危険です。
原則として、次のように分けるのがよいと思います。
事実は非同期化する。
文脈は検索可能にする。
判断と責任は、人間が短く同期する。
目的は会議をゼロにすることではありません。
人間の対話を、価値観、優先順位、トレードオフ、責任といった、本当に同期が必要な論点へ集中させることです。
コミュニケーション構造を改善する4つの操作
コミュニケーションボトルネックへの対応を、四つの操作に整理してみます。
1. 同期点を消す
最も速いコミュニケーションは、そもそも必要のないコミュニケーションです。
- 不要な承認を廃止する
- 権限を現場へ移す
- チーム間の依存関係を減らす
- 一つのチームが完結して判断・実行できる範囲を広げる
- 自明な判断をルールや自動処理へ変える
問題が起きるたびに会話を増やすのではなく、なぜ毎回その会話が必要になるのかを見直します。
2. 同期範囲を狭める
同期が必要でも、全員を参加させる必要はありません。
- 最終判断者を明確にする
- 相談対象と承認対象を分ける
- 責任境界を明確にする
- APIやデータの契約を強くする
- 一つの変更に必要な文脈を局所化する
「全員が知っている」ことと、「全員の合意が必要である」ことは別です。
3. 同期時間を短くする
会議の中で、背景説明から始めないようにします。
- 事実は事前に共有する
- AIに関係資料を集めさせる
- 論点、選択肢、判断基準を事前に整理する
- 会議では未解決の判断だけを扱う
- 会議の終了条件を「説明完了」ではなく「判断完了」にする
30分の会議を15分に短縮するより、30分のうち25分を占めていた文脈説明を事前に終わらせる方が効果的です。
4. 判断を再利用する
同じ議論を繰り返さないようにします。
- 意思決定と理由を記録する
- 適用範囲と例外を残す
- 再検討条件を明示する
- 繰り返される判断をルールへ変える
- 判断基準をチェックリストやテンプレートへ変える
- AIから検索できる形で保存する
一度行った判断を、次回もゼロから再計算しないことが重要です。
議事録より「判断の構造」を残す
従来の議事録は、「誰が何を話したか」を時系列で残すことが中心でした。
しかし、後から必要になるのは、発言の全文ではありません。
- 何を決めたか
- なぜ決めたか
- どの選択肢を捨てたか
- 判断時の前提条件は何か
- どの範囲に適用されるか
- どのリスクを受け入れたか
- 誰が責任を持つか
- どの条件が変われば再検討するか
この情報があれば、後続メンバーは過去の会話を再生しなくても、判断の構造を理解できます。
アーキテクチャ上の重要な意思決定と、その背景・選択肢・理由を記録する実践として、ADR（Architecture Decision Record）があります。ここではこの発想を、アーキテクチャ設計に限らず、要件、運用、リスク受容、責任分界を含むプロジェクト全体の意思決定へ広げます。たとえば、次のようなDecision Recordが考えられます。
decision:
今回決めたこと
context:
背景、目的、現在の制約
options:
- 選択肢A
- 選択肢B
- 選択肢C
decision_criteria:
判断に使った基準
outcome:
採用した案と、その理由
rejected_options:
採用しなかった案と、その理由
risks_accepted:
受け入れたリスク
scope:
この判断が適用される範囲
owner:
最終判断者
revisit_conditions:
再検討する条件
AIは、会議やチャットからこの構造を抽出できます。
さらに、過去のDecision Recordを検索し、現在の議論に関係する判断を提示したり、前提条件の変化を検出したりできます。
単に会話を保存するのではなく、
会話から再利用可能な判断知を作る
ことが重要です。
会議時間ではなく「待ち時間」を測る
コミュニケーション改善のKPIとして、会議時間やメッセージ数だけを見るのは危険です。
重要な判断のための会議まで減らしてしまう可能性があるからです。
測るべきなのは、仕事が前へ進むまでの時間です。
| 指標 | 見ているもの |
|---|---|
| 意思決定リードタイム | 論点が生まれてから方針が決まるまでの時間 |
| ハンドオフ待機比率 | 作業期間のうち、他者の返答や作業を待っている割合 |
| レビューキュー滞留時間 | レビュー作業ではなく、着手されるまでの時間 |
| 文脈再構築時間 | 背景や過去経緯を調べ直す時間 |
| 認識違いによる手戻り率 | 誤解、要件漏れ、判断変更による再作業 |
| 意思決定参加人数 | 一つの判断に実質的な同期が必要な人数 |
| エスカレーション深度 | 判断確定までに上がる組織階層数 |
| 同一質問の再発率 | 過去の判断や知識が再利用されず、同じ質問が繰り返される割合 |
特に最初は、次の二つだけでも有効です。
- 意思決定に何日待ったか
- 他者の返答や作業を何日待ったか
実装時間が短くなった後、プロジェクトの遅延要因を調べると、作業時間より待ち時間の方が長いケースが増えていくはずです。
まず、一つの「遅れた変更」を分解する
コミュニケーション構造を改善するために、最初から組織全体の会議を棚卸しする必要はありません。
直近で遅れた変更を一つ選び、次の問いで分解します。
- 何が止まっていたのか
- 誰、または何の返答を待っていたのか
- 必要だったのは、事実、文脈、判断、承認、責任のどれか
- 最終判断者は明確だったか
- 判断に必要な情報はどこにあったか
- 誰の頭の中にしかない文脈があったか
- 何人の同期が必要だったか
- その同期点は本当に必要だったか
- 次回は削除、権限移譲、非同期化、ルール化、AI化できるか
- 今回の判断を再利用できる形で残したか
「コミュニケーションが悪かった」で終わらせず、たとえば次のように具体化します。
- セキュリティレビューの着手待ちに4日かかった
- 顧客要件の判断根拠が一人の担当者の頭の中にしかなかった
- 最終判断者が不明で、5人の合意を取っていた
- 過去の判断理由が残っておらず、同じ議論をやり直した
- 会議時間の大半を、事前共有可能な状況説明に使っていた
ここまで具体化できれば、コミュニケーションは個人の話し方ではなく、改善可能な設計問題になります。
コミュニケーション能力から、コミュニケーション・アーキテクチャへ
これまで、コミュニケーションの問題は、個人の能力として扱われることが多くありました。
- 説明が分かりにくい
- 報告が遅い
- 会議が長い
- 関係者調整が苦手
- 情報共有が足りない
もちろん、個人のスキルは重要です。
しかし、AI時代に必要なのは、それだけではありません。
誰が、誰と、何について、いつ同期するのか。
どこまでを非同期にし、どこからを人間の判断にするのか。
その判断を、どのように保存し、再利用するのか。
この構造そのものを設計する必要があります。
これを 「コミュニケーション・アーキテクチャ」 と呼びたいと思います。
コミュニケーション・アーキテクチャが扱うのは、たとえば次のような設計です。
- 情報の置き場所
- 意思決定権限
- 承認経路
- チーム間の責任境界
- 同期と非同期の使い分け
- エスカレーション条件
- Decision Recordの形式
- AIが支援する範囲
- 人間が直接対話すべき条件
AI時代のプロジェクトマネジメントでは、タスクを分解して割り当てる能力に加えて、この同期構造を設計する能力が重要になると考えます。
おわりに
AIによって、個人が作業を完了する速度は大きく上がります。しかし、プロジェクトの速度は、最も速い個人によって決まるわけではありません。文脈が伝わるまでの時間、判断が確定するまでの時間、責任者が決まるまでの時間、他チームとの依存関係が解消するまでの時間——こうした同期の速度によって決まります。
AIが速くするのは、主に作業ノードです。だからこそ、これからは同期エッジを意図的に設計する必要があります。そのための操作は、本文で述べた「消す・狭める・短くする・再利用する」の四つに集約できます。そして、その効果は、まず会議時間ではなく、判断待ちとハンドオフ待ちで測ります。
AI時代のコミュニケーション課題は、「もっと会話するか、会議を減らすか」という二択ではありません。
人間同士が同期しなければならない場所を、プロジェクト全体の構造として設計すること。
これが、実装が速くなった後のプロジェクトを、本当に速くするための次のテーマではないでしょうか。