FDEという言葉には、企業によってさまざまな使われ方があります。FDEを理解する上で代表的な例の1つが、データ分析ソフトウェアベンダーPalantirの「FDSE」（Forward Deployed Software Engineer）です。

　FDSEは少人数のチームで顧客の現場に入り、顧客と直接話しながら重要な問題を理解します。その上で、アーキテクチャの設計、データの処理や統合、顧客固有のアプリケーション開発などを手掛けます。課題の特定から解決策の設計、実装、本番導入までを一気通貫で担う役割です。

　Palantirには、FDSEと並んで「DS」（Deployment Strategist）という職種もあります。

　DSは顧客の業務やワークフローを理解し、解くべき問題と必要なデータを特定します。さらに、顧客と新しい業務の進め方を作り、導入や教育、定着まで進めます。現場で得た知見を自社の製品チームへ戻し、製品改善につなげることも役割の1つです。

　現在では、こうしたFDSEやDSに見られる要素を合わせ持ち、顧客の現場に入り、課題の抽出から解決策の提案、実装までを担い、そこで得た知見を自社へ持ち帰る人材をFDEと呼ぶ場合もあります。

　こうしたFDEの働き方には、大きく2つの特徴があります。1つ目は、現場の課題を解決することです。2つ目は、そこで得た知見を汎用（はんよう）化することです。

　情シスにとって重要なのは、この2つを別々の仕事として扱うのではなく、「現場の課題解決」と「全社への横展開」を一連の流れとしてつなぐことです。

情シスに必要なのは「個別解」を「全社の資産」に変える役割

　事業会社の情シスには、従来から大きく2つの仕事がありました。1つは、ネットワークやクラウド、認証、業務システムなど、全社共通のシステム基盤を設計、導入、運用する仕事です。もう1つは、特定部署の業務課題に対して、小規模なシステムやツールを作り、ITを使って問題を解決する仕事です。

　ただし、この2つは別々の担当者や組織によって進められることが少なくありません。例えば、全社共通のシステム基盤は情シスが担当し、現場の業務改善はDX（デジタルトランスフォーメーション）推進部門や事業部門が担う、といった形です。

　このように役割が分かれていると、ある部署で有効だった工夫や実装知見が、その部署だけに閉じてしまう場合があります。そこで情シスが参考にしたいのが、“FDE的な働き方”です。

　情シス自身が現場の課題解決に関わり、そこで得た知見を自部門へ持ち帰り、他部署でも利用できる仕組みに変えることで、個別の業務改善を全社の資産へと発展させることができます。

　FDEというと、SaaSベンダーやSIer、コンサルティング会社で顧客の現場に入り込む役割を思い浮かべるかもしれません。しかし、FDEの「現場で課題を見つけて解決し、そこで得た知見を組織へ持ち帰って再利用する」という考え方は、事業会社の情シスにも当てはめられます。本稿では、この働き方を「事業会社型FDE」と呼びます。

情シスが取り入れたい「事業会社型FDE」の働き方

　情シスがFDE的な働き方を取り入れる場合、まず担当部署に入り込み、現場の個別課題を解決します。その上で、そこで得た実装知見を情シス部内へ持ち帰り、他部門でも利用できる全社共通の仕組みへ変えていきます。

　例えば、情シスが総務部門と一緒に、定型作業を支援するAIアプリケーションを作ったとします。従来であれば、総務部門の課題を解決した時点で案件は完了するかもしれません。

　しかし、FDE的な働き方を取り入れるのであれば、情シスはそこで終わらせません。どのようなデータ連携が必要だったのか、どのような権限設計が必要だったのか、どの機能なら別部署でも再利用できるのかを整理します。

　その上で、営業部門や人事部門などでも利用できる共通のサービスや基盤へ広げます。つまり情シスに求められるのは、現場で生まれた「個別解」を、組織全体で使える「共通解」に変えることです。

FDE的な働き方を取り入れるために、情シス組織が変えるべきこと

　ただし、FDEという役割を新設したり、高いスキルを持つ人材を情シスに配置したりするだけでは、仕事の進め方は変わりません。FDE的な働き方を情シスに取り入れるのであれば、情シス自身が、事業部門との関わり方や案件の進め方を変える必要があります。

要件が固まる前から現場に関わる

　1つ目は、情シス担当者が事業部門の企画段階から関われるようにすることです。情シスの役割を、完成した要件を受け取り、その通りにシステムを導入することだけに限定してしまうと、FDE的な働き方は実現しにくくなります。

　現場の業務を見て、担当者と話しながら、「本当に解くべき問題は何か」を考えるところから情シスが関わる必要があります。そのためには、情シスがプロジェクトに参加するタイミングも変える必要があります。

　「システム化することが決まってから情シスを呼ぶ」のではなく、現場が「この業務に困っている」と感じた段階から、情シス担当者が関われる仕組みが求められます。

工程ではなく「課題単位」で仕事を担う

　2つ目は、情シスの仕事の受け方を変えることです。要件定義は企画部門、設計は情シス、開発は外部ベンダー、運用は別チームというように工程ごとに細かく分担していると、情シスが課題解決に一気通貫で関与することは難しくなります。

　もちろん、全ての作業を情シスが自ら実施する必要はありません。重要なのは、「この機能を開発してください」という単位ではなく、「この業務課題を解決する」という単位で情シスが関与することです。

　その上で、情シスが必要な関係者を巻き込み、どこまでを自部門で担い、どこを他部門や外部ベンダーに任せるのかを判断しながら、課題解決を進めます。

個別案件の完了だけで評価しない

　3つ目は、情シスの成果をどう評価するかです。FDE的な働き方では、ある部署の案件を完了させることだけがゴールではありません。

　その案件から得た知見を別の部署でも利用できる仕組みに変え、次の課題解決につなげることも重要です。

　そのため、「予定通りリリースできたか」「工数を何時間削減できたか」といった個別案件の成果だけではなく、「他部署にも展開できる仕組みにできたか」「共通基盤の改善につながったか」「次の案件を速く進めるための知見を残せたか」といった視点も必要です。

　情シスの成果を、個別案件の完了だけではなく、組織全体で再利用できる仕組みをどれだけ増やしたかという観点でも見る必要があります。

「FDE」という新しい職種を作る必要はない

　ここまで読むと、「情シスにFDEという新しいポジションを設け、人を採用した方がいいのではないか」と思う方もいるかもしれません。しかし、重要なのは肩書ではありません。

　重要なのは、既存の情シス組織の中でFDE的な働き方を実現することです。例えば、既存の情シス担当者が1つの案件でFDE的な役割を担うところから始めることができます。

　まずは、対象業務と利用者が明確で、小さく検証できる案件を1つ選びます。

　例えば、「総務部門の定型作業を支援するAIアプリケーションの開発」といった案件です。

　情シス担当者が総務部門に入り込み、業務上の課題を理解します。その上で、課題発見、要件整理、設計、開発、テスト、導入までを、生成AIを活用しながら1人または少人数のチームで横断して進めます。ここで重要なのは、アプリケーションを導入したところで終わらせないことです。

「課題解決→汎用化」のループを1つの案件で試す

　施策がうまくいったら、情シスはそこで得た知見を自部門へ持ち帰ります。総務部門向けに作ったアプリケーションであれば、「他部署でも必要になる共通機能は何か」「どこまでを全社基盤として提供できるのか」を検討します。そして、他の組織でも利用できるサービスやシステム基盤へ広げます。

　別の部署で利用すれば、新しい課題や要求が見つかります。そこで得た知見を、再び共通基盤へ反映します。つまり情シスは、次のようなサイクルを回します。

• 現場の課題を発見する
• 解決策を実装する
• 知見を情シスに持ち帰る
• 汎用化する
• 別の現場で利用する

　生成AIによって、情シス担当者1人が担える範囲は広がりつつあります。だからこそ、これまで別々の担当者や組織が担っていた「現場の課題発見」「実装」「全社への横展開」を、情シスがつなぎやすくなっています。

　ただし、こうした働き方を実現できるかどうかは、担当者個人の能力だけでは決まりません。以下を考慮する必要があります。

• 情シスが要件の固まる前から現場へ入れるか
• 工程ではなく課題単位で仕事を担えるか
• 個別案件の完了だけでなく、横展開まで成果として評価できるか

　重要なのは、FDEという人材を配置することではなく、情シスがFDE的に動ける組織を作ることです。

　まずは1つの小さな案件で、既存の情シス担当者が「課題解決と汎用化」のループを回してみる。それが、FDE的な働き方を情シス組織へ取り入れる第一歩です。