大まかな前提条件
はじめに
要件定義、要件開発に関する記事、書籍は多くありますが（当然ながら特にシステム開発関連が多いですが）、ここではWebサイトのリニューアルに限定した要件定義の内容や進め方について、これまでの経験を元に、私なりにまとめていきたいと思います。
Webサイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。
また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては３ヶ月から１年程度の期間で行うリニューアルを想定した内容となります。
受託案件（発注側からは外注する）の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側（制作者側）の内容として記載していきます。
対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。
Webサイトリニューアルについて
多くの企業サイトの場合、３年から５年くらいでサイトの全面または一部リニューアルが行われる場合が多いかと思います。場合によっては、１０年など長期利用となっていることも案外遭遇します。
Webサイトリニューアルの目的は様々ですが、企業としてはリニューアルの結果として以前より、より利益が上がる（売り上げが上がる、経費が下がるなど）ことが目的となるかと思います。
（目的と書きましたが、利益自体が企業の本来の目的ではない点に関しては、ドラッカーの「利益とは、企業が事業を継続・発展させていくための条件である。明日さらに優れた事業を行なうためのコスト、それが利益である。」であるかと）
Webサイトリニューアルの全体の流れについて
要件定義といってもどこまで何を「要件定義」の中で行うかは『定義』によってきますが、全体としては以下の流れ、ステップでWebサイトをリニューアルする前提としています。
構築の流れ
- RFP【提案依頼書】（クライアントが提示）
- 提案【提案書】
- 戦略策定【戦略策定書】
- 要件定義【要件定義書】
- 設計・計画【各種設計書】
- 構築・テスト・リリース【実装されたサイト、テスト結果報告書】
- 運用【マニュアル】
※かっこ【】内は主なアウトプット
※見積書作成、スケジュール作成などはもちろん別途行う
※別途基本契約、個別契約の中で機密保持や瑕疵担保責任、知的財産権の帰属は定める想定とする
要件定義書の中にもリニューアルの目的も記載は必要となりますが、経営戦略や企業としてどうしていくか、課題はなにがあり、あるべきはどうなるかについては、戦略策定の中で実施する想定となります。（KGI、KPIの策定含め）
そのため、この記事内には含んでいませんので、別の機会にRFPや戦略策定についてもまとめたいと思います。
受発注（契約）とそのタイミングについて
ウォーターフォールモデルを想定しています。
Web制作会社側としての受注の範囲については上記「構築の流れ」の全体の場合もあれば、2から5や、3から5などの場合もあるかと思います。（発注側の社内で実施している場合や、コンサルティング会社で実施済の場合など）
理想的には構築のステップ毎に発注をもらうことだと思います。なぜなら、上のステップが終わらないかぎり次のステップでの費用が本来確定しないからです。
また、RFP・戦略策定・要件定義までは準委任契約が望ましいです。
（とはいえ、請負契約となることも多いかとは思います。）
RFPと運用については基本契約は別れると思いますが、それ以外については一括契約となることもあります。
ただ、一定規模以上の案件であればせめて、要件定義までとその後の設計・構築については契約を分けて行うことは必須かと思います。
なお、企業の予算確保の関係で、事前にWebサイトリニューアルに関わる予算全体を発注元の企業内で承認をうける必要があるため、通常RFPを元に受けて提案（提案書・概算見積書）を元に予算確保が行われると思います。
※この時点では『概算』ですが、ここが実質予算上限になったりすることもあります。
要件定義とは
要件定義・要件開発とは何か
要件定義とはクライアント（発注元・顧客）の望んでいるサイト・機能をまとめることです。
システムでどうするかということもありますが、どういったことが出来る必要があるか、したいかをまとめるものです。
『定義』というとすでに望んでいる明確なものがあって、それをまとめるイメージですが、実際にはクライアント自身も明確に網羅的にすべての要件をもっているわけではなく、聞くだけで作成できるものではありません。
そのため『要件開発』と呼ぶことが適切とする場合もありますが、ここでは以降も一般的な『要件定義』と呼びます。
また、要件定義をまとめた書類を【要件定義書（RDD / Requirement Definition Document / business requirements document)】と呼びますが、本記事では要件定義書でまとめていく内容とそのまとめ方、クライアントとの確認・調整方法について記載していきます。
要件定義の目的
クライアントとWeb制作会社の『認識のズレを最小化する』ことです。
ひいては、クライアント内、Web制作会社内でも認識のズレを最小化することができます。
なお、極論として認識のズレが発生しない場合、発生した場合の影響が（費用、期間的にも）無視できるレベルであれば、要件定義は不要です。
例えば、クライアントから全幅の信頼があり、費用と期間以外はすべておかませで好きなようにやってよい場合や（クライアントの協力は結局必要ですが）、リニューアルの規模自体が極端に小さい場合ゆあ、実施する内容がすべて明確な場合であれば、見積書内に記載する前提条件レベルで要件定義としても大きな問題はないとは思います。
が、実際このような場合はあまりないので、やはり要件定義は必要となるでしょう。
また、書類だけがあればよいというものではなく、それがクライアントに伝わり認識されていなければ意味がありません。（契約としては、「ここ」に書いているのでで済ませられる可能性もありますが、クライアントは納得できない状態となり、プロジェクトとしてはうまくいかないことになります。）
書類単体としてもわかりやすく理解できるように作成する必要はありますが、クライアント担当者の知識レベルや知っている業務の範囲も様々だったりするため、ひとつづつすべての内容は説明する機会が必要です。担当者だけでは判断できない部分がある場合は関連するメンバーをあつめて説明をおこない認識のすりあわせと、内容調整を行う作業を必要に応じて繰り返す必要があります。
要件定義で何をどこまで定義するか
『認識のズレを最小化する』ためには、漏れなく、より細かく定義が必要ではありますが、費用や期間の制約は当然ありますので、何をどこまでどのように定義するかは事前に定めておかないと進められれない、期間に収まらないことになりがちです。
要件定義の結果としては設計フェーズ以降の正式な見積書を作成できる必要がありますので、ブレのない見積書ができるところまでを定義する必要があります。
要件定義はクライアントの要件ではありますが、制作会社側としては「やること・やらないこと」を明確にすることで費用、期間が確定できます。
要件定義の際に、「できる・できない」の確認が発生することもありますが、極論としてはなんでも要件の定義としては「できる」となります。
※現実世界でできること、法律上できることであれば。
もちろん定義の結果としては、費用や期間に影響がありますので、設計以降の予算やリニューアル予定日が決まっている場合であれば、予算上、期間上できない・現実的ではないということは多くあると思います。
そのため、優先順位や期間については複数ステップを検討するなど、全体としての計画も必要となります。
なお、認識のズレは設計を行っても、実際の構築してすべて完成したもので確認して調整したとしてもズレはどうしても出てきますので、ゼロにすることはまず当然不可能ですが、大きな問題、手戻りが発生しないように、制作会社側としては事前に推測できることについては定めていく必要があります。
いつまで要件定義書を更新するか
構築の流れの中で「3.要件定義」でおこない、いったんの完了（納品）となりますが、その後流れで要件定義に関わる部分が変更となる場合もあると思います。
変更が発生しないように定義出てきることが望ましくはありますが、サイトのリニューアル公開までについては、必要な場合は要件定義書に戻って更新することが望ましいでしょうか。
当然、紐づいて費用やスケジュールが変更になってきますが、双方（クライアント、制作会社）が合意していれば問題はないため、変更内容にあわせて要件定義についても更新していくべきです。
要件定義書を基準にできるため、追加・変更なのか、もとからの要件なのかも後から確認できるものになっているはずです。
※要件定義を更新していないと、実際の状況とことなり認識のズレの要因になるためです。
顧客が本当に必要だったもの
有名な風刺画があります。知っている方も多いと思います。
Webサイトのリニューアルやシステム開発の行ったことがある人（特に制作会社側の人である程度の経験がある人）であれば、笑えて・笑えない絵です。
そして程度の違いこそあれ、多少なりともこれに近いことを経験している人も多いと思います。
※いろんなパロディがあって面白いが、その筋に詳しくないと理解できない
繰り返しとなりますが、上記のような状況とならないために認識のズレを最小化するために重要となってくるのが、上流工程ともよばれる戦略策定と要件定義となります。
要件定義で決める内容
要件定義書の目次
要件定義書の中の目次は以下のように定義します。
- 全体概要
- プロジェクトの目的
- Webサイトリニューアルの背景と目的
- 目標・評価達成指標
- コンセプト
- リリース予定日
- 概要スケジュール
- 納品物
- プロジェクト対象範囲
- 対象ドメイン
- 対象コンテンツ
- 対象システム
- 機能要件
- 利用システム・サービス
- 機能一覧
- 機能詳細
- 非機能要件
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- 環境・エコロジー
※非機能要件の項目についてはIPAの非機能要求グレード*1の内容にあわせています。
要件定義書を何でつくるか
ワードでもパワーポイントでもエクセルでもなんでも良いと思います。
クライアントとより確実に認識のすりあわせができれば良いと思います。
細かなマトリクス情報なども一部必要なため、エクセルの資料も必要となる場合が多いとは思います。
また、資料は１つでなくとも状況に応じて複数になる形でもよいと思いますが、一式（ワンセット）として要件定義を管理する必要があります。
要件定義の進め方
RFPと戦略策定が終わったあとの想定となりますが、まずは要件定義書を作成していく上で必要となる情報集めをする必要があります。
要件定義書としてどのような物となり最終的な納品物として何ができるか事前にクライアントに説明できるのが望ましいです。
全量をテンプレートにしたサンプルを定時するか、ざっとドラフト版の全量要件定義書を作って定時する方法もあります。
ヒアリングや受領した資料からわかる範囲を記載し、あとは規模や内容から制作会社側が経験上最適と推定できる内容で一度定義してしまう形がよいと思います。
その上で、クライアントに内容を確認してもらいその後、説明（レビューのMTG）を行う機会を設けてすべての内容について全量説明しつつ想定や実施したいことと合っていないか確認していく必要があります。
詳細についてはそれぞれのポイントないでも記載していく予定です。
要件定義作成にあたってリクエストする情報・資料
これから紹介していく内容でも定義をしていきますが、事前にクライアントにリクエストしておくべき資料について以下に記載します。（クライアントに用意があればですが）
- アクセス解析結果の情報（Google Analyticsのアカウントなど）
- Google Search Consoleなどのアカウント
- 現状のページ一覧
- 現状の各種設計書
- 現状のインフラ構成
- 現状のネットワーク転送量
- 現状のサーバ内ファイル一式・データベース
ここまでで、vol.1は以上となります。
次回は、要件定義書の全体概要について紹介していきます。
*1: 非機能要求グレード: https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
