全体最適という幻想と、個別最適の衝突から生まれる本物
「全体最適を考えて動いてください」
マネジメント層からよく聞くこの言葉。でも、正直なところ「それって具体的に何?」って思いませんか。
最近、自分でもよくわからなくなってミスったので、その反省を書きます。
サッカーで考える全体最適の罠
まず例え話として、サッカーのボランチ(守備的ミッドフィルダー)の話をしましょう。
ボランチの選手が「チームの方針のことを考えて」守備重視でプレーしたとします。攻撃参加を控えて、ディフェンスラインの前でがっちり守る。一見、全体最適っぽいですよね。
でも結果はどうでしょう。
- 中盤の攻撃力が落ちる
- 前線が孤立する
- 得点チャンスが激減する
- 結局、守備的なのに失点も防げない
なぜこうなるのか。それは、ボランチが「想像上の全体最適」を追いかけたからです。
個別最適の衝突が生む本当の最適解
本来なら、こうあるべきでした:
- ボランチ「俺は攻守のバランスを取りたい」
- センターバック「もっと前線をカバーしてくれ」
- オフェンシブMF「もっと前に出てきて欲しい」
この「個別最適のぶつかり合い」から、議論が生まれます。そして監督(上位レイヤー)と擦り合わせた結果、「今日は相手が強いから守備7:攻撃3でいこう」といった具体的な全体最適が見えてくる。
エンジニアリングでも同じですよね。
- フロントエンド「UXを最高にしたい」
- バックエンド「パフォーマンスを追求したい」
- インフラ「コストを抑えたい」
この個別最適をぶつけ合って、初めて「今回のプロダクトではUX重視で、でもレスポンスは500ms以内」みたいな落とし所が見つかる。
マネジメント層が陥りがちな罠
「全体最適を考えて」と言いながら、実は抽象的な理想論を勝手に想像していませんか?
マネジメント層は確かに一つ上のレイヤーの優先度を意識する必要があります。でも、それに寄せすぎて個別最適を無視すると、チームは「で、結局何すればいいの?」状態になります。
大事なのは:
- 各メンバーの個別最適を引き出す
- それらを戦わせる場を作る
- 上位の優先度と擦り合わせる
- 具体的な行動指針に落とし込む
この「議論を戦わせる」プロセスを飛ばして、いきなり全体最適を取りに行くから破綻するのかなと
実装に落とし込むと
コードレビューでもよくある話です。
「もっと全体のアーキテクチャを考えて」という抽象的なフィードバックより、「このモジュールの責務はXXだから、この処理は別モジュールに」という具体的な議論の方が建設的。
個別最適(各モジュールの責務)を明確にして、それらの関係性を議論することで、結果的に良いアーキテクチャ(全体最適)が生まれる。(ちょっと違うか…?)
結論
つまり”全体最適”とは、個別最適の議論を戦わせる姿勢 + 結論を軌道修正してそれにコミットする動き ということ。全体最適は”目指すもの”じゃなくて”個別最適をぶつけあった結果として生まれるもの”。
個別最適を主張して、他の個別最適とぶつけて、上位レイヤーと擦り合わせる。このプロセスを大切にすることが、本当の全体最適への道なんじゃないでしょうか。