全体を見よう：目の前の成果にとらわれない思考法
この記事が役立つ人
- 様々な思考法について学んで実践したい人
- 駆け出しのエンジニア
「目の前の成果」に集中しすぎていない？
たとえば「営業成績を上げろ」と言われたとき、どう動くか。とりあえず契約をとる。そのために多少の無理をする。クレームが来る。でも目標は達成した。
そんな経験、心当たりがある人もいるかもしれない。
数字は確かに大事。でも、それって「全体としてうまくいってる」のかな？
この問いに向き合うのが「全体最適」の視点。
全体最適ってどういうこと？
一言でいえば、「全体の幸福や成果を優先する思考法」。
部分的にうまくいっても、全体が壊れたら意味がない。だから、最初から“全体が良くなる道”を考えていく。
これは、部分最適とは違う視点。
たとえば開発チームが納期に間に合わせることだけを考えて、設計ミスを見逃す。結果、運用コストが倍増する。
「目先だけでなく、長いスパン・広い視野で考えよう」というのが全体最適。
よくある“部分最適”の落とし穴
- 営業部だけがインセンティブ目当てで契約を急ぐ→サポート部が疲弊
- 家族の一人だけが我慢することで成り立つ生活→長期的に崩れる
- 目の前の勉強だけに集中→体調や人間関係を壊す
このように、「一部分の最適化」が全体の不調につながることは意外と多い。
◆ 因果関係の流れを図で考える
ここでは、こうした部分最適の流れを、因果関係としてフローチャートやProlog風の図で可視化する。
・どんな要素がつながっているか
・どこにフィードバックがかかっているか
・どの関係が好循環／悪循環を生むのか
そうした図を通して、「今どこを変えるべきか？」の判断が見えてくる。
フローチャート（悪循環モデル）
説明：目標達成がクレーム・疲弊・低下という“負の連鎖”にフィードバックしながらループしている構造。
疑似言語
目標 = 「営業成績を上げる」
if 目標が数値として設定されている:
動き = 「契約をとる」優先
方法 = 「多少の無理」含む
if 方法 == 無理:
顧客状態 = 不満
サポート状態 = 疲弊
チーム全体 = パフォーマンス低下
if チーム全体 == 低下:
本来の成果 = 減少
結果 = 「営業成績」だけは達成されたように見える
説明：if構造で因果を整理。「条件に従ってどんな流れが生じるか」をモデル化。
prolog
% 事実
目標(営業成績_向上).
手段(契約優先).
手段に伴う(契約優先, 無理をする).
無理をすると(クレーム).
クレームが来ると(サポート疲弊).
サポート疲弊が起きると(チームパフォーマンス低下).
チームパフォーマンス低下があると(全体成果の低下).
% ルール
成果見えるように(X) :- 目標(X), 手段(_), \+ 全体成果の低下.
説明：Prologでは 事実（Fact）とルール（Rule） で因果構造を記述。最後の成果見えるように(X)で、見かけの成果が得られる条件を定義。
「全体を見る力」はどう育てる？
じゃあ、どうやって“全体を見る”視点を持てばいいのか？
たとえば、こんなことから始められる。
- ステークホルダーの視点で考える
→自分だけでなく、同僚・顧客・上司・未来の自分の視点で見直す - フィードバック構造を意識する
→自分の行動が、どこに影響を与え、何が返ってくるのか - 静的構造と動的因果の違いを理解する
→組織の仕組みとその変化を、別々に見るようにする
挿入する図では、改善前後のモデルを比較する予定。
数字だけで見ていたものを、関係性でとらえ直す視点の転換がカギ。
prologで示すと以下のようになる。
% ルール：見かけの成果
見かけの成果(X) :-
目標(X),
手段(S),
手段に伴う(S, _),
\+ 全体成果の低下.
% ルール：本当に成果が上がる
本当の成果(X) :-
目標(X),
手段(S),
手段に伴う(S, 効果),
効果があると(良い影響),
全体成果の向上があると(良い影響).
まとめ：視野を広げると、判断も変わる
全体最適の視点は、すぐに習得できるものではない。
でも、「今、全体で見たらどうなんだろう？」と問いかけるだけで、行動は変わりはじめる。
小さな視野では見えなかった「大きな無駄」や「無理」が見えてくる。
そしてそれに気づけたとき、より健全で持続可能な判断ができるようになる。
Discussion