Dyno

CMS を使ったサイト構築における「設計」とは

CMS

今回は CMS を使ったサイト構築における「設計」 についてお話しします。

「 CMS × 設計 」というと「 CMS そのものの設計」と「 CMS を利用したサイトの設計」の 2 つの意味が考えられるのですが、今回はこのうちの後者「 CMS を利用したサイトの設計 」のお話です。

想定読者

本記事の想定読者は、 CMS を使ったサイト制作の依頼をしたい経営者・ ICT 担当者 の方です。

最近はウェブサイトのおおよそ 8 〜 9 割方は CMS を使った構築になるでしょうし、その意味では、サイト制作の依頼をしたい方全般と言ってしまってもよいかもしれません。

前提

この記事で「 CMS 」というのは「コンテンツマネジメントシステム」の略です。 コンテンツマネジメントシステムは本来はウェブに限定されないソフトウェアの分類なはずですが、この記事では 「ウェブサイトを構築するための CMS 」――英語でいうところの WCMS のことを指して「 CMS 」と呼ぶ ことにします。

では早速本題に入ります。

CMS における設計とは？

CMS 固有のお話に入る前に、一般的な用語としての「設計」について見ていきましょう。 ウェブ制作業界以外の方には、こちらの説明から入る方が理解がスムーズに進むと思います。

まずは辞書的な意味から見てみましょう。 「設計」に相当する英語の「 design 」について、英語の Wikipedia では次のような説明がされています。

Design is the creation of a plan or convention for the construction of an object, system or measurable human interaction (as in architectural blueprints, engineering drawings, business processes, circuit diagrams, and sewing patterns).

意訳:

設計とは、計画やルールを作ることである 。 それは、モノやシステム、人間の計測可能なインタラクションを構築するためのものであり、形態としては、構造の設計図、機械製図、ビジネスプロセス、回路図、型縫い等の形になる。

（強調箇所は私によるものです）

「設計」は英語でも意味の広いことばのようで、ざっくりとした説明がされています。

Wikipedia に書かれている定義をもうひとつ見てみましょう。

"a roadmap or a strategic approach for someone to achieve a unique expectation. It defines the specifications, plans, parameters, costs, activities, processes and how and what to do within legal, political, social, environmental, safety and economic constraints in achieving that objective."

意訳:

（設計とは） ある人が固有の結果を達成するための、ロードマップまたは戦略的アプローチである 。 設計により、仕様、計画、パラメータ、コスト、作業、処理の流れと、その結果を達成する際に、法律・政治・社会・環境・安全・経済等の制約の中で何をどのようにするか、ということが定義される。

（強調箇所は私によるものです）

こちらは先ほどのものよりもわかりやすいですね。

平易なことばでまとめてみると次のようになるでしょうか。

  • 設計とは、特定の 目的 に対して、諸 条件 を考慮した上で、 何をどうするか を決めること。
  • その成果物は 仕様書 や スケジュール表 、 設計図 等であり、それがどれになるかは領域や状況により変わる。

CMS の場合の「設計」もまさにこのとおりです。 つまり、 CMS を使ったサイト構築における設計とは、構築すべきサイトの目的と諸条件を考慮して、 CMS をどう利用してどんなサイトを作るかを決めること です。 CMS やウェブサイトだからといって特殊なことは無く、要は、 設計とは制作における戦略策定の作業 です。

ただし、上の定義で成果物のパターンがいろいろ紹介されていたように、成果物の点では CMS ならではなところがあります。 CMS を使ったサイト構築における「設計」作業の成果物の例をあげてみます。

  • ユーザー面
    • 対応端末 / OS 一覧
    • ユーザーグループ一覧
    • ユーザーライフサイクルの説明
    • ユーザー権限表
  • 情報面
    • サイトマップ
    • ナビゲーションパーツ一覧
    • ページ内のパーツのレイアウト図
    • RSS フィード一覧
    • SNS 連携方針
  • コンテンツ登録・移行面
    • 登録作業方針
    • 移行作業方針
  • 機能面
    • 機能一覧
    • 各機能利用時の作業の流れの説明
    • 各機能に使われるデータ一覧
  • データモデル面
    • ページコンテンツタイプ一覧
    • その他データモデル一覧
  • デザイン面
    • 押さえるべきポイント一覧
    • デザインテイストの説明
    • カラーマップの説明
  • 技術面
    • 利用する CMS
    • 利用する CMS プラグイン一覧
    • 利用するデータベース
    • 利用するサーバー
    • その他利用する技術一覧
  • アクセシビリティ面
    • 対応するポイント一覧
  • セキュリティ面
    • 対応方針
  • パフォーマンス面
    • 対応方針
  • 運用面
    • コンテンツ運用方針
    • コミュニケーション方針
    • SEO 方針
  • 保守面
    • システム保守方針
    • 次期リニューアル方針

「サイトマップ」や「デザイン」等のわかりやすい部分だけでなく、さまざまな側面で設計を行うことができます。 通常のウェブサイト制作でカバーすべき範囲はおおよそこのとおりですが、サイトの性格によっては、他にもカバーすべき範囲があるでしょう。

ポイントは、これらはあくまでも一例であるという点です。 「戦略」が一般にそうであるように、設計の成果物にも「絶対にこれ」というものはありません。 上位の目的や目標の具体性、取りうるオプションの多さ、チームメンバーの熟練度等によって作るべき成果物は異なってきます 。 規模の非常に大きなプロジェクトでは「設計でやるべきこと・作るべきものを決める」という「メタレベルでの設計」が重要になることもあるでしょう。

これも「戦略」がそうであるように、設計で議論すべきポイントの抽象度・具体性のレベルも状況によってまちまちです。 「必ずこれ」という絶対の基準はありません。

あくまでも私の個人的な経験に基づくものにはなりますが、「少なくともこれは作った方がよいだろう」と思えるものは次のとおりです（上のリストからの抜粋です）。

  • ユーザー面
    • 対応端末 / OS 一覧
    • ユーザーグループ一覧
  • 情報面
    • サイトマップ
    • ナビゲーションパーツ一覧
    • ページ内のパーツのレイアウト図
  • コンテンツ登録・移行面
    • 登録作業方針
    • 移行作業方針
  • 機能面
    • 機能一覧
  • 技術面
    • 利用する CMS
    • 利用する CMS プラグイン一覧
    • 利用するデータベース
    • 利用するサーバー
  • セキュリティ面
    • 対応方針
  • パフォーマンス面
    • 対応方針
  • 運用面
    • コンテンツ運用方針
    • SEO 方針
  • 保守面
    • システム保守方針

少し数が多いと感じられるかもしれませんが、これらをピックアップしたのには共通の理由があります。 それは、これらの項目は たとえ設計フェーズで決めなかったとしてもどこかのタイミングで遅かれ早かれ決める必要がある というものです。 このあたりに関して適切な議論を経ないままに制作作業が進められることがよくありますが、このあたりはきちんと話し合って決めた方が断然よいと考えます。

サイトが公開されたときにはいずれにせよ決まっているところなので、うやむやのうちに制作担当者の裁量で決められてしまうよりも、きちんと議題としてあげて意思決定をしておいた方が、上位の目的や目標の達成度・達成確率は断然高くなるでしょう。

この設計作業の成果物については、別の記事でも取り上げています。 興味のある方はぜひそちらもご覧ください。

定義に関してはこれ以上の深掘りはしませんが、「 CMS = ソフトウェア 」「ウェブサイト = 情報の集まり」「ウェブサイト = メディア」という見方をすると、 CMS を使ったウェブサイト構築の設計とは「ソフトウェア設計」や「システム設計」「情報設計」「ユーザ経験設計」といったさまざまな領域の設計の寄せ集めと考えることもできます。 英語の Wikipedia には各種「設計」のページがあるので、より深掘りしたい方はそちらをご覧になってみてください。

CMS を使ったサイト構築における設計がどういうものなのかはおおよそおわかりいただけたかと思います。

続いて、 CMS を使ったサイト構築において「設計をすると何がよいのか」という設計の「メリット面」について見てみたいと思います。

CMS における設計のメリットとは？

CMS を使ったサイト構築における設計のメリットには次のようなものがあります。

直接的メリット

プロジェクト単発での直接的メリットは次のとおりです。

  • 上位目的・目標の達成
  • 要件の充足
  • 開発効率の向上
  • 運用効率の向上
  • コストの低減
  • リスクのコントロール
  • メンバー間の情報共有

上で Wikipedia の定義を通して見たとおり、要は「設計≒戦略」なので、「戦略を立てることのメリット」がそのまま「設計」のメリットということになります。

まず、上位目的や要件との論理的な矛盾をチェックし整合性を高めることによって、要件が充足できる可能性が高まります。 その結果、大元の上位目的や目標の達成確率も上がります。

構築方法や運用方法に関してオプションがいくつもある場合は、実際の制作作業に入る前に、どれがベストな方法かを見極めることで、より効果的・効率的なオプションを選択できる確率が上がります。 発注者側は当然制作のプロではありませんし、一方の制作担当者も発注者のビジネスのプロでは無いので、それぞれの知識・認識には限界があります。 いきなり制作に入るのではなく、設計フェーズでこれらの知識・認識を持ち寄ることで、よりよい意思決定を行うことができます。

制作や運用のフェーズにおけるリスクについても、実際に始まってから把握するのではなく、あらかじめ見通しを立てて大枠の方針を決めておくことで、実際にリスクが発生した際によりよい対応をよりよいタイミングで行えるようになります。

チーム規模・金額・期間等の点でプロジェクトの規模が大きくなればなるほど、これらのメリットは大きくなると言うことができるでしょう。

間接的メリット

プロジェクト単体ではなく、中長期的な視点から見たメリットとしては次のようなものがあります。

  • メンバーの教育
  • ナレッジの蓄積

プロジェクトメンバーの教育や組織のナレッジの蓄積がより効果的・効率的に行えるという点も、「設計」のメリットと言えるでしょう。

特に、発注者側の視点で言うと、サイトの構築やリニューアルの機会はそう頻繁に経験できるものではありません。 サイトを一度構築したら次のリニューアルは 5 〜 8 年後、ということもよくあるので、数をこなして経験を積むということがなかなかできません。

その意味で、 CMS 選びやサイトの構成に関してきちんと議論してその成果を文書としてまとめておくことが、とても大きな価値を持ちます。

このあたりはウェブ以外の領域では当然のことかもしれませんが、ウェブ業界は新しいこともあって業界歴 10 年未満という人が大半ということもあり、制作会社側にもこのあたりの思想・文化を持っている会社はあまり多くないように思います。

このあたりについては特に、制作会社に任せっきりにするのではなく、発注者側が価値を理解して率先して進めることが重要です。

きちんと設計をした方がよい場合とそうでもない場合

CMS を使ったサイト構築における設計とは何か（ WHAT ）、そして、そのメリットは何か（ WHY ）というところを見てきました。

では、 CMS を使ったサイト構築における設計はどんなときでもじっくり綿密にやればよいのでしょうか。 私は、そうともかぎらない、と思います。

例えば、次のようなケースでは、綿密な設計を行う時間が十分になかったり、時間を割いてやったとしてもそのコストに見合った価値が得られなかったりするでしょう。

  • プロジェクトの規模が小さい
  • 探索・実験が必要である
  • コスト・費用対効果の感覚がゆるい

プロジェクトの規模が小さい : チーム・予算・期間等の点でプロジェクトの規模が小さい場合は、設計フェーズはそこそこにして、制作担当者に一任するのがよい（せざるを得ない）こともあるでしょう。 その際に重要なのは、制作担当者に一任しても大丈夫かどうかの判断をすることです。 担当者の経験や判断材料が十分でない場合は、十分な経験を持つ人に代わりに担当してもらうようにする、十分な経験の人にサポートに入ってもらう、十分な判断材料を提供する、等の対応を行う必要があります。

探索・実験が必要である : ウェブのプロジェクトではわりと多い気がしますが、構築するサイトやサービス・参入する市場・リスクに対して組織やチームが十分な知見・経験を持っていない場合もあります。 そのようなときは、設計フェーズにいくらリソースを注いでも成果物の品質が上がってこないため、探索的・実験的にプロジェクトを前に進める必要があります。 このタイプの活動の必要性に関しては、近年「デザインシンキング」「プロトタイピング開発」という言葉が有名になり日本でも認識が広まってきた感じがします。

コスト・費用対効果の感覚がゆるい : コストや費用対効果に対する感覚がゆるい場合も、設計フェーズはあまり重要でないことがあるでしょう。 PDCA サイクルやビジネスレビューの文化・習慣が無いような組織や、身内だけで経営をしている組織等の場合は、コストや費用対効果について議論することがあまり効果を持たないこともあるでしょう。 そのような組織では、設計のメリットに対する認識が十分に共有できない・伝わらない可能性があるので、設計をきちんとやるかどうかは単に担当者の好みの問題です（個人的にはこれはよいとは思いませんが、現実にそういう組織はたくさんあると思います）。

逆に、これらのケースにあてはまらない場合（≒ほとんどの場合）は、設計はある程度の時間をかけて行った方がよいでしょう。

設計を綿密に行ってみると、実際に構築されたサイトを見る前に判断できる意思決定ポイントがいかに多いかに気付かされるはずです。

まとめ

以上、 CMS を使ったサイト構築における設計とはどんなことなのか、そして、そのメリットは何なのか、どんな場合にきちんと設計をした方がよいのか、というポイントをご説明しました。

設計≒戦略策定なので、戦略の価値を十分知っている方には特に目新しい情報は無かったかもしれませんが、 CMS やサイト制作ならではなポイントについて何らかのヒントを得ていただけたなら幸いです。

CMS ベースのサイト制作の発注を検討している方・発注の準備をしている方はぜひ参考にしてみてください :)

今更聞けない？「 CMS 」とは？
「 SEO に強い CMS 」が嘘である理由