アメーバ構造がもたらすもうひとつの問題は、意思決定の優先順位が常に流動的であることだ。
何を救い、何を捨てるか――その判断が誰にも明確に定義されていない。
それが、Googleの中枢にある“トリアージの難しさ”だ。
プロダクトの寿命が短くなる背景には、単なる人気や採算性だけでなく、「誰が判断するのか」という問題がある。
アメーバ構造では、プロジェクトの発案も中止も、複数の部署とレイヤーにまたがって行われる。
そのため、誰かが明確に「終わらせる」と決めない限り、システムは惰性で動き続ける。
現場では、リソースの再配分や人材の再配置が常に行われている。
だがその「優先順位の再調整」は、医療現場のトリアージに似ている。
最も救う価値のあるもの、まだ助かるもの、もう助からないもの。
それらを冷静に仕分けなければ、全体が崩壊する。
しかし、感情や社内政治、そして過去の栄光が絡むと、その判断は極端に難しくなる。
観測者の視点から見ると、
Google内部のトリアージは、明確なガイドラインよりも“空気の流れ”で動いているように見える。
明文化されない優先順位。
影響力のある人物や、注目されている領域のほうへ自然と資源が流れる。
だからこそ、誰も「判断していないのに、結果として判断されている」状態が生まれる。
情報面でも同じ構造がある。
Googleでは「Need to Know（知る必要がある人だけに知らせる）」という原則が強く働く。
これは機密保持のための合理的な設計だが、同時に“情報のトリアージ”でもある。
知らなくていいと判断された失敗や不具合は、共有の段階で切り捨てられ、別のチームが同じ問題を繰り返す。
つまり、知らされないこと自体が、学習の断絶を生んでいる。
AIやハードウェア領域など、リソースを要する部門ほどこの傾向は顕著だ。
Tensorの開発やPixelの設計チームは、他部署との連携を保ちながらも、トリアージの“実行者”としての役割を負っている。
つまり、誰が見ても続ける価値があるとされるプロジェクトを残し、そうでないものを静かに止める。
それが明示的に語られないまま、組織のDNAとして機能している。
トリアージがうまく機能すれば、リソースは効率的に循環する。
しかし、優先順位の基準が不透明だと、現場は常に「自分が切られる側ではないか」という恐怖と隣り合わせになる。
この緊張感がモチベーションを生む一方で、長期的な信頼関係を損ねる結果にもつながっている。
この構造的矛盾――誰も意思決定していないのに、誰かが結果として選別される――。
それはGoogleの強さの源であり、同時に脆さの象徴でもある。
次章では、この曖昧なトリアージがどのように“構造の老化”を生み、
やがて籠城戦へと変化していくのかを見ていく。
本稿はAIを共同編集者として用いましたが、内容と判断は私の意志に基づいています。