要件定義とは？徹底解説｜誰が何を決めるのかを整理する

要件定義は、ベンダーに丸投げすれば分厚い資料が出てくるだけの工程——そう思っていませんか。発注側からよく聞くのは「専門的な話はよく分からないので、そちらでまとめてください」という一言です。でも、要件定義でいちばん重荷を負うべきなのは、実はベンダーではなく発注側です。

要件定義とは：まず1分だけ

要件定義とは、システムやITツールを導入する前に、「何のために」「何を」「どこまで」作るのかを言葉と資料にする工程です。ここで固めた内容が、その後の設計・開発・テスト・費用・スケジュールすべての基準になります。要件は性質の異なる三つに分かれます。業務要件（何を実現したいか）、機能要件（システムに何をさせるか）、非機能要件（どんな品質・条件で動かすか）です。この三つを一緒くたに議論すると、決めるべき人と決まる順番が崩れます。多くの現場では、要件定義書という名前の文書自体はベンダーが作成します。でも、そこに書く「何を実現したいか」という中身まで丸ごと任せてしまうと、あとになって自社の意図とずれた内容が固まってしまいます。

業務要件・機能要件・非機能要件の違い

三つの違いは、問いの立て方で見分けられます。業務要件は「何をしたいか」、機能要件は「システムに何をさせるか」、非機能要件は「どんな条件で動かすか」です。たとえば「受注から出荷までの状況を一元的に把握したい」は業務要件、「受注データを入力すると在庫が自動で引き当てられる」は機能要件、「同時に100人が使っても3秒以内で応答する」「顧客情報を暗号化して保存する」は非機能要件にあたります。

現場でいちばん抜け落ちやすいのは、業務要件です。ここは業務プロセスそのものの見直しと切り離せません。今のやり方を前提に要望を出すのか、やり方自体を変えるのかで、後に続く機能要件はまったく別物になります。この線引きを先にしておきたい方は、BPRの進め方もあわせて読んでみてください。業務を「今のまま」前提で固めるか、「変える」前提で固めるかを、要件定義の手前で一度立ち止まって選べます。

非機能要件も見落とされがちです。動く・動かないという機能の話ではなく、「どれだけ速く」「どれだけ安全に」「どれだけ止まらずに」動くかという話なので、ふだんの業務では意識されにくいからです。パッケージ型のERPを検討している場合は、標準機能がどこまで非機能要件を満たしているかを先に見ておくと、自社で作り込む範囲を絞り込めます。ERP選定のチェックポイントにその見極め方をまとめています。

発注側とベンダー、誰が何を決めるか

「専門的なことはベンダーに任せる」という感覚そのものが、実は最初のつまずきです。ベンダーが決めてよいのは「どう作るか」までで、「何のために」「何を」は発注側にしか決められません。現場の業務を知らない相手に、業務要件を渡すことはできないからです。

影響範囲が全社に及ぶプロジェクトほど、この分担があいまいなまま走り出しがちです。基幹システム刷新のように部門をまたぐ案件では、業務要件を決めるべき人が複数部門にまたがり、誰も「主導」を引き受けないまま会議だけが増えるということが起きます。分担表を先に共有しておくだけで、この空白は防げます。

とりわけ見落とされがちなのが、テスト基準・受入条件です。「動くかどうか」ではなく「何をもって完成とするか」を先に決めておかないと、開発が終わったあとに「思っていたのと違う」という指摘が積み重なり、リリース直前になって手戻りが発生します。受入条件は、非機能要件と同じくらい早い段階で言語化しておく価値があります。

一段深く：曖昧な要件はどう壊れていくか

デザイン思考の基本は、目の前の要望をそのまま形にするのではなく、「そもそも何のためか」に立ち返って設計しなおすことです。要件定義も同じで、機能の一覧を埋める作業ではなく、目的から逆算して「決めるべきこと」を洗い出す作業です。

私は、物流・製造の現場で発注する側に立ったこともあれば、ITスタートアップで事業を作り提供する側に立ったこともあります。今はDXコンサルタントとして、支援する側から要件定義という同じ工程を見ています。そこで見えるのは、いつも同じ壊れ方です。現場は「今のやり方」を前提に要望を語り、ベンダーはその言葉をそのまま機能要件に翻訳します。ここまでは誰も間違っていません。問題は、その先です。繁忙期に何人が同時に使うか、権限をどこまで分けるか、障害が起きたときに何分止まってよいかといった非機能要件は、現場の言葉にはもともと出てこないので、誰かが意識して問わない限り抜け落ちます。抜け落ちたまま設計・開発が進み、カットオーバーの直前になって性能不足や権限漏れが表面化し、追加の見積りが後出しで積み上がっていきます。立場を変えながら見てきて、これがいちばん多い崩れ方だと感じています。

だから要件定義でまずやるべきことは、機能を細かく決めることではありません。業務要件・機能要件・非機能要件のどれを、いつ、誰が決めるのかという「決め方」を先に握ることです。ここさえ握れれば、細部は後からいくらでも詰められます。

よくある質問

Q. 要件定義書は発注側とベンダー、どちらが書くのですか。

A. 業務要件は発注側が言葉にし、機能要件・非機能要件はベンダーが技術的な形に落とし込みながら、発注側が内容を確認して承認するのが基本の分担です。片方だけが書いて片方が読むだけ、という形にすると、実務で使われない要件定義書になりがちです。

Q. 要件定義とRFP（提案依頼書）は同じものですか。

A. 別の工程です。RFPは発注先を選ぶために「何を実現したいか」を先に示す依頼文書で、要件定義はその後、選んだベンダーと一緒に「何を」「どこまで」作るかを詳細に固める工程です。RFPの段階で細部まで決め切ろうとすると、ベンダー選定が長引くだけになります。

まとめ

要件定義は、ベンダーに任せて終わる工程ではありません。業務要件・機能要件・非機能要件を区別し、何を発注側が決め、何をベンダーが決めるのかを先に握っておきます。それだけで、後工程の対立や追加見積りの多くは防げます。全部を細かく決めなくていいのです。まず、この三つの区別と分担表から始めてみてください。ご自身のプロジェクトでの分担の整理は、お問い合わせからもご相談いただけます。

この記事を書いた人

小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。