FDEとは、顧客の現場に入り込み、成果で報酬を得る新しい職種のこと

出典: 【中島聡】米国で急拡大する新職種「FDE」とは／年間10億円の削減例も／40年書いたコードをAIに任せた理由／生産性は10倍に／「成果で稼ぐ」働き方とは

AIが書いたコードを、そのまま使えるのか？この章は、AIの進化と、コードを書く仕事の変わり方の話です。

最初の問いは、松尾さんから。世界最高レベルの性能を持つ最先端の汎用AIが注目されているけれど、どう評価するのかと尋ねます。

答えは、進化の速さに驚いている、というもの。ここ4か月で、コーディングを完全にAIへ任せるようになったと話します。

半年前までは、AIに少しコードを書かせても、毎回すべての確認が要り、信頼できなかったそうです。今は、ほとんどコードを見ずにAIへ指示を出す毎日。

今の流れは、AIにコードとテストを書かせ、よければそのコードを別のAIにレビューさせて、通ればマージする、というものです。

中島聡さん（動画 2:15〜）

またそのコードを別のAIにレビューさせて、え、よかったらマージするという感じで

40年あまりプログラムで生計を立ててきたやり方が、この4か月でガラッと変わった、という言い方も動画の中で出てきます。

続けて松尾さんは、フロンティアAIには、話題づくりが先に立っているだけでは、という懐疑的な見方もあると問います。

答えは、マーケティングの面はあったと思う、ただ急激な進化をしている、というもの。普通のソフトエンジニアのレベルを超えてきた、と中島さんは話します。

若いエンジニアに任せる時も相当な信頼が要ったそうで、今コードを見ずに取り込めるのは上位10〜15%ぐらい。AIがその水準に来た、というのが本人の感覚です。

中島聡さん（動画 4:02〜）

書いたものを取り込めるエンジニアって多分上位10%とか15%ぐらいしかいないので、そのレベルに上がってきたってことですよ。

任せたあとの確認で時間が消えていくなら、手が空いたことにはなりません。確認を誰に、どう預けるかが、任せる仕事の中心になります。

私の場合、外に出す文章や成果物は、渡す前に、作ったAIとは別の系統のAIに確かめさせています。点検役は、合否を判定して返すだけです。

公開するかどうか、最後の判断は私が持っています。点検役の判定は、あくまで材料です。

私の記事より（AIの速さに確認が追いつかない問題を、和田卓人さんの解説から整理した記事・仕様・型・リスク・理解。残りの4つで、人間が見る場所を絞るの節）

私なら、確認することを全部書き出して、2つに分けます。間違えると影響が大きいもの。間違えても、すぐ戻せるもの。人間が見るのは、影響が大きい方だけに絞ります。

全部を見ない代わりに、人が見る範囲を先に決めておくこと。中島さんの流れと私の運用が並ぶのは、この一点です。

違うところもあります。中島さんの流れでは、確認をテストと別のAIのレビューに預け、コードはほとんど見ません。

40年あまり書いてきた本人の経験の上に立つ感覚。私が持っているのは、公開するかどうかの最後の判断です。

私なら、作業はAIに渡し、何を合格とするかの基準と最後の判断は自分で持ちます。

仕事が速くなった先で、何が起きるのか。この章は、生産性の話と、それが採用にどう響くかの話です。

AIの津波が押し寄せる時、最初にまともに受けているのは自分たちソフトエンジニアだ、と中島さんは話します。働き方は根本から変わった、という見立てです。

中島聡さん（動画 4:58〜）

その津波が来たので波に乗るしかないわけですよ。

じっとしているだけでも置いていかれる、だから自分の生産性を爆発的に上げる、と続けます。

生産性は、本人の感覚で少なくとも10倍ぐらい。

中島聡さん（動画 5:11〜）

少なくとも10倍ぐらいにはなってますよね。

以前は、べらぼうに優秀なエンジニアが下につくと、仕事を渡してもすぐ終えて指示待ちになることが、たまにあったそうです。今は、AIがその状態。気づいていないソフトエンジニアがいたら深刻だ、と中島さんは説明します。

一般の人には、どう押し寄せるのか。まだ見えない部分もあるそうです。ただ、少なくとも米国では、若いエンジニアを取るのをやめよう、と普通に言われていると話します。

中島聡さん（動画 6:12〜）

少なくとももう米国においてはとにかくあの若いエンジニア取るのやめようっていうのはもうごく普通に一般に言われてて

会社が伸びる時は、毎年10%、20%と採用を増やすもの。

生産性が上がるなら人数を減らしたい、けれど減らし方が分からないので、とりあえず雇わない雇い止めがまず起きている、と説明します。

小さな会社の始め方も変わった、という話。お金を集めて10人、20人、30人のエンジニアをそろえる時代は終わり、1人の優秀なエンジニアで一昔前の20人、30人分の生産性が出るそうです。

ここで松尾さんの問い。プログラマーの世界で起きたことは、ほかのホワイトカラーにも広がるのか？

答えは、ソフトエンジニア並みかは分からないが、普通の仕事でも3倍、力を入れれば10倍ぐらいの生産性向上は起きて不思議はない、というものです。

本人も、ソフトだけでなく文章や映像も作る人。収録の前日にも、英語で約20ページの論文を、AIと話しながら実験して1日で書いたそうです。

その波には、ソフトエンジニアでない人も乗らないと置いていかれる、と中島さんは話します。

変わる所は、はっきりしています。作る時間が縮むほど重くなるのは、何を作るかを決める人の役割。

若手の採用を控える動きは、減らし方が分からないまま、とりあえず雇わないという話。人を増やす前に、何を任せるかを決める順番が問われています。

AIに委ねて、人は積み減らして生き直す。空いた時間に仕事をさらに積むだけなら、抱え込みは減りません。

10倍という数字を追う前に、空いた時間に何をするかを先に決めます。

ソフトウェアを作る現場には、どんな役割の人がいたのでしょう？ 話の流れで、松尾さんは新しい職種FDEの話に入ります。画面には、その定義が出ます。

画面の定義では、FDEはForward Deployed Engineerの略。顧客の現場に深く入り込み、課題発見からシステムの実装・運用・定着までを一貫して担います。技術とビジネスの両輪で成果を出すエンジニア職、という定義。

ここで中島さんは、昔のソフトウェア開発を振り返ります。いたのは、ソフトエンジニア、仕様と工程を管理するプログラムマネージャー、テストをするQA、UIや使い心地を設計するデザイナー。4つの職種がソフトウェアを囲んでいました。

生産性が大きく上がった今、中島さんの開発では、残りの3人がいらなくなっていると話します。仕様は自分で決めます。デザインはAIと一緒に考え、テストのプログラムもソフトもAIに書かせます。

4人で分けていた仕事を、1人が全部持てるようになった、というのが話の前提です。

中島聡さん（動画 11:33〜）

私が仕様を決めて、ま、デザインもAIと一緒にして

話は、楽器のたとえに進みます。バイオリン奏者から、指揮者になった感じ。ほかの奏者はいらず、全部AIが弾いて、指揮だけでオーケストラの音楽ができてしまう、と説明します。

中島聡さん（動画 12:00〜）

私は指揮してるだけで、あの、オーケストラの音楽ができちゃうっていう状況になってます

ただ、この仕事は難しい。かなり経験を積まないとできない、と中島さんは続けます。

元プログラムマネージャーでも、相当優秀でないと務まらないそうです。上から仕様書だけを受けてコードを書いていた人には、プログラムマネージャーやデザインの仕事はできない、という見方です。

残るのは、全体を見る力。お客さんは何を求めているのか、いい音楽とは何か、まで踏み込んだ深い理解を持つ人しか、仕事ができなくなったと話します。今ソフト業界で起きつつあるのが、まさにFDEだ、という説明。

中島聡さん（動画 12:38〜）

その全体を見る力とかね、そもそもお客さんは何を求めてるんだっていうこと

任せる側に回ると、作る手の仕事は減ります。残るのは、何を良しとするかを決める仕事。仕様もデザインもテストもAIに渡せる今、人が持つのは、その目です。指揮台に立つって、そういうことなんですよね。

私の記事より（AIが作った物の確認を、人に残る判断から整理した記事・AI時代に人へ残る5つの判断。確認が通っても、中身を知らなくていいことにはならないの節）

私は、確認が通ったことと、理解していることを別に置きたいです。AIが作る量が増えるほど、この差が効いてくると読みました。

確認が通ったことと、理解していることは、別の物です。任せたあとに手元に残したいのは、理解のほうです。

全体を見る力は、任せる量が増えるほど効いてきます。演奏が全部AIになっても、どの音楽を目指すかを決めるのは指揮台の人。

私なら、お客さんが何を求めているかは、自分で縦に掘ります。

システムを頼んだのに、現場の仕事が軽くならないという話を、聞いたことはありませんか？ この章で目が向くのは、お金の取り方そのものです。

話は、日本のエンタープライズ向けの仕事から始まります。一番前に立つプライムベンダーが顧客から契約を取り、仕様書を書いて下請けに投げます。その下に孫請けが続き、コーディングは仕様書を書くエンジニアが担う構造です。

画面のスライドには、顧客から元請け、一次請け、二次請け、三次請けへと続くピラミッド。ゼネコンと同じ形です。

大人数で作るので、人月で儲かります。人手をかけるほど儲かる、変なビジネスモデルだった、と中島さんは話します。

FDEを最初に始めた会社がある、と中島さんは考えています。特別に優秀な人を、相手の会社の中に送り込む形です。ビジネスの理解からプログラミング、テスト、UI設計、AIの活用まで、全部できる人。

送り込まれた人は、内部の全データにアクセスします。AIを使いこなすには何をすればいいのか、現場で探る役。

例に挙がるのは小売店です。在庫の削減、季節ごとの仕入れのタイミング、数の予測、天気に合わせた数の調整。ビジネスは複雑だ、と中島さんは説明します。

それを顧客から聞いて理解し、AIで実装して、相手の中に組み込む。そこまで1人で全部できる、という説明です。

だからFDEは、人月ではなく成果報酬。店に行き、在庫管理システムを調べて効率よくしますと言って、実際にやってしまう。年間10億円の在庫コストを減らせた状況を作ってから、年間の報酬を求める流れです。

画面のスライドにも、年間10億円のコスト削減という記載があります。

対して人月は、在庫管理システムを作ってと言われたら、何人月でいくらと決め、作って納品したら終わり。

中島聡さん（動画 16:21〜）

それで実際に在庫が減るかどうかなんてどうでも良くて

FDEは、本当に成果が出ないとビジネスにならないのだそうです。話はそう続きます。送り込まれた人は、その会社の在庫を減らし、経費を減らし、売上を上げることに本気で貢献する、という説明です。

中島聡さん（動画 16:44〜）

貢献した結果の成果報酬を、え、年間契約でもらうというビジネスモデルなので

人月の交渉ではありません。根本的に、ビジネスの形が違うという話です。

ただし、特別に優秀な人が要ります。分業体制を作りすぎたITゼネコン体制では、コーディングから顧客の要望まで全部できる人がほとんど育っていません。だから非常に厳しい、と中島さんは話します。

中島聡さん（動画 16:59〜）

それが果たして日本のそのソフト業界にいるのかっていうぐらい優秀な人ですよね。

松尾さんは、究極の形は成果報酬型で、それを実現できるのがFDEではないか、と問います。日本ではやってきた人がいないので、遅れて取り組むことになる、という見立て。

中島さんの答えは、そういう人はGAFAMも欲しがる、というもの。人材として非常に少ないうえに給料が高い。昔ながらの日本企業が雇えるのか、という問題もあると話します。

人月は、作って納品したら終わり。成果で稼ぐなら、成果が出るまで関わり続けることになります。違いは、どこで手を離すか、なんですよね。

私は、集客とセールスを、パーパスやミッションが合う人や、AIに、成功報酬で分け合う形で委ねる組み方を話しています。

自分は、商品やサービスづくりに集中します。いまのところ、構想の段階の組み方です。

私の記事より（コーディネーターに任せても忙しいなら、終点を持つ人を決める記事・まとめの節）

窓口を任せても忙しいなら、終点まで引き受ける一人が決まっていません。

私は過去の記事で、窓口を任せても忙しいなら、終点まで引き受ける一人が決まっていません、と書きました。課題発見から定着まで通して担うFDEの説明は、私の中でこの見方と並びます。

ただ、成果で稼ぐ形には、特別に優秀な人が要ります。中島さん自身がそう話しています。

仕組みの名前だけ借りても、成果は出ません。誰でもすぐできる話ではない、というのが私の受け止めです。

成果が出るまで関わる人を、自分の側にどう置きますか？

私なら、成果で稼ぐ形を、誰でもすぐできる話とは考えず、最後まで引き受ける一人を先に決めます。

作業はAIに渡します。何を合格とするかの基準と、最後の判断は、自分の側に置いたまま。

空いた時間の使い方を、先に決めておきます。任せたあとに仕事を積み直さないためです。

成果で稼ぐ形は、最後まで引き受ける一人を先に決めるところから。任せている作業と、任せたい作業を3つ書き、それぞれを最後まで引き受ける人を横に書いてみてください。名前が書けない行が、先に決める所です。