脱「何でもできる人」――AI時代の熟練エンジニアが目指す「自走可能性」の設計

長く顧客向けシステムの開発に携わっていると、いつの間にか「何でも分かる人」になっていることがあります。

新規案件の要件を整理し、設計し、開発を取りまとめる。

稼働後には改善要望を受け、障害があれば原因を調べる。問い合わせにも答える。昔の仕様について聞かれれば、経緯まで含めて説明する。

顧客から見れば頼りになる担当者です。

会社から見ても、難しい顧客を任せられ、新しい案件も取ってこられる貴重な人材です。

本人にも達成感があります。

顧客の業務を深く理解し、単なるパッケージ製品では解決できない問題までシステムで解決する。長く業務システムに携わってきたエンジニアにとって、これは仕事の醍醐味の一つでしょう。

しかし、この働き方には少し怖い性質があります。

成功するほど、仕事が減らないのです。

有能だからこそ、限界まで仕事が積み上がる

ここでいう「フルスタックエンジニア」は、フロントエンドからインフラまで扱える、という一般的な技術領域の意味とは少し違います。

新規案件を獲得して売上を作る一方で、その顧客の改善、改修、運用、QA、問い合わせ対応まで、長期にわたって担当し続けるエンジニアを想定しています。

顧客Aの案件を成功させる。

すると、

「A社については、この人が一番よく分かっている」

となります。

次に顧客Bの案件を任されます。

こちらもうまくいけばB社にも詳しくなる。

ところが、A社との関係は終わりません。

問い合わせもあれば追加開発もある。何年か前に作った機能で問題が起きれば呼ばれます。

こうして、

成功 → 信頼 → 担当範囲拡大 → さらに成功 → さらに担当範囲拡大

という循環が生まれます。

ピーターの法則では、人は能力を発揮できなくなる職位まで昇進するとされます。

それになぞらえるなら、こちらは「昇進なきピーターの法則」とでも呼べるでしょう。

ただ、本質は少し違います。

エンジニア本人が無能になったわけではありません。

有能であり続けた結果、その有能さを利用する仕事が能力限界まで積み上がったのです。

しかも厄介なことに、限界は見えにくい。

本人が90％の負荷で踏ん張っている間は「回っている」と評価されます。

そして新規案件と既存顧客の障害が重なり、納期を落とす、品質を落とす、顧客対応が遅れる、といった事態になって初めて限界が観測されます。

成功している間は追加され、失敗して初めて追加が止まる。

個人の能力管理だけでは解決しにくい構造です。

売上はスケールさせたいのに、仕組みがスケールしない

もう一段視点を上げると、これは働き方よりもビジネスモデルの問題に見えてきます。

企業である以上、売上拡大は重要です。

顧客10社より100社、100社より1,000社へサービスを広げたい。

特にSaaSのようなビジネスでは、顧客が増えても人員やコストが同じ割合では増えないことが重要になります。

ところが、契約上はSaaSやサービス型ビジネスであっても、実態が、

製品＋顧客別設定＋個別判断＋問い合わせ対応＋熟練SEの暗黙知

で成立していたらどうでしょうか。

顧客を一社増やすたびに、エンジニアが覚えておかなければならない事情も増えていきます。

売上はSaaSとしてスケールさせようとしているのに、デリバリーは受託開発のまま。

極端に言えば、

「人間がAPIになっている」状態です。

顧客数が増えるほど、そのAPIへの呼び出しも増えます。

そして最終的なスケール限界は、サーバー性能でもライセンス数でもありません。

詳しいエンジニアの注意力です。

顧客の難題を解くことは、むしろ競争力である

ここで誤解したくないのは、泥臭い顧客対応自体が悪いわけではないということです。

ビジネスの現場は、きれいな仕様書通りには動きません。
例外があります。
組織固有の事情があります。
過去からの経緯があります。

「そんな業務は標準機能では対応できません」と切り捨てるサービスよりも、顧客の本質的なペインまで踏み込んで解決できるエンジニアや企業の方が、高い価値を提供できる場合もあります。

問題は、その解決後です。

顧客Aの難題を解決した。

その経験が、

• 共通機能になる

• 設定値になる

• 業務ルールとして整理される

• ドキュメントになる

• テストとして残る

• AIエージェントが参照できる知識になる

• 顧客自身が判断できる仕組みになる

ところまで変換されれば、それは資産です。

しかし、

「あのケースならAさんに聞けば分かる」

で終わればどうでしょう。

難題を解決した経験は、そのエンジニアへの将来の問い合わせ義務になります。

つまり、

解決した問題は、ノウハウ化・標準化・リファクタリングされなければ、資産から負債へ変わります。

私はこれを「スケール負債」と考えると分かりやすいと思っています。

コードが汚いわけではありません。

システムそのものは正常に動いているかもしれない。

しかし顧客が増えるたび、人間が覚え、判断し、対応し続けなければならないものが増えていく。

これは技術的負債とは別の、事業成長に対する負債です。

「システムを所有する」とは、自分でコードを書くことではない

この問題には、ベンダー側だけでなく顧客側の構造も関係します。

日本ではIT人材がベンダー企業側に偏り、多くのユーザー企業がITベンダーへ強く依存してきた構造について、IPAも「低位安定構造」として問題を指摘しています。経済産業省もレガシーシステムのモダン化にあたり、ユーザー企業側にシステムの可視化、標準化、上流人材の育成・確保などを求めています。

ただし、ここからすぐに、

「では何でも内製化すべきだ」

という結論にはしたくありません。

顧客企業がJavaやPythonを書ける必要はありません。

重要なのは、システムに関する意思決定能力を保持しているかです。

例えば、

「この例外を認めるのか、業務を標準化するのか」
「このデータが矛盾したとき、何を正とするのか」
「この変更によってどんなリスクを受け入れるのか」
「誰がその判断責任を持つのか」

といったことです。

つまり、

システムを所有するとは、自分で作ることではない。
そのシステムについて、自分たちで意思決定できることである。

ここまで外部へ委ねてしまうと、少しでも例外が発生するたび、

「とりあえずシステム会社に聞こう」

となります。

ベンダーの熟練SEが答える。

問題は解決する。

しかし顧客側には判断能力が蓄積しない。

次回も同じSEに聞く。

善意で何でも解決する優秀なエンジニアが、皮肉にもベンダー依存を強化してしまうことさえあります。

FDEを「何でもやる人」にしてはいけない

ここで昨今注目されているFDE（Forward Deployed Engineer）の話につながります。

顧客の現場へ深く入り込み、業務を理解し、課題設定から技術的な解決まで関与する。

この説明だけを聞くと、日本のベテランSIerには、
「それなら昔からやっている」
と思う人もいるでしょう。

確かに共通点は多くあります。
だからこそ注意が必要です。

FDEを、

営業もできる。
コンサルもできる。
要件定義もできる。
コードも書ける。
運用も見る。
顧客成果まで責任を持つ。

というスーパーエンジニア論だけで理解すると、旧来の属人型フルスタックSEを名前だけ変えて再生産する可能性があります。

本来、Forward Deployed型の仕組みには、その先があります。

PalantirのFoundry導入モデルでは、導入が成熟した段階で顧客側チームがプラットフォームを自律的に所有する状態が想定されており、組織側に明確な役割とownershipを置く設計になっています。

国内でもLayerXのFDE活動では、顧客案件で発見した問題をプロダクトへフィードバックし、その後の自動化へつなげる「現場→プロダクト改善」のループが紹介されています。

この観点から見ると、FDEは「何でもやる人」ではなく、

「スケールしないものを発見し、スケールする仕組みに変換する人」

と捉えた方が、本質に近いのではないでしょうか。

AIは「スーパー属人化エンジニア」も作れてしまう

この問題にAIを持ち込むと、少し怖い未来も見えてきます。

生成AIを使えば、問い合わせ調査が速くなる。
コードも速く書ける。
仕様書も作れる。
テストも補助できる。

一人の熟練エンジニアが、以前の1.5倍、2倍の仕事を処理できるようになるかもしれません。

しかし構造を変えずに生産性だけを上げたら、

「まだ余裕がある」

と判断されるだけかもしれません。

20件だった問い合わせが40件処理できる。

担当顧客も増える。

AIが強力になるほど、一人の人間の周囲に巨大な属人システムが形成される。

スーパー属人化エンジニアの誕生です。

一方、AIにはまったく別の使い方があります。

問い合わせへ回答するだけでなく、

「なぜこの問い合わせには人間の判断が必要なのか」を分析する。
過去の例外を分類する。
暗黙の判断基準を取り出す。
顧客ごとの差異を構造化する。

AIエージェントへ渡せるもの、プロダクトに組み込むもの、顧客へ判断能力を戻すもの、人間が責任を持って残すものを切り分ける。

するとAIは、

熟練者の処理能力を増幅する道具

から、

熟練者の知識をシステムへ移植する道具

へ変わります。

「自分がいなくても回る」は、廃業することではない

ここまで読むと、

「では自分の仕事を全部なくせばいいのか」

と思われるかもしれません。

そうではありません。

目指すのは、自分を不要にすることではなく、自分が扱う問題の位置を移動させ続けることです。

例えば、

問い合わせ
↓
自分が調べる
↓
自分が判断する
↓
自分が回答する

というループを担当していたなら、

次には、

問い合わせ
↓
なぜ人間への問い合わせが必要なのかを調べる
↓
必要な判断材料・データ・権限を整理する
↓
AI、プロダクト、業務ルール、顧客組織へ判断を再配置する
↓
顧客が自走する

という仕事へ移る。

そして自分は、まだ仕組み化されていない次の問題へ向かいます。

これは仕事をなくすことではありません。

既知の問題を手放し、未知の問題へ進むことです。

熟練エンジニアの経験は、AI時代にこそ使い方を変えられる

長く顧客システムを支えてきたエンジニアには、独特の能力があります。

仕様書には書かれていない事情を知っている。
顧客が言葉にできない問題を察知できる。
「仕様上は正しいが、この運用では事故になる」と分かる。
どの例外を許容し、どれを標準化すべきか判断できる。
関係者の利害を読みながら、実際に動く形へ着地させられる。

本人からすれば、

「昔からやっているだけ」

かもしれません。

しかし、AIエージェントが扱える範囲が広がるほど、この経験の使い道も変わっていくはずです。

AIにできない仕事を抱えて抵抗するのではありません。

AIへ渡せる領域を広げ、その外側に現れた新しい問題へ移る。

AIが扱えない死角を見つける。

例外が増えたら、その例外を単に処理するのではなく、なぜ発生しているかを考える。

人間、AI、システム、組織のどこに判断を置くべきかを設計する。

そして顧客や組織が自分たちで判断できる状態へ持っていく。

この能力は、単なる「自動化スキル」とは少し違います。

私はこれを、

自走可能性を設計する能力

と捉えています。

AI時代のエンジニアリングは「自走可能性」の設計へ

これまでシステムエンジニアの仕事は、「動くシステムを作ること」と考えられてきました。

しかしAIエージェントが業務の中へ入り込むほど、設計対象は広がります。

人間。
AIエージェント。
業務ルール。
データ。
権限。
意思決定。
例外処理。
そしてフィードバックループ。

これらを含めて、

どうすれば、この組織やビジネスは自走できるのか

を考える必要があります。

そう考えると、熟練エンジニアが目指す先も少し違って見えてきます。

より多くの顧客を一人で担当できる人になることではありません。

誰よりも速く問い合わせを処理できる人になることでもありません。

一度深く問題へ入り込み、
未知を理解し、
解決し、
その解決を仕組みへ変換し、
人・AI・プロダクト・顧客組織へ適切に再配置し、

自分は次の未知へ進む。

そんな人です。

だから私は、これからのFDEや熟練エンジニアを、

「何でもやる人」ではなく、「スケールしないものを発見し、スケールする仕組みに変換する人」

と考えてみたいと思います。

AIと競争しないために、AIのできない仕事へ逃げ続ける必要はありません。

むしろ、

AIが扱える領域を増やしながら、その境界の外側へ移り続ける。

長年、顧客の難題と向き合ってきた経験は、そのためにこそ使えるのかもしれません。