「要件を教えてください」と聞いても、返ってくるのが「それを一緒に考えてほしい」という案件がある。FDEとして現場に入っていると、こういう案件に遭遇する頻度は、想像以上に高い。
これは困った状況に聞こえるかもしれないが、実は違う。要件が固まっていない案件こそ、FDEが最も価値を発揮できる領域だと私は考えている。ここでは、そういう案件をどう進めているかを書く。
目次
「要件がない」のではなく「言語化されていない」
まず認識を変える必要がある。要件が固まっていないように見える案件でも、依頼する側の頭の中には、多くの場合、漠然とした困りごとが確かに存在している。ないのは要件そのものではなく、それを言語化する手段だ。
現場の担当者は、システムの要件定義に慣れていない。「今の業務のここが面倒」という感覚はあっても、それを「〇〇という機能が必要」という形に翻訳する作業は、普段やっていない仕事だ。この翻訳作業を依頼する側に丸投げすると、いつまでも要件は固まらない。翻訳を手伝うのがFDEの最初の仕事になる。
業務の実態を見に行く
言語化を手伝うために、私がまずやるのは、実際の業務を見に行くことだ。ヒアリングの場での説明と、実際の業務の様子は、しばしば食い違う。
説明では簡単そうに聞こえた作業が、実際に見ると想像以上に複雑な判断を含んでいたり、逆に大変そうに語られていた作業が、実は単純な繰り返し作業だったりする。この食い違いに気づけるかどうかが、後の要件定義の精度を大きく左右する。可能な限り、現場の作業を直接見る、あるいは録画してもらうなどして、実態を自分の目で確認するようにしている。
「困りごとの深さ」を見極める
業務の実態を見た上で、次にやるのは困りごとの深さを見極めることだ。同じ「面倒だ」という言葉でも、その裏にある深刻度は案件によって全く違う。
軽度な困りごとは、多少の手間を許容すれば現状維持でも回る。一方、深刻な困りごとは、業務の停止や重大なミスにつながりかねない。この見極めを誤ると、優先順位を間違えたシステムを作ってしまう。私は、困りごとが起きたときに実際に何が起きるか、誰がどう対処しているかを具体的に聞くことで、この深さを測るようにしている。
小さく検証しながら要件を育てる
ここまでの情報を集めたら、いきなり大きな要件定義書を作るのではなく、小さいスコープで検証を始める。これは以前書いた「ヒアリングからプロトタイプまでを最短で回す型」とも重なる考え方だ。
要件が固まっていない案件では特に、最初の検証スコープを絞り込むことが重要になる。困りごとの中で最も深刻な部分、あるいは最も検証しやすい部分を1つ選び、そこだけを対象にした小さな検証を回す。この検証を通じて要件の解像度を上げながら、少しずつスコープを広げていく。
「決めない」ことも選択肢に入れる
要件が固まっていない案件を進める中で、時には「今は決めない」という判断も必要になる。全ての要件を無理に確定させようとすると、根拠の薄い決定を積み重ねることになり、後で手戻りが大きくなる。
私は、検証を通じて確度が上がった部分から順に確定させ、まだ確度が低い部分は「仮の前提を置いた上で、後で見直す」という形で進めることを、依頼する側と最初に合意しておくようにしている。これによって、要件が固まっていない状態でもプロジェクトを前に進めながら、無理な決め打ちによるリスクを避けられる。
まとめ
要件が固まっていない案件は、要件がないのではなく言語化されていないだけだ。FDEとしての進め方は次の通りになる。
- 実際の業務を見に行き、説明と実態の食い違いを確認する
- 困りごとの深さを見極め、優先順位の根拠にする
- 小さいスコープで検証しながら要件を育てる
- 確度の低い部分は「今は決めない」という選択肢も持つ
要件定義書を先に完成させてから動くのではなく、動きながら要件の解像度を上げていく。この進め方ができるかどうかが、要件が固まっていない案件を任せられるかどうかの分かれ目になる。
