FDEとは少し違う?僕らが「ビジネスのど真ん中」に飛び込んでイノベーションを起こす理由
最近、社内のメンバーと話していて「FDE(Forward Deployed Engineer)」という言葉に出会いました。
この言葉を調べてみると、、、
フォワードデプロイドエンジニア(FDE)は、ビジネスの最前線に立ち、技術的な専門知識を駆使して課題解決を直接支援するエンジニアです。AI企業のPalantir社が提唱した役割で、従来のエンジニアとは異なり、顧客の現場に深く入り込み、製品の導入からカスタマイズ、運用までを一貫して担当します。
「ビジネスの最前線に飛び込み、現場の課題を技術で解決するエンジニア」とありました。最前線...かっこいいですね😃
ドクターズプライムでも、ここ1年でエンジニアがビジネスの現場に深く入り込み、AIを用いて業務フローを根底から見直す動きが加速しています。最初聞いた時はこれってFDEじゃんと思っていたのですが、「顧客の最前線」というより、社内の営業、人事、マネジメントといった「ビジネスの最前線」だったのでもしかしたらFDEとまでは言えないかもしれませんね。。。
この働き方を1年くらい実践していますが、これはドクターズプライムのミッション実現にとって、戦略上大きな価値を生むと考えています。
仕様書を待つのではなく、課題のある場所へ自ら出向いていく。そして、営業、人事、マーケターといった仲間と同じ目線で悩み、その解決策を技術という道具で形にする。まぁFDEと呼ぶかどうかはさておき、ビジネスにエンジニアが入り込んで何をしているのかという話をしていきます。
「ビジネス越境」の実践例
2つの事例を紹介します。
1. 【人事】カルチャーを浸透させる「OS」の構築
「カルチャーを、もっと社員一人ひとりに多義性なく浸透させたい」。人事のチームの大きなテーマとなっています。
その施策の一つに、週1回の全社朝会で「カルチャーに沿った行動」を考えたり、議論したり、発表しあったりする文化が元々ありました。素晴らしい取り組みですが、どんな行動がカルチャーに紐付くのか分かりにくい、という声も上がっていました。また、人数が多くなりチームを分けて議論するうちに、チームごとに新たな解釈が生まれ本来意図していた意味とは違う伝わり方をして多義性が生まれることもありました。
そこで、エンジニアが人事チームに入り、このカルチャー浸透の仕組みを「組織のOS」として再設計しました。最終的には、行動指針に沿って行った行動をフォームで具体的に記述してもらいその結果をAIが分析し、「あなたのこの行動は、カルチャーのこの部分と繋がっていますね」や「解釈が少しずれているようです。◯◯のような行動を心がけましょう」と客観的なフィードバックがメールで返ってくるような運用を行なっています。(ここには副次的な効果もあり、AIに言われる方が受け入れやすいというような声もありました。)
AI評価の仕組みを導入することで、全社が公平に多義性なくインストールすることができた、象徴的なプロジェクトです。
2. 【マネジメント】AIによるフィードバック品質の均質化
「マネージャーの経験やスキルによって、メンバーへのフィードバックの質に差が出てしまう」「マネージャーの負担を少しでも軽くしたい」。これは、特定の誰かではなく、組織全体が抱えていた課題でした。
この課題に対し、まずは毎月末の振り返りと次月の目標設定においてAIを用いたフィードバックが走るようにしました。特に目標設定のところでは上長がチェックする前に目標設定の基準が揃うので上長側の工数を省けています。
ここはエンジニアが普段の業務の中でレビューに出す前にローカルやCIでlintやユニットテストで落ちたり、AIレビューでコメントをもらったりと、人のチェックを行う前に潰す方がいいよねという考えをフローに適用しました。
さらに現在は、今まで当たり前のように行なってきた上長との1on1すら無くせないか試行錯誤してみています。例えば、メンバーの日々の活動記録(日報やSlack、エンジニアであればFindy Team+の結果など)をもとに、客観的なフィードバックをAIが生成し自分自身で経験学習を回せる仕組みを構築中です。
当たり前にやっていたコトを0に出来ないかという無理難題?から、会社全体のマネジメント品質という「仕組み」を技術の力でアップデートしていく。そんな視点を大切にしています。
ビジネスに飛び込むエンジニアが持つべき「仕組み化の極意」
これらの活動を通して、僕たちが共通して大切にしている思考法があります。それは単なる「業務効率化」の視点を越えた、イノベーションを起こすための「仕組み化の極意」です。
極意1:前提を疑う「そもそも、これって必要ですか?」
ビジネスサイドに入って最初にやるべきことは、コードを書くことではありません。「なぜ、この業務は存在するのか?」を問うことです。
多くの場合、改善の依頼は「今あるこのフローをもっと楽にしてほしい」という形でやってきます。しかし、僕たちはそこで立ち止まります。
- 「そもそも、このフロー自体をなくせませんか?」
- 「このアウトプットを得るんだったら、全く違うアプローチでも良くないか?」
- 「この業務の目的を達成する上で、無駄なステップはないか?」
エンジニアの論理的・構造的な思考は、こうした「前提の破壊」において強力な武器になります。既存の延長線上で改善を考えるのではなく、常にゼロベースでオペレーションを組み直し、本質的な価値創造を目指す。この視点なくして、ビジネスに入り込む意味はないとさえ感じています。
極意2:AIネイティブでオペレーションを再構築する
AIの登場で、業務のあり方は根本から変わりました。重要なのは、「既存の業務をAIに置き換える」という発想ではなく、「AIの存在を前提とした、全く新しいオペレーションを設計する」というAIネイティブな思考です。
後からAIを付け足すのではなく、初めからAIという優秀な同僚がいる前提で、人間とAIが最もパフォーマンスを発揮できる業務フローを描く。これが、これからのビジネス×テクノロジーのスタンダードになると考えています。
まとめ:ビジネスのミッションを実現するために
AIが進化し、多くの定型的なコーディングが自動化されつつある今、エンジニアに求められる役割は確実に変化しています。
ビジネスの現場に飛び込み、生々しい課題に触れる。それは、今まで見えていなかった解像度で事業を理解する絶好の機会です。そして、そこで得たインサイトを元にテクノロジーを駆使してイノベーションを起こすことは、エンジニアにとって自分自身の枠組みを超えた大きな成長をもたらしてくれます。
ミッション視点で現場に入って課題を解決するために、自らのスキルを伸ばし今まで持ってこなかった発想や技術から解決策を出す過程が、個人視点で学習するだけでは見えない成長を生み出しています。
ぜひ、これからFDEになられる方やビジネスの現場に入って課題解決される際はこの極意を参考にしてみてください!!
Discussion