はじめに
以前いた会社で、別案件の同僚がこぼしていた。
「要件が全然固まらない。もう何か月も、グダグダ会議ばかりやっている」
その人は結局、しびれを切らして転職してしまった。
話を聞きながら、私は少し違うことを考えていた。
──それ、私には天国では?
まだ形になっていないものを構造化していく。
複雑な業務を整理し、抽象化し、モデルへ落とす。
要件定義の経験自体は多くないが、その「考える部分」は好きで、向いていると思う。
正直に言えば、天国なのはそこまでだ。
関係者へ説明して回ったり、利害を調整したりする部分は、たぶん向いていない。
「要件定義」という一つの工程の中にすら、私に向く仕事と向かない仕事が混ざっている。
そして、要件が固まった瞬間からは、今度こそ私の地獄が始まる。
納期に追い立てられながら、決まったものを大量に作っていく作業は、私にはひどく消耗する。
(ちなみに、日常の摩擦を消す小さなツール作りは楽しい。要するに、私の能力は偏っている。)
同じプロジェクトの中に、誰かの地獄と、誰かのの天国がある。
エンジニアの能力には、それくらい偏りがある。
ところが、この業界には根強い人材像がある。
ITエンジニアなら、ある程度は何でもできるべき
要件定義も、設計も、実装も、テストも、運用も。 担当技術が変わっても、案件が変わっても、それなりに動ける。
この前提で人材を評価すると、強みの偏りは「不足している能力」として見えるようになる。
なぜ、こうなるのか。
この記事では、これを個人の能力の問題ではなく、日本のIT業界に残る構造──ジェネラリスト幻想──として考えてみたい。
ジェネラリストそのものが問題なのではない
先に断っておくと、これは「広い範囲を見ることが得意な人」を否定する話ではない。
複数領域を理解し、専門家同士をつなぎ、システム全体を俯瞰できる人は必要である。
それも一つの適性であり、専門性である。
問題なのは、全員がその形を目指すべきだという前提のほうだ。
抽象化が突出している人に、実装速度まで平均以上を求める。
実装能力が突出している人に、顧客折衝まで同じ水準で求める。
テスト設計が非常に強い人を、要件定義が苦手だから総合力が低いと評価する。
こうなると、人材育成は強みを伸ばすことより、低い能力を平均値まで引き上げる作業になっていく。
能力を尖らせるのではなく、平らにする。
この「均一な一人前」を作ろうとする発想を、ここではジェネラリスト幻想と呼ぶ。
エンジニアの能力には偏りがある
エンジニアの仕事を分解すると、必要な能力はかなり違う。
抽象化・構造化が強い人
要件整理、業務構造の理解、モデル化、アーキテクチャ、複雑な問題の分解。
まだ形になっていないものを扱うことに強い。
実装が強い人
コーディング、リファクタリング、パフォーマンス改善、実装上の細かな判断。
仕様を具体的な動作へ落とし込むことに強い。
障害解析が強い人
ログ解析、再現条件の特定、原因切り分け、既存コードの読解。
未知の不具合を追うことに強い。
テストが強い人
境界値の発見、例外ケースの想定、品質リスクの発見。
「どう作るか」より、「どう壊れるか」を見ることに強い。
改善・軽量自動化が強い人
スクリプト、小規模ツール、既存作業の自動化。
巨大なシステムを作るより、日常の摩擦を小さく消していくことに強い。
プロトタイピングが強い人
試作品の高速実装、技術検証、仕様探索。
完成形を作る前に、動くものを使って問題そのものを探ることに強い。
もちろん、複数の能力を高い水準で持つ人もいる。 ただ、すべての能力が同じ高さになるとは限らない。
能力には偏りがあることを前提にしたほうが、人間の実態には近い。
なぜ「何でもできる人」が求められやすかったのか
では、なぜ日本のIT業界では「一通り何でもできる人」が扱いやすいのか。
個人の価値観だけではなく、産業構造も関係していると考えられる。
経済産業省の「DXレポート2.1」は、日本のIT産業について、ユーザー企業とベンダー企業の相互依存関係や、多重下請け型の産業構造を指摘している。
ベンダー企業側では低い利益水準から売上総量の確保が必要となり、労働量をベースにしたビジネス構造からの転換が課題として示されている。
ここから先は、一つの構造的な仮説である。
人材を案件へ配置し、その稼働によって売上を作る構造では、特定の領域で非常に強い人より、いろいろな案件へ入れやすく、複数工程を一通り担当できる人のほうが運用しやすい。
要件定義も少しできる。 設計もできる。 実装もできる。 テストもできる。
こういう人なら、案件の状況が変わっても配置を変えやすい。
つまり、「能力が高い人」と「配置しやすい人」が、同じものとして評価されやすい構造が生まれる。
そして長い時間をかけて、「どこでも使える人=優秀なエンジニア」という価値観へ変換されていった可能性がある。
ジェネラリスト幻想は、単なる精神論ではなく、人材を配置する仕組みから生まれたのかもしれない。
多次元の人間が、一つの箱へ入れられる
人間の能力は多次元である。 抽象化、実装、分析、調整、品質への感度、改善。それぞれに強弱がある。
しかし人員配置では、「Aさんをこの案件へ入れる」という一人単位で扱われる。
人間の内部は多次元なのに、配置するときには一つの箱になる。
この構造で何が起きるか。
たとえば五つの能力があるとする。
あるエンジニアは、
抽象化: 非常に高い 実装: 普通 テスト: 普通 運用: 低い 調整: 低い
という特性を持っているとする。
別のエンジニアは、五つとも普通だったとする。
均一な総合力を見る組織では、後者のほうが安定した人材に見えやすい。
しかし、抽象度の高い問題を解く場面では、前者が圧倒的な価値を出す可能性がある。
ところが、「一人のエンジニアは一通りの仕事ができるべき」という評価軸では、突出した一つより、低い二つのほうが目につく。
その結果、強みの偏りが大きい人ほど「できないことが多い人」に見えるという現象が起きる。
本当は強みが突出しているだけなのに、それが弱点の多さとして処理される。
「誰が向いているか」より「誰が空いているか」
能力の偏りを生かすには、仕事と人を丁寧に組み合わせる必要がある。
しかし、プロジェクトには納期も契約も予算もある。
案件が始まる。 人が必要になる。 稼働状況を見る。 入れられる人を探す。
すると、「誰がこの仕事に最も向いているか」より、「誰なら今ここへ入れられるか」が優先されることがある。
これは担当者個人の問題ではない。 限られた人員で案件を成立させる以上、一定の合理性がある。
しかし、この合理性を繰り返すと、「どこへ入れても最低限動ける人」が最も価値の高い人材に見えるようになる。
人材配置の都合から生まれた人物像が、いつの間にか「優秀なエンジニア像」へ変わる。
ここに、ジェネラリスト幻想が固定化される仕組みがある。
人材モデルは変わり始めている
興味深いのは、公的な人材モデルを見ると、すでに「万能なIT人材」から離れ始めていることである。
経済産業省とIPAが2026年4月に公表した「デジタルスキル標準 ver.2.0」では、DXを推進する人材を一種類として定義していない。
人材類型は、ビジネスアーキテクト、デザイナー、データサイエンティスト、データマネジメント、ソフトウェアエンジニア、サイバーセキュリティの6類型に分けられている。
さらに注目したいのは、類型の内側である。
「ソフトウェアエンジニア」という一つの類型の中だけでも、
フロントエンドエンジニア、バックエンドエンジニア、クラウドエンジニア/SRE、フィジカルコンピューティングエンジニア という4つのロールが定義されている。
フロントエンドとバックエンドとクラウドは、別の役割である──公的なスキル標準は、すでにそう言っている。 「ソフトウェアエンジニア」は、標準の上ではもう一つの箱ではない。
なお、同じ資料にはこうも書かれている。 これらのロールは数十名以上のエンジニアチームを持つ企業を想定したもので、小規模な企業では複数のロールを少数または一人が担うこともあり、分担や組み合わせは各社の状況により柔軟に変わりうる、と。
つまり標準が言っているのは、「一人が複数ロールを担ってはならない」ではない。
考える単位はロールであり、それを誰が何個担うかは状況次第ということだ。
一人が全部を担うことは、現実にある。
しかしそれは配置の事情であって、「全部できるのが一人前」という人材像とは別の話である。
つまり、現在のスキル標準は、「IT人材なら全部できるべき」ではなく、
「異なる役割には、異なる能力が必要である」という方向へ進んでいる。
ここに、面白いズレがある。
スキルモデルは、すでに多次元化している。
それでも、人員配置には「一人を一つの箱として案件へ入れる」という古い構造が残っている。
人材像は変わり始めているのに、人の使い方がまだ追いついていない。
偏りを無視すると、何が起きるのか
能力の偏りそのものは問題ではない。問題になるのは、偏りを無視して配置することである。
まず、強みを使う時間が減る。
高い価値を出せる領域より、不得意領域の処理に多くの時間を使うことになる。
次に、認知負荷が上がる。
不得意な仕事は、同じ成果を出すために必要な負荷が大きい。 得意な人なら短時間で終わる仕事が、不得意な人には重い。
そして、生産性が下がったように見える。
本人の能力全体が低いのではなく、能力と仕事が噛み合っていないだけなのだが、成果だけを見ると「生産性が低い人」に見える。
最後に、評価が弱点へ集中する。
突出した能力があっても、「でも○○はできない」という評価になり、本人も強みを伸ばすより弱点を埋めることに時間を使うようになる。
冒頭の話に戻ると、要件が固まらない案件は、実装が強い同僚には消耗戦だった。
同じ案件でも、少なくともその「抽象的に考える部分」は、私なら強みを使える場所だっただろう。
人が消耗するかどうかは、能力の総量ではなく、組み合わせで決まっている。
スペシャリスト化すれば解決するわけでもない
では、全員をスペシャリストにすればよいのか。
それも違う。
複数領域を横断すること自体が得意な人もいる。 技術と業務をつなぐ人。設計と実装をつなぐ人。顧客と開発チームをつなぐ人。 こうした人は、本来の意味でジェネラリストとして価値を出す。
だから必要なのは、「ジェネラリストか、スペシャリストか」という二択ではない。
その人の能力特性を前提として、役割を設計することである。
広く見ることが強みなら、広く見る。
一つの領域に深く入ることが強みなら、そこへ集中する。
改善が強いなら、小さな摩擦を大量に消す。
試作が強いなら、探索段階を担当する。
全員を同じ形にする必要はない。
「人を配置する」から「能力を組み合わせる」へ
考え方を少し変えてみる。
従来は、「このプロジェクトに誰を入れるか」から考える。
これを、「このプロジェクトには、どのような能力が必要か」から考える。
要件整理が必要。 アーキテクチャ設計が必要。 高速な実装が必要。 テスト設計が必要。
必要な能力を先に分解し、そのあと人を組み合わせる。
すると、一人ですべてを満たす必要がなくなる。
さらに言えば、必要な能力はフェーズによっても入れ替わる。
探索フェーズでは、抽象化とプロトタイピングが主役になる。
実装フェーズでは、実装力と品質の目が主役になる。
一人をプロジェクトへ通期で固定するのではなく、フェーズの重心に合わせて主役を入れ替える。
もっとも、冒頭の同僚と私を単純に入れ替えれば済む、という話でもない。
私が引き受けられるのは要件の構造化までで、関係者への説明や利害の調整は、それが得意な別の誰かの方が良い。
つまり、組み合わせの単位は「フェーズ」ですらなく、その中の「能力」である。
箱を開けると、中にはまた箱がある。
解像度を上げるほど、「一人で全部」がいかに乱暴な単位だったかが見えてくる。
ソフトウェア設計で、すべての責務を一つの巨大なクラスへ詰め込まないのと同じである。
責務を分け、得意な場所へ置き、インターフェースで接続する。
なぜか人材設計になると、「全部入りHumanクラス」を作ろうとしてしまう。
そろそろ、この設計思想は変えてもよいのではないか。
偏りは欠陥ではなく、チーム設計の入力値
能力の偏りを見るとき、「何が足りないか」だけを見る必要はない。
「どこへ配置すると最も価値が出るか」という見方もできる。
抽象化へ強く偏っている。 実装へ強く偏っている。 改善へ強く偏っている。 複数領域を横断することへ強く偏っている。
それは、人材としての不完全さではない。 チームを設計するための特性情報である。
偏りを消してから配置するのではない。 偏りを読み取り、それを組み合わせる。
この発想へ移れば、人材育成も変わる。
不得意をすべて平均まで持ち上げることだけが成長ではなくなる。
最低限必要な領域は補いつつ、強い領域をさらに伸ばす。 足りない部分は、別の人と接続する。
個人の完全性ではなく、チームの完全性を目指す。
AI時代には、この考え方がさらに重要になる
AIによって、これまで一つの職種にまとまっていた仕事は、さらに細かなタスクへ分解されつつある。
コード生成。 テスト案の生成。 ログの要約。 プロトタイピング。
デジタルスキル標準 ver.2.0がAI実装・運用やデータマネジメント関連の役割・スキルを拡張したことからも、必要な能力の組み合わせ自体が変化していることが分かる。
そうなると、「ITエンジニアという人を一人配置する」という考え方より、「人間とAIを含め、必要な能力をどう組み合わせるか」という設計のほうが重要になる。
人間にも能力の偏りがある。 AIにも得意不得意がある。
必要なのは、すべてを平均化することではない。
異なる強みを接続し、一つのシステムとして機能させることである。
「一人で何でもできること」を標準とする発想は、AI時代にはむしろ不自然になっていくのかもしれない。
とは言っても、能力の偏りに合わせた配置は簡単ではない
ここまで書くと、「そんなに都合よく、人の得意分野だけを組み合わせられない」と思うかもしれない。
その通りだと思う。
プロジェクトには、納期も予算も人数制約もある。
小さなチームでは、一人が複数の仕事を担当しなければ回らないこともある。
特定領域に強い人だけを集めても、誰も担当できない仕事が残る可能性がある。
人の入れ替わりもある。 案件ごとに必要な能力も変わる。
そのため、「全員が自分の得意分野だけを担当する」という組織を作るのは現実的ではない。
しかし、ここで話を終える必要もない。
問題は、完全な適材適所が実現できないことではない。
適材適所ができないからといって、能力の偏りそのものを欠点として扱う必要はないということだ。
たとえば、実装が苦手な人に実装を担当してもらう必要がある場面はある。
その場合でも、
「実装が苦手だからエンジニアとして能力が低い」 と評価するのか、
「今回は必要上担当しているが、この人の主な強みは別の領域にある」 と評価するのかでは、大きく違う。
配置には制約がある。しかし、評価まで制約に引きずられる必要はない。
完全な最適配置を目指さなくても、
本人の強みを把握する。
主戦場となる領域を決める。
不得意領域を担当する割合を減らす。
チーム内で補完関係を意識する。
評価では「何ができないか」だけでなく「どこで大きな価値を出すか」を見る。
といったことはできる。
まずは、「全員が均一であるべき」という前提を外すことから始めればよい。
おわりに
エンジニアの能力には、偏りがある。
問題は、偏りがあることではなく、偏りがある人間を、「一人前なら全部できるはず」という均一な型へ押し込むことである。
要件が固まらない案件で消耗していた、あの同僚は、「要件定義が苦手な人」だったのだろうか。
それとも、「主戦場が実装にある人」だったのだろうか。
呼び方を変えても、納期や人数の制約は変わらない。
それでも、その人がどこで価値を出す人なのかは、正しく見えるようになる。
見え方が変われば、配置も、育成も、評価も、少しずつ変わっていく。
エンジニアの能力の偏りをなくす必要はない。
偏りを欠点として数える習慣を、やめることから始めればよいのだと思う。