要件定義をやりきったのに、出来上がったシステムが使われない。受託開発をやっていると、この光景を何度も見る。原因は「要件定義が甘かったから」だけではない。要件定義を「一度決めたら守るべき約束」として扱ってしまったことにも原因がある、というのが私の見方だ。
この記事では、要件定義に必要な三つの姿勢——現場理解、あるべき姿の提示、そして PoC による最適値の探索——を、開発を受ける側の実務から整理する。
要点
- 要件定義は現場の業務理解が前提だが、現場の言うとおりに作るだけでは「今の非効率をそのままシステム化した物」ができる。
- 「あるべき姿」を提示し、強い意思で推進する役割を、要件定義の担当者が引き受ける必要がある。
- 一方で、定義した要件を全部実現しなければならない、という考えは捨てるべきである。
- PoC で動かしながら変更を重ね、最適値を見つけていくほうが、結果として当たる確率が高い。
- 品質とスピードはフェーズで使い分ける。PoC はスピード、本番は品質。
現場に深い理解を持つ、が「現場の言いなり」ではない
要件定義の出発点は現場理解にある。ここは譲れない。業務の順序、例外処理、誰がいつ何を入力しているのか。ここを知らずに書いた要件は、必ず運用フェーズで破綻する。
ただ、現場ヒアリングをそのまま要件に落とすと、たいてい今の業務フローを丸ごとシステムに写経したものが出来上がる。現場の人は「今のやり方を楽にしてほしい」と話すが、今のやり方自体が最適とは限らない。Excel と紙とメールで回している運用を、そのまま画面に置き換えても、投資に見合うリターンは出ない。
だから、現場に寄り添うことと、現場の要望をそのまま要件にすることは、はっきり分けて考える必要がある。関連する構造は「使われないシステム」が生まれる構造でも書いた。
「あるべき姿」を出し、意思をもって推進する
現場理解の上に必要なのが、「本来こうあるべきだ」という設計者側の意思である。
- 今の業務のうち、システム化せずにやめるべき作業はどれか
- 業務の順番自体を変えることで消える手作業はないか
- 例外運用を許すのか、業務側を標準に寄せるのか
これらは現場からは出てこない。外から業務を見て、複数の会社の現場を見てきた側が提示するしかない。そして提示するだけでは動かないので、意思をもって推進する必要がある。ここが要件定義の担当者にとって一番難しいところで、技術力よりも交渉と胆力の仕事になる。役割分担の整理は要件定義は誰がやる？を参照してほしい。
定義した要件を「全部実現する」必要はない
ここが今回いちばん言いたいところだ。
要件定義書を作ると、その瞬間に文書が権威を持つ。「決めたことなので実装します」「合意した内容なので変更できません」という会話が始まる。しかし要件定義の時点で分かっていることは、プロジェクト全体で分かることのうちのごく一部でしかない。最も情報が少ない時点で決めた内容を、最後まで守り抜くことを目標にするのは、意思決定として合理的ではない。
要件定義の成果物は「守るべき契約」ではなく、その時点での最良の仮説だと捉えたほうがいい。仮説なので、検証して外れていれば捨てる。捨てられる前提で作るからこそ、早く作れる。
もちろん、契約や予算の観点で範囲を固定せざるを得ない場面はある。だからこそ「どこを固定し、どこを可変にするか」を要件定義の段階で合意しておく。全部固定でも全部可変でもない設計にする。費用面の考え方は要件定義の費用相場にまとめている。
PoC で動かしながら最適値を見つける
仮説を検証する手段が PoC である。紙の上のレビューを何周しても分からないことが、動くものを一度触ってもらうと 5 分で分かる。
私たちが実務で意識しているのは、次のような使い分けだ。
- PoC フェーズはスピードを優先する。 テストコードも運用設計も最低限でよい。目的は「この方向で合っているか」の判定であって、資産を作ることではない。
- PoC の出力は動くコードではなく、判断である。 「この画面構成では現場が入力しない」「この自動化は精度が足りない」という判断が得られれば、そのコードは捨ててよい。
- 本番実装フェーズに入ったら品質側に振り切る。 PoC のコードをそのまま本番に昇格させない。ここを混ぜると後で必ず返済させられる。
AI エージェントを業務に組み込む案件では、この進め方の効果がさらに大きい。精度も運用負荷も、実データで動かすまで分からないからだ。要件定義書の中で「精度 95% 以上」と書いても、その数字には根拠がない。まず動かして、実際の値を見てから合意し直すほうが速い。
PoC をいつ打ち切るか——先に決めておく3つの基準
PoC でいちばん多い失敗は、失敗しないことではなく 終わらないこと である。「もう少し精度を上げれば」「あと1機能だけ試せば」で延々と続き、本開発の予算と時期を食う。これを防ぐには、始める前に終了条件を決めておくしかない。私たちが必ず合意しておくのは次の3つだ。
| 決めておくこと | 具体例 | 決めないと何が起きるか |
|---|---|---|
| 判定する問い（1つだけ） | 「現場の担当者が、既存のExcel入力をやめてこの画面を使うか」 | 検証項目が増え続け、いつまでも結論が出ない |
| 判定に使う数字と閾値 | 「実データ100件で、担当者の手直しが2割を下回るか」 | 「まあまあ良い」で解釈が割れ、次工程に進めない |
| 期限と、超えたときの扱い | 「4週間。届かなければ方式を変えるか、その範囲は自動化しない」 | 延長が既定路線になり、本開発の開始が後ろ倒しになる |
重要なのは、閾値に届かなかったときの選択肢に「やらない」を入れておくことだ。ここを入れずに始めた PoC は、結論が「もっと頑張る」にしかならない。PoC は投資判断のための道具であって、実装の前倒しではない。
PoC から本開発へ何を引き継ぎ、何を捨てるか
「PoC のコードをそのまま本番に昇格させない」と書いたが、では何を残すのか。捨てるのはコードであって、検証で得た判断は資産として全部残す。引き継ぎの形を決めておくと、本開発の見積もり精度が上がる。
| 引き継ぐもの | 具体的な中身 | 本開発でどう効くか |
|---|---|---|
| 判定結果と根拠データ | 閾値に対する実測値、試した条件、外れたケース | 「なぜこの方式か」を後から説明できる |
| 確定した業務フロー | 誰がいつ何を入力し、例外をどう処理するか | 要件の手戻りが減る |
| 触った現場からの指摘 | 使わなかった機能、増やしてほしかった項目 | 作らない機能を決められる |
| 非機能の実測値 | データ量、同時利用者数、応答時間の実績 | 見積もりの前提が数字で置ける |
| 捨てるもの | PoC のコード、暫定のデータ構造、手動運用の手順 | 技術的負債を持ち込まない |
非機能要件をどこまで決めるべきかは非機能要件とは？発注側が決める3項目と見積への効き方で整理している。
PoC を発注するときの契約と見積もりの形
PoC は「完成させる」ことを目的にしないので、請負契約と相性が悪い。完成責任を負わせると、受注側は安全側に倒して検証範囲を狭め、結局「動く既成物」が出てくるだけになる。実務上は準委任で、次の3点を発注側が定義するのが噛み合う。
- 期間と体制（例：4週間、エンジニア1名＋PM 0.3名）
- 提出物（動くコードではなく、上の引き継ぎ表にあたる判定レポート）
- 本開発へ進む場合の扱い（PoC の成果物の権利、同じ体制を継続できるか、単価は据え置きか）
3つ目を決めずに PoC だけ発注すると、良い結果が出ても本開発の体制が組めず、時間を空けて別の会社にゼロから説明し直すことになる。契約形態そのものの違いは請負契約と準委任契約の違いに、要件定義フェーズでどちらを選ぶかは要件定義は請負か準委任かにまとめている。
「どこまで PoC で確かめ、どこから作るか」を相談したい方へ
シンシアでは、要件が固まりきっていない段階からのご相談を承っています。PoC の判定基準の置き方、本開発へ渡す成果物の決め方、体制と費用の組み立てまで、発注側の立場で一緒に整理します。
開発を受ける側にとって、これは何を意味するか
この進め方は、開発会社の商売の形にも影響する。
- 見積もりの単位が変わる。 「要件定義一式いくら」ではなく、「検証をこの範囲でこの期間」という売り方になる。
- 顧客との関係が長くなる。 一度作って納めて終わりではなく、変更を前提にした継続的な関わりになる。継続案件のほうが単価も安定する。
- 人材要件が変わる。 言われたとおりに作れる人ではなく、業務を見て「やめましょう」と言える人が必要になる。育成の設計もそちらに寄せる必要がある。
要件定義を「決めて守るもの」として運用している限り、この転換はできない。逆に言えば、ここを変えられる会社は、同じ人数でも顧客の事業成果に踏み込める。私はそこに勝ち筋があると考えている。
FAQ：要件定義と PoC の進め方に関するよくある質問
要件定義の前に PoC をやるべきですか、後ですか？
順番は「現場理解 → 粗い要件（仮説）→ PoC → 要件の確定」が実務的だ。何も決めずに PoC を始めると何を検証しているのか分からなくなり、逆に要件を完全に固めてから PoC をやると、外れたときに捨てる量が大きくなりすぎる。粗い仮説を立てた直後が、いちばん安く検証できるタイミングである。
PoC にはどのくらいの期間と費用がかかりますか？
判定したい問いの数で決まるが、問いを1つに絞れば数週間規模で組めることが多い。期間を延ばすより、問いを削って短く回し、必要ならもう一度回すほうが総額は安くなる。要件定義フェーズ全体の費用感は要件定義の費用相場にまとめている。
PoC で良い結果が出たのに、本開発で作り直しになるのはなぜですか？
PoC は「方向が合っているか」を確かめるもので、運用に耐える設計もテストも入っていないからだ。作り直しは失敗ではなく、想定された手順である。問題になるのは、PoC のコードをそのまま本番に昇格させた場合で、そのときは負債として後から返済させられる。
要件定義書は結局作らなくてよいのですか？
作る。捨てられるのは「決めた内容」であって、決めた経緯と、今どこが固定でどこが可変かの記録は必要である。むしろ変更を前提にするほど、何をいつ誰が決めたかの記録が効いてくる。書き方は要件定義書の書き方で扱っている。
発注側に専門知識がなくても PoC は依頼できますか？
できる。むしろ専門知識がないほど、紙のレビューより動くものを触ったほうが判断しやすい。発注側に必要なのは技術の知識ではなく、「何ができたら成功と言えるか」を業務の言葉で言えることである。ここが出せれば、閾値への翻訳は開発会社側の仕事になる。
まとめ
要件定義に必要なのは、現場への深い理解と、あるべき姿を出す意思と、そして決めたことを捨てられる柔軟さの三つである。三つ目が抜けると、要件定義は儀式になり、使われないシステムが生まれる。
PoC で動かし、変更しながら最適値に近づける。そのプロセス全体を要件定義と呼ぶべきだ、というのが私の考えだ。
