Dyno

CMS を使ったサイト構築の手順

CMS ウェブ制作プロジェクト管理

今回はウェブ制作の発注者側の方に向けて「ウェブサイト構築の手順」について説明します。

今日ウェブサイト構築といえばその 90% 以上は CMS を使った開発になるので、 CMS を使うことを前提にお話をしていきます（あくまで私の観測範囲での認識ですがそう大きく外れてはいないと思います）。

前提

本記事では読者について以下の想定を置いています。

  • ふだんウェブサイト構築に関わっていない経営者やウェブ担当者
  • ただし CMS がどういうものなのかは知っている

ですので、できるだけ業界用語を使わず、 CMS とは何なのかという説明は行わずに話を進めていきたいと思います。

ウェブサイト構築の 4 つの手順

各フェーズの呼び名はさまざまですが、ウェブサイト構築の一般的な手順はおおよそ次のとおりです。

  1. 企画
  2. 設計
  3. 実装
  4. 公開

上から順番に説明します。

1. 企画

最初のフェーズは「企画」です。

「企画」フェーズではウェブサイト構築プロジェクト全体の企画立案を行います。 具体的には以下のようなことを行います。

  • 目的・ CSFs (Critical Success Factors) ・戦略の設定
  • 環境分析
  • ターゲット・提供便益の設定
  • リスクの洗い出しと対策の決定

このフェーズがその後の活動のすべての土台となるので、ここをおろそかにして先のフェーズに進めてはいけません。 プロジェクトを実際に進めてみないと見えてこないこともありますが、大枠の戦略は仮説ベースでよいのである程度固めてからスタートするのがよいでしょう。

変化の速い現代を表すことばに「 VUCA 」ということばがあったりしますが、 ICT とウェブの世界というのはとりわけ変化の速い世界です。 戦略を立案する際に前提とした諸条件が、プロジェクトを進めている間にどんどん変わっていきます。 そのため、戦略立案に関わる企画フェーズは最初に一度行ったらおしまいではなく、プロジェクトをある程度進めた後でも必要に応じて都度やり直す必要があるでしょう。

発注者視点で見た場合には、このフェーズが特に重要です。 なぜなら、いわゆる「ウェブ制作会社」の多くは後の設計や構築のフェーズは得意ですが、この企画フェーズが得意ではありません。 そのため、この「企画」フェーズのレベルや成果物の良し悪しは多くの場合発注者の腕にかかってくるからです。

特に「構築」をサービスの中心に据えているウェブ制作会社の場合、その主な関心事は「指定された要件を満たすサイトを作ること」です。 そもそもの要件設定やさらにその前提となる戦略立案が間違っていた場合、製作会社がいくらがんばって高品質なサイトを作ってくれても、本来の目的を達成することは難しいでしょう。 制作会社の努力を水の泡にしないためにも、最初の企画フェーズが重要です。

また、仮に「企画」フェーズをサポートするコンサルティング会社やマーケティング会社を利用する場合でも、主導権と責任は発注者側が持っているという自覚が必要です。 ウェブ制作のコンサルタントやマーケターはあくまでもウェブ制作のプロであり、発注者のビジネスにおけるプロではありません。 コンサルタントやマーケターが発注者と同じレベルで発注者の環境や業界のことを知っているわけではないので、企画の品質の担保は発注者が行うもの、と考えるべきです。

「企画」フェーズの成果物

「企画」フェーズの一般的な成果物は次のとおりです。

  • 企画書
  • プロジェクト概要説明書
  • 作業一覧表（「 WBS 」）

2. 設計

「企画」の次のフェーズは「設計」です。

「設計」フェーズでは、実際に手を動かしてウェブサイトの構築を行う前に、構築に関する方向性を決定します:

  • 何を作るのか（ WHAT ）
  • 何を使って作るのか（ with WHAT ）
  • どういうアプローチ・構成で作るのか（ HOW ）

システム開発の世界ではこのフェーズは「要件定義」「仕様策定」と呼ばれたりしますが、ウェブの世界ではふんわりした「設計」という呼び方が使われることが多いです。

一般的なシステム開発における「設計」と比較したときのウェブ制作の「設計」の特徴は、機能面での検討が少なくなるかわりに「情報」「デザイン」「コンテンツ」等その他の部分での要件や仕様の決定も必要になるところです。

経営者の方に馴染みのある「戦略」ということばを使うなら、前の「企画」フェーズで行ったのは「プロジェクト全体」の戦略策定でしたが、ここで行うのは「実装」フェーズにおける戦略の策定です（実際は、サイトを公開した後の「運用」フェーズの戦略も決めておくべきですが、今回は「構築」がテーマなので今回はそこには言及しません）。

「設計」フェーズの重要性は一般論でいうところの戦略の重要性に似ています。 ある目的・目標に対応したサイトを作るのにも無数のアプローチが考えられ、採用したアプローチによって、実装フェーズのコストパフォーマンス、中期的に実施可能な施策の幅、運用フェーズの効率等が変わってきます。 さらに重要なことには、方針を明確にすることによって、各担当者への権限移譲が効果的に行なるようになります。

設計フェーズで詰めておくべき具体的なポイントには、例えば次のようなものがあります。

ユーザー面:

  • ターゲット便益の実現のために押さえるべきポイント
  • ターゲットの利用行動モデルの構築
  • 運営スタッフも含めた利用者グループの定義
  • 利用パターン（ユースケース）の洗い出し

情報面:

  • サイト内の情報の構成・配置の設計
  • コンテンツの種類と内容
  • 旧サイトからのコンテンツ移行方針

機能面:

  • 主要な機能と優先順位づけ

デザイン面:

  • デザインにおいて押さえるべきポイント・テイストの決定

技術面:

  • 利用する CMS
  • 利用するサーバー
  • 利用するデータベース
  • その他利用する技術

ここでは社外メンバーも含めたプロジェクトメンバーがすでに決まった想定でお話ししていますが、もしこの段階で制作パートナーが決まっていなければ、ここで「制作パートナーの選定基準の決定」も行うべきです。 構築フェーズで最も重要な CSF は「腕のよい制作パートナー」です。

個人的には、 CMS の選定に迷う時間があるなら、腕のよい制作会社の選定に時間をかけたほうがよいと思います。 なぜなら、プロジェクトの成否に関して言うと、「どの CMS を使うか」で生じる影響よりも「どの制作会社に依頼するか」で生じる影響の方が断然大きいからです。

余談ですが、ここまでの「企画」「設計」のフェーズを「上流」、「実装」以降のフェーズを「下流」と呼ぶ習慣が業界にはあります。 具体的には「私は上流が専門です」といった使い方をします。 この用語は本来の意味である時間的な前後関係を表すだけでなく、「偉い人と下っ端」という意味の「身分の上下」を連想させることもあります（「下流老人」なんて書籍も流行りました）。 実際に「身分の上下」のニュアンスで使う人もいるので（「私は上流が専門です」と言う人の多くは「下流は下っ端がやるもの」と思っています）、発注者側の方は不用意に使わないことをおすすめします。 時間的な前後関係を表すために「上流」「下流」ということばを使いたくなったときは、昔から製造業で一般的な「前工程」「後工程」ということばを使うのがよいと思います。

「設計」フェーズの成果物

「設計」フェーズの一般的な成果物はおおよそ以下のとおりです。

  • 便益実現のために押さえるべきポイントの一覧
  • メインターゲットの行動モデル
  • 利用者グループの一覧
  • 利用方法の一覧
  • サイトマップ
  • 主要ページのワイヤフレーム
  • コンテンツタイプの一覧
  • デザイン方針説明シート
  • 旧サイトから移動するコンテンツの一覧
  • 利用技術の一覧

「サイトマップ」や「ワイヤフレーム」等には共通語として通用する名前が付いていますが、標準的な名前がついていないものが大半で、会社によって呼び方がまちまちです。

当然ですが、必ずしもこれらすべてを成果物として生み出さないといけないわけではありません。 実際のプロジェクトでは、手間・コスト・時間とのバランスを見て、費用対効果の高いものから順に選んで作成します。

3. 実装

「設計」の次のフェーズは「実装」です。

「実装」フェーズでは基本的に「設計」フェーズで定めた方針に従ってウェブサイトを作り込んでいきます。

具体的な作業としては以下のようなことを行います。

  • CMS の立ち上げ・基本設定
  • 確認用サーバーの立ち上げ
  • コンテンツの入れ物となるコンテンツタイプの作成
  • プラグインの導入や独自機能の開発
  • デザイン
  • テーマコーディング
  • 旧サイトからのコンテンツ移行
  • コンテンツの作成と登録
  • テスト

「実装」フェーズの作業は基本的に制作会社が行うことが一般的ですが、発注者はただのんびり完成を待っていればよいというわけではありません。 発注者には実装フェーズに入ってからもやるべき仕事があります。 「企画」「実装」フェーズで定めた方針と実装とが整合しているか、各機能は正しく動作するかといった点は制作会社に任せきりにせず、発注者も確認しなくてはいけません。 デザインカンプを見ての選定、コンテンツ素材の調達やコンテンツ制作等も多くの場合は発注者側が責任を持って行う必要があります。

発注者にとっての「実装」フェーズの最大の注意点は、今日日本においてウェブ制作の契約は「実装」フェーズの前に金額を固定して行う形が一般的ですが ウェブ制作というのは探索的なプロセスであり必ずしも計画どおりには進まない という点です。

プロジェクト規模が大きくなり「実装」フェーズに時間がかかればかかるほど、社会や社内の環境の変化が大きくなります。 その変化に伴って戦略やリスクの認識を見直す必要があります。 加えて、「設計」フェーズで「実装」に関するありとあらゆることを見通せることは稀です。 新しいことに挑戦する意欲的なプロジェクトであればあるほど、「実装」フェーズに入って初めて気づく前提の見落としや新たな制約、取りうるオプションの発見がよく起こります。 発注者側はそんなウェブ制作プロジェクトの特性を理解して「変化にどのように対応するのか」をあらかじめ考えておくことが大切です。

発注者側あるいは双方の責任で実装の手戻り・ロスが発生した場合に、その穴埋めをすべて制作会社にさせるのはフェアではありません。 そんなやり方は短期的にはうまく行くかもしれませんが、そのツケは必ずどこかで払う必要があることを覚えておくべきです。

「実装」フェーズの成果物

「実装」フェーズの主な成果物は次のとおりです。

  • デザインカンプ
  • 公開準備のできた確認用サイト
  • 確認項目のチェックリスト
  • 公開作業のチェックリスト
  • 各種マニュアル

メインの成果物は「確認用サイト」ですが、必要に応じてその他の成果物を適切にチェックすれば、プロジェクトをよりスムーズに進めることができます。

4. 公開

「実装」フェーズが終われば最後の「公開」フェーズに進みます。

「公開」フェーズでは文字通りそのまま、サイトを本番稼働用のサーバーに載せてインターネット上で公開します。 「公開」フェーズでは主に行うことは次のとおりです。

  • サイトの公開
  • 旧サイトからの切り替え
  • 本番サイト上での再テスト・確認
  • その他公開に伴う作業

「公開」フェーズにおける理想は、「実装」フェーズのうちに公開に伴う一式の作業を事前に洗い出してチェックリスト化しておいて、実際の作業はチェックリストに従って機械的に進めることです。 公開作業でやるべきことはタイミングや状況が変わってもそう大きくは変わらないので、事前に完全なチェックリストを作ることができます。 事前にチェックリストを作成し検証することによって、サイト公開によくあるトラブルの多くは未然に防げます。

ちなみに、サイトの公開については「本番化」の他に「カットオーバー」「サービスイン」等さまざまな呼び方があります。 細かなことを言えばそれぞれに違いはありそうですが、ほぼ同じ意味合いのことばと考えて差し支えありません。

公開に際して行うべきその他の作業はサイトによって異なります。 サイトによっては PR 等のリリースや何らかのキャンペーンが必要になるでしょう。 関連するサイトからのリンクの設置やインフルエンサーへの依頼等が重要になることがあるかもしれません。

ここまでプロジェクトが大きな問題なく進んでいれば作業は落ち着いているケースが多いですが、発注者側は、制作会社に任せっきりにせず本番サイトの見栄えや機能、リンク等に不具合が無いか主体的に確認するとよいと思います。

「公開」フェーズの成果物

最後の「公開」フェーズの主な成果物は本番稼働したサイトです。

  • 本番稼働したサイト

ということで、 CMS を使ってサイトを構築する手順についてでした。

終わりに

今回はシンプルな 4 つのフェーズに分けて CMS の構築手順をご説明しました。

  1. 企画
  2. 設計
  3. 実装
  4. 公開

各フェーズの呼び方やフェーズの分け方は無数にありますが、全体のおおまかな流れはおそらくどの制作会社・どのプロジェクトで共通です。

「これからウェブプロジェクトを始めよう」「サイト制作を依頼しよう」という方のご参考になれば幸いです :)

「 SEO に強い CMS 」が嘘である理由
サイト制作の契約時にうやむやにすると後々モメがちなポイント