FDEの「作らない」提案｜不要な開発を見抜く
本記事でいうFDEは Forward Deployed Engineer（顧客の現場に入り込み、AIやソフトウェアを業務に合わせて実装・運用する技術者）を指します。ディスク暗号化のFull Disk Encryptionではありません。FDE 提案というと「顧客の課題を解決する物をどう作るか」に話が向かいがちですが、現場で成果を出すFDEほど「それ、本当に作る必要がありますか」と立ち止まります。この記事を読めば、顧客から出た開発要望に対して作る/作らないを切り分ける判断軸を持ち、既存ツールの活用・運用ルールの変更・見送りといった選択肢を含めて提案を組み立てられるようになります。一緒に考えていきましょう。
FDE 提案の出発点は「作らない選択肢」を持つこと
私たちがFDEの提案を考えるとき、最初に置く問いは「それは本当に必要ですか」です。顧客の要望をそのまま受けて開発に入るのは簡単ですが、作ったものは必ず保守・運用・引き継ぎのコストを生みます。要望を鵜呑みにせず、要否そのものを疑うところから提案は始まります。
要望の裏にある「本当にやりたいこと」を分ける
顧客が「〜を作ってほしい」と言うとき、それは手段であって目的ではないことがほとんどです。実際、最初に「それ、本当に必要ですか」と言われたのが衝撃だった、という声をいただくことがあります。言われた手段を実装する前に、その先の目的まで遡ると、作らずに済む道が見えることが少なくありません。課題の引き出し方そのものはFDEのヒアリング術｜顧客の本当の課題を引き出すで詳しく扱っています。
作った後のコストを提案の天秤に乗せる
多くの開発要望は、作る時点のコストだけで判断されがちです。しかしFDEが見るべきは、その後です。誰が保守するのか、担当者が辞めたら引き継げるのか、権限やログの管理は誰が回すのか。この運用側の負荷を天秤に乗せると、短期的には便利でも中長期では割に合わない開発が見えてきます。
作る/作らないを切り分ける4つの判断軸
要否を感覚で決めると説得力がありません。私たちは次の4つの軸を顧客と一緒に確認しながら、作らない選択肢も含めて提案を組み立てています。
判断軸 | 作らない方向に傾く状況 |
|---|---|
頻度・件数 | 月に数回しか発生しない。手作業のほうが安い |
既存ツールで代替可能か | 今あるSaaSやスプレッドシートの機能で足りる |
運用・引き継ぎの負荷 | 保守できる人が社内に残らない。属人化が濃い |
統制・監査の要求 | 権限やログ管理の体制が整わないまま走らせる危険 |
頻度が低いなら作らないほうが安い
小売業のクライアントの現場で、ある帳票の自動生成を作ってほしいという要望が出たことがあります。よく聞くと発生は月に2〜3回。手作業なら1回15分です。これを開発・保守すると、作るコストと維持コストが手作業の積み上げを何年も上回る計算でした。私たちは数字で示して見送りを提案し、代わりにテンプレートを整えるだけで終わりにしました。前川が大切にしている「数字で語る」という考え方は、こうした作らない判断でも効きます。
既存の仕組みで足りるなら新規開発を止める
士業事務所のケースでは、顧客管理システムを一から作りたいという相談を受けました。しかし業務を整理すると、必要な機能の大半は既に契約している会計ソフトとクラウドストレージの組み合わせでカバーできました。運用ルールを少し変え、フォルダ構成と命名規則を決めるだけで、開発ゼロで要望の8割が満たせたのです。内製か外部かの前に、そもそも作るかを問う。この順番が大事です。内製か外部かの判断軸はAI導入の内製化と外部活用の判断軸をご覧ください。
「作らない」を支えるのは統制と属人化の視点
市場に出回るFDEの解説の多くは「顧客の現場に入って物を作る」ところで止まっています。ですが私たちは、作った後に誰がどう統制し、どう引き継ぐかまで含めて要否を判断することが差別化の核心だと捉えています。
属人化する開発は作らないほうがいいこともある
製造業のクライアントの現場で、現場担当者が独自に作り込んだマクロが止まり、作った本人が異動していて誰も直せない、という場面に何度も出会ってきました。便利だからと作ったものが、引き継げないがゆえに負債化するのです。前川はシステムPMから運用保守まで上流下流を通して経験してきましたが、その経験から、引き継ぎと運用定着の負荷が高すぎる開発は、たとえ技術的に作れても見送るほうが顧客のためになると考えています。
統制コストを払えない開発は走らせない
AIエージェントを業務に組み込む相談では特に慎重になります。動かすこと自体は容易でも、権限の切り分け、操作ログの記録、不可逆なアクションへの承認といった統制を回す体制がなければ、作ること自体がリスクになります。体制が整うまでは一部を手運用のまま残す、という「作りきらない」判断も提案の一つです。この領域はAIエージェントの権限管理設計｜FDE実践術で掘り下げています。
作らない提案こそ中立の立場だから言える
自社開発を売りたい立場だと、作らない提案は収益を手放す話になります。だからこそ私たちは、誰に頼むにせよ必要な要否判断の観点を中立に示せると考えています。必要なスキルの全体像はFDEに必要なスキルの全体像｜8領域で解説で整理しています。
よくあるご質問
Q. 顧客が「どうしても作ってほしい」と言う場合、作らない提案は受け入れられますか。
目的とコストを数字で並べて示すと、受け入れられることが多いです。作る費用だけでなく保守・引き継ぎ・統制の負荷まで可視化すると、顧客自身が見送りや代替を選ぶ場面が少なくありません。頭ごなしに否定せず、一緒に天秤にかける姿勢が鍵です。
Q. 作らないと判断しても、代わりに何を提供すればよいですか。
既存ツールの組み合わせ、運用ルールやフォルダ構成の整備、テンプレートの用意など、開発を伴わない解決策が候補になります。要望の目的が満たせれば手段は問いません。整理した業務フローやルール自体が成果物になります。
Q. 作る/作らないの判断を社内で定着させるにはどうすればよいですか。
頻度・既存ツールでの代替可否・運用負荷・統制要求といった判断軸を共通の言葉にして、要望が出た段階で確認する習慣をつけることが有効です。法人向けの研修でも、こうした要否判断の進め方を扱っています。詳しくはお問い合わせください。
FDE活用のご相談はお気軽に
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。