信頼構築とは: 技術力を発揮する「前提条件」を作る仕事
現場常駐での信頼構築は、しばしば「ソフトスキル」「あれば望ましいもの」として扱われます。しかしFDEの実務では、これは技術力を発揮するための前提条件です。理由は単純で、システム設計に必要な情報の多くは、信頼された相手にしか開示されないからです。
信頼がない状態のプロジェクトで起きることは、おおむね決まっています。
- 実際のデータが得られない — 整えられた「見せてよいデータ」だけが渡され、実運用の汚れたデータ・例外だらけの実態は隠れたままになる
- 率直な意見が得られない — 「実はこの手順、マニュアルと違うやり方で回している」「この項目は誰も入力していない」といった、設計を左右する事実がヒアリングに現れない
- 使われない — 完成したシステムが「あの外部の人が作ったもの」のまま、現場の業務に組み込まれずに放置される
要件定義の質も（要件の言語化スキル）、検証の質も（PoC設計スキル）、その上流にある「現場がどこまで本当のことを話してくれるか」に依存しています。信頼構築とは、こうした情報を得られる関係をつくる仕事です。
FDEの現場でどう使うか: 最初の2週間と3つの原則
最初の2週間が立場を決める
常駐が始まって最初の2週間は、現場がFDEを見極める期間です。この期間に「自分たちの仕事を理解しようとしている人」と認識されるか、「上から評価しに来た人」と認識されるかで、その後に得られる情報の質が大きく変わります。この期間の振る舞いとして、実務では次の3つの原則が機能します。
原則1: 現場の業務を先に手伝う
提案より先に、理解と貢献を差し出します。現場の作業を隣で見せてもらう、可能なら単純作業を一緒にやってみる、繁忙時のボトルネックを一つ引き受ける、といった行動です。「まず自分たちの仕事を分かろうとした」という事実は、どんな自己紹介より強く働きます。副産物として、マニュアルには載っていない例外処理や暗黙のルール（システム設計で最も重要な情報）も、この過程で自然に把握できます。
原則2: 専門用語で武装しない
RAG、ファインチューニング、エージェントといった専門用語は、使う側にとっては正確さでも、聞く側にとっては壁になります。専門用語で話すことは、無意識のうちに「分かる人／分からない人」の線を引く行為です。現場の業務用語を先に覚え、相手の言葉で説明します。「AIが文書を検索して答えます」で足りる場面で「RAGアーキテクチャを採用します」とは言いません。専門知識を前面に出さないことは、謙遜ではなく、情報を引き出すうえで実際に有効な方法です。
原則3: 小さな約束を必ず守る
「明日までに議事録を送ります」「次回までにこの点を調べておきます」といった小さな約束を守れるかどうかが、信頼の基盤です。大きな成果を出す前の段階では、現場は小さな約束の守り方でFDEを評価しています。同時に、守れない約束はその場でしないことも同じくらい重要です。「それは次回までに確認します、ただし◯◯の部分は間に合わないかもしれません」と率直に伝えられる人が、長期的には信頼されます。
変化への抵抗は「合理的な反応」として扱う
AI導入の現場では、業務が変わることへの警戒や抵抗にほぼ必ず出会います。この段階で現場を「抵抗勢力」と見なすと、信頼関係を築くことはできません。自分の業務や評価が変わるかもしれない状況で慎重になるのは合理的な反応であり、抵抗の背後には多くの場合、正当な懸念（例外ケースは問題ないか、品質の責任は誰が持つのか、自分の役割はどうなるのか）があります。FDEの仕事は抵抗を押し切ることではなく、懸念を具体的に聞き出し、設計と運用ルールに反映することです。抵抗の中身は、しばしばそのまま要件です。
今どうやって身につけるか: 現職でできる「越境」の訓練
1. 他部署のプロジェクトに越境する
信頼構築の訓練に、転職を待つ必要はありません。現職で自分の所属部署の外のプロジェクトに関わる機会（営業部門の業務改善、経理のツール導入、他部署との合同プロジェクトなど）を意識的に求めることです。自部署では通じる前提が通じない環境で、相手の業務を理解し、相手の言葉で話し、小さな約束を守って信頼を積み重ねます。これはFDEが顧客先で毎回行うことの縮小版であり、社内でも「よそ者」から始める経験は十分に積めます。
2. 非エンジニアへの説明機会を増やす
技術を知らない相手への説明は、回数がものを言う技能です。社内勉強会で非エンジニア向けに話す、経営層向けの報告資料を書く、家族に自分の仕事を説明してみる、といった方法で「相手が持っている知識だけで理解できる説明」を組み立てる練習を意図的に増やしてください。説明した後に「どこが分かりにくかったか」を聞いて改善するところまでやると、効果が大きく上がります。説明を数字と金額で組み立てる技術はROI説明・経営層報告のスキルで扱っています。
これらの経験は、FDEの選考でそのまま語れる実績になります（面接対策）。学習全体の順序は未経験からのロードマップ、FDEに必要なスキルの全体像はFDEになるにはを参照してください。
FDE Outlook: AI導入の成否を分けるのは「人間側」になっていく
今見えていること: 生成AI導入プロジェクトの失敗要因として、モデルの性能不足そのものよりも、組織側の要因（現場の巻き込み不足、業務プロセスとの不整合、変化への抵抗、推進体制の欠如）を挙げる調査や実務報告が、この数年一貫して目立ちます。技術が「動くかどうか」の問題は急速に解決されつつあり、残っているのは「組織に根づくかどうか」の問題だ、という傾向です。国内でFDE組織を運営するSansanが、顧客の現場を訪問して業務プロセスの整理から入る働き方を公式に発信していることも、この認識の表れと読めます。
今後の見立て: モデルの性能とコーディングの生産性はAIの進化とともに底上げされ続けます。一方で、現場に入り込み、警戒を解き、実際の業務と率直な意見を引き出し、変化を定着させるという人間側のスキルは、当面AIには代替されにくい領域です。技術がコモディティ化するほど、差がつくのは信頼構築のような対人の実行力になります。FDEという職種の価値の少なくない部分が、今後この領域に移っていくと当サイトは見ています。スキル全体のマップはFDEスキル一覧を参照してください。
出典
- Sansan Tech Blog「技術と事業をつなぐ。Sansan AIエージェントに向き合うFDEの挑戦」（2026年7月）顧客訪問から業務プロセス整理に入る働き方の詳細はSansanのFDE解説を参照