コードと数字に強いエンジニアが陥る「人間系」と「全体像」の罠
元シティバンクの金利トレーダーであるGary Stevenson氏のインタビュー動画の中で、非常に示唆に富む言葉がありました。
「数字や数学にとても強い人の多くは、物事の人間的な側面や全体像を理解することが得意でない人が多い」
動画内では主にマクロ経済学や金融市場の文脈で語られた話ですが、これを聞いて「まさにソフトウェアエンジニアリングや組織マネジメントの現場でも全く同じことが起きている」と感じた方は少なくないはずです。
ロジックを極め、数理的・決定論的に物事を組み立てる能力は、エンジニアにとって最大の武器です。しかし皮肉なことに、その武器への過度な依存と思考の偏りが、時にプロダクトの失敗やチームの機能不全を引き起こす根本原因になります。
なぜ「数字やロジックに強いエンジニア」ほど人間系や全体像を見失いやすいのか。現場で起きている2つの構造的な罠と、そこから抜け出すための視座の転換を掘り下げていきます。
1. なぜ「数字や論理に強い人」は局所最適に沈むのか
エンジニアの日常は、極めて明確なルールに支配されています。
型システム、アルゴリズムの計算量、クエリの実行計画、単体テストの成否――。これらはすべて「入力に対して明確な出力が返ってくる」閉じた世界です。数学やコーディングが得意な人ほど、こうした決定論的でコントロール可能な空間で圧倒的なパフォーマンスを発揮します。
しかし、一歩ズームアウトした瞬間、ソフトウェア開発を取り巻く現実は曖昧で非決定論的な要素で満ちています。
Gary Stevenson氏は動画の中で、現代のエコノミストが数理モデルばかりに夢中になり、一般市民の生活実感や心理という現実から乖離して予測を外し続けた構図を指摘していました。英語の慣用句で言う「You can’t see the wood for the trees（木を見て森を見ない）」の状態です。
エコノミストたちは「ゼロ金利にすれば理論上は消費が増えるはずだ」と机上のモデルを信じ込んでいましたが、Gary氏が一般庶民の友人に直接話を聞くと「そもそも金がないからこれ以上使えるわけがない」という切実な現実が返ってきました。数式に没頭するエリートたちは、「生身の人間の生活（人間的側面）」と「富が富裕層へ急速に移転している（全体像）」という現実にまったく目を向けていなかったわけです。
これ、開発現場でも本当によく見かける光景なんですよね。
「数式やコードとして綺麗に表現できる部分」に没頭するあまり、その外側にある「誰がどう使うのか（生身のユーザー心理）」や「何のためにこれを作っているのか（事業の全体像）」から視線が外れてしまうのです。
2. 現場で起きる2つの構造的な罠
「モデルの正しさに惹かれ、生身の人間の現実を計算から除外してしまう」という認知の歪みは、組織の内部（協働関係）と外部（ユーザー・事業）の双方で、極めて不条理な形で噴出します。
罠1：チーム組織を「無機質な論理モデル」として扱う過ち（内側の人間系の欠落）
技術力が高くロジックに長けたエンジニアほど、アーキテクチャの設計において「ドメイン境界」や「責務の分離」を完璧に定義しようとします。コンウェイの法則を意識し、「アーキテクチャに合わせてチーム編成を疎結合に切り分けよう（逆コンウェイ操縦法）」と論理的に組み立てることすらあるでしょう。
しかし、それでもなお現場が破綻するケースが後を絶ちません。なぜなら、「組織図の箱と矢印」の裏にある生身の人間の感情、信頼関係、コミュニケーション摩擦を変数から除外してしまうからです。
ホワイトボードの上では、チームAとチームBをドメインごとに分割し、明確なAPIインターフェースを定義すれば、お互いに不可侵で並行開発できるように見えます。しかし、現実の人間はAPIのように動きません。
- チーム間の心理的距離が開いた結果、「仕様の違和感」をカジュアルに相談できなくなり、結合段階で大規模な認識ズレが発覚する。
- 「自分たちのドメインの責務ではない」という論理的正当性を盾に、境界領域のバグや仕様調整の押し付け合い（感情的な摩擦）が起きる。
- メンバー個々のスキル習得速度や認知負荷を無視して理論上の最適分担を強いた結果、特定メンバーへの過負荷とバーンアウトを引き起こす。
人間組織を「無機質なグラフ構造」として捉え、感情や関係性といった泥臭い人間系を捨象した設計は、どれほど論理的に正しく美しくても現場の運用に耐えられません。
罠2：「仕様の論理的正しさ」に閉じこもり、ユーザー体験と事業価値を見失う過ち（外側の人間系と全体像の欠落）
もう一つの深刻な罠は、プロダクトの価値を評価する基準が「技術的・論理的な無矛盾性」だけに閉じてしまい、画面の向こうにいる生身の人間と事業の目的（全体像）が見えなくなることです。
数理やコードに強い人ほど、「要件定義書に書かれたロジック通りに、コーナーケースまで破綻なく完璧に動くシステム」を構築することに知的好奇心とプライドを感じます。しかし、生身の人間がプロダクトを使うプロセスは、極めて非論理的で感情的です。
- 「正しいが使えない」機能の量産: 仕様としては1ミリの破綻もなく、すべての例外処理が網羅されている。しかし、ユーザーの実際の業務フローや操作時のストレス、認知的負荷（人間的側面）に思いが至っていないため、極めて操作性が悪く現場から敬遠される。
- 局所的な完璧主義と事業の死: 「このデータ整合性は数学的に厳密に保たれなければならない」「将来の拡張性に備えて完璧な抽象化レイヤーを敷くべきだ」と手元のコードベースの論理的純粋性に没頭する。しかし、事業全体（全体像）を見渡せば、今求められているのは「2週間後に市場の仮説を検証するための泥臭いMVP」であり、半年かけて作った完璧な設計はリリースの遅れによって事業ごと無価値になる。
Gary Stevenson氏が指摘したエコノミストたちも、「数理モデルの中の変数」ばかりを熱心に計算し、「現場の一般人が実際にどうお金を使い、何に苦しんでいるか」を見に行きませんでした。
エンジニアも全く同じです。エディタとIssueトラッカーという「閉じた論理の世界」に引きこもり、生身のユーザーがどんな表情で画面に向かい、どんな痛みを抱えているのか（人間系）、そして事業が今どの局面にあって何を生き残りの賭けにしているのか（全体像）を泥臭く見に行かないこと。これこそが、数字やロジックに強い人が陥る最大の盲点です。
3. 「人間系と全体像」を捉えるための視座の転換
数字やロジックの強さを殺さずに、人間系と全体像を捉えられるエンジニアやテックリーダーになるには、どこへ視座を移すべきなのでしょうか。
① 認知負荷（Cognitive Load）を主変量として設計する
『チームトポロジー』でも提唱されているように、現代のソフトウェア開発において最も制約となるリソースは、サーバーのスペックでもネットワーク帯域でもなく、人間の脳のメモリ（認知負荷）です。
アーキテクチャやコードベースの良し悪しを判断する基準を、「理論的な純粋さ」から「生身のチームやユーザーが抱える認知的・感情的負荷が許容範囲に収まっているか」へシフトさせる必要があります。
- ドメインモデルとしては共通化するのが論理的に正しいが、あえて重複を持たせた方がチーム間の合意形成コスト（人間系の摩擦）を減らせる。
- 最新で表現力の高い技術スタックを採用するより、チーム全員が慣れ親しんだ枯れた技術を使った方が、事業の不確実な領域に脳のリソースを集中できる。
- システムの整合性を守るための複雑な入力バリデーションを組むより、ユーザーのメンタルモデルに寄り添ったUI設計にして「そもそも迷わせない」構造を作る。
こうした「泥臭いが人間系に適った判断」を下せるかどうかが、シニアエンジニアとしての分水嶺になります。
② 「正しさ」の証明ではなく「文脈」の同期に時間を使う
どれほど優れたアーキテクチャや仕様であっても、関係者がその背景にある「なぜ（Why）」を腹落ちしていなければ機能しません。
ロジックに自信がある人ほど、結論の正しさを一方的に証明（プレゼン）しようとしがちです。しかし本当に必要なのは、自分が見ている「全体像の解像度」をチーム全体に共有することです。
- なぜ今この技術的負債を返済することが、半年後のビジネス展開において不可欠なのか。
- なぜこのリファクタリングを後回しにしてでも、競合より先に泥臭いUI変更をリリースしなければならないのか。
- 画面の向こうにいるユーザーは、今どのような業務上のペインに苦しんでおり、この変更でどう感情が動くのか。
ビジネス側の思惑、顧客の置かれた状況、チームメンバー個々のモチベーション。そうした「非技術的な定性情報」を自ら現場へ拾いに行き、コードの設計思想と結びつけて語れるようになること。それこそが、全体像を捉えたエンジニアリングの姿です。
4. ロジックの向こう側にあるもの
コードや数式に向き合っている時間は、エンジニアにとって極めて居心地が良いものです。入力に対して明確な出力が返り、自分の知性でコントロール可能な決定論的で嘘をつかない世界だからです。
しかし、Gary Stevenson氏が数理モデルに没頭するエコノミストたちを評したように、数字やロジックへの強い適性は、時に「生身の人間の感情」や「不条理な現実の全体像」に対する強烈な盲点を生み出します。
私たちが解くべき本質的な課題は、いつだってコードエディタや設計図の外側にあります。
論理的思考や数理的な強さを手放す必要はありません。それは間違いなく強力な武器です。ただし、その切れ味鋭い刃を、閉じたモデルの純粋性を守るためだけに振るうのではなく、チームの認知負荷を和らげたり、ユーザーの切実な痛みを解消したり、事業の生き残りをかけた文脈を読み解くために使っていく。
「木」であるロジックを極めた上で、恐れずに「森」である人間系と全体像の泥臭さに踏み込んでいけるかどうか。そこに、単なる作業者を超えたシニアエンジニアやテックリーダーとしての真の価値があるのだと思います。
