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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大事なのは：

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

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

実装に落とし込むと

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

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

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

結論

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

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