開発会社選びで失敗しないための「FDE型の開発パートナー」とは
開発会社を選ぶとき、最初の商談で「ここなら良さそう」と感じることがあります。営業担当の説明が分かりやすい。提案資料がきれい。過去の実績も豊富に見える。こちらの話にもよくうなずいてくれる。
ところが、契約して実際にプロジェクトが始まると、急に話が噛み合わなくなることがあります。
「あれ、商談で話していたことと違う」「この前入れた要望が、全然違う形で伝わっている」「営業担当には伝わっていたはずなのに、PMやエンジニアには業務の背景が届いていない」。こうした違和感が、要件定義や実装の段階で出てきます。
これは、開発会社選びでよく起きる失敗です。
原因は、営業担当の能力が低いからとは限りません。むしろ営業担当は優秀なことが多いです。課題を聞くのがうまく、説明も上手で、発注側が不安に思っていることをうまく言語化してくれます。
しかし、システムやアプリを実際に作るのは営業担当ではありません。契約前に相談している相手は営業担当で、契約後に要件定義や実装を進めるのはPM、ディレクター、エンジニア、デザイナーであることが多いです。
ここで乖離が生まれます。営業担当は話を聞くのが上手く、発注側の課題をうまく整理してくれます。しかし、実際に作る人がその場にいなければ、業務の背景や判断理由は後から伝えるしかありません。その過程で、商談時に共有した温度感が薄れてしまうことがあります。
だからこそ、開発会社を選ぶときは「営業が良いか」だけでは足りません。実際に要件定義し、設計し、実装する人が、どこまで業務理解に入ってくれるか を見る必要があります。
そこで知っておきたいのが、FDE型開発 です。
営業が良くても、開発がうまくいくとは限らない
開発会社の商談では、発注側が不安に感じていることを営業担当が整理してくれます。
「この業務を効率化したいんですね」 「既存システムとの連携が重要ですね」 「まずは小さく作って、段階的に広げるのがよさそうです」
こう言われると、発注側としては安心します。自社の課題を理解してもらえたように感じるからです。
しかし、商談で理解された内容が、そのまま開発現場に届くとは限りません。
よくあるのは、契約前は営業担当と話し、契約後にPMが入り、PMが要件定義を行い、さらにエンジニアへタスクとして渡される流れです。この流れ自体は珍しいものではありません。ただし、最初に話を聞いた人と、実際に作る人が違うほど、理解のズレは起きやすくなります。
営業担当との会話では「現場の困りごと」として共有されていた話が、PMには「必要な機能」として伝わる。PMが整理した「必要な機能」は、エンジニアには「実装タスク」として渡される。そうなると、最初にあった業務背景や判断理由が抜け落ちていきます。
たとえば、発注側が「案件管理画面がほしい」と言ったとします。営業担当との会話では、本当の課題は「営業担当ごとに入力の粒度が違い、次のアクションが見えないこと」だと共有されていたかもしれません。
しかし、開発フェーズに入ると、その文脈が「案件一覧画面を作る」「ステータスを表示する」「担当者で絞り込めるようにする」というタスクに変換されます。結果として、画面はできても、営業会議で使える情報になっていない、ということが起きます。
これが、契約前に話していた相手と、実際に要件定義・実装を担当する相手が分かれているときに起きる典型的なズレです。
要件定義でズレる理由
開発会社選びで失敗したと感じるタイミングの多くは、要件定義です。
商談では話が早かったのに、要件定義になると急に細かい確認が増える。こちらの業務を説明しても、表面的な機能の話に戻ってしまう。現場の例外処理を伝えると、「それは追加要件です」と言われる。
こうしたことが起きるのは、要件定義が単なる機能整理になっているからです。
本来、要件定義で重要なのは、「どんな機能を作るか」だけではありません。
- 誰が使うのか
- いつ使うのか
- どの業務の前後に入るのか
- 例外処理はどこで起きるのか
- どの判断は人が行うべきか
- どの情報を次の業務に渡すのか
- リリース後に誰が運用するのか
こうした業務の流れまで見ないと、使われるシステムにはなりません。
しかし、営業、PM、エンジニアが分かれている体制では、要件定義が「発注側から聞いた内容を仕様書に落とす作業」になりやすくなります。仕様書としては整っていても、現場の仕事の流れが反映されていなければ、実装後にズレが出ます。
つまり、開発会社選びで見るべきなのは、提案資料の完成度だけではありません。要件定義の段階で、実際に作る側がどれだけ業務に入り込めるかです。
FDE型開発とは何か
FDEとは、Forward Deployed Engineerの略です。直訳すると「前線に配置されたエンジニア」。顧客の現場や業務に入り込み、課題整理、設計、実装、運用定着まで関わるエンジニアを指します。
もともとはPalantirが広めた働き方として知られています。Palantirの公式ドキュメントでも、顧客の複雑な課題から得た学びを開発へ還元する方法論としてForward Deployed Engineeringが説明されています。
日本でFDE型開発と言う場合、必ずしも「FDEという職種名の人がいる」という意味ではありません。重要なのは、業務理解と実装を分断しない開発体制 です。
FDE型開発では、実際に作るエンジニアが、初期の課題整理や要件定義にも関わります。営業が聞いた話をPMが整理し、PMがエンジニアに渡すだけではありません。エンジニア自身が、現場の業務やユーザーの動きを理解しながら、何を作るべきかを考えます。
これにより、発注側との会話が「この機能を作るかどうか」だけではなく、「この業務をどう変えるか」「このアプリをどう使われる状態にするか」という議論に変わります。
FDE型開発が効く理由
FDE型開発が効く理由は、伝言ゲームを減らせることです。
従来型の開発では、営業、PM、エンジニアの間で情報が流れていきます。もちろん、うまく連携できている会社もあります。ただ、関係者が増えるほど、業務理解の濃度は薄くなりやすいです。
FDE型では、実装する側が早い段階から業務理解に入ります。だから、発注側の言葉をそのまま機能に変換するのではなく、背景を理解したうえで設計できます。
たとえば、発注側が「承認機能がほしい」と言ったとします。従来型では、そのまま承認ボタンや承認ステータスを作る話になりがちです。
しかしFDE型では、「なぜ承認が必要なのか」「誰が何を確認しているのか」「承認が遅れる原因は何か」「承認をなくせる条件はないか」まで見ます。すると、単純な承認機能ではなく、入力時のチェック、金額条件による自動承認、例外時だけの通知など、別の設計が見えてくることがあります。
これは、現場の言葉をそのまま作るのではなく、現場の課題を理解して作るという違いです。
システム開発でもアプリ開発でも、成果を分けるのはここです。表面上の機能を作るだけなら、多くの会社ができます。しかし、実際に使われる形まで落とし込むには、業務やユーザーの理解が必要です。
開発会社選びで確認したいこと
開発会社を選ぶとき、実績や費用を見るのは当然です。ただ、それだけでは契約後のズレを防げません。
商談の段階で、次のような点を確認すると、FDE型に近い進め方ができる会社かどうかが見えやすくなります。
実際に作るエンジニアと話せるか
まず確認したいのは、商談や契約前の段階で、実際に設計・実装を担当するエンジニアと直接話せるかです。
発注側が感じている課題や業務の細かい事情は、営業担当を通して伝えるより、作る人に直接話した方が早く、ズレも少なくなります。技術的にできること、業務上やるべきこと、後から手戻りになりそうな点も、その場で見えやすくなります。
営業だけで判断しない
営業担当の説明がうまいことと、開発がうまく進むことは別です。営業担当は課題を聞くのが仕事ですが、実際に要件を整理し、設計し、実装するのは別の人であることが多いからです。
だからこそ、契約前に「実際に作る人と話せるか」「その人が業務理解に入ってくれるか」を見ておくことが重要です。ここを確認せずに営業の印象だけで決めると、契約後に「あれ、話していた内容と違う」という状態になりやすくなります。
小さく作って確認できるか
最初から大きく作ると、ズレに気づくのが遅くなります。
FDE型に近い会社は、早い段階で動くものを出し、現場やユーザーの反応を見ながら調整する進め方を取ります。
要件定義を長く続けるより、重要な業務や画面から小さく作り、使ってみて直す方が、結果的に手戻りが少なくなることがあります。
運用まで見ているか
システムやアプリは、リリースして終わりではありません。誰がデータを更新するのか、問い合わせが来たら誰が見るのか、権限変更や例外対応をどうするのか。運用まで考えないと、現場に定着しません。
開発会社を選ぶときは、リリース後の運用や改善まで話せる相手かどうかも重要です。
FDE型の開発パートナーと組むメリット
FDE型の開発パートナーと組むメリットは、発注側が最初から完璧な仕様書を用意しなくても、前に進められることです。
もちろん、何も考えずに丸投げできるという意味ではありません。ただ、発注側だけで業務を整理し、要件を固め、仕様書に落とし込む必要はありません。
- 「何を作ればいいか分からない」
- 「現場ごとにやり方が違う」
- 「アプリを作りたいが、運用まで見えていない」
- 「AIを使いたいが、どの業務から始めるべきか分からない」
こうした段階から、業務やユーザーの流れを一緒に整理し、小さく作りながら形にしていけるのがFDE型の強みです。
開発会社選びで失敗しないためには、営業が上手いかどうかだけで判断しないことです。実際に作る人が、どこまで業務やユーザー理解に入ってくれるか。営業、要件定義、設計、実装、運用が分断されない体制になっているか。
この観点で見ると、開発会社の選び方は大きく変わります。
Arintiが考える開発者選び
開発会社を選ぶときに大切なのは、きれいな提案資料や営業トークだけではありません。実際に作る人が、事業や業務の文脈を理解したうえで設計・実装できるかです。
Arintiは、IT事業会社でプロダクト開発や事業推進を経験してきたエンジニアで構成された、DX・開発支援会社です。商談の段階から実際に開発するエンジニアが入り、課題の整理、業務理解、技術選定、開発までを一貫して担当します。
システムを開発して納品するだけでなく、事業成果の達成まで見据え、事業視点でDX・開発支援 を行っています。実際に開発を行うエンジニア自身が、初期の相談段階から関わることで、商談で聞いた内容と実装が分断されにくい体制を重視しています。業務DX、システム開発、アプリ開発、データ基盤構築、AI活用、プロダクト開発まで、事業に必要な仕組みを一気通貫で支援します。
営業時の印象だけで開発会社を選ぶのではなく、実際に作る人とどこまで話せるか、業務理解と実装が分断されないかを確認したい場合は、FDE型の開発パートナーと組む進め方が有効です。システム・アプリ開発やDXに関するご相談は、お問い合わせフォームからご連絡ください。
▼会社HPはこちら
よくある質問
Q. 開発会社選びでよくある失敗は何ですか?
契約前に話す営業担当は感じが良く、課題も理解してくれたように見えたのに、実際に要件定義や実装を担当するPM・エンジニアとは理解に乖離が出ることです。
その結果、「商談では伝えたはずなのに」「入れたかった内容と違う」という状態になり、要件定義や実装の段階で現場とのズレが起きます。
Q. FDE型開発とは何ですか?
Forward Deployed Engineerの考え方を取り入れ、顧客の業務理解、課題整理、設計、実装、運用定着までを分断せずに進める開発の進め方です。
日本語の記事では、FDEという職種そのものだけでなく、業務理解と実装を切り離さない開発体制を指して「FDE型開発」と呼ぶことがあります。
Q. なぜFDE型だと失敗しにくいのですか?
営業、要件定義、設計、実装が分断されにくく、実際に作るエンジニアが業務理解に関わるためです。
発注側の言葉をそのまま機能に変換するのではなく、背景にある業務課題を理解して設計できるため、伝言ゲームによるズレを減らしやすくなります。
Q. 開発会社を選ぶときは何を見ればよいですか?
営業資料の見栄えだけでなく、商談や契約前の段階で、実際に設計・実装を担当するエンジニアと直接話せるかを確認することが重要です。
最初から作る人に話した方が、技術的にできること、業務上やるべきこと、後からズレそうな点が早く見えます。エンジニアが初期から業務理解に入る体制かどうかも確認したいポイントです。