FDEがはまる失敗パターン7選：現場で起きがちなつまずきと回避策

FDEの現場で起きる失敗の9割は、コードの品質ではなくコミュニケーションと期待値管理の問題から生まれます。

「6週間かけて作り上げたダッシュボードを、誰も開かなくなった」という話は珍しくありません。原因を掘り下げると、技術的な選択ミスではなく、最初の合意形成や引き渡しのやり方に問題があったケースがほとんどです。

この記事では、FDEが陥りやすい7つの失敗パターンを取り上げ、それぞれがなぜ起きるのか、どうすれば防げるのかを具体的に説明します。FDEとは何かを把握した上で読むと、各パターンのリアリティがより伝わるはずです。

---

結論：失敗を防ぐ鍵は「作る前」にある

7つの失敗パターンに通底しているのは、「動くものを早く見せようとするあまり、合意形成と期待値の整合を後回しにする」という判断です。

現場での失敗は以下のどれかに帰着します。

• 要件の不一致（何を作るかがずれていた）
• 使われない設計（誰がどう使うかを考えていなかった）
• 関係者の分断（誰が何を期待しているかを把握していなかった）

それぞれに対応する打ち手は決まっています。以降で一つずつ見ていきます。

---

失敗1：要件が曖昧なまま実装を始める

よくある場面

「現場の声を聞いて、まず動くものを作ってみましょう」という合意でキックオフした。ヒアリングは30分のオンラインミーティングだけ。翌週には最初のプロトタイプを出した。

3週目に「思っていたのと違う」と言われる。何が違うかを確認すると、ユーザーが想定していた業務フローと、FDEが作ったものでは前提が根本的にずれていた。

なぜ起きるか

FDEには「早くデモを出して議論を前に進める」という本能があります。これ自体は正しいのですが、ヒアリングが浅いまま実装に入ると、修正コストが膨らみます。「とりあえず作って修正」が成立するのは、修正サイクルの中でも要件が収束していく場合だけです。

回避策

初週に必ず現場で業務フローを観察する時間を取ってください。画面共有や実際の操作を見るだけで、ヒアリングでは出てこない「当たり前の前提」が見えてきます。

また、最初のデモを出す前に、スコープを一枚の文書にまとめてクライアント担当者の確認を取る習慣をつけることが重要です。「作って見せてから修正」ではなく、「認識を合わせてから作る」という順番に変えるだけで、後半の手戻りが大幅に減ります。

---

失敗2：完成形を見せようとして最初のデモが遅れる

よくある場面

「中途半端なものは見せたくない」という判断で、デモの準備に2週間かけた。ようやく出したデモで「そもそもこの方向性でよかったでしたっけ」という話になり、ゼロから作り直す羽目になった。

なぜ起きるか

FDEには技術者としての誠実さがあり、不完全なものを出すことに抵抗を感じる人が多いです。しかしクライアント側は「完成品」より「方向確認できるもの」を早く見たがっています。2週間後の完璧なデモより、3日後の粗削りなプロトタイプのほうが、方向修正に使えます。

回避策

「デモの目的は完成度の確認ではなく、方向確認だ」と最初に合意してください。プロジェクト開始時に「最初のデモはX日以内に出す。UIは仮で構わない」というルールを設定しておくと、心理的な障壁が下がります。

モックアップや固定データを使ったデモでも、「この方向でよいか」「このデータ項目は合っているか」という確認は十分できます。動くものを早く出すほど、修正コストは小さくなります。

---

失敗3：クライアント担当者の交代でコンテキストが失われる

よくある場面

3ヶ月間、現場担当者のAさんと毎週会議を重ねて要件を積み上げてきた。プロジェクト4週目にAさんが異動し、後任のBさんが担当になった。Bさんはこれまでの経緯を知らず、「このシステムは何のために作っているんですか」という質問から会議が始まった。

なぜ起きるか

コンテキストが「FDEとクライアント担当者の二者間の記憶」に依存していると、担当者が変わった瞬間に積み上げが消えます。企業側の組織変更や人事異動は、プロジェクト期間中に普通に起きます。

回避策

週次の議事録を残すだけでなく、「このプロジェクトの目的・スコープ・今週時点での状況」を一枚にまとめたリビングドキュメントを常に更新してください。このドキュメントは担当者が誰になっても、30分で現在地を把握できる内容にしておきます。

FDEが口頭で説明できることと、文書で引き継げることは別物です。特に意思決定の経緯、却下した選択肢とその理由は、後から見たときに最も価値がある情報です。

---

失敗4：技術的負債を積みながらスピードを優先しすぎる

よくある場面

「とにかく早く動かすことが最優先」という方針でスプリントを重ねた。4週目に入ると、新しい機能を追加するたびに既存の動作が壊れるようになり、修正に追われる時間がどんどん増えた。

なぜ起きるか

FDEは短いサイクルで価値を届けることを得意としますが、「スピード最優先」が続くと設計の一貫性が崩れていきます。特にAIを使ったシステムは、プロンプトのバージョン管理やデータのパイプラインが複雑になりやすく、後から整理するコストが高くなります。

回避策

「このスプリントは動かすことを優先する」という判断をするたびに、翌スプリントで何を整理するかを明示的にスコープに入れてください。負債は借りた瞬間に返済計画を立てておくことが重要です。

また、ログの設計とエラーハンドリングは最初から作り込んでおく価値があります。後から追加しようとすると、コードの至るところを触ることになります。AI導入失敗パターンでも取り上げていますが、システムの問題が「なぜ起きているか」を即座に追えない設計は、後半のデバッグコストを数倍に押し上げます。

---

失敗5：作ったシステムを引き渡した後に誰も使わない

よくある場面

8週間かけて開発したシステムを引き渡し、クライアントに「ありがとうございました」と言われてプロジェクトを終えた。1ヶ月後に状況を聞くと、「実はほとんど使われていない」と判明した。

なぜ起きるか

このパターンが最も多い失敗です。「動くシステムを作ること」と「そのシステムが業務に組み込まれること」は全く別の課題です。現場の担当者がシステムの使い方を知らない、業務フローへの組み込み方が決まっていない、効果測定の基準がないという状態で引き渡すと、使われないまま終わります。

回避策

引き渡しのタイミングより前に、以下の3点を準備してください。

• 現場担当者が一人で操作できるまでのハンズオン時間
• 「このシステムを使って何をするか」という業務フローへの組み込みルール
• 2週間後・1ヶ月後に効果を確認するKPIと担当者

特にハンズオンは省略されがちですが、「使えた体験」を一度作ることが継続利用に直結します。FDE成功事例では、引き渡し後も月1回のフォローアップを設定したことで定着率が上がったケースが紹介されています。

---

失敗6：ステークホルダーの期待値がばらばらで後から揉める

よくある場面

現場担当者は「日常業務の効率化」を期待していた。中間管理職は「データ分析のレポート機能」を求めていた。役員は「コスト削減の数字」を求めていた。FDEはどれを優先するか曖昧なまま実装を進め、3ヶ月目のレビューで三者から異なる方向のフィードバックが来た。

なぜ起きるか

大きな組織でのプロジェクトでは、立場によってゴールが異なります。これは自然なことですが、最初に整合を取らないと、プロジェクト後半で「期待と違う」という評価が重なります。FDEが現場担当者との関係構築に集中する一方で、意思決定権を持つ上位ステークホルダーへの情報共有が疎かになるケースも多いです。

回避策

プロジェクト開始時に、ステークホルダーマップを作ることを習慣にしてください。「誰がこのプロジェクトの成功を判断するか」「その人は何をもって成功と判断するか」を書き出し、担当窓口と合意を取っておきます。

週次レポートを現場担当者だけでなく、中間管理職にも共有する形式にしておくと、後半での認識ずれを防げます。FDEのコミュニケーションスキルでも述べているように、ステークホルダーごとに情報の粒度と焦点を変えることが重要です。

---

失敗7：FDE自身がバーンアウトする

よくある場面

「クライアントの期待に応えたい」という気持ちから、週末や深夜にも対応を続けた。3ヶ月目に入ると、判断の質が落ち始め、小さなミスが増えた。プロジェクト終了後、燃え尽きてしまい次の案件に入れない状態になった。

なぜ起きるか

FDEは現場に深く入り込む仕事です。クライアントの課題を自分ごとに感じる人ほど、境界線を引くのが難しくなります。また、複数のプロジェクトを掛け持ちする場合、それぞれで「最優先対応」が発生すると、物理的に無理が生じます。

回避策

プロジェクト開始時に「対応時間の境界線」を明示的に設定してください。「平日の何時から何時が対応可能か」「週末の緊急対応は原則なし」という前提を最初に伝えておくことで、クライアント側も無理な要求をしにくくなります。

スプリントの設計も重要です。毎週金曜日に「来週完了できないタスクを今週の月曜日に可視化する」という習慣を作るだけで、週末の無理な追い込みが大きく減ります。自分の状態を管理することも、FDEとしての専門性の一部です。

---

失敗を防ぐFDEの実践チェックリスト

7つのパターンをまとめると、以下のチェックリストになります。プロジェクト開始時と各スプリントの振り返りで確認してください。

プロジェクト開始時

チェック項目	目的
現場で業務フローを観察する時間を取ったか	要件の前提を正確に把握する
スコープを一枚の文書にまとめて合意を取ったか	後半の手戻りを防ぐ
ステークホルダーマップを作ったか	期待値のずれを早期に発見する
最初のデモを何日以内に出すか決めたか	方向修正のコストを下げる
対応可能な時間帯を伝えたか	バーンアウトを防ぐ

毎週のスプリント中

チェック項目	目的
今週完了できないタスクを月曜日に可視化したか	週末の追い込みを防ぐ
リビングドキュメントを更新したか	担当者交代に備える
今週積んだ技術的負債と返済計画を記録したか	後半の設計崩壊を防ぐ

引き渡し前

チェック項目	目的
現場担当者がシステムを一人で使えるか確認したか	定着率を上げる
業務フローへの組み込みルールを決めたか	使われない結末を防ぐ
1ヶ月後のKPIと担当者を設定したか	効果測定と継続利用につなげる

---

FDEとして現場に入り込む以上、技術とコミュニケーションの両方を同時にこなすことが求められます。7つのパターンはどれも「経験した人が後から気づく」ものですが、事前に知っておくことで回避できます。

次のプロジェクトで「作ったものを誰も使わない」という結末を防ぐために、特に失敗5と失敗1の対策から始めてみてください。