お役立ち記事

要件定義とは？ その目的と重要性

要件定義とは、開発するシステムの機能や仕様などを確定していく作業です。RFP（提案依頼書）の内容をさらに掘り下げ、実際にシステム化する範囲や、実装する機能などを具体的に決めていきます。

出来上がった要件定義書をもとにベンダーは次の工程となるシステム設計を行います。そして、その設計をもとに開発が行われます。

つまり、要件定義とは開発するプロダクトの土台となる非常に重要な工程なのです。

「要件定義はベンダーの仕事」は間違い！

「要件定義はベンダーの仕事でしょ？」

「うちの要求は全部伝えたし、あとは実績あるベンダーにお任せで！」

要件定義書を作成するのはベンダーであるため、こうした考えを持つ発注担当者の方がときどきいらっしゃいます。しかし、これは正しくない考えです。

確かに「要件定義書」というドキュメントの取りまとめはベンダーが行いますが、「要件定義」というプロセスには発注側企業の主体的な参加が不可欠です。

「でもRFPを提示したし、それをもとに要件定義書を作成すればいいんじゃないの？」

いいえ、RFPはあくまでも「自社の要求（WANT）」にすぎません。その要求を、実現可能な機能、予算、スケジュールなどに落とし込み、「作るべき要件（MUST）」として再定義するのが要件定義です。その作業は発注側企業の協力なくしては進みません。

もし要件定義をベンダーに任せきりにしてしまうと、どのようなことが起こり得るのでしょうか。よくあるのは、次のパターンです。

• 設計工程に入った段階で、必要な機能の抜け漏れに気づき、要件定義をやり直すことに。
• そのやり直しによって、スケジュールが大幅に遅れ、予算もオーバーしてしまった。
• スケジュールの遅れを取り戻そうと、レビューもテストも不十分なままシステムをリリース。出来上がったシステムは、当初想定していたものとは全然違うものに……。

ベンダー側がいくら頑張ってくれたとしても、発注側企業が主体的に要件定義に関わらなければ、プロジェクトは成功しません。プロジェクトの真の目的や価値を握っているのは発注側企業だからです。

ベンダーとしっかりコミュニケーションをとりながら、互いに協力して要件定義を進めていきましょう。

要件定義は、「やらないこと」を明確にする作業でもある

「自社の要求（WANT）」を「作るべき要件（MUST）」に再定義する過程で、諦めなくてはいけない機能が出てくることがあります。また、企画当初は話に出ていなかった関連部門からの新たな要求が、この段階で追加されることもあります。

そうしたとき発注担当者は、社内の関係部門から吸い上げた要求を再度見直し、調整を行い、「目的達成のためにどの機能を採用して、何を先送りにするか」ということを決めていかなくてはなりません。関係部門から反発が出る可能性もあるでしょう。そうしたことを乗り越えて、全社的な合意を得る必要があります。

このように要件定義とは、「やること」だけでなく、「やらないこと」を明確にする作業でもあります。

要件定義の流れ

発注側から見た、要件定義の流れは以下のとおりです。

1. ベンダーからヒアリングを受ける

はじめに、ベンダーからのヒアリングを受けます。発注側企業の要求定義（RFPに記載した内容）を再度整理し、以下の内容を再確認していきます。

• システム開発の背景と課題
• 解決または実現したいこと
• 目的とゴール
• 機能
• 開発範囲
• システムの利用者について
• 予算
• スケジュール
2. 機能要件を策定する

実際にどのような機能を実装するかを決めていきます。発注側企業の要求の中には、「あったらいいな、というレベルだけど、とりあえず要求に加えておこう」といったものも含まれていると思います。それらもあわせてすべての要求を精査し、実装するべきかどうかを検討します。

3. ベンダーが要件定義書を作成する

策定した機能要件をベンダーが要件定義書としてまとめます。

要件定義書は以下のような項目で作成されます。

• 現状の課題、目的、ゴール
• システムの全体像
• 機能要件
• 非機能要件
• 工数
• 予算
• スケジュール
• 開発体制
• ベンダーと発注側企業の連絡方法、頻度

要件定義のポイント

要件定義において、発注側企業はどのような点に気をつけたらいいのでしょうか。そのポイントを解説します。

1. 機能要件などの洗い出しがしっかりと行われているかどうか入念にチェックする

必要な機能要件を洗い出し、抜け漏れがないかを入念にチェックしましょう。ここで抜け漏れがあると、後になって追加コストが発生する可能性があります。

また、同じ理由で、それらの機能に関する画面の作り方に要望がある場合には、この段階でできるだけ細かく伝えておくことをおすすめします。

例えば「検索機能」において、検索結果が0件だった場合の画面で「0件です」と表示させるだけでいいのか、あるいは「条件を広げるとこんな結果もあります」として、別条件で検索した結果を表示させるのか」といったようなことです。要件定義によって正式な見積金額が決定するので、工数に影響する部分については可能な限り細かく決めておくのが望ましいのです。

とはいっても、「まだそこまではわからないよ……」という方がほとんどでしょう。そういうときは、どういった選択肢があるのかをベンダーから教えてもらいながら進めましょう。

逆に、「ここはどうしますか？ こういう画面にしますか？」と細かい相談や提案をしてくれるベンダーであれば、それは信頼できる良いベンダーだといえると思います。

2. 要求機能一覧をベンダーと一緒に最適化していく

RFPに盛り込んだ「要求機能一覧」をすべて実装すると、予算オーバーになってしまう。そんな場合は、機能の取捨選択が必要になります。

機能に優先順位をつけておき、優先度の低い機能は削る、という方法が一番シンプルですが、それができない場合もあるかと思います。

その場合は、ベンダーと相談して、最も安く機能を盛り込む方法を探ります。

機能にも、リッチな機能、シンプルな機能、シンプルを極めた機能、とグレードを持たせることができます。当然、リッチな機能ほど高く、シンプルにすればその分、コストは安くなります。ベンダーからそうした選択肢をもらって、金額を予算内に収めるようにします。

3. 機能の動作は、デモ画面や既存のWebサイトを用いて具体的に伝える

“ないものを形にする”システム開発において、発注側とベンダーの認識を合わせることはとても大変です。実装したい機能について「このボタンを押したら、こういう画面が出てきて……」とちゃんと伝えたつもりでも、相手に伝わっておらず、フタを開けてみたら全然違うものが出来上がってきた、というのは実によくある話です。

そうした認識のずれを防ぐにはどうしたらいいのでしょうか。

一番の方法は、現物を使って説明することです。一番いいのはデモ画面を用意してもらうことですが、それが叶わない場合は、競合など既存のWebサイトを用いるといいでしょう。実際の動作をベンダーに見せて、「これと同じようにしたい」と言えば、認識はずれません。

4. スケジュールが破綻していないかどうか

要件定義によってスケジュールが確定します。

システムの利用者に向けてリリース日を公表していたりする場合は、開発スケジュールを遅らせることができないかと思います。

そのため、スケジューリングが破綻していないかを要件定義の段階でしっかりと確認しておきましょう。

5. 自社の要求が正しく理解されているかを確認する

自分はこういうつもりだったのに、ベンダーは違う解釈をしていた、というのはよくあることです。それは上記の3.で説明した機能面だけにとどまらず、システム開発におけるあらゆるコミュニケーションの場面で起こります。

間違った解釈のまま開発が進んでしまうと、後々の軌道修正が大変になります。ベンダーには曖昧な表現を使わず、より具体的に、正確に要求を伝えることを心がけましょう。

今回のまとめ

今回は要件定義のポイントや流れについて解説しました。

要件定義とは、「自社の要求（WANT）」を「作るべき要件（MUST）」に再定義していく作業です。この工程を経て、開発するシステムの機能や仕様などが確定します。

ここで決まった内容は設計の土台になります。非常に重要な工程なので、発注側企業はベンダーとしっかりコミュニケーションをとって、要件定義を行っていきましょう。

次回は「システム開発の工程と、発注側企業の役割」について解説します。