こんにちは！BAsixs参画企業ビジネス・アーキテクツの小泉です。

今日は、ご提案時にお客様からよくご質問いただく「要件定義ってなんですか？」について、触れてみたいと思います。

システム開発やWebサイトの制作を行う上で「要件定義」はなくてはならない工程の一つです。

要件定義なくして、発注側が真に望むサイトを制作してもらうことは非常に難しいです。

この記事では、要件定義がなぜ必要なのか「要件定義の目的」から、要件定義を行う上で気をつけるべきことなどを紹介し、具体的な要件定義の流れを説明します。

要件定義はなぜ必要？

要件定義とは、制作会社（受託者）が、発注側（委託者）の要件を要件定義書に取りまとめ、両者が合意形成する工程のことを言います。言い換えると、Webサイトにおいて発注側（サイト利用者や消費者の場合もあります）が望んでいるサイトを、どう実現するかを制作会社がまとめ、明確化する作業のことです。

「思っていたのと違う」「追加の費用が発生する」「納期に間に合わない」などのリスクを軽減するためには、要件定義が有効です。

要件定義の目的は、発注側と制作会社の認識のズレを最小化すること。ひいては、発注側社内でも認識のズレを無くすために必要です。

要件定義をすることで得られるメリットは4つあります。

要件定義をすることで得られる4つのメリット

メリット1. プロジェクトの目的を見失わない

制作会社に依頼してから実際にWebサイトが公開されるまでには少なくとも数ヶ月程度の期間を要します。公開までの間で、発注側または制作会社側の担当者が変更になったり、公開後に新しいコンテンツを企画する時などの戦略策定時に、当初の目的に立ち戻れる要件定義書は一つの指標となります。

メリット2. プロジェクトの評価ができる

制作会社の設計不備や成果物の要件漏れが無いか、納品時に確認し承認する判断基準にも要件定義書が活躍します。

また、要件定義の段階でKPIを策定することで、ビジネスの成長に貢献できているか、効果測定ができるようになります。

メリット3. 追加で費用が発生したり、スケジュールの遅延を防げ

多くの場合、要件定義の確定内容をもとに、その後の設計・開発工程の正式な見積もりやスケジュールが算出されます。

例えば、納期と費用、対応するスコープの中で何を優先するのかを記載することで、制作会社から発注側の意図を汲んで提案してもらえます。ここを曖昧にしていると、追加で費用が発生したり、スケジュールの遅延につながります。

メリット4. 発注側社内での合意形成を取るために有効

RFP（提案依頼書）と同様に、社内のステークホルダーに情報共有するツールとしても要件定義書は有効です。プロジェクトの目的や要件をまとめた資料を展開できるようになることで、社内での合意形成が取りやすくなります。

RFPとは何か、作成するメリットや項目については以下の記事で説明していますので、是非ご覧ください。

提案依頼書（RFP）とは？要求仕様書・要件定義書との違いや重要性の考察 | BAsixs（ベーシックス）

要件定義書に書いてあること

要件定義書は、プロジェクトによって項目が大きく変わります。Webサイトリニューアルを想定した項目をご紹介します。

次に、要件定義の流れを紹介します。

要件定義を進める6つのステップ

それでは、実際の要件定義の流れについてご紹介します。各ステップでどんな情報を制作会社に渡すべきか、要件定義をもらった時に見るべきポイントはどこかを紹介します。

要件定義は大きく6つのステップで進めます。

1. コミュニケーションルールを決める
2. プロジェクトの目的・目標を設定する
3. 現状の問題・課題・要望を関連部署から洗い出す
4. 課題を3つに分類し体系立てて整理し、スコープを決める
5. 課題とスコープをもとに、サイト要件（要件定義の項目）を決める
6. 要件定義書に合意する

それでは、各ステップについて簡単に説明します。

ステップ1. コミュニケーションルールを決める

ルール作成は制作会社が主導しますが、発注側が事前に知っておいた方がいいこと、準備すべきものを中心に紹介します。

1.要件定義の全体スケジュールに合わせて定例会を設定する

要件定義を話し合う前に、発注側の会社指定のガイドラインやレギュレーション、関係部署の体制図やステークホルダーとの関係図、業務フロー図等があれば事前に制作会社へ共有しましょう。共有内容によって定例会での確認事項が増減するためです。

発注側の情報を考慮して、要件定義を完了するまでのスケジュールと、要件定義で決める項目一覧を制作会社がリストアップして提示します。リストアップした要件定義の項目をもとに、打ち合わせの予定を立てます。

案件や規模にもよるので、一概には言えませんが、1回1.5〜2時間×8回程度の実施が一般的です。週次の定例会議と考えると、約2ヶ月程度の期間を要件定義にかけます。

しかし、「対象範囲が広い」「サイトの規模が大きい」「ステークホルダーの数が多い」などの場合、内容が複雑化するので、要件定義の打ち合わせ回数が多くなります。

2.データの受け渡しルールを決める

要件定義や制作フェーズでも特に大切なことの一つが、制作会社とやり取りするデータの保管・管理です。もし、発注側で電子文書のやり取りに使うクラウドストレージの指定がある場合は、予め制作会社に伝えておくとスムーズです。

たとえば、発注側の社内から出てくる質問をQA表にまとめて制作会社へ渡すとログが残るので、制作会社と発注側の認識を合わせやすくなります。

3.タスク管理ルールを決める

要件定義を検討する中で、発注側・制作会社の双方に、様々なタスクが発生します。そのため、要件定義の段階でタスク管理ルールを事前に決めておくと、誰がタスクのボールを持っているか把握しやすくなります。特に、発注側の窓口担当が複数人いる場合には、社内の誰が担当しているかが一目で分かるので便利です。

具体的には、タスク管理ツールを使って以下の6つを管理します。

• タスクの概要
• タスクの担当者
• 進捗状況
• 優先順位
• 期限
• タスクに関わる、関係者間のやり取りのログ

また、「ミーティングのリマインド連絡」などのタスクとして管理しない共有事項などは、チャットツールやWeb会議システムなど普段使い慣れているコミュニケーションツールをあわせて使い、発注側と制作会社との両者が気軽に密なコミュニケーションを行う環境を整えておきましょう。

ステップ2. プロジェクトの目的・目標の設定を設定する

本プロジェクトの目的・目標をそれぞれ設定します。目標とはいわゆるKPIの設定です。「どういう仕様をクリアすれば、本プロジェクトが成功と言えるか」の指標を定めることです。

KPIを定めるときに重要な3つの要素は「指標」「値」「期間」です。

例えば、ビジネスのリターンとなる「自社サービスの契約」「会員登録」「商品購入」などの指標に、数値と期間を追加します。「月間〇〇件のターゲット企業からお問合わせを獲得する」など、明確で誰もがわかりやすい目標を定めるようにします。

ステップ3. 現状の問題・課題・要望を関連部署から洗い出す

制作会社が各関連部署へヒアリングや確認を行います。発注側がRFPや要求事項一覧を事前に作成している場合は、それらをもとにヒアリングできます。

このステップでは、発注者は関係部署の洗い出しと、各部署の主要メンバーへのヒアリング日程を決めます。

次に洗い出した洗い出した課題を整理します。

ステップ4. 課題を3つに分類し体系立てて整理し、スコープを決める

ステップ3で洗い出した中から、問題（達成したい目標と現実の差）を解決するためにやるべきこと、すなわち「課題」を抽出します。課題の中には、固まり切っていなかったり適切ではない場合もあるからです。

確定するためには、引き出した要求を体系的に整理する必要があります。抽出した課題を3つに分類し、それぞれの位置づけや要求間の関係を整理しておきます。

• ビジネス要求：プロジェクトの目的、ゴール
• ステークホルダー要求：ビジネスを成長するために、ステークホルダーが必要だと考える要求
• ソリューション要求：ステークホルダーの要求を実現するために必要なプロジェクト成果物

そして課題を具体的にしたり矛盾を発見して修正し、「ステークホルダー要求」「ソリューション要求」が「ビジネス要求」と整合しているか、妥当性を確認します。

プロジェクトの目的・目標をもとに、抽出したそれぞれの課題に対して、優先的に解決する課題と、優先度が低く初回の対応範囲に含める必要が無い課題に大きく分けます。まずスコープに含めない課題を決めると進めやすいです。

3つに分類し整理した課題を、目的達成のために必要かという観点で優先順位をつけます。そしてプロジェクトのスコープに入れるべきかを、ステークホルダーと合意します。

ステップ5. 課題とスコープをもとに、サイト要件（要件定義の項目）を決める

ステップ4で整理した課題を解決するためにはどのような仕様にすべきかを決めます。

制作会社が要件定義書に落とし込み、一つのファイルにまとめるので、特に発注側のタスクはありません。Webサイト制作にかかる費用やサイト公開に向けた各フェーズのスケジュールを作成します。納品物や納品形態も決めます。

ステップ6. 要件定義書に最終合意する

最後に、制作会社が作った要件定義書を発注側が確認します。

要件定義は、作成中に合意しながら進めます。基本的に最終合意のタイミングで変更や修正は殆ど入りませんが、制作フェーズに入る前に最終確認します。

双方で合意した要件定義をもとに、制作会社が詳細な見積書を作成します。

よりよい要件定義にするために、事前に決めておきたい4つのポイント

要件定義は、発注者側の要求を取りまとめたものを、どのように実現するかを文書化して、発注側と制作会社とが合意したものです。

要件定義の前に、発注者側で社内のステークホルダー（経営層・決裁者、関係部署、運用担当者、Web管理者）の要求を取りまとめる必要があります。特におさえておきたい4つのポイントをご紹介します。

1.ゴールを設定する

要件定義でつまずく多くの原因は、発注側が考えるゴールを明確に設定できていないためです。

例えば、「誰をターゲットにするのか」「どんなコンテンツを見せたいか」「サイト訪問者にどんな行動をとってもらいたいか」といった目的が定まっていないと、次の設計フェーズで認識齟齬が生まれてしまいます。

そして制作会社と発注側の認識がずれているため以下のような悪循環に陥ります。

1. 発注者側が意図している通りに、設計がされない
2. 設計が間違っていても、発注側は認識のズレを見つけられないため、軌道修正できずに制作される
3. 制作されたものを見て、発注側は「要望と違う」と感じる
4. 当初の目標を達成するためには追加開発するしか選択肢がなく、コストが増加し、リリース時期が後ろ倒しになる。

悪循環を回避するためには、まずプロジェクトを立ち上げる目的となる、ビジネスのニーズを表した「ビジネス要求」を社内で合意しておく必要があります。

分かる範囲で、3つの要求「ビジネス要求」「ステークホルダー要求」「ソリューション要求」を洗い出し、それぞれの要求の位置づけや要求間の関係を整理しておきます。すると、経営層や決裁者も考えを整理しやすくなるので、ビジネス要求を引き出したり、合意しやすくなります。

弊社では経営層や決裁者が明確なゴールをイメージできていない場合、ビジネスの目的を元にいくつか案を提案し、その中からゴールを決めていただいています。

2.関係部署と調整する

要件定義と聞くと、発注側のプロジェクトへの期待をまとめる作業のようなイメージを持つかもしれません。しかしビジネスに関わる全てのステークホルダーの期待、すなわち「ステークホルダー要求」を実現することは不可能です。

一方で、発注側の社内とは言え、関係部署（営業やシステム部、CS部など）の人が抱える課題や要望を全て明確には理解することは困難です。

担当の部署のみで要件を決めてしまい、関連部署からの課題や要求をヒアリングしなかったために、Webサイトを見てほしいターゲットを間違えて設定してしまう可能性や、一度固めたはずの要件を再定義しなければいけない場合もあります。

要件の変更や再定義を防ぐためにも、事前に担当部署だけでなく、関連部署を巻き込んだプロジェクトであると認識し、要求や課題を確認する場を設けることが重要です。この時、制作会社がそれぞれの関係部署にヒアリングすることで、新たな要求を顕在化し抽出できる場合があります。

要求事項を確定するためには、引き出した要求を体系的に整理します。そして要求の不足や矛盾を発見して修正し、プロジェクトの目的と要求との妥当性を確認します。

発注側の社内で要求事項を取りまとめ、一覧にまとめたほうが制作会社に伝えやすいです。

3.どのように解決したいのか考える

ステークホルダーの要求を実現するために、どのように解決したいのか、どんな成果物が必要かなどの「ソリューション要求」を決める必要があります。

要件定義書をもとに、制作会社が提案してくれるとは言え、要求を整理する段階でどのように解決したい・解決できると思っているか方向性は決めておくとよいです。

4.発注側と制作会社双方で正しく情報共有する

要件定義書は作成すれば完了ではありません。制作会社側とも要件について合意する必要があります。

発注側のWebへの知見や、制作会社側のビジネスへの理解度など、状況も様々なため、共有した情報は一つずつ内容を確認する機会が必要です。

例えば、発注側と制作会社側双方の前提知識や使っている言葉（専門用語、企業内用語、業界独特の言い回しなど）がそもそも違う可能性もあり、文書をつくればOKというわけではありません。

まとめ：よりよい要件定義にするために

要件定義フェーズは、お互いのことを理解するプロセスのため、うまくいかないと後々大きな問題に発展する可能性があります。お互いを理解できない原因の一つに、コミュニケーションルールを決めずにプロジェクトが進むことが挙げられます。

また弊社では問題を解決するために、ビジネス課題を元に、ステークホルダーの意見や状況を考慮した施策をご提案します。予算やスケジュールによって、対応する範囲や優先して解決すべき課題が何か、どう解決すべきかも先導いたします。

要件定義を制する者がプロジェクト成功を制する

作成した要件定義書はWebサイト制作を行う上で、指針となり、迷ったときに立ち返る事ができるため、発注側・制作会社双方の拠り所となります。

このように、Web制作を行う上で、要件定義書の作成はとても重要な過程です。大規模なサイトほど、ステークホルダーが増え、要件が複雑化する傾向にあるため、要件定義にかけるコストや時間を取る必要があります。一般的に全体の費用の約2割を要件定義に費やす必要があると言われています。

要件定義の成功は、発注側の期待・望む通りの成果物を納品されることに繋がります。

弊社ではこれまで要件定義からご依頼いただく場合が多く、お客様の課題から要望、要件に落とし込む要件定義の段階でお客様（発注側）と合意形成をしてきました。その結果、設計・実装の工程で遅延を防ぎ、プロジェクトを成功へと導くことができました。

なぜなら双方の言い分が異なった場合や、追加の要望が発生した場合などは、要件定義を軸にお話しすることで、目的を見失わずスムーズに判断できるからです。

要件定義とは、設計をするときの根拠であり、取り組む範囲を明確化し、効率よく進めるためになくてはならない工程なのです。

ビジネス・アーキテクツでは、大規模なサイトの要件定義も多数実績があり安心しておまかせいただけます。更に、要件定義後の制作・運用まで一貫した体制でお受けできます。是非一度ご相談ください。