少し話を戻して、最近私が企業を訪問する際に見かける光景を話そう。

　有能な人材が不足しているとは感じない。私が目にするのは、無計画な増改築によって意図せず出来上がった「偶発的なアーキテクチャ」の山だ。20年にわたって既存システムにアプリケーションが継ぎはぎされ、データは矛盾した状態で十数カ所に複製されている。セキュリティ設定が何重にも上書きされた結果、誰がどのデータにアクセスできるのか、誰も自信を持って答えられない。システム全体をシンプルにするはずだったクラウド移行が、結果として500個ものマイクロサービスを生み出した上に、そのうち40個は他のものと同じ処理をしているといった具合だ。システム全体を完全に把握している人は誰もいない。

　そして、また同じ嘆きを耳にする。「自社のシステムを理解している人が見つからない」と。

　見つかるはずがない。

　このシステムを構築した人を雇うことはできない。構築した人は退職したか、スタートアップに転職したか、「本人しか理解していないストアドプロシージャ（データベースの複数クエリをまとめたプログラム）」に関する質問攻めに嫌気がさして、答えるのをやめてしまったかのいずれかだからだ。

　問題は「世の中に優秀な人材がいない」ことではない。地球上でほんの一握りの人しか保守できないシステムを構築しておきながら、「採用市場で声を掛ければ、そうした幻の人材が次々と魔法のように湧く」と期待したことだ。

ごく少数の人しか理解できないシステムの代償

　私はこれまでのキャリアで、この問題の両方の立場を経験してきた。普通の優秀なエンジニアが、1年がかりで口伝の知識を得なくても作業できるようにシステムをシンプルにしようとするアーキテクトになったこともある。システムが複雑になり過ぎて、企業がシステムの仕様を代えが効かない数人に丸投げして属人化させてしまったために呼ばれたコンサルタントだったこともある。

　そこで私が学んだのは、システム構築には「誰も触れたがらない、直接的で不快なトレードオフ」が存在することだ。リファクタリングを先送りするたびに、「取りあえずもう一つ場当たり的な回避策を追加しておけばよい」と妥協するたびに、あるいは古いツールを直すことから逃げて新しいツールを導入するたびに、企業は費用を節約しているわけではない。「システムの複雑さ」を借金として買い込んでいるのだ。そして後になってから「採用難」という形でそのつけを払わされる。

　本当にいら立たしいのはここからだ。IT業界はほぼ満場一致で、このスキル不足に対する解決策を「もっと人を教育すること」に求めている。資格取得、ブートキャンプ（短期集中のプログラミングスクール）、スキルアッププログラム、企業が未経験者を現場で育てる徒弟制度などだ。

　私はこれらの取り組みに反対しているわけではない。人への投資は必要であり、私自身もIT分野での人材育成に多大なエネルギーを費やしてきた。しかし、新しいエンジニアを1万人訓練したところで、本番環境の設定を1つ変更するだけで秘伝の知識が必要になる現場に彼らを放り込んでも、何も解決しない。単に新人が業務を覚えるための時間を長くするだけだ。

　解決策は、理不尽な複雑さに耐えられる人を育てることではない。「ごく普通のエンジニア」が作業できるように複雑さを取り除くことだ。ここで言う「普通」とは、最大の敬意を込めた言葉だ。なぜなら、現場で働くエンジニアのほとんどがそうだからだ。

　賢くて意欲的なエンジニアに、システムの境界線が明確で、ドキュメントが整備されたクリーンな環境を与えれば、数週間で戦力になる。同じエンジニアに、20年間かけて肥大化した「スパゲティ状態のシステム」を与えれば、1年間もがき苦しむことになる。それを見た経営層は、本当の問題は引き継いだシステムにあるのに、「採用の失敗」と評価する。

終わりのない「ユニコーン」探し

　私はこのパターンを何度も見てきたので、結末を容易に予測できる。

　企業は数百万ドルを費やして、あらゆる古い技術から最新技術までを完璧に熟知している「ユニコーン」（実在しない幻の存在）を雇おうとする。自社のメインフレームも、マイクロサービスも、レガシーなデータ変換の仕組みも、複数のクラウドサービスも全て知っている人物が、都合よく電話を待ちながら暇にしているかのように探し回る。そして、「そもそもシステムがひどい作りだったからこそ重要になっているだけの、特定の古いフレームワーク」を知らないという理由で、優秀な候補者の採用を見送ってしまう。

　その後、企業はスキル不足を宣言して、ビザの発給枠拡大を政府に求めたり、ベンダーに頼ったりと、自分以外の誰かに解決を求める。厳しい現実を言えば、解決策のほとんどは内部にあり、システムの構造改善にあり、たいていは非常に地味な作業だ。

　私自身の経験から具体例を挙げよう。私が訪れたある金融機関は、クラウドエンジニアを全く採用できない「壊滅的な状況」にあると説明した。採用担当者との会話は「要件を満たす人がいない」「誰も市場にいない」という、毎回同じ結論に達した。

　しかし、システムの中身を見てみると、その金融機関は、システム内のレガシーな依存関係を全て残したままクラウド移行をしていたことが分かった。クラウドサービス内に新しく構築したアプリケーションは、30年前の社内業務システムに接続しなければ動かない仕組みだった。しかもそのシステムは、退職間近の1人のエンジニアの頭の中にしかドキュメントが存在しないものだった。

　彼らが直面していたのは「クラウドエンジニアの不足」ではない。「10年前に廃止されるべきだったシステムを、5年もかけてわざわざ学ぼうとする人材の不足」だったのだ。

　そこで私たちは地味な作業に取り組んだ。システム同士の依存関係を文書化し、古いシステムをきれいなインタフェースの裏に隠して抽象化し、廃止できるものは廃止した。すると途端に、採用の問題はほとんど消え去った。突然、条件を満たすエンジニアが豊富に見つかるようになった。

　これは採用市場の状況が変わったからではない。システムが整理されたことで、そこで働くために必要なスキルが、「ごく普通の優秀な人が現実的に習得できるレベル」にまで下がったのだ。

人材不足は現実だが、誰もが指摘する問題ではない

　ここで誤解されたくないのは、IT業界にはスキルギャップが存在し、本当に採用が難しい分野もあることだ。

　セキュリティの専門知識はごまかしが利くものではなく、攻撃者の思考を真に理解できる人材への需要は確実に高まっている。データエンジニアも不足している。世の中のシステム構築があまりにも粗末だったからこそ、複雑なものを整理できる優秀なアーキテクトには価値がある。

　私は人材不足がうそだと主張しているわけではない。その大部分、つまり誰もが大声で不満を漏らしている部分は、自業自得だと主張しているのだ。

　だから、この問題について尋ねる経営陣にはこう答えているし、読者の皆さんにも同じことを言おう。「スキル不足だ」と言う前に、まず自社のシステムを見せてほしい。システムの依存関係図を見せてほしい。新人のオンボーディングにどれくらい時間がかかるかを教えてほしい。マニュアルがどこにも存在しない暗黙知を必要とするシステムが、本番環境にいくつあるのかを数えてほしい。

　もし、その答えのどれか1つでも頭を抱える状況なら、あなたの企業が抱えているのは「スキルの問題」ではない。「複雑さの問題」を抱えているのだ。複雑さの問題は修正できる。ただし、人を雇って手っ取り早く回避するのではなく、誰もやりたがらない、困難で退屈で費用のかかる「システムの整理」に取り組む必要がある。

　これからの時代を勝ち抜く企業は、「最も多くの人を雇った企業」ではない。「採用できる普通の人材で運用できるほど、システムをシンプルに保てている企業」だ。それがこの勝負の全てであり、それ以外の騒ぎはもっともらしい言い訳に過ぎない。