なぜ要件定義はまとまらないのか
本記事では、要件定義が止まる構造的な理由と、プロトタイプ起点で前に進める方法を整理します。
要件定義が難しいのは当然
DXやAIが普及し、様々な業務でDX化やAI適用の検討が進んでいます。しかし、それらのDXや業務システムの開発において、「要件定義が進まない」「議論が噛み合わない」と感じたことはないでしょうか。
- 会議を重ねても仕様が固まらない
- 現場に詳しい担当者が議論についてこない
- システム構築が進んでから、要件の不備に気づく
こうした状況は珍しくありません。そして多くの場合、「現場のITリテラシーが低い」「要件定義のやり方が悪い」といった話にすり替えられがちです。 しかし、結論から言えば 要件定義が難しいのは当然 です。
それは個人の能力の問題ではなく、要件定義自体が難易度が高い業務だからです。
要件定義は「３つの異なる思考」を同時に使う
本来、DXや業務システム開発は次のように進められるのが理想です。
- ユーザーの業務を理解し、現在の業務フロー図を作成する
- システム導入後の業務フロー図を作成する
- 業務をどうシステム化したいかを整理する
このプロセスをうまく回すことができれば、現場にとって価値のあるシステムが生まれ、結果としてDXにつながります。そのために、業務を深く理解している現場の人（ドメインスペシャリスト）とシステムを理解しているエンジニアやシステム開発会社が協業し、ユーザーにとって本当に価値のあるサービスを作れるのが理想的です。
しかし、実際にはエンジニアやシステム開発会社が現場の声を捉えきれなかったり、整理された要件定義ができても現場を理解している人が要件定義を読み込んで改善のための指摘をすることができなかったりします。それは、要件定義が同時に「３つの異なる思考」を往復する必要があるからです。
- 今の業務がどう回っているのかを理解する現状理解
- 業務をモデル化する抽象化
- システムとしてどのように実装するのかという実装化検討
業務のスペシャリストは1には精通しているのですが、2や3は経験がなく、分からないことが多くあります。一方でエンジニアは3には強いのですが、業務のスペシャリストからヒアリングをしても業務のイメージが沸かないために1ができなかったり、1ができても2ができないことがあったりします。
現場をよく知った人が要件定義についてこれない理由
DX化やAI適用の議論には、現場の業務をよく知るスペシャリストの参加が必須です。しかし、多くの場合、システム開発の文脈では次の壁にぶつかります。
- 画面遷移やUIを頭の中で想像できない
- データがどのように保持・連携されるかイメージしづらい
- 状態管理や例外ケースの議論になると途端に抽象度が上がる
要件定義の議論は、「業務の言語」と「システムの言語」が混ざった高度に抽象的な会話です。そのため、業務に詳しくても、
- 議論の前提を理解できない
- Yes / No を求められるだけになる
- 徐々に発言が減る
といった状態に陥りがちです。これは能力不足ではありません。要件定義という行為自体が、非エンジニアにとって極めて参加しづらい構造を持っているのです。
抽象的な議論の難しさ
そもそも、人は経験したものについて話すことができますが、未経験のものについて議論することは難しいと感じます。
要件定義ではこれから開発するシステムについて議論をするため、存在しないシステムを、操作することもできず、どのような体験になるのかも分からないなかで、それを想像しなければなりません。
システムを作った経験や、ITのトレンドを把握できていないと、完成したシステムをイメージしながら、どのようなところに注意すべきかなどを議論することは難しいと言えます。
人の行う業務とシステムの違い
また、人の行う業務とシステムの違いも大きく影響しています。
人の業務は、例外や暗黙知が多く、その場の判断や工夫で成立しています。現場の善意や経験によって「うまく回っている」ケースも少なくありません。
一方でシステムは、あいまいさを扱えません。以下のような“決める作業”が必要になります。
- 用語や入力値を定義する
- 例外を整理して減らす（残すなら条件を明文化する）
- 処理の流れ、分岐、責任分界点を事前に決める
要件定義とは、これまで人が柔軟に処理していた業務を、システムが扱える形に「翻訳」し、制約の中で省力化・低コスト化の落とし所を見つける議論なのです。そのため、業務のスペシャリストはシステム化のためのコツを知らなければならず、エンジニアは、現在の業務をいかに整理するとシステム化しやすいかをアドバイスする必要があり、お互いが協力することが重要です。
動くものを見せると議論が一変する
要件定義が特殊な業務であり難しいことは前述のとおりですが、だからといって現場のスペシャリストを巻き込まないわけにはいきません。むしろ、議論に深く関わってもらわなければ、DXやAI適用は成功しないのです。
そこで、要件定義という難しい業務に参加してもらうのではなく、プロトタイプやMVPといった実際に「動くもの」を用意できると状況は大きく変わります。
- 「この操作、実際の業務だと使いづらい」
- 「この項目は現場では不要」
- 「ここは毎日使うから、もっと簡単にしたい」
抽象的な議論では沈黙していた人が、体験を通じて具体的に発言できるようになるのです。
つまり、要件定義として言葉だけで議論するのではなく、プロトタイプを操作しながら体験を踏まえて議論するようにするのです。これにより、現場のスペシャリストが議論に参加できる幅が全く変わります。
要件定義を主役にしない
ここで重要なのは、要件定義そのものをやめることではありません。むしろ逆です。
業務のスペシャリストとエンジニアがプロトタイプの機能や操作性を議論し、その議論の結果を要件定義にまとめるのです。
要件定義を会議の主役にすると議論が止まってしまうことも多くなりますが、プロトタイプを主役にすることで非エンジニアでも議論に参加しやすくなり、深い議論ができるようになります。また深い議論ができることで、エンジニア側にも新しい気付きが得られるようになります。
プロトタイプを起点に要件定義を進めるという選択肢
私たちは、この考え方を整理し、実践できるUX駆動開発を独自フレームワークとして再定義し、実践しています。
プロジェクトを開始する際に、その目的や方針についてヒアリングをしたうえで、すぐにプロトタイプの開発に着手します。短期間でプロトタイプを触りながら議論ができる状況を作るためです。そして、プロトタイプを利用した議論のなかで、様々な意見が交わされ、それをもとにプロトタイプの改修と要件定義を作り込んでいきます。
要件定義が終わると設計や開発に着手しますが、プロトタイプを流用することで期間を短縮できますし、完成したシステムも期待値からズレにくくなります。
このような進め方により、関係者を巻き込みやすくなり、手戻りを減らし、現場にあったシステムを作ることが可能になっています。