コンテンツマップで定義するものは？要件定義の重要ポイント。
たぐと申します。
東京のweb制作会社でプロデューサーをしています。
今回は、主にweb制作会社、webサイトの運用を任されている企業の担当者の方向けに
「コンテンツマップ」というものについて話をします。
コンテンツマップとは？
コンテンツマップとは何でしょうか？
コンテンツマップは、webサイトを作るにあたり、
制作が必要なページを洗い出し、それをどのように制作するかを定義したもの。
です。
作る目的は、制作スコープの定義です。
コンテンツマップをすりあわせることで、
今回のwebサイトリニューアルで、
- これだけのページが出来上がる。
- これだけの素材準備が必要。
- こういう機能が実装される。
- ここはスコープ外ですよ。
そういうことを明確にするのです。
そして、コンテンツマップとお見積書を確実に対応させます。
ここ、とても重要です。
大事なことなので、もう一度言います。
コンテンツマップとお見積書を確実に対応させることが必要です。
そしてそれをクライアントに提出するタイミングは、制作のかなり初期段階。
概算見積時に作成することが多いです。
最終的には、要件定義フェーズでFIXしている必要があります。
もちろん、企画段階で、ページは増えることはありますし、機能だって増えることはあります。
初期段階でこれを作るメリット、それは
お見積で、何をどこまで想定しているかが明確になること
です。
これを最初にすり合わせておくと、後々妙なトラブルになることがありません。
コンテンツマップで定義すべきもの
では、コンテンツマップにはどのようなものが含まれるのでしょうか。
主なものを紹介します。
1. ページ名・階層
webサイトを構成するページ一覧です。
ページがどこの分類に属するのか含めて定義します。
古いサイトだと、カテゴリトップにあたるページが無かったり、整理してはじめて「このページも必要だね。」ということが分かったりします。
プロジェクトの初期段階だと、個別ページ単位の内容など明言できないこともありますので、同種の情報、例えば、サービス詳細ページや、お客様の声、先輩の声といったコンテンツは「一式」としてまとめてしまって問題ないです。
※必要に応じ、後で触れる「サイトマップ」で定義すれば良いです。ここでは、ボリューム把握が優先です。
2. 素材有無・状態
新規に作るページか、そのまま移行か、既存コンテンツをベースに内容を見直すか、そういうことを定義します。
ページに掲載するテキストや画像の元素材有無です。これがあるか無いかでページ作成工数は大きく変わります。
- 既存のまま移行。
- 内容は既存のまま。デザインだけリニューアル。
- 内容は既存をベースにするが見直す。
- 新規に作る。
これらをコンテンツマップのページ単位で定義しておきます。
3. CMS対応
CMSに対してどのように対応する想定かを定義しておきます。
大きく言うと、以下のようなパターンがあります。
- しない。静的ページでCMS管理下に置かない。
- CMS管理画面でHTMLのコードベタ貼り。
- コンポーネントベース。定義されたパーツを使う。
- 機能化。ページ個別にコンポーネント定義を行う。
- CMS管理のコンテンツを参照する（要は一覧ページ）。
※ここの内容、詳しくはまた別記事で紹介しますね。
要はCMSで更新できるようにします、と言っても色んなパターンがありますよ、ということです。そして、その実装方法で結構コストにも影響がでます。
4. システム対応有無
具体的には、お問い合わせフォーム、資料請求フォーム、製品検索機能など、バックエンドと連携するシステムを指します。
これらは、独自のスクラッチで作るケースもあれば、CMSの機能としてプラグイン提供されていることもありますし、ASPサービスとして、提供されているものを初期費用、月額費用を払って利用させてもらうというケースもあります。
そして、これもその実装方法により費用が大きく変わってくるので、なるべく初期段階での擦り合わせをしておいた方が良いです。
そういう機能って、クライアントも理解が甘いことが多く、「あれ？それ、入ってるものと思ってたけど〜？」って話になりやすい部分です。
デザインとか、見た目の部分に多くの時間を割いてしまった案件などで特に起こりがちです。
5. ページ制作対応レベル
ページ単位でどの程度の労力をかけるか、レベル分けしたものです。
そのレベルごとの単価を定義しておいて、機械的に金額算出するイメージです。
下記のような分類が考えられます。
あくまで例なので参考としてご覧ください。
対応レベルS（トップページ）
トップページのデザイン、コーディングです。
やはりここは、結構時間がかかります。
以降のページのベースにもなるので、デザイナー、コーダー、JavaScriptプログラマーの工数を多めに見積もっておきます。
- 画面設計：あり
- デザイン：あり
- コーディング：あり
- JavaScript：あり
対応レベルA（下層主要ページ）
個別にページデザインを行う下層のベースになるページ群です。ここで、webサイトを構成する要素は一通り揃えます。
- 画面設計：あり
- デザイン：あり
- コーディング：あり
- JavaScript：あり
対応レベルB（下層ページ展開）
個別にページデザインをしますが、基本的には「対応レベルA」で定義したコンポーネントを組み合わせてページを作ります。
ただ、一部、デザイン定義をしておかないと作れないことがあるというページです。
- 画面設計：あり
- デザイン：あり
- コーディング：あり
- JavaScript：なし
対応レベルC（下層ページ展開・ページデザイン作成無し）
ここは、完全にコンポーネントベースのページです。
ページデザインを個別には作らず、画面設計書とコンポーネント定義を元に、コーディングを進めていきます。
- 画面設計：あり
- デザイン：なし
- コーディング：あり
- JavaScript：なし
対応レベルD（単純データ移行、CMSデータ投入）
ここは、ある意味コーダーは不要で、誰でも出来る単純作業を想定します。
- 画面設計：なし
- デザイン：なし
- コーディング：なし
- JavaScript：なし
6. 作成画像パーツ点数
ページごとのおよその画像作成点数を想定しておきます。
画像は、基本、写真の加工、既存の図の成形程度をイメージします。
ゼロからのイラスト書き起こしは、別項目を立てることが多いです。
コンテンツマップとサイトマップの違い
ちなみに、コンテンツマップと似た言葉で「サイトマップ」があります。
その違いは何でしょうか？
コンテンツマップは、
制作範囲の定義とその作り方的な意味合い
が強いように思います。
一方サイトマップは、
仕様定義的な意味合い
が強いように思います。
ただ、最終的には、コンテンツマップとサイトマップは統合しても問題ないと思います。
順番として、
まずコンテンツマップ。
その後サイトマップという流れです。
サイトマップでは、コンテンツマップに加えて次のようなものの定義が加わります。
- URL・ディレクトリ
- リニューアル前のページURLとリダイレクト有無
- ページタイトル
- ページ要約文（デスクリプション）
より具体仕様にあたるような情報です。
【補足】ドキュメントは極力集約する。
web制作においては、さまざまなアウトプット（ドキュメント成果物）がありますが、数を抑え、なるべく集約できるのが理想だと思っています。
そういう意味では、○○マップと呼ばれるものも他にも複数あります。
- コンテンツマップ
- ハイレベルサイトマップ
- サイトマップ
- ディレクトリマップ
- キーワードマップ
あたりでしょうか。
私としては、このうち、コンテンツマップ、サイトマップ、ディレクトリマップの３つは１つのドキュメントに集約すべきと思っています。
クライアントはドキュメントがたくさんあると混乱しますからね。
それが何のために存在するのか、それに対してどういうアクションを取ればよいか、クリアな状態でプロジェクトを進められるのが理想です。
意味の近いものはドキュメントとしては１つにまとめ、その中で、ページを分ける、シートを分ける等で分類することをお勧めします。
理想は提案ありき。その上でスコープを擦り合わせる。
今回はコンテンツマップというものについてまとめてみました。
コンテンツマップを作る目的は、制作スコープの定義です。
一旦定義してしまう。
ということが重要かなと思っています。
何より、そうせざるを得ない一番の理由があります。
それは、
クライアントは予算確保をしないといけない。
ということです。
このプロジェクトに幾ら費用がかかるのか？
それをwebサイトの設計完了後に提示されて、予算をはるかに超える金額だったら、どうしようもありません。
クライアントは発注時には予算確定が必要なのです。
なので、まずは内容と費用を想定してしまうこと。そこがスタートです。
分析やヒアリング、企画設定を通して変わる部分もあるでしょう。
ただ、webサイトの幹になる部分は、大きく変わらないことが多いです。
webサイトのオーナーの企業の事業体系が変わったり、webサイトで紹介するサービスや事業、商品が大きく変わらない限りは。
そこを定義した上で、すり合わせを進めると、あとになってから「あれがない」「こうしてもらえると思っていた」という齟齬が発生するリスクが少なくなります。
もちろん、その初期段階で、「こうあるべきですよね」という企画提案ありきで、コンテンツマップが出来上がるのが理想です。
場合によっては、要件定義そのものをプロジェクト化するということも、可能ならクライアントサイドで検討いただきたいところです。
コンテンツマップとお見積をセットしてプロジェクト初期段階で定義、すり合わせを行う。
これは、プロジェクト成功のための必要条件だと考えます。
