要件定義をやりきったのに、出来上がったシステムが使われない。受託開発をやっていると、この光景を何度も見る。原因は「要件定義が甘かったから」だけではない。要件定義を「一度決めたら守るべき約束」として扱ってしまったことにも原因がある、というのが私の見方だ。
この記事では、要件定義に必要な三つの姿勢——現場理解、あるべき姿の提示、そして PoC による最適値の探索——を、開発を受ける側の実務から整理する。
要点
- 要件定義は現場の業務理解が前提だが、現場の言うとおりに作るだけでは「今の非効率をそのままシステム化した物」ができる。
- 「あるべき姿」を提示し、強い意思で推進する役割を、要件定義の担当者が引き受ける必要がある。
- 一方で、定義した要件を全部実現しなければならない、という考えは捨てるべきである。
- PoC で動かしながら変更を重ね、最適値を見つけていくほうが、結果として当たる確率が高い。
- 品質とスピードはフェーズで使い分ける。PoC はスピード、本番は品質。
現場に深い理解を持つ、が「現場の言いなり」ではない
要件定義の出発点は現場理解にある。ここは譲れない。業務の順序、例外処理、誰がいつ何を入力しているのか。ここを知らずに書いた要件は、必ず運用フェーズで破綻する。
ただ、現場ヒアリングをそのまま要件に落とすと、たいてい今の業務フローを丸ごとシステムに写経したものが出来上がる。現場の人は「今のやり方を楽にしてほしい」と話すが、今のやり方自体が最適とは限らない。Excel と紙とメールで回している運用を、そのまま画面に置き換えても、投資に見合うリターンは出ない。
だから、現場に寄り添うことと、現場の要望をそのまま要件にすることは、はっきり分けて考える必要がある。関連する構造は「使われないシステム」が生まれる構造でも書いた。
「あるべき姿」を出し、意思をもって推進する
現場理解の上に必要なのが、「本来こうあるべきだ」という設計者側の意思である。
- 今の業務のうち、システム化せずにやめるべき作業はどれか
- 業務の順番自体を変えることで消える手作業はないか
- 例外運用を許すのか、業務側を標準に寄せるのか
これらは現場からは出てこない。外から業務を見て、複数の会社の現場を見てきた側が提示するしかない。そして提示するだけでは動かないので、意思をもって推進する必要がある。ここが要件定義の担当者にとって一番難しいところで、技術力よりも交渉と胆力の仕事になる。役割分担の整理は要件定義は誰がやる？を参照してほしい。
定義した要件を「全部実現する」必要はない
ここが今回いちばん言いたいところだ。
要件定義書を作ると、その瞬間に文書が権威を持つ。「決めたことなので実装します」「合意した内容なので変更できません」という会話が始まる。しかし要件定義の時点で分かっていることは、プロジェクト全体で分かることのうちのごく一部でしかない。最も情報が少ない時点で決めた内容を、最後まで守り抜くことを目標にするのは、意思決定として合理的ではない。
要件定義の成果物は「守るべき契約」ではなく、その時点での最良の仮説だと捉えたほうがいい。仮説なので、検証して外れていれば捨てる。捨てられる前提で作るからこそ、早く作れる。
もちろん、契約や予算の観点で範囲を固定せざるを得ない場面はある。だからこそ「どこを固定し、どこを可変にするか」を要件定義の段階で合意しておく。全部固定でも全部可変でもない設計にする。費用面の考え方は要件定義の費用相場にまとめている。
PoC で動かしながら最適値を見つける
仮説を検証する手段が PoC である。紙の上のレビューを何周しても分からないことが、動くものを一度触ってもらうと 5 分で分かる。
私たちが実務で意識しているのは、次のような使い分けだ。
- PoC フェーズはスピードを優先する。 テストコードも運用設計も最低限でよい。目的は「この方向で合っているか」の判定であって、資産を作ることではない。
- PoC の出力は動くコードではなく、判断である。 「この画面構成では現場が入力しない」「この自動化は精度が足りない」という判断が得られれば、そのコードは捨ててよい。
- 本番実装フェーズに入ったら品質側に振り切る。 PoC のコードをそのまま本番に昇格させない。ここを混ぜると後で必ず返済させられる。
AI エージェントを業務に組み込む案件では、この進め方の効果がさらに大きい。精度も運用負荷も、実データで動かすまで分からないからだ。要件定義書の中で「精度 95% 以上」と書いても、その数字には根拠がない。まず動かして、実際の値を見てから合意し直すほうが速い。
開発を受ける側にとって、これは何を意味するか
この進め方は、開発会社の商売の形にも影響する。
- 見積もりの単位が変わる。 「要件定義一式いくら」ではなく、「検証をこの範囲でこの期間」という売り方になる。
- 顧客との関係が長くなる。 一度作って納めて終わりではなく、変更を前提にした継続的な関わりになる。継続案件のほうが単価も安定する。
- 人材要件が変わる。 言われたとおりに作れる人ではなく、業務を見て「やめましょう」と言える人が必要になる。育成の設計もそちらに寄せる必要がある。
要件定義を「決めて守るもの」として運用している限り、この転換はできない。逆に言えば、ここを変えられる会社は、同じ人数でも顧客の事業成果に踏み込める。私はそこに勝ち筋があると考えている。
まとめ
要件定義に必要なのは、現場への深い理解と、あるべき姿を出す意思と、そして決めたことを捨てられる柔軟さの三つである。三つ目が抜けると、要件定義は儀式になり、使われないシステムが生まれる。
PoC で動かし、変更しながら最適値に近づける。そのプロセス全体を要件定義と呼ぶべきだ、というのが私の考えだ。
