「上司が無能」だと思うエンジニアが見落としている組織構造の話

ある朝、LinkedInを眺めていて目に留まった一文がある。

この問題提起は興味深いと同時に、熟考を要するものだった。なぜなら、この認識には組織や役割に対する様々な前提が含まれているからだ。

「無能」とは何を指すのか

この文脈で「無能」が何を意味するのか、まず考察してみよう。実際の現場では以下のようなケースが存在する：

1. 優秀なエンジニアの上司が一般的なエンジニア
2. 技術力は乏しいが管理能力が高い上司
3. エンジニア経験がない非技術系管理者
4. 中小企業における非エンジニア上司

注目すべきは、これらが必ずしも「無能」を意味しないということだ。企業で上司になっているということは、少なくともその組織において求められる役割を果たしているはずである。では、なぜ「無能」という評価が生まれるのだろうか。

組織論から見る問題の本質

ここで思い出すのは、漫画『理想のヒモ生活』の1シーンで、自分が率いる兵たちが無能だとバカにする隊長に対する将軍のセリフだ。

この洞察は、組織運営の本質を突いている。普通の兵士と普通の隊長で機能する組織に、突出した能力を持つ人材を投入するとどうなるか？

優秀なエンジニア配属時のシナリオ分析

このような組織に優秀なエンジニアを配属するとどうなるのか。AIにシミュレーションを依頼したところ、以下の3つのシナリオが提示された：

シナリオA：適応的な変化 隊長が優秀な兵を準指導者として活用し、部隊全体の技能向上と作戦遂行能力の向上を実現する。

シナリオB：組織的抵抗 既存の権力構造維持のため優秀な兵が孤立し、本人の意欲低下や退職につながる。

シナリオC：制度的解決 本部が優秀な兵を適切な部隊へ転属させ、現状の部隊構造を維持しながら組織的ミスマッチを解消する。

統計的および心理学的な観点から、最も実現性が高いのは**シナリオB（組織的抵抗）**だ。AIによれば、組織慣性の法則により70-85%の組織が変化に抵抗し、変革成功率は30%未満にとどまる。さらに、中間管理職の60-70%が現状維持を好む傾向にあり、組織適応できない優秀人材の離職率は通常の2.5倍に達する。

開発手法の現実：アジャイルVSウォーターフォールという幻想

LinkedInの投稿では、「ウォーターフォール型の開発しかしたことがない上司に、優秀なエンジニアがアジャイルを提案してもすべて却下される」という事例が挙げられていた。しかし、これは表層的な対立構造を示しているに過ぎない。

ウォーターフォール型の特徴と役割

• 工程分業が明確（要件定義→設計→実装→テスト）
• 各工程に専門家を配置可能
• 役割分担が明確で、必要スキルセットが限定的
• 補助金や公的プロジェクトで必須となる場合が多い

アジャイル開発の理想と現実

• 短いサイクルで全工程を繰り返す
• 一人のエンジニアが複数工程を担当
• 幅広いスキルセットが要求される
• テスターやコーダーは頻繁な変更対応に追われる

開発手法の難易度と組織適合性

2つを比較すると、その差は明確であり、明らかにアジャイルの方が難易度が高い。その理由は次の通り：

【難易度が高い理由】

• マルチスキル要求：設計から実装まで一貫して理解する必要がある
• 高い自律性：自己管理能力と判断力が求められる
• コミュニケーション能力：頻繁な対話と調整が必要
• 不確実性への対応：要件の変化に柔軟に対応する力

つまり、アジャイル開発はそこそこ優秀なエンジニアで構成されたチームでなければ機能しない。

言ってみれば、ウォーターフォール開発は一般兵で構成された部隊に適しており、アジャイル開発は特殊部隊でなければ運用できない。

では、一般兵の部隊に特殊部隊の隊員が配属されたら…話が元に戻る。 では一般兵の部隊を特殊部隊のように運用したら…部隊が崩壊することは容易に想像つく。

私自身は「アジャイルっぽいウォーターフォール」での開発スタイルが多い。結局、テスターやHTMLコーダーは必要不可欠であり、アジャイルだとエンジニアは気が楽になる一方で、これらの専門職は振り回される傾向がある。補助金を活用したシステム開発では、ウォーターフォールを前提とした資料が求められたことがほとんどだった。

現実の開発現場では両者の手法が混在しており、「アジャイル＝善、ウォーターフォール＝悪」という単純な二元論で語れるものではない。

組織理解の必要性：視野を広げる

ここまでの分析から見えてくるのは、「無能な上司」という批判の背景には、組織構造や役割の違いに対する理解不足があるということだ。

日本のSIer業界では依然として人月換算による契約形態が主流であり、この構造はウォーターフォール型開発と整合性が高い。アジャイル開発の導入が進まないのは、単に「保守的な上司」のせいではなく、業界の構造的な制約があるからだ。

「無能な上司」という批判は、多くの場合、個人的な資質の問題ではなく、単に「異なる視点を持つ組織や役割」とのすれ違いが原因だ。

まとめ：「無能」というレッテルの落とし穴

私自身も若い頃には「上司が自分の提案を却下する＝無能」と感じていたが、経験を重ねるにつれて、開発手法や業務形態の違い、組織が求める成果や役割の多様性に気づくようになった。

これは、『美味しんぼ』の主人公・山岡士郎に対する私の見方の変化と重なる。連載開始当初、私は完全に山岡の味方だった。父親である海原雄山の厳格さや威圧的な態度に反発を覚え、若き山岡の挑戦に心を寄せていた。

しかし、結婚し、子を持ち、親として歳を重ね、40代半ばで再び『美味しんぼ』を手にした時、驚くべき変化があった。あれほど応援していた山岡の浅はかさが目につき、いつしか海原雄山の気持ちが理解できる自分がいた。組織の責任者としての重圧、若手の育成の難しさ、伝統と革新のバランス—これらはすべて、マネジメントを経験した者にしか真に理解できない課題だ。

現実には、多くの現場はウォーターフォール寄りの開発スタイルでうまく機能している。アジャイル開発が理想とされがちだが、すべての現場にアジャイルが最適とは限らない。実際、アジャイルに振り回される立場の人々（テスターやHTMLコーダーなど）がいることも忘れてはいけない。

自分のやり方が通らない時に即座に上司を無能と評価する前に、視点を変えてみてはどうだろうか。その不満は本当に上司個人に向けるべきものなのか、それとも単に自分がまだ組織や社会の仕組みを十分に理解できていないだけなのか。

問題の本質は、短絡的な評価を下してしまうエンジニア自身の視野の狭さにあるかもしれない。SNSで職場の不満を表明するエンジニアは、一時的に承認欲求は満たされるかもしれないが、人事権を持つ側からは別の視点で評価されることを忘れてはならない。

そう、エンジニアを評価するのは、己ではなく常に自分以外なのだ。今『美味しんぼ』を読み返せば、山岡士郎よりも海原雄山に共感するエンジニアであれば、「無能な上司」という評価の背後にある本質を理解する準備ができているはずだ。