Dyno

CMS を使ったサイト構築の手順について説明します

2018/04/10

ウェブ業界以外の人とウェブ制作についての話をすると、ふだんウェブ制作に携わっていない方にとってウェブサイト構築という仕事はどのように進めるものなのかいまひとつイメージしづらいものだということがよくわかります。

今回は、ふだんウェブ制作に接していない経営者やマーケティング担当者――いわゆる「発注者」側の方を対象に、標準的な「ウェブサイト構築の手順」についてご説明してみたいと思います。

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

前提

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

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

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

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

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

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

各フェーズについて上から順番に説明していきます。

1. 企画

最初のフェーズは「企画」(キカク)です。

ウェブサイトは上位のビジネス上の目的を果たすためのアプローチ・手段なので、具体的なサイトの内容の検討に入る前に、ビジネス面の企画立案を行っておく必要があります。

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

このフェーズはどちらかというと概念的でつかみどころのない作業のためか、ないがしろにされがちです。 しかし、このフェーズがプロジェクトの成否の最初の分かれ目になるので、しっかりと議論し詰めておくことが重要です。

ここでは少なくとも以下のことを済ませておくのがよいでしょう。

  • a) 目的・ KSF (Key Success Factor) ・戦略の設定
  • b) 上の a) の根拠となる環境分析
  • c) ターゲット・提供便益の設定
  • d) リスクの確認と対策の決定

他の業界でも同じだと思いますが、 ICT やウェブの世界は変化のスピードが速いので、戦略の前提となる「できること」や「やるべきこと」が技術の移り変わりや技術の普及度合いの変化を受けて刻々と変わっていきます。 そのため、ウェブの世界に馴染みの薄い方が環境分析を行って切れ味のよい戦略を組み立てるのはなかなか難しいと思います。 主要メンバーがウェブにあまり強くない場合は、少なくとも 1 人はウェブに詳しい方をプロジェクトメンバーに招き入れるのがよいでしょう。

尚、発注者視点で見た場合にはこのフェーズがたいへん重要です。

「構築」を専門としている多くのウェブ制作会社はこの企画フェーズを得意にはしておらず、その力を発揮してくれるのは「何を作るのか」がおおよそ決まった後のフェーズです。 そのため、この「企画」フェーズは制作会社任せにせずに発注者側で責任を持って詰めておく必要があります。

ビジネス上の成功に直結する上位目的をいっしょに追い求めてくれる希少な制作会社がすでにパートナーになってくれている場合は別ですが、「構築」を中心としたサービスを提供している制作会社の多くは、発注者から持ち込まれた企画にたとえ穴があると感じてもそれを必ず指摘してくれるわけではありません。 「構築」を中心とした制作会社の関心事の中心はあくまでも「構築」であり、その先にある発注者のビジネスの成功はそれとは別問題だからです。

また、「企画」フェーズをサポートしてくれる会社やコンサルタントのサポートを受ける場合でも、企画の主導権と責任は発注者側が持っているという意識を持っておくべきです。 ウェブ制作のディレクターやコンサルタント(私を含む)はあくまでもその道のプロであり、発注者のビジネス領域のプロではありません。 ディレクターやコンサルタントは発注者と同じレベルでその業界のことを知り尽くしているわけではないので、ベースの企画の妥当性は発注者側が担保する必要があります。

(とはいえ、構築の現場やウェブの世界観を知らない経営者や担当者がこのフェーズを進めるのは難しいので、私がこの領域でサービスを提供しています)

このフェーズの成果物

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

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

2. 設計

「企画」が完成した次のステップは「設計」(セッケイ)です。

システム開発の世界ではこのフェーズは「要件定義」「仕様策定」と呼ばれたりしますが、ウェブの世界ではもう少しふんわりした「設計」という呼称で呼ばれることが多いようです。 ウェブ制作の場合は、旧来のシステム開発で重要になる側面の他に「情報設計」「デザイン」「コンテンツ」といったその他の面も重要ですし、設計に含めるべき重要なポイントは年々少しずつ増えて行っているので、おおづかみの「設計」ということばで呼んでおいた方がよい、という考えがその背景にはあるのかもしれません。

「設計」フェーズでは、実際に手を動かしてウェブサイトの構築を始める前に、以下にあげるような開発の大枠の部分を決定します。

  • 何を作るのか ( WHAT )
  • 何を使って作るのか ( with WHAT )
  • どういうアプローチで作るのか ( HOW )

前の「企画」フェーズでは「プロジェクト全体」の戦略を決めましたが、ここでは主に「実装」フェーズの戦略を決めます(実際にはサイト公開後の「運用」フェーズの戦略もここで決めておくべきですが、今回は「構築の手順」がテーマであり「運用」はトピック外ということで今回は割愛します)。

実際にものを作り始める前に「設計」を行うべき理由は、一般論でいう「戦略はなぜ重要なのか」の理由と同じです。 それは 1 つのサイトを構築するのにも無数のアプローチがあり、そして、採用したアプローチによって、ビジネス戦略とのフィット、短〜中期的に取りうる施策オプションの幅、運用フェーズの効率、サイトのライフスパン全体のコスト等々が決まってくるからです。 そして、明確な「設計」方針を作ることで、実装を担当する各担当者に効果的に権限を移譲できるようになります。

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

  • a) ユーザー面
    • ターゲット便益の実現のために押さえるべきポイント
    • ターゲットの利用行動モデルの構築
    • スタッフも含むサイト利用者グループの定義
    • スタッフの利用パターンの洗い出し
  • b) 情報面
    • サイト内の情報の構成・配置の設計
    • コンテンツの種類と内容
    • 旧サイトからのコンテンツ移行方針
  • c) 機能面
    • 主要な機能と優先順位づけ
  • d) デザイン面
    • デザインにおいて押さえるべきポイント・テイストの決定
  • e) 技術面
    • 利用する CMS
    • 利用するサーバー
    • 利用するデータベース
    • その他利用する技術

ここではパートナーも含むプロジェクトメンバーはすでに決まっている想定で話をしていますが、もしこの段階で制作パートナーが決まっていなければ、これらと並んで重要なポイントのひとつに「制作パートナーの選定基準」があります。

次の記事でも述べているとおり、少なくとも技術面においては最も重要な KSF は「優秀な制作パートナーと組むこと」です。

CMS 間の性能の差異よりも制作会社間、技術者間の能力の差の方が大きく、プロジェクトの成否に与える影響は大きいので、そこは他のポイントよりもむしろ優先して決めるべきポイントだと思います。

余談ですが、ここまでの「企画」「設計」のフェーズを「上流」、実装以降のフェーズを「下流」と呼ぶ習慣が業界にはあります。 ただ、この呼称は単純な時間的な前後関係だけでなく「上の身分と下の身分」「偉い人と下っ端」という意味の「上下」を連想させることがありますし、実際そのニュアンスで使っている人も多いので、発注者側の立場の方は使わない方がよいと思います。

「上流」「下流」ということばに慣れることで無意識のうちに「自分たちが上で、制作会社は下」という意識を持ってしまう可能性もありますし、「上流」「下流」という言葉遣いを好まない業界人も一定割合いるため、これらのことばを使うことには無用なリスクがあります。 時間的な前後関係を示す意味でフェーズを切り分けるのであれば、製造業で一般的な「前工程」「後工程」ということばを使うのが無難です。

このフェーズの成果物

「設計」フェーズの成果物は、おおよそ以下のものとなります。

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

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

また、これらをすべて必ず用意しないといけないわけではありません。 実際のプロジェクトでは、手間やコストとのバランスとかけられるコストの額を見ながら、費用対効果の高いものから順に選んで作成するのがよいでしょう。

3. 実装

「設計」が終われば、次に続くフェーズは「実装」(ジッソウ)です。

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

具体的な作業としては、「 CMS の立ち上げ・基本設定」「確認用サーバーの立ち上げ」「コンテンツの入れ物となるコンテンツタイプの作成」「プラグインの導入や独自機能の開発」「デザイン」「テーマコーディング」「旧サイトからのコンテンツ移行」「コンテンツの作成と登録」「テスト」等を行います。

「実装」フェーズの作業の大半は制作会社側で行うことが一般的ですが、発注者はただ完成を待っていればよいかということそんなことはありません。 発注者には実装フェーズに入ってからもやるべき仕事があります。

「企画」「実装」のフェーズで定めた方針と実装が整合しているか、各機能は正しく動作するかといったポイントは制作会社だけでなく発注者も確認しなくてはいけませんし、デザインカンプを見ての選定、コンテンツ素材の調達やコンテンツ制作等も多くの場合は発注者側が責任を持ってやる必要があるでしょう。

発注者視点で見た場合の「実装」フェーズの最大の注意点は、ウェブ制作の契約は現在日本では「実装」フェーズに入る前に固定費で行う形一般的ですが、その一方で ウェブ制作というのは時間がかかる探索的なプロセスであり必ずしも計画どおりには進まない という点です。

時間が経てばビジネス環境や技術環境が変化します。 組織体制や人事体制も変わります。 それに伴って戦略やリスクの認識は見直しが必要となります。

また、「設計」フェーズで「実装」に関するすべてを見通せることは稀で、ほとんどのプロジェクトでは「実装」フェーズで初めて「設計」フェーズの見落としや新たな制約、取りうるオプションの存在に気づくことがあります。

発注者側はそのようなウェブ制作プロジェクトの特性を理解して「変化にどのように対応するのか」をあらかじめ考えておくことが大切です。

(世間ではそれが横行していますが)契約金額の見直しなく「実装」フェーズの作業内容を変えるのは原則 NG です。 金額と作業内容は当然リンクしているので、作業内容を変える場合はそれにリンクした金額その他を見直すというのが最低限のルールです。

どうしても金額が変えられない場合は、制作会社が「固定額の中でやりくりできる」形を作りましょう。 例えば、ひとつの仕様を変更する場合、その仕様に関わる実装がすでに進んでしまっていると、当然その分の手戻り・ロスが発生します。 そのようなときに、そのロス分にふさわしいコスト削減を制作会社が行えるような提案・相談を行うのがよいでしょう。

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

このフェーズの成果物

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

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

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

4. 公開

テスト・確認等も含めて「実装」フェーズが終われば、ようやく「公開」(コウカイ)フェーズです。

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

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

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

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

また、 CMS を利用する場合は、プログラムをそのまま本番稼働用のサーバーに設置するだけではなく、 CMS 内の設定を本番用に変更する必要があるパターンが一般的です。

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

ここまで来ればプロジェクトとしては落ち着いているケースが多いですが、発注者側としては、制作会社に依存せず、本番サイトの見栄えや機能、リンク等に不具合が無いか主体的に確認するのがよいでしょう。

このフェーズの成果物

最後の「公開」フェーズの成果物はもちろん、本番稼働した実サイトです。

  • 本番稼働したサイト

以上が、 CMS を使ってサイトを構築する手順についてでした。

終わりに

今回はわかりやすさを重視して、シンプルな 4 つのフェーズにまとめて CMS の構築手順についてご説明しました。

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

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

暗闇の中どこに向かって進んでいるのかわからないまま歩くのはストレスですが、全体の地図が見えていて向かうべき方向が明らかな環境のツアーは快適です。 ぜひサイト構築の全体を頭に入れて、安心してウェブプロジェクトを進めるようにしてみてください。

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