意思決定の遅延は、どこで生まれるのか

データ基盤への投資は、クエリを高速化した、レポートをリアルタイム化したという技術指標で評価されることが多い。事業成果に効くのは、データが得られてから意思決定が実行されるまでの時間のほうだ。技術遅延の削減は必要だが十分ではなく、残りの要因は組織構造の中にある。

どこに時間が溶けているか

データが得られてから意思決定が実行されるまでを分解すると、データ収集、クエリ実行、レポート生成、レポート閲覧、議論、合意形成、承認、実行指示、実行という段階が並ぶ。

Snowflake や BigQuery のようなクラウドデータウェアハウス、あるいは Databricks や ClickHouse のようなリアルタイム分析基盤への投資が効くのは、このうち最初の3段階だけである。クエリ最適化と適切なアーキテクチャがあれば、技術遅延は数分から数秒のオーダーまで落とせる。

残りの段階は組織的な遅延で、技術投資ではほとんど動かない。データが1秒で得られる組織でも、そのデータに基づく意思決定に2週間かかる。この非対称は多くの企業で観察される。並列に処理できるタスク数と待ち時間の関係を示す Little の法則の応用として理解できるし、API 契約における非推奨化の遅延にも同じ構造が現れる。

階層は掛け算で効く

意思決定プロセスの階層数は遅延の支配的要素になる。各承認者が平均2営業日で応答すると仮定すれば、3階層の承認プロセスは6営業日、およそ1.2週間の遅延を生む。

実測ではこの推定が楽観的すぎる。承認者のカレンダー空き状況、代理承認の可否、差し戻しの発生を織り込むと、実際の遅延は2週間から3週間に伸びることが多い。

階層を減らすには承認閾値の設計がいる。金額、影響範囲、リスク分類といった基準で、承認不要、上長のみ、経営会議の3段階に分ける設計は広く採用されている。基準が保守的すぎると実質的にほぼ全ての意思決定が経営会議に上がり、階層削減は機能しない。配送性能指標の設計と同様、境界の引き方が組織文化との衝突を伴う。

合意を取る範囲を決める

日本企業を含む多くの組織で採られている合意形成型の意思決定は、遅延と直接的なトレードオフの関係にある。関係者全員の理解と同意を得るためのコミュニケーションサイクルが増えるからだ。

文化を全面否定する処方箋は現実的でない。合意形成には実行段階でのコミットメントを高める効果があり、それを失えば実行遅延が増える。実務的な妥協は合意の対象を絞ることになる。意思決定の方向性、つまり何をやるかは少人数で決め、実装の詳細、どうやるかで関係者の合意を取る。

Amazon の disagree and commit 原則や Netflix の informed captain モデルは、この分割の異なる実装例といえる。ただし disagree and commit は Jeff Bezos が2017年の株主宛書簡で定式化した用語であって、組織全体で機能するかは心理的安全性の水準に依存する。反対意見を表明できない文化で commit だけを求めれば、意思決定は速くなるが実行段階の抵抗が増える。

速ければいいわけでもない

速い意思決定が常に良いとは限らない、重要な判断は熟考されるべきで遅延削減の目的化は危険だ、という反論がある。Kahneman が示したように、直感的な速い判断は複雑な状況で系統的な誤りを生む。

この反論は重要な判断と日常的な判断の区別を暗黙に前提としている。実務ではその区別が明示されず、日常的な判断まで重要な判断と同じ承認プロセスを通ることのほうが問題になる。判断の重要度でプロセスを分岐させる設計が、遅延削減と熟考を両立させる。

意思決定遅延の削減はデータ基盤への投資では達成できない。承認階層の見直し、合意対象の分割、重要度に応じたプロセス分岐といった組織設計が、技術投資の効果を事業成果に変換する条件になる。技術遅延だけを追いかけると、データはリアルタイムだが意思決定は月単位、という乖離が残る。