Webサイト制作を成功させる要件定義書【作り方・ポイント】


Webサイトの制作だけではなくプロジェクトが進む上で要望ややりたいことがどんどん増えてしまい収集がつかなくなる。。。なんていうことの経験はないでしょうか。
多くの場合こう言った状況は明確な要件を定義していないために起きる場合が多いと思います。
そうならないためにもなんのために何を作っているのかをプロジェクトがスタートする段階で定義しておく必要があります。
ワークフローの中で依頼する側も制作をする側にとっても重要な項目が要件定義です。
依頼する側がどんなものを作りたくて、ゴールはどこにあるのかを制作する側が言語化しお互いの共通言語を持つために作成するのが要件定義書です。
今回はwebサイトのリニューアルを例に挙げて要件定義の解説をしていきたいと思います。
要件定義はwebサイトの制作だけではなく全てのクリエイティブにとって重要な項目ですので、制作会社や個人事業主の方に発注を考えていらっしゃる方はぜひ参考にしていただければと思います。
目次
要件定義とは?
要件定義をWikipediaで検索すると以下のように説明されています。
「ソフトウェア要件」とは、あるソフトウェアに必要な機能や性能のこと。
ソフトウェア開発やシステム開発においては、「要件定義」とは、そのソフトウェアシステムに必要な機能や性能を明らかにしてゆく作業のこと
出典元:Wikipedia
Wikipediaにもあるように要件定義については
- ソフトウェア要件
- システム要件
などさまざまな要件があることがわかります。
上記のWikipediaの内容ではIT全体を指している内容ですのでサイト制作やサイトリニューアルでは定義不要なものもあります。
例えばソフトウェア要件などはサイト制作では多くの場合不要になるかと思います。
しかし、システム要件については規模の大小はありまが必ず毎回定義をしています。
「システム要件」という字面だけを見ると難しい内容に感じますし、企業のweb担当者様からするとピンとこないワードでもあるかもしれません。
Webサイトの制作でのシステム要件というと主に下記のような内容が挙げられるかと思います。
- サーバー/ドメイン情報について
- CMS(WordPressなど)の要不要
- CMSに求める機能策定
- お問い合わせフォームの機能
などです。
つまり「システム要件」というのはユーザーの目に見えない部分の仕組み部分での要件をまとめていくということになります。
また、Wikipediaには「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこととあります。
これがまさに今回の記事で解説していく内容で機能や性能を明らかにしていく作業という部分に集約されているといえます。
ここまでWikipediaで紹介されていた要件定義についてを解説しましたが、実際にwebサイトの制作やリニューアルで行われる要件定義ではシステム要件などの他にもっとさまざまな項目を定義していきます。
そしてそれらをクライアント企業と制作側の共通認識であり制作の指標として定義することでプロジェクトのスタートから納品(公開)までそれぞれがブレることなくプロジェクトを進めていく助けとなります。
要件定義のポイント
要件定義については「まだよくわからない」「結局なにをするの?」「だれがやるの?」という疑問があるかと思います。
そこで要件定義のポイントとして、要件定義ですべきことを順番に解説していきたいと思います。
要望(要件)の整理
まずはクライアント企業からの相談を制作側が受けてその内容を整理していくところから始まります。
この段階ではまだプロジェクトがスタートしているわけではなく、あくまでも相談ベースという場合もあり、まだ制作そのものの受発注が確定していない(契約前)状態でもあります。
この段階でのクライアント企業からの相談内容のことをRFP(提案依頼書)とも言いますが、必ずしも書面での依頼というわけではありません。
概ね以下のような相談をいただくことが多いので例としていくつかあげたいと思います。
- Webサイトの制作(またはリニューアル)をしたいので相談したい
- バナー制作をしたいので見積を依頼したい
- ○月×日までにLP(ランディングページ)が必要なのですができますか?
- Webサイトのリニューアルをしたいと考えていますが、〇〇円くらいの予算で○月一杯で公開できるように進めたいと考えているので相談させて欲しい
などファーストコンタクトでのお問い合わせ内容は企業様によって粒度も内容もさまざまです。
まれに「何をいつまでにどれくらいの金額でどうしたいか」を明確にPDFなどにまとめられている状態でご相談をいただくこともありますが、これは本当に稀です。Wepotにご相談いただく場合はざっくばらんにご相談いただいて問題ありません。
ご相談いただいた上で
- 何を
- いつまでに
- どのくらいの金額で
- どんな効果が得たいのか
などヒアリングし初回の要望としてWepotの担当者がまとめていきますのでご安心ください。
それらをまとめて要件定義書にもまとめていきます。
ただ、この段階ではクライアント企業のやりたいことの大枠がわかったという程度に過ぎないのでここから掘り下げてお互いの共通認識としての資料作成をしていきます。
また、この段階でご相談いただいた内容に対して簡易的な暫定のお見積もりやご提案書を作成しご提案することもあります(ほとんどがそうです)。
ご提案をさせていただいた上でクライアント企業側からの正式な発注のお知らせをいただいた段階で契約書をまとめ、要件定義も次のフェーズに移行し実際の制作に必要な内容や情報をまとめていくことになります。
制作を依頼するにいたった背景
契約処理などが終わるといよいよ要件定義書を作成していくことになりますが、Wepotでは要件定義書を作成していく上でとても中だと考えている項目があります。
それがwebサイトや動画や名刺やチラシなどの制作を依頼するに至った背景や経緯をおうかがいすることです。
- なぜ作ろうと思ったのか
- なぜ作る必要があったのか
などどうしてそれを必要とするのかという部分を明確にすることで、よりクライアント企業の要望に沿った成果物をご提供できると考えています。
また、背景や経緯を知ることで納品後の運用や使い方などについても設計することができますので中長期の目標や戦略にも役立つかと思います。
制作の目的
背景や経緯を明確にしたことで目的をより明確にすることができるようになります。
目的を明確にすることで要件定義の次のフェーズであるIA(情報設計)の粒度や正確性にも影響するので重要な項目となります。
目標の設定
目標の設定には
- 制作する上での目標設定
- Webサイトそのものの目標設定
と大きくふたつがあります。
制作する上での目標
制作する上での目標とはwebサイトを公開するまでに必要なページや機能などを指します。
基本的にはすべてのページや機能を制作し公開することになりますが、要望次第では公開を複数設定し複数回に分けてコンテンツや機能を他段階で追加していく場合もあります。
これらが制作する上での目標設定となります。
Webサイトそのものの目標設定
これは端的にいうと、お問い合わせ数であったり申し込み数などwebサイトを通じてクライアント企業が得たい具体的な具体的な項目の設定です。
- お問い合わせを増やしたい
- 採用にあたっての申し込みを増やしたい
など企業によって目的はさまざまですが、その目的に合わせた詳細な目標を設定します。
クライアント企業によってはこの段階でKGIを明確に設定することもあります。
目的と目標があってこそ明確なIA(情報設計)ができるともいえますのでとても重要な内容となります。
目的や目標のないwebサイトではユーザーの流入を増やすための施策を打つことも難しいですし、目的に対して効果を発揮することが難しくなります。
クライアント企業と制作側でしっかりと話し合い目的や目標を明確に設定することが重要です。
サイトの全体像の把握
どんなページが必要でCMSが必要なページはどこなのかなどを図におこすことで把握するということを指します。
サイトマップという呼ばれ方もしますが図表で視覚的に掲載することでクライアント企業にもわかりやすくお互いの認識を合わせるために作成します。
また、全ページを網羅しておくことで足りているページ足りていないページなどを把握することもできます。
サイトマップと似ているものでディレクトリマップというものがあります。
制作会社によってはサイトマップとディレクトリマップを同じものとして扱っている場合もあるかとは思いますが、Wepotではサイトマップとディレクトリマップは別のものとして用意しています。
サイトマップ
サイトマップは上記にもあるように、図表で視覚的に全ページを把握できるようにしたものです。

ディレクトリマップ
ディレクトリマップはGoogleスプレットシートやExcelで作成することが多いです。
サイトマップと違って表で作成し、各ページに必要な要素やURLの設定なども記載します。
Wepotでは主に以下の内容をディレクトリマップにまとめています。
- 項ページ名
- ページURL(ディレクトリ)
- ページごとのmeta要素
- title
- description
- Googleアナリティクスなど解析ツールのタグ
ディレクトリマップはサイト制作におけるIA(情報設計)の領域にも入ってきますので要件定義の段階ではまだ作成できません。
要件定義の段階で作成するのはサイトマップまでとなります。

対応ブラウザやレギュレーションについてのまとめ
Webサイトを閲覧するユーザーごとに閲覧環境は違います。
そこでどのバージョンのブラウザまで対応が必要かなどについてをまとめていきます。
クライアント企業様の方で明確な要望がない場合はWepotの方からご提案朝仕上げていますが、基本的には各デバイスが定めているサポート期間内のものをご提案させていただいております。
例えばInternet Explorer11(俗にIE11とよばれる)については現在はまだマイクロソフト社がサポートをしている状態ですので対応をしますが、来年移行Microsoft社のサポートから外れるためWepotでも対応範囲外とさせていただくことになると思います。
開発における環境の取り決め
開発環境というと難しく聞こえますが、簡単にいうとどのようにして制作するのかということになります。
CMSを使用しないサイト制作であれば多くの場合細かな取り決めは不要かもしれませんが、CMS(WordPressなど)を使用したwebサイトの開発の場合にはクライアント企業のサーバーに直接開発環境を作成させていただくなどする場合があります。
納品物と納品方法
Webサイトの制作にはデザインデータや実際にブラウザで表示されるwebサイトの他にもさまざまな資料を作成しますので単純にデザインやHTMLファイル一式を納品するという以外にも納品物がたくさんある場合があります。
例えば、
- 要件定義書
- 役割分担(プロジェクトメンバー構成)/作業スコープ
- 提案書
- 情報設計書類
- ディレクトリマップ
- ワイヤーフレーム
- デザイン仕様書
- 実装仕様書
- DB(データベース)設計書類
- デバック(検証)表
- 見積書
などです。
クライアント企業やプロジェクトによっては上記の中から必要なものだけを納品する場合もありますし、これに加えて要望のある書類を提出することもあります。
これらの書類を提出するかしないか、作るか作らないかなどの定義を含め要件定義書に納品物とその納品方法について取り決めたことを記載します。
制作における作業スコープ
プロジェクトにおけるクライアント企業と制作側とのお互いの作業内容を明確にすることで認識のすれ違いやそれぞれのタスクの過不足などを把握できるようにします。
クライアント企業(発注側)の作業
クライアント企業の作業内容としては概ね以下のものが考えられます。
- 各種お打ち合わせや定例会の参加、または要請
- サーバー情報の提供、または契約
- ドメイン情報の提供、または取得
- 各種コンテンツの文言作成(契約内容によっては制作側でライターをアサイン)
- デザインの確認や使用する画像/写真などの最終決定
- 受け入れテスト
主にクライアント企業では制作に必要な情報の提供や制作中の打ち合わせや意思決定が作業スコープとしてあげることができます。
制作側(受託側)の作業
制作側の作業としては主に制作に関わる内容となります。
なようは概ね下記のようなものになります。
- 各種打ち合わせや定例会の企画、出席
- プロジェクト管理
- 見積作成
- スケジュール作成
- 要件定義書など各種書類作成
- デザイン
- HTML/CSS/JavaScriptの実装
- CMSへの組み込み
- 各種ガイドラインやマニュアルの作成
- 開発環境の構築
- テスト環境の構築
- 本番環境の構築
- デバック(検証)表の作成とデバック
- 公開手順書の作成
などです。
まとめ
要件定義は制作に必要な項目の策定や取り決めなど重要な項目ばかりが集まった資料と言えます。
要件定義が疎かになるとクライアント企業と制作側で齟齬や行き違いが発生しやすい状態を作り出してしまうため時間がかかったとしても細かく話し合い、互いの認識をしっかり合わせていく必要がある書類です。
Wepotでは要件定義資料を元に詳細なIA(情報設計)をするため、効果のでやすい制作物をクライアント企業に納品するためとても重要視しています。
要件が定まっていなかったりまだまだ相談ベースという場合でもお気軽にお問い合わせいただければ要件の壁打ちから制作までご相談に乗らせていただきます。