ファジーな要件を構造化する5ステップ — Forward Deployed Engineering（FDE）の実践

「やりたいことはあるが、要件が書けない」。新規案件の最初に必ず聞く話です。RFPを書こうとすると業者比較ができず、現場に聞くと不満は集まるけれど打ち手にならない。私たちはこの状態を「ファジーな要件」と呼んで、入口から構造化することを請け負ってきました。5つのステップに整理します。

「要件定義の前」が大事な理由

RFPは要件が決まっていることを前提にした文書です。要件がまだ決まっていない段階でRFPを書こうとすると、書けないまま時間だけが過ぎます。本当に必要なのは「要件を決めるための作業」で、これを発注先の選定より先に終わらせる必要があります。

私たちはこの段階に入る働き方を Forward Deployed Engineering（FDE） と呼んでいます。Palantir 社が世に広めた概念で、エンジニアが顧客の現場に入り込み、要件を一緒に決めるところから関わる進め方です。「決まったものを作る人」ではなく、「決め方を一緒に作る人」が現場に必要だ、という発想です。

ステップ1：棚卸し

最初にやるのは現場の棚卸しです。動いているシステム、契約しているSaaS、関わっている人、いま走っている案件、進行中の取引。一覧にして紙1枚に並べると、ほぼ必ず「誰も全体像を知らなかった」ことが分かります。

棚卸しの目的は把握ではなく 合意形成 です。同じ一枚を見ながら関係者で会話すると、認識のズレがその場で見えます。要件を決める前提として、まずここを揃えます。

ステップ2：課題の言語化

現場の不満を集めて並べると、似た話が複数の人から出てきます。これをMECE（重複なく漏れなく）に分類して、課題として言語化します。

注意点があって、抽象度を上げすぎると打ち手につながりません。「業務効率が悪い」では何もできない。「請求書の手入力に月40時間かかっている」まで具体にすると、打ち手の候補が見えてきます。

ステップ3：選択肢の列挙

1つの課題に対して、最低でも3つの選択肢を並べます。最有力案だけを持っていくと、決裁者は「他に方法は？」と聞くしかなく、その場で意思決定できません。選択肢の不在は、決定の不在を生みます。

ステップ4：評価軸の合意

選択肢が並んだら、何で選ぶかを決めます。コスト、導入速度、既存システムへの影響、運用負荷、内製可能性。案件によって重視する軸は違うので、ここを先に合意します。

軸を後から足すと、結論がひっくり返ります。「やっぱりセキュリティも見たい」が後から入ると、すでに進んでいた検討が無駄になります。軸の追加は意思決定のやり直しと同じです。

ステップ5：推奨と却下理由

最後に、推す案と却下案の理由を併記したメモを作ります。「A案を推す。理由は◯◯。B案は△△の点で却下。C案は◇◇の点で次点」という形です。

推す案だけ書いた資料は、意思決定の場で使えません。「他の選択肢を検討したのか」が分からないと、決裁者は判断できないからです。却下理由まで書くと、意思決定の場が短くなります。

FDEという働き方

この5ステップは、要件定義書を書く前にやる仕事です。発注書を書く前にやる仕事、と言ってもいい。要件が決まっていない段階で発注先を選ぶと、決まった人と決まっていない要件を一緒に決めることになり、立場の非対称で迷走しがちです。

私たちはこの段階に パートナーとして 入ります。発注先候補ではなく、要件を一緒に決める伴走者として。決まったあとの実装フェーズに進むかどうかは、要件と一緒に決めます。