コンサルでもSEでもない。AI時代に必要な「最後まで価値を出す人」とは

いつもありがとうございます。さくたろうです。

ITの仕事では、

「考える人」と「作る人」が分かれていることが多いように思います。

コンサルタントは、

経営課題や業務課題を整理する。

構想を描く。

ロードマップを作る。

SEやエンジニアは、

要件を受け取り、

設計し、

構築し、

システムを動かす。

もちろん、実際の現場ではもっと曖昧です。

でも大きく見ると、

考えるところと、作るところが分断されている。

私は、この分断にずっと違和感がありました。

なぜなら、顧客が本当に欲しいのは、

立派な構想書でも、

高品質なシステムでもなく、

だからです。

では、

経営課題を理解し、

業務課題に落とし、

技術に翻訳し、

実際に作り、

現場で使い、

効果が出るところまで見る。

そんな役割は誰が担うのでしょうか。

最近、この役割に近いものとして、

FDE（Forward Deployed Engineer）

という職種を目にする機会が増えてきました。

社内でも、FDEというキャリアパスをどう作るか、という話が少しずつ出ています。

ただ、FDEという言葉を見ていて、私は一つ気になっています。

「それって、何でもできるスーパーマンを求めていないか？」

今日は、

AI時代に必要な「最後まで価値を出す人」とは何なのか。

そして、

FDEという役割をどう捉えればいいのか。

そんなことを考えてみたいと思います。

コンサルでも、SEでもない

IT業界では、役割が比較的分かれています。

コンサルタントは、

経営課題や業務課題を整理する。

構想を描く。

ロードマップを作る。

一方でSEやエンジニアは、

要件を受け取り、

設計し、

構築し、

システムを動かす。

もちろん、実際の現場ではもっと曖昧です。

でも大きく見ると、

「考える人」と「作る人」

が分かれていることは多い。

私は、この分断にずっと違和感がありました。

顧客が本当に欲しいのは、

立派な構想書でも、

高品質なシステムでもありません。

だから本来は、

課題を理解した人が、

解決策を考え、

技術に落とし、

実際に動かし、

その結果まで見た方がいい。

FDEという役割は、

この「考える」と「作る」の間を埋める存在なのではないかと思っています。

「AIを入れたい」は、課題ではない

例えば、

顧客から、

「生成AIを活用したい」

と言われたとします。

ここで、

「ではAIエージェントを作りましょう」

「Copilotを使いましょう」

と始めるのは簡単です。

でも、

本当に聞くべきなのは、

「なぜAIを入れたいのですか？」

ではないでしょうか。

人手不足なのか。

利益率を上げたいのか。

顧客対応を速くしたいのか。

新しいサービスを作りたいのか。

意思決定を速くしたいのか。

ここが分からなければ、

どんな技術を使えばいいかも決まりません。

つまり、

「AIを入れたい」

という言葉を、

そのままIT要件として受け取らない。

ここが重要です。

経営課題は、そのままITにはならない

例えば、

経営者が、

「利益率を上げたい」

と言ったとします。

これをそのままシステム要件にはできません。

なぜ利益率が低いのかを分解する。

原価が高いのか。

在庫が多いのか。

値引きが多いのか。

間接業務が重いのか。

営業生産性が低いのか。

そこから業務を見る。

例えば在庫が問題なら、

需要予測。

発注。

在庫可視化。

欠品判断。

廃棄。

こうした業務に落とす。

さらに、

その業務をどう変えるのか。

最後に、

AIなのか。

データ基盤なのか。

ローコードなのか。

ERPなのか。

既存システムの改修なのか。

を考える。

つまり、

という翻訳が必要になります。

私は、この翻訳ができる人の価値は、これからますます高くなると思っています。

AI時代は「要件を待つ」だけでは始まらない

これまでのSIerでは、

顧客から要件をもらう。

RFPを受け取る。

見積もる。

設計する。

作る。

という仕事の進め方が多くありました。

もちろん、これも重要です。

でもAIのように技術の変化が速い領域では、

顧客自身も、

何を作ればいいのか分かっていない

ことが増えています。

「AIで何かできないか」

という相談に、

最初から完成した要件定義書が出てくることはありません。

だったら、

要件を待っているだけでは仕事は始まりません。

顧客と一緒に、

課題を探す。

仮説を作る。

小さく作る。

使ってもらう。

効果を見る。

改善する。

この繰り返しになります。

FDEは、かなりこの動きに近いのではないかと思います。

FDEは「要件定義の前」からいる

FDEの面白さは、

完成した要件を渡されてから仕事を始めるのではなく、

にあると思います。

顧客の現場を見る。

業務を理解する。

課題を見つける。

仮説を置く。

まず動くものを作る。

使ってみる。

結果を見る。

また考える。

このループを回す。

だから、

従来の、

要件定義。

設計。

開発。

テスト。

リリース。

という一直線のプロジェクトとは少し違います。

ただ、ここで一つ違和感が出てくる

FDEという役割を考えていくと、

こんな能力が必要だと言われ始めます。

経営課題が分かる。

業務課題を整理できる。

AIが分かる。

自分で設計できる。

自分で構築できる。

クラウドも分かる。

データも分かる。

セキュリティも分かる。

顧客とも話せる。

PoCもできる。

本番導入もできる。

効果測定もできる。

さらに、

得られた知見を型化して、

次の案件へ展開できる。

ここまで並べると、

私は少し不安になります。

それ、スーパーマンではないか。

FDEを「何でもできる人」にすると、誰もなれない

もちろん、

全部できるに越したことはありません。

でも、

それをFDEの必須条件にすると、

ほとんど誰もなれません。

しかも、

セキュリティ。

AIモデル。

MLOps。

データ基盤。

クラウド。

アプリ開発。

経営。

業務。

それぞれ一つだけでも、

かなり深い専門領域です。

全部を専門家レベルで求めるのは、

現実的ではありません。

そして、

この定義のままキャリアパスを作ると、

二つのことが起きると思います。

一つは、

「FDEになるには何でもできないといけない」

となって、

誰も目指せなくなること。

もう一つは、

FDEという肩書きだけが広がり、

人によって意味がまったく違う

状態になることです。

FDEは「スキルの総和」ではなく「責任範囲」で定義した方がいい

だから私は、

FDEを、

持っているスキルの数で定義しない方がいいと思っています。

それよりも、

何に責任を持つ人なのか

で定義する。

例えば、

私は、このくらいがFDEの本質に近いと思っています。

重要なのは、

全部を自分でやることではありません。

全部をつなぐこと。

です。

セキュリティの専門家になる必要はない

例えば、

AIを使った業務改革を進めていて、

セキュリティが重要な論点になったとします。

FDE自身が、

セキュリティアーキテクトと同じ深さで設計できる必要はないと思います。

でも、

「このデータをAIへ渡していいのか」

「認証・権限設計はどうするのか」

「ログは必要ではないか」

「機密情報をどう扱うのか」

という論点に気づく必要はある。

そして、

ここから先は専門家が必要だ

と判断する。

これも立派な能力です。

AIモデルも同じ。

高度なモデルチューニングを全部自分でできなくてもいい。

データ基盤も同じ。

大規模な基盤を自分で構築しなくてもいい。

大事なのは、

ではないでしょうか。

FDEに必要な能力には「深さ」が違う

キャリアパスとして考えるなら、

FDEに必要なスキルを全部同じレベルで並べるのではなく、

例えば3段階くらいに分けた方が現実的です。

自分で深く持つべきもの

経営・業務課題の理解。

課題設定。

仮説思考。

顧客との合意形成。

価値設計。

効果測定。

プロトタイピング。

このあたりは、

FDE自身のコア能力になる。

自分で使える方がいいもの

AI。

データ。

クラウド。

ローコード。

API。

アプリケーション。

このあたりは、

自分で小さく試せる程度の実装力を持つ。

専門家と会話できればいいもの

高度なセキュリティ設計。

ネットワーク。

MLOps。

高度なモデル開発。

大規模データ基盤。

法務やコンプライアンス。

ここは、

論点を理解し、

専門家と会話し、

適切に巻き込めればいい。

こう考えるだけでも、

FDEがかなり現実的な職種になります。

重要なのは「自分で全部やる」ではなく「最後まで手放さない」

私は、

ここがFDEの一番重要なポイントだと思っています。

セキュリティは専門家にお願いする。

データ基盤はデータエンジニアにお願いする。

大規模開発は開発チームにお願いする。

それでいい。

でも、

「あとはよろしくお願いします」

で終わらない。

なぜこの仕組みを作るのか。

どんな業務を変えるのか。

どんな効果を出すのか。

そこは最後まで持つ。

つまり、

これが、

FDEなのではないかと思っています。

そして、成果を「型」にする

もう一つ、

FDEにとって重要なのが、

一つの案件を成功させて終わらないことです。

ある顧客で、

AIによって見積業務を改善できた。

そこで得た知識を、

その案件の中だけに残さない。

どんな課題だったのか。

どんな業務に向いていたのか。

どのような技術構成だったのか。

何が失敗したのか。

どんな統制が必要だったのか。

どの指標で効果を測ったのか。

これを整理する。

そして、

次の顧客でも使える形にする。

つまり、

個社対応を「型」に変える。

以前の記事でも、

100人いても毎回ゼロから考えていたら強い組織にはならない、

という話を書きました。

FDEにも、

この視点が必要だと思っています。

一人のFDEがすごい。

ではなく、

一人の経験によって、次のFDEがもっと速く価値を出せる。

ここまでいって初めて、

組織として強くなります。

SIerにとって、FDEはかなり重要な役割になるかもしれない

SIerは、

システムを作る力を長い間磨いてきました。

高品質に作る。

安定して動かす。

大規模なプロジェクトを管理する。

これは大きな強みです。

一方で、

顧客の相談が、

「このシステムを作ってほしい」

から、

「この経営課題をどうにかしたい」

へ変わると、

求められる役割も変わります。

経営課題を理解する。

業務まで入る。

解決策を考える。

必要ならAIを使う。

小さく試す。

成果を確認する。

必要な専門家を巻き込む。

そして、

うまくいったものを型化する。

これは、

従来のコンサルタントやSEの境界だけでは、

少し説明しづらい。

だからこそ、

FDEという役割が出てきているのかもしれません。

「経営課題をITに翻訳する人」は、FDEなのかもしれない

FDEとは、

何でもできるエンジニアではない。

経営も、

業務も、

AIも、

セキュリティも、

開発も、

すべて一人で完璧にこなす人でもない。

私は、

なのだと思っています。

つまり、

全部をやる人ではなく、全部をつなぐ人。

そして、

専門作業は人に任せても、

顧客価値への責任だけは最後まで手放さない。

そこまでやって、

初めてFDEという役割に意味が出る。

もしFDEを、

「経営もできる、業務もできる、AIもできる、セキュリティもできる、コードも書ける人」

として定義してしまったら、

ただのスーパーマン探しになってしまいます。

そうではなく、

何を自分で持ち、何を専門家に任せ、それでも最後まで価値をつなぎ続けるのか。

FDEというキャリアを考えるなら、

スキル一覧を作る前に、

まずここを決めた方がいい。

私は、そんなことを考えています。