全体最適という幻想と、個別最適の衝突から生まれる本物

Posted on 2025.07.06

「全体最適を考えて動いてください」

マネジメント層からよく聞くこの言葉。でも、正直なところ「それって具体的に何?」って思いませんか。

最近、自分でもよくわからなくなってミスったので、その反省を書きます。

サッカーで考える全体最適の罠

まず例え話として、サッカーのボランチ(守備的ミッドフィルダー)の話をしましょう。

ボランチの選手が「チームの方針のことを考えて」守備重視でプレーしたとします。攻撃参加を控えて、ディフェンスラインの前でがっちり守る。一見、全体最適っぽいですよね。

でも結果はどうでしょう。

  • 中盤の攻撃力が落ちる
  • 前線が孤立する
  • 得点チャンスが激減する
  • 結局、守備的なのに失点も防げない

なぜこうなるのか。それは、ボランチが「想像上の全体最適」を追いかけたからです。

個別最適の衝突が生む本当の最適解

本来なら、こうあるべきでした:

  1. ボランチ「俺は攻守のバランスを取りたい」
  2. センターバック「もっと前線をカバーしてくれ」
  3. オフェンシブMF「もっと前に出てきて欲しい」

この「個別最適のぶつかり合い」から、議論が生まれます。そして監督(上位レイヤー)と擦り合わせた結果、「今日は相手が強いから守備7:攻撃3でいこう」といった具体的な全体最適が見えてくる。

エンジニアリングでも同じですよね。

  • フロントエンド「UXを最高にしたい」
  • バックエンド「パフォーマンスを追求したい」
  • インフラ「コストを抑えたい」

この個別最適をぶつけ合って、初めて「今回のプロダクトではUX重視で、でもレスポンスは500ms以内」みたいな落とし所が見つかる。

マネジメント層が陥りがちな罠

「全体最適を考えて」と言いながら、実は抽象的な理想論を勝手に想像していませんか?

マネジメント層は確かに一つ上のレイヤーの優先度を意識する必要があります。でも、それに寄せすぎて個別最適を無視すると、チームは「で、結局何すればいいの?」状態になります。

大事なのは:

  1. 各メンバーの個別最適を引き出す
  2. それらを戦わせる場を作る
  3. 上位の優先度と擦り合わせる
  4. 具体的な行動指針に落とし込む

この「議論を戦わせる」プロセスを飛ばして、いきなり全体最適を取りに行くから破綻するのかなと

実装に落とし込むと

コードレビューでもよくある話です。

「もっと全体のアーキテクチャを考えて」という抽象的なフィードバックより、「このモジュールの責務はXXだから、この処理は別モジュールに」という具体的な議論の方が建設的。

個別最適(各モジュールの責務)を明確にして、それらの関係性を議論することで、結果的に良いアーキテクチャ(全体最適)が生まれる。(ちょっと違うか…?)

結論

つまり”全体最適”とは、個別最適の議論を戦わせる姿勢 + 結論を軌道修正してそれにコミットする動き ということ。全体最適は”目指すもの”じゃなくて”個別最適をぶつけあった結果として生まれるもの”。

個別最適を主張して、他の個別最適とぶつけて、上位レイヤーと擦り合わせる。このプロセスを大切にすることが、本当の全体最適への道なんじゃないでしょうか。