中島聡氏とdiv石原圭氏が語る「FDE思考」:AIを個人の効率化で終わらせず、業務そのものを作り直す

YouTubeで開く ↗
概要

AIを業務に取り入れる企業は増えたが、多くは「個人がChatGPTを使って少し楽になった」段階にとどまっている。この動画では、Windows 95やInternet Explorerの開発に関わったエンジニア/起業家の中島聡氏と、AI・ITスクールを運営するdivのCEO石原圭氏が、この壁をどう越えるかを議論した。鍵として示されたのが「FDE(フォワード・デプロイド・エンジニア)」の考え方である。両氏の立場は、エンジニアが現場に入るだけでなく、業務を知る現場の人がエンジニア的な発想を持つべきだというものだ。

18分で読めます
1:45

「40年で最大の波」:中島氏が自分でコードを書かなくなった理由

冒頭で司会者は、パソコン、インターネット、そしてAIという変化を当時と比べてどう感じるかを中島氏に尋ねた。中島氏は、ワクワクする感覚は似ていると認めたうえで、40年以上ソフトウェア業界にいて今回ほど大きな波に出会ったことはないと答えた。インターネットやスマートフォンも大きな流れだったが、今回は「桁違い」であり、社会が変わるのにまだみんな気づいていないだけだという。

司会者が、生成AIが登場して2年ほどで自分の業務がかなり効率化できたと感じる程度だと話すと、中島氏は自分の場合は「100%」変わったと応じた。半年前と今とでやっていることがまったく違う。40年間プログラムを書いて生きてきたが、今は一切書かず、AIに書かせている。しかもAIが書いたコードを読むこともない。半年前はまだ読んでいたが、今は読みもしないと中島氏は話した。

3:05

FDEとは何か、なぜ非エンジニアに関係するのか

石原氏によれば、FDEはForward Deployed Engineerの略で、アメリカ発祥の概念である。エンジニアがコンサルタントのように現場に深く入り込み、プロダクトの実装まで担う職種として注目されており、OpenAIを含む多くの企業がFDEを採用したり顧客企業に送り込んだりしているという。

司会者は、現場の課題を見抜く力はどの職種にも必要だが、設計・実装を担うエンジニアとなると、これまでコードに触れていなかった人にどこまで関係があるのかと疑問を示した。これに対して石原氏は、FDEはもともと「業務プロセスを知らなければ実装できないので、エンジニアが現場に入る」という発想だが、逆に業務側で働く人もエンジニアの発想を持てるようになったと説明した。AIによって自分でコードを書かなくてもよくなった今、現場側からエンジニア側に入っていく道もある。それがdivの考える「FDE思考」であり、すべてのビジネスパーソンに必要なものだというのが石原氏の主張である。

4:49

日本のAI導入:利用は8割、業務変革は2割

議論の最初のテーマは、AI導入がなぜ個人業務の効率化で止まってしまうのかだった。石原氏はスライドで、何らかの業務でAIを使っていると答えた企業の割合が2025年に約5割、2026年には約8割に達したことを示した。ChatGPTやGeminiに触れたことのない人はかなり減り、個人がAIに相談したり資料を作らせたりする活用は進んでいるというのが石原氏の見方である。

一方で、AIによって組織単位で業務を根本から変えている会社はかなり限定的だという。別のスライドでは、業務変革に取り組んでいる企業は全体で約2割、中小企業では約1割にとどまっていた。石原氏は、多くの会社では社員にChatGPTが配られ、個人が使っているだけの段階で止まっていると評した。

6:02

中島氏の見方:DXの本質は既存ビジネスを滅ぼすこと

中島氏は、これは日本に限った話ではなく、アメリカでもAIを導入したのに効率があまり上がっていないというデータが出てきていると指摘した。そのうえで、少し前に日本で流行したDXと同じ構図だと述べた。中島氏の定義では、DXとはデジタル技術を既存の業務に取り入れることではなく、デジタル技術を担いだ新しいビジネスが既存のビジネスを滅ぼすことである。日本ではこの意味がねじ曲げられたが、AIでも同じことが起こると中島氏は見ている。

わかりやすい例として中島氏が挙げたのが、Amazonが既存の書店を潰したことだ。Amazonは守るものがなく、オンラインで本を売ったから勝てた。AIも同じで、既存の業務に少しずつAIを取り込んでも何も変わらないというのが中島氏の主張である。

具体例はソフトウェア開発だった。従来は、プログラムマネージャーがニーズを拾って仕様書を書き、デザイナーがデザインし、エンジニアが実装し、QAグループがテストするというように、少なくとも4つのグループが関わっていた。この形態のまま各自にAIで効率化しろと言っても、せいぜい10〜20%の改善にしかならない。しかし「4種類の仕事はいらない、1人でできる」と考えて1人がAIに全部やらせれば、効率は300%上がると中島氏は述べた。

ただし、これはベンチャー企業を作るくらい思い切ったことをすればできるが、既存の組織では非常に難しい。トップはそもそも理解していないので言い出せないし、現場の人は自分の仕事を失いたくないので「この仕事はいらない」とは言えない。その結果、デザイナーもプログラムマネージャーもエンジニアもQAもChatGPTで自分の仕事を少し効率化し、「AIを導入した」と言っているのが日米共通の現状だという。組織のトップに変えようとする人が現れない限り会社はなかなか変わらず、特に日本は人を簡単に解雇できないため、100人でやっていた仕事がAIで10人でできると気づいても実行できない。だから本当に賢い人は会社を抜けて自分で会社を作る。それがアメリカのダイナミズムで、今アメリカで激しく起きていると中島氏は話した。

9:00

現場とベンダーの分断を埋める役割

組織変革の壁について、石原氏は日本のシステム開発の構造を挙げた。日本では外部ベンダーにシステムを作ってもらったり、既存のSaaSを組み合わせたりするのが一般的だった。現場の人は、業務で何に困っているか、何が使いやすく何が使いにくいかを知っている。しかしITの知見やセキュリティの判断がないため、自分で作るという発想が出てこない。逆にベンダー側には要件は降りてくるが、本当の「なぜ」が分からない。この分断が続いてきたというのが石原氏の整理である。

この溝を埋めるのがFDEであり、作る側の人が業務を知る側に入っていく、つまり要件定義や課題発見といった上流にエンジニアが入っていくことがFDEの重要なポイントだと石原氏は述べた。

9:56

アメリカと日本のFDE市場

アメリカの状況を問われた中島氏は、FDEの能力は簡単に測れないため、自称FDEが大量に生まれており、企業側もフィルタリングが難しく、間違った人を採用して失敗し解雇するということも起きていると話した。それでも、たとえばPalantirで経験を積んだような本物のFDEは引く手あまたで、40万〜50万ドル(日本円で6000万〜7000万円程度)の給料が平気で出るのではないか、と中島氏は見ている。

石原氏によれば、日本でもアメリカに遅れて企業がFDEを募集し始めており、もともとはプロダクトを持つ会社がそれを顧客に導入するためのFDEが出発点だという。ただし位置づけはアメリカとかなり違い、数千万円の報酬という人はまだほとんどいないだろうとした。一方で、コードを書くだけのエンジニアの価値は下がっていくため、一般のエンジニアも顧客と話して課題を見つけ、要件定義の手前から入ることが求められるようになると石原氏は考えている。グループ会社で開発事業を手がけるdivxでは、ChatGPTが登場した2023年頃からAIによる開発を必須にしており、開発現場がAIで回るようになった結果、顧客と話して課題を見つけ提案するところから入るエンジニアが出てきているという。

12:12

中島氏のMicrosoft時代:頼まれる前にプロトタイプを作る

中島氏自身がこうした思考をいつ身につけたのかという問いに、中島氏はMicrosoft時代の話をした。上から降ってくる仕事を待っていてもそれなりの待遇は得られるが、会社として次に何をすべきかというビル・ゲイツの言葉を聞き、上司に頼まれる前に作ると出世することに気づいた。それが社内での「出世術」だったという。上司の言うことを聞く必要はなく、ビル・ゲイツのメッセージから何を作ればビルが喜ぶかを考え、頼まれる前にプロトタイプを作って上司に見せる。なぜ作ったのかと聞かれて理由を説明すれば、手柄はすべて取れると中島氏は語った。

きっかけはWindows 95の時期だった。中島氏はWindowsのグループで1992年頃から95年にかけて開発に取り組んでいたが、Windows 95の発売の半年ほど前、ビル・ゲイツが突然「次はインターネットだ」と言い出した。Windowsを作っている立場からすれば「次はWindowsではないのか」と思う。調べると、社内にはInternet Explorerの小さなグループができていて、Netscapeとの戦いが始まっていた。中島氏がNetscapeのウェブサイトの資料を片っ端から読むと、これからはOSの時代ではなくインターネットの時代だと書かれていた。まさにOSを作っている最中にそう言われ、ビル・ゲイツも同じ方向を発信している以上、インターネットに注力するしかないと考えた。そこで中島氏は、インターネットの技術をWindowsに取り込む機能をWindows 95の発売前から密かに組み込み始め、発売直後に「こういうものを作った」とプレゼンした。ビルが喜ぶに決まっている、と中島氏は振り返った。

石原氏はこの話を受けて、FDEという言葉は最近のものだが、エンジニアがビジネス思考を持てば、定義とは関係なく昔からこうした働き方になっていたのだろうと感想を述べた。

15:51

何をAIに任せるかではなく、何を人間に残すか

2つ目のテーマ「FDE思考を取り入れろ」で、石原氏はあらためて論点を整理した。これまでは、プログラミングに加えてセキュリティ、ネットワーク、コンピューターの理解といった習得のハードルが非常に高く、エンジニアはどこも人材不足だった。そのため、エンジニアが現場に入るのが唯一の解決策だった。しかし今は、プログラムを書く部分をAIに任せられる。業務を理解している人がエンジニア的な発想を持てば、「ここが非効率だ」「ここに時間がかかっている」「ここさえ変えれば全部自動化できる」と気づけるようになる。大規模システムには依然として大変な部分があるが、形にするハードルは大きく下がったというのが石原氏の主張である。

中島氏は、「AIが職を奪うのではなく、AIを使いこなす人が職を奪う」という言葉に触れ、10人でやっていた仕事が1人でできるようになると述べた。その1人は、なぜその機能が必要かというニーズの部分から、セキュリティのしっかりしたシステムを作るところまで、幅広い知識を持たなければならない。そのためにはかなり勉強が必要だという。

18:42

事例:経理業務130時間を20時間に

石原氏は、divが実際に提案した経理業務の改善事例を紹介した。ある企業の経理業務に非常に時間がかかっており、顧客自身もどこに何を入れれば解決するのかまったくイメージできない状態で相談を受けたという。調べると、請求書が届いたら照合し、部署に内容を確認しに行き、勘定科目に落とし込み、承認を経て会計ソフトに取り込むという一連のプロセスに、約130時間かかっていた。

どう解決するかを問われた司会者は、毎回人間の目視チェックが必要な部分が大変そうなので、請求書の照合などを写真撮影で自動化できないかと答えた。石原氏はそれも解決策の一つとした。

中島氏の答え方は違った。自分がFDEとして派遣されたら、まず承認など絶対に人間が関わらなければならない部分を見つけ出し、それ以外をすべて自動化するという。請求書と領収書の数字が合っているかは自動でできる。しかし、そもそもその支出が会社として正しいかどうかは人間が見なければならない。そうしたゼロにできない部分を抜き出し、そこだけ人間が関わり、あとは自動にするのが自然だと中島氏は述べた。

石原氏はこの発想が非常に重要だと応じた。これからは「何をAIに変えるか」ではなく「何を人間に残すか」を考え、それ以外はすべてAIにやらせる発想が必要だという。さらに、人間がやらなければならないと思われている作業も本当にそうなのかを問うべきだとした。今のシステムだから人間にしかできないだけで、別のシステムに変えてAIが読めたりAPIで操作できたりすれば解決するのではないか。この承認は本当に人間が必要だが、ダブルチェックはAIに任せればよいのではないか。そうやってAIに任せる部分を極力増やす発想が大事だと石原氏は話した。

実際のプロセスとして石原氏が説明したのは次の流れである。まず現場に行き、記帳担当者や照合担当者など実際に業務をしている人に話を聞く。それを音声などで書き出して業務を可視化し、プロセスフローチャートにしてFDE自身が理解し、顧客にも分かる形にする。そのうえで人間が残るべきポイントを決め、それ以外はAIにやらせる。新しく何かを導入するのか、どこから情報を取るのかを設計しつつ、その場でシステムにして顧客に使ってもらい、使いやすい・使いにくいというフィードバックを受けて改善する。最終的に実装し、運用まで行う。

石原氏が強調したのは、このプロセスのうちエンジニアでなければできないのは「システムを作る」という1工程(スライドでは7番)だけで、仕事の大部分は業務理解と顧客とのコミュニケーションだという点だ。AIがない時代は開発に膨大な時間がかかり、普通の人にはできなかった。しかし今、現場の人が開発部分を自分で実現できるなら、業務理解はもともと持っているので、欲しいものや自動化できるものをその場で作って導入できる。そうした人が部署や会社にたくさんいれば、部署単位・会社単位でプロセスそのものを変えようという発想が現場から出てきて、AI推進が進むと石原氏は見ている。逆に、自分に与えられた業務の範囲だけで開発して自分の仕事を楽にするのでは、改善はその範囲にとどまる。

改善後は、申請が上がった時点で必要な情報にAIがアクセスでき、ルールに基づく検査をしたうえで結果だけを承認者に届ける形になった。人は最後の判断と承認だけを行う。根本的に人がやる作業が減った結果、130時間が約20時間に下がったという。組織全体で進める際には、ヒアリングした業務を「経理担当者がやること」「AIエージェントができること」「システムを作って対応すること」と分解し、担当を決めてAIエージェントを組み込んでいくと石原氏は説明した。

25:33

中島氏の取り組み:非エンジニアのための「ハーネス」

ここまでの議論を受けて中島氏は、エンジニアにコミュニケーション能力を求めるのか、コミュニケーション能力を持つ人にAIでエンジニアリングをしてもらうのかは大きな問題であり、今まさにそれをテーマにコードを書いていると明かした。

中島氏によれば、少なくとも現時点のAIは、非エンジニアがシステムを作れと頼んでも押さえどころを押さえてくれない。そこで、馬でいう馬具のように、馬が暴走しないようにする仕組みを用意すればよいのではないかと考えている。中島氏らはこれを「ハーネス」と呼んでいる。ニーズを分かっている人が「作って」と言えば、セキュリティなどの部分はハーネスが押さえているので、AIが何をしても壊れない。そういう作り方のシステムを作れば問題は解決するというのが、中島氏の現在のテーマであり、取り組んでいる最中だという。これがうまく回れば、その一歩先として、FDEがいなくても顧客自身が問題を解決できる時代が来るのではないかと中島氏は述べた。

26:49

育成プログラムの設計:あえてAIを使わない段階

3つ目のテーマ「どう身につけるか」では、石原氏がdivの「テックキャンプ FDE」を紹介した。個人のAI活用を超えて組織の業務変革を起こせる人材を育てることを目的とした、4か月のマンツーマン伴走型プログラムだという。

内容は2段階に分かれる。ステップ1ではスキルを習得する。AIエージェントの基本的な使い方や概念の理解から始め、その後ウェブアプリケーション開発を、あえてAI使用禁止で学ぶ。石原氏はその理由を、基礎を理解していないと、AIに書かせれば書けてしまうが何が起きているか分からない状態になるからだと説明した。いったんエンジニアの基礎を身につけたうえで、AIエージェントを活用した応用に進む。セキュリティやインフラ周りの知識もこの基礎部分で学ぶという。

ステップ2では架空のクライアントを相手にロールプレイを行う。実在の会社をモチーフにした「T精密部品会社」という設定で、社員数なども細かく決められている。経営者へのヒアリングから状況把握、課題設定、提案、システム化と実装、納品、運用までを通して行う。先ほどの経理事例の検討を、より本格的にやる形だと石原氏は述べた。

divはもともと10年以上、未経験者をエンジニアとして育成する事業を行ってきたといい、そのノウハウをFDE育成に取り込んでいると石原氏は説明した。受講者の多くは働きながら夜や週末に学んでおり、途中で脱落する人はそれほど多くないという。受講者は30代〜50代が中心で、業界も業務知識もさまざまだ。エンジニアもいるが一部で、自分の業務にAIを取り込みたい人や、自らその発想を持ちたい経営者も学んでいる。たとえば小学校の教員の課題のように、現場ごとの課題は本当にバラバラで、受講者から運営側が想像していなかった解決策が出てくることも多く、自分たちも勉強になっていると石原氏は話した。個人向けのほか、企業内のFDE育成支援と、divのFDEが企業に入ってAI導入を進める法人向けサービスもあるという。

33:13

中島氏の評価:Claude Code教室との違い

プログラムについて意見を求められた中島氏は、こうした話は疑いを持って聞くとしたうえで、世の中に多いClaude Code教室と比べると「筋はいい」と評価した。目標がはっきりしているからだという。Claude Codeのコマンドやスクリプトの作り方は必要だが、それだけ教わっても何に使うのかが分からなければ意味がない。Claude Codeは道具であり、目的はクライアントや自分自身の問題を解決することだ。その実践を通して学ぶアプローチは筋がいいと中島氏は述べた。

石原氏は、少なくとも現時点では、プログラミングの知識がまったくない非エンジニアでも問題ないとは言えないと考えている。現場の人もある程度エンジニアに近づき、エンジニアも現場の思考を持つ必要があり、両方が求められる時代だという。コンピューターの基礎概念やセキュリティを学んだうえで、Claude CodeやAIはあくまで手段として、自分の業務の目的のためにどうヒアリングし、どう進めるかという一連のプロセスを学ぶことが本質であり、カリキュラムの中でClaude Codeを扱う部分はごく一部だと説明した。

35:47

「1回しか使わないソフト」がほぼタダで作れることの価値

最後に中島氏は、今のホワイトカラーの仕事は8割ほどなくなると思うと述べた。残るのはAIを使いこなす人であり、FDEだけが答えではないものの、AIを使いこなして業務を効率化し、会社のプロセスを良くするという意味でこうした学びは有効で、会社がお金を出してくれるなら喜んで参加すればいいのではないかと語った。

そして中島氏が「すごく大事な話」として付け加えたのが、ソフトウェアの価値についての見方である。コードを書けるAIが登場したことでSaaS企業の株価が下がった。ソフトウェアの開発コストが下がれば1〜2人のベンチャーでもSaaSを作れるようになり、蓄積したソフトウェアを持つSalesforceやAdobeの価値が下がると市場が考えたからだ。しかし中島氏は、それは単なるコスト削減にすぎず、実はたいした価値ではないと考えている。

中島氏が「とんでもない価値」だとするのは、ユーザーが1人しかいない、あるいは1回しか使わないソフトをほぼタダで作れるようになったことだ。たとえば来週5人でキャンプに行くとき、誰が何を持っていくかを調整するアプリを20分で作ってみんなに配り、使い終わったら終わりにする。割り勘の際に「男性は倍払う」といったルールのアプリもその場で作れる。これまではコストが高すぎて誰も作ろうとせず、汎用アプリやGoogleスプレッドシートを工夫して使っていた。今まで誰もソフトウェアにしようとしなかったことを、その場で作って使い捨てられる点にこそ大きな価値があり、まだ気づいていない人が多いと中島氏は話す。この発想で業務に取り組めば、とんでもないことが起こるのではないかというのが中島氏の見立てである。

石原氏も、日々自分用にいろいろなものを作り、楽になったことに毎日感動していると応じた。この感覚を今味わっている人と、自分ごととして捉えていない人とでは、今後大きな差がつくと石原氏は考えている。最初はプライベートや、使いづらいアプリを自分用に作り直す程度で構わない。その発想が生まれれば、視野を部署全体に広げ、自分が作ったものを全員で使えないか、部署を変えられないかと考えられるようになり、部署も組織も変わっていく。そう考えられる人を増やすことが大事だと石原氏は締めくくった。