論理的デザイン

C

H

A

P

T

E

R

18

論理的デザイン
POINT

論理的デザインのコンセプト
論理的デザインのためのテクニック
論理的デザインから導き出される成果物
論理的デザインに関与してほしい人々

すべての要件を集め終えたら、特定の CMS 製品には依存しない（または論理的な）デザインに着手し、情報をどうやって収集、管理、発行すれば良いかを厳密に定義していくことになる。この Chapter では、論理的デザインを構築するのに使えるいくつかのプロジェクトテク
ニックと成果物について概説する。

ノート
この Chapter は、要件収集とデザインの背景となるプロジェクトプロセスを扱う。実際に要件収集とデザインを行う際に考慮すべきことについては、Part4（デザイン・構築編）の「CMSをデザインする」で扱っている。

1. 論理的デザインを始めるにあたって
このセクションでは、CMS の論理的デザインをするために必要なことをまとめている。論
理的デザインとそれが必要な理由、複雑さの中でデザインを実施するためのテクニック、組
織内の人々にその結果を伝える方法について説明する。
このセクションは、詳細な説明を省いたまとめとして読むか、この Chapter をすでに読んでいて CMS の論理的なデザインをするために必要なことのチェックリストが欲しいという人に、復習として読んでほしい。
論理的デザインを行うには、次のようなステップを踏むと良い。
１．チームメンバーが集まり、これからの仕事に向けた組織作りをする。
・デザインプロセスの一部として作成するドキュメントについて話し合う。各ド
キュメントに何を含めるべきか、どのように詳細を取りまとめるのかといったこ

411

Chapter18とを事細かに決める。どんなツールを用いるのか、スプレッドシート、XML スキー
マ、または収集するコンテンツの管理に使うデータベースなどを明確にする。
・各デザインドキュメントを作成するのに用いるプロセスを決める。特に、各々のデザインドキュメントを完成するのにどれくらいの繰り返しを必要とするのか、また繰り返しの作業それぞれを通して何を達成したいのかを決める。また、制約をどのように設けるのか、特に、デザインに関する制約事項を見極めるために実施することになる、三角測量の範囲について決めておく。
２．チームで議論して決定したことを、アプローチ、ツール、そしてプロセスについて詳述
した「デザインアタックプラン」としてドキュメント化する。
３．これからの仕事に向けて、適切な人材が揃っているかについて検討する。もし必要ならば、デザインを実行するために必要な追加スタッフを見つけ出して確保する。
４．計画作成後には、情報を集めて分析し、デザインドキュメントを作成する。ドキュメ
ントには、以下のことが含まれていなければならない。
・収集デザイン。ここで、収集システムとプロセス、つまり、執筆者、取得情報源、
コンポーネントの作成と変換、必要な人材を規定する。
・管理デザイン。ここで、論理的デザインの管理システムとプロセス、つまり、コン
テンツスキーマ、アクセス構造、コンテンツのライフサイクルプロセスを規定する。
・発行物デザイン。ここには、戦略ドキュメント、ページデザインファイル、パーソ
ナライゼーション計画、そしてアドミニストレーション用ドキュメントが含まれる。
・オーディエンス分析。ここで、組織の全員に、いまデザインしているシステムでリーチしようとしている相手は誰なのかを伝える。
・ローカライゼーション計画。ここで、どのくらいの範囲でコンテンツをローカラ
イズするか、および設定するローカライゼーションのレベルを決めるのに必要なプロセスとシステムについても記述する。
・リスク評価。ここで、論理的デザインや実装計画、スケジュール、または予算の変更が必要になる可能性を持つ問題や状況、不測事態への対応に関して言及する。
５．デザインドキュメントで確認したリソース、成果物、
制約事項の必要性などに基づいて、プロジェクト計画を見直す。
６．デザインドキュメントをできるだけ少ないページに簡約したエグゼクティブサマリー（要旨）を作成する。
７．デザインドキュメントの承認を得る（または、必要に応じて改訂版を作る）。特に、委任書にある項目が予算内で収まるように、あるいは組織が望む期間内で終わるように、規模を調整する。
以上のことが終わったら、ハードウェアとソフトウェアを用いた実装について決定を行う
プロセスに進むことになる。

412

論理的デザイン

2. 論理的デザインとは何か
要件収集を終えるころには、CMS をどのようにデザインすべきか、なぜそのようにデザインするべきなのかについて、他の人からたくさんのアイディアを得ていることだろう。次は、あなたがそれに答える番だ。論理的デザインでは、これまでに判明したあらゆるゴールと要件を、CMS がどのようにしてかなえるかを決めていくことになる。
私は、論理的デザインという用語を、この後で扱うことになる物理的デザインと対比させるために使うことにした。物理的デザインでは、CMS を実際にハードウェアやソフトウェア
を用いて構築する際の仕様と計画をまとめる。論理的デザインでは、特定のプラットフォー
ムによる制約の外でシステムを作り上げていく。論理的デザインを他の用語で言い換えると、「プラットフォームに依存しないデザイン」と言い換えることができる。なぜ、そのようなことをする必要があるのか。ここで、2、3 の理由を挙げる。
CMS は、ハードウェアとソフトウェア以上のものを含んでいる。例えばコンテンツは、ハードウェアでも、ソフトウェアでもない。
「どうやって実現するか」を決める前に「何を実現したいか」を明確にすることが大切だ。
システムを作った後に、結局それが望んでいたものでなかったと気づく以上に、時間の浪費となることはないし、またそれは、関係者が今後のキャリアを築いていく上での妨げになる恐れもある。
CMS を構築する際に、どんなハードウェアとソフトウェアが必要なのかを判断するための情報が必要になる。どんなプラットフォームが必要なのかを決めるための一番良い方法は、
そのプラットフォームに何をしてほしいかを知ることだ。すでに CMS を持っていたとしても、たくさんのボタンを押し始める前に、そこで何を得たいのかを明確にしておくべきだ。
論理的デザインは、大きいパズルのようなものだ。それぞれのピースは、執筆者、情報源、コンポーネント、発行物等に関連する要件から収集した情報の破片だ。作り上げようとしている収集、管理、発行プロセスなどが、完全で美しい 1 つの絵になるようにそのピースをすべて繋ぎあわせなければならない。もし 1 つのピースが合わなければ、すべてが折り合うまで
他のピースを再編成していかなければならない。時には当てはまらないものを取り除く必要もあるかもしれない。
論理的デザインは、次のように、プロセス、リレーションシップ、構造をもたらす。
プロセスをデザインする。それは、コンテンツを収集し、管理し、発行することである。
例えば、すべての発行物の発行サイクルに合わせるには、特定の種類のコンテンツをどのように正しい頻度で収集するべきか考える必要がある。
システム内での主要なプレイヤーとのリレーションシップ作りを行う。そして、そのプレイヤーたちが互いに支え合い、高め合えるような関係を築くようにする。例えば、執筆者に対して、発行物テンプレートをうまく使うことで、様々なオーディエンスに向けたコン

413

Chapter18

あなたの論理的デザイン
論理的デザインは、システムで何をしたいのかを明確にしてくれる。物理的デザインとはそのシス
テムを築き上げるための必要なパーツを組み合わせることである。物理的デザインと論理的デザインの関係は、次に挙げるような多くの他の状況の中でも見ることができる。
コンピュータ自体は、チップ、ディスクドライブ、それにたくさんの配線による、物理的デザインを持つ。同時に、論理的デザインも持っている。特定の入力（コンピュータの中央演算処理装置に現れる 1 と 0）に応じて、コンピュータは特定のアクションを実行し、特定の出力を生じるようにデザインされている。コンピュータの物理的デザインは、それ自身の体系と内部のロジックでソフトウェアを「実行」することができる。
スーパーマーケットは、棚、床、天井やその他のたくさんの商品による、物理的なデザインを持つ。
また、論理的デザインも持っている。それは商品を発送センターから買物かごまで移動させるシステムだ。スーパーマーケットの物理的なデザインは、「スーパーマーケットの人が」あなたに一番買って欲しい商品の方へ、あなたの体と目を動かすようにするための販売促進機能を「実行して」いる。
あなたの脳は、ニューロン、ホルモンや多くの接続による、物理的なデザインを持つ。そしてまた、論理的デザインも持つ。ニューロン群は、特定の機能をつかさどる機能的な領域を形成する。そして、その機能的な領域は、さらに複雑な機能を実行するために集合体になっている。さらにより高いレベルで、脳の物理的なデザインは、それ自身の体系とロジックを持つ意識と思考プロセ
スを「実行して」いる。
すべての場合において、物理的デザインは論理的デザインに影響を与えるが、それを決定することはない。論理的デザインは、物理的デザインが持つ広範な制約の中で起こる。論理的デザインは、物理的デザインの境界の外では何もできない。しかし一方で、論理的デザインは、物理的デザインを越
えて動くことはできる。例えば、私はワープロで書くことができる。書くことは、コンピュータの物
理的なデザインの一部ではない。CMS では、システムを構成するハードウェアとソフトウェアは、あなたがコンテンツや発行物を作ることを可能にする（が、それを決定することはない）。
物理的デザインだけ、論理的デザインだけ、というものは存在しない。スーパーマーケットにある個々の棚やニューロンもまた、物理的デザインと論理的デザインを持っている。実際、コンピュータや脳のような面白いシステム内には、無数のレベルのデザインが存在する。CMS においては、物理的デザインはハードウェアとソフトウェアからできているが、それら自体の内部に論理的および物理的デザインが存在する。
論理的デザインは、システムが存在するための本当の理由だ。論理的デザインを存在させるために、
コンピュータ、スーパーマーケットそして、（おそらく）脳の物理的デザインがそこにある。CMS にとっても同じことが言える。寄稿者、コンポーネント、それに発行物の論理的デザインが必要だ。そして、それを可能にするコンピュータとネットワークの物理的デザインが必要だ。

テンツタイプに対処してもらう方法などを考え出さなければならない。
コンテンツ構造をデザインする。コンテンツ構造は、配信することになっている情報を完全に反映していなくてはならないし、また、その管理を自動化させるのに十分なメタデータ
を含まなければならない。例えば、伝えたいと思っている情報を組み立てるためのコンテ
ンツタイプ一式を作り出したり、また配信自動化のための管理データを付け足したりする。

414

論理的デザイン

このプロセスの最後の方になると、他の人からの指示を受けて仕事をしていたころをな
つかしく思うかもしれない。あるいは、もしあなたが私のようなタイプの人間であるならば、このプロセス、つまり、試行錯誤しながら非論理的なものを論理的で効果的なフレー
ムワークに収める作業をすることに、とてもやりがいを感じるかもしれない。

3. 仕事を終わらせるテクニック
このセクションでは、論理的デザインを学んで実践するために役立つテクニックを紹介する。その中には、ビジネスゴールから実際のシステム作りへとどう進めたらいいのか、そのプロセスを通してどのようにして繰り返していけばいいのか、デザインのいろいろな面をどのようにして均等にバランスよく組み立てるといいのか、これまでに収集した膨大な詳細情報をどのように管理すればいいのかといったことが含まれている。
論理的デザインとは、CMS を機能させるために使う特定のハードウェアとソフトウェアに依存しない CMS のデザインだ。これは、論理的デザインは正しいシステムを選ぶ際に役立たない、あるいは、これが結局インストールすることになるシステムによって用いられないということを言っているのではない。実際、論理的デザインは役に立つ。論理的デザインは何をすべきかを明確にしてくれるし、特定の CMS はその対処方法も示してくれる。
以下に、考慮すべき論理的デザインの側面について挙げる。
オーディエンス分析

これは、どんな顧客をターゲットにしていくかを詳述するものだ。

Chapter 25（デザイン・構築編）「オーディエンスを列挙する」では、オーディエンス分析について完全な詳細を知ることができる。
発行物デザイン

ここでは、各々の発行物がどんなコンテンツとナビゲーションを含むのか、また、それらは CMS によってどのように構成され、自動的にパーソナライズされるのかについて定義する。Chapter 26（デザイン・構築編）「発行物をデザインする」では、発行
物デザインについての完全な詳細を知ることができる。
コンテンツタイプのデザイン

ここでは、管理することになる完全なコンテンツタイプ一式と、それぞれが厳密に、どのように組み立てられるかを明らかにする。Chapter 27（デザイン・構築編）「コンテンツタイプをデザインする」で、コンテンツデザインについての完全な詳細を知ることができる。
執筆者分析

ここでは、どのコンテンツに対してどのような執筆者を必要とするか、そしてどのように彼らを支援していけばいいのかを判断する。Chapter 28（デザイン・構築編）「執筆者に対応する」においては、執筆者分析についての完全な詳細を知ることができる。
情報源分析

ここでは、どこから情報を取得するか、また CMS で扱うためにはその情報源をどのように処理すればいいかを判断する。Chapter 29（デザイン・構築編）「取得情報源に対応する」では、情報源分析についての完全な詳細を知ることができる。
アクセス構造デザイン

ここでは、コンテンツを組織化してレポジトリ内に保持するた

め、また発行物で用いるナビゲーションを生成するために必要となる、階層やその他のア

415

Chapter18

クセス構造を定義する。Chapter 30（デザイン・構築編）「コンテンツのアクセス構造をデザインする」では、アクセス構造分析についての完全な詳細を知ることができる。
ワークフローとスタッフィングのデザイン これらデザインは、CMS を立ち上げて実際に運用していくために必要な職務（ジョブ）やタスクの種類や数について明確に示すためのものだ。Chapter 33（デザイン・構築編）の「ワークフローとスタッフィングモデルをデザインする」では、ワークフローとスタッフィングの分析についての完全な詳細を知ることができる。
これらの多様な分析やデザインは、それぞれが孤立しているものではない。むしろ多くの点で重なり合って互いに情報を与え合っている。

リファレンス
Chapter 23（デザイン・構築編）の「コンテンツマネジメントの車輪」では、これらすべての分
析についての概要と、それらがどのように影響し合っているかについての説明がある。

3-1. なぜ論理的デザインをするのかほとんどの人々は、自分たちが CMS を完全に定義するために蓄積しなければならない情報
量を、過小評価する傾向にある。事実、多くの組織が CMS の要件を定義する段階を完全に無視し、購入してある何らかのソフトを使って、自分たちが今持っているのと似たようなページを作ろうとしている。
あなたの期待に反するかもしれないが、私は、そのようなアプローチが悪いとは思わない。
システムをいじってみて、それでどんなことができるかを実験し、組織が何を必要としているかを探る長大な時間を持てるのであれば、そのような手法はとても良い始め方だ。CMS についての基本的なことを教えてくれるし、実際のツールを用いて実用的な経験を与えてくれる。
一方で、現在のように数ページを生成することができるシステムから、包括的なページ生
成と配信のプロセスを体系化できるシステムへ変えるのであれば、そこには大きな飛躍がある。最も良い CMS を見つけて、それを使いえさえすれば後者のようなプロセスが起こるだろう、と期待してはいけない。しかし、CMS を使って得た経験は、結局行わなければならない論
理的デザインを行ううえで役立っていくだろう。
いくつかの組織は、ツールを買ってすぐに分析を始める。何度も同じようなことを言うが、これでもうまくいくこともある。特定の製品による制約をプロジェクトのプロセスにすぐにあてはめることによって、CMS ベンダーが提供する多くの方法とツールを使い始めることができる。そのうえ、すぐに結果を出し、すぐに画期的な目標を達成するかもしれない。一方、
もしよく知らないまま購入してしまうと、大きなリスクを払うことになるかもしれない。つまり、システム（おそらく、非常に高価なものだろう）を購入してしばらく使っても、そのシステムがニーズに合わないものだと気づくだけになるかもしれない。結局、本当に何を欲しているのかを知る前にツールを選んでしまうと、それを無駄にしてしまうことがあるわけだ。

416

論理的デザイン

たとえ、そのツールが組織にとって「なにがしかの」価値があったとしても、そのツールが役に立たないということだ。
私がこれまでに示したステップをたどっているなら、随分たくさんの時間がすでに費やされているに違いない。また、人々が必要とするシステムに関して、多くの詳細な情報を入手していることだろう。準備評価と委任のプロセスの間に収集されたもので、システムを定義するために十分そうだと見えるかもしれない。そうかもしれないが、おそらくそうではないだろう。これまで収集したものは確かに、人々が何を望んでいるのかを明確にしているだろうが、組織が必要としているものをきちんと定義しているだろうか。少なくとも、それらの要望を整理して増補し、組織の各部門の人々に、その結果が完全であることに同意してもらわなければならない。おそらく好調なスタートを切っていて、多くの様々なことを得ているだろうが、システムデザインの基礎を築くのに必要な詳細なことがらに関しては、十分な準備はできていない。
もし論理的デザインを行うにあたって疑問が生じているとしても、次のようなことに大変役立つのは間違いない。
システムの選択

論理的デザインをするということは、CMS を使って何をしたいかを明確にすることだ。すでにどんな CMS パッケージにするかという考えがあるのならば、計画を行うチームは、選択したシステムとデザインの適合度合いを判定するのにそのデザインを使用することができる。まだシステムを選択していなければ、そのデザインは、欲しいと思っている明確なシステム像を示してくれるだろう。そのシステム像と製品ベンダーから提示されたシステム像を比較することができる。また、CMS ベンダーに知的な質問をして、なめらかなプレゼンテーションにひどく惑わされることもなくなるだろう。最終的に、もし、独自仕様のシステムを開発することを選ぶなら、論理的デザインはソフトウェ
アの要件仕様に多大なインプットを与えてくれる。
システムの実装

CMS を実装するためには、一連の仕様を作成することになる。仕様は

何をしたいかということと、どのようにしてそれを実現したいかということを結びつける。
論理的デザインは何をしたいかを示す。構築したり購入する CMS の特徴や機能は、どのようにしてそれを実現するかということだ。何をしたいかという明確な考えを持っていないときは、使用する CMS の特徴と機能が決めてくれるだろう。論理的デザインは、シス
テムに管理してほしいコンテンツと発行物の光の中に見られる特徴と機能を確かなものにすることで、仕様に現実性を加える。
システムの公開とメンテナンス

論理的なデザインは、システム配備時に必要なたくさんの成果物のために、正しいスタート地点を提供しなければならない。例えば、論理的デザ
インは CMS に貢献するスタッフについて詳細を描き出す。そのスタッフは、システムが配備されるときに必要な人々と同じである。加えて、ユーザをトレーニングしたり、システ
ムをメンテナンスする際に必要となるドキュメントのほとんどは、論理的デザインの成果物から直接得られるものだ。

417

Chapter18

3-2. ビジネスからシステムへ
私はプロジェクトのこのフェーズを、ビジネスゴールの階層、委任時の宣言文、および一連の要件から始まることを想定している（これらの項目が関連するさらなる情報については、
Chapter 16「プロジェクト委任を確保する」の「4. 成果物を検討する」のセクションを参照）。
ここでは、デザインへと進んでいくために、これらのゴールと要件を用いることができる。
図 18-1 は、ビジネスゴールの階層を示すものだ。またこの図は、委任宣言文が体系化された
ビジネスゴールの頂点に置かれ、また、同様にコンテンツ領域宣言文は発行物とコンテンツ

委任宣言文
ゴール階層

コンテンツ階層

領域宣言文

ビジネス

コンテンツタイプ協議されたゴールタイプの頂点に置かれるということを示している。

コンテンツ

図 18-1：ビジネスゴールの階層は直接コンテンツの階層につながっている。そして、それは 1 組のコンテンツタイプに至る。

「この目的を達成するためには、どんな情報と機能を提供する必要があるだろうか？」という質問に答えるならば、
委任宣言文は、コンテンツ領域宣言文として言い換えることができる。
そして、1 つの領域宣言文から、その領域（コンテンツ階層）にあるコンテンツの種類のアウ
トラインを作り始めることができる。このようにすることで、委任のプロセスにおいて得たビジネスに関する知識から提供すべきコンテンツに関する知識に、自然に軸を変えて見ることができるようになる。

リファレンス
Chapter 30（デザイン・構築編）「コンテンツのアクセス構造をデザインする」の「2-2. コンテ
ンツ領域」のセクションで、コンテンツ領域宣言文についてさらに詳しい内容を得ることが
できる。

ヒント
コンテンツ階層を構成するときは、人々が配信しようとしているコンテンツについて、すでに知っていることにあまり影響されないようにしなければならない。委任宣言文から領域宣言文へと厳密に進めることができるのなら、何がシステムに含まれているかを評価するため、独自の方法を持つことになるだろう。自分が作ったアウトラインと、人々が要件の中で求め418

論理的デザイン

たものの間に見られる矛盾が役に立つ。それを使って、コンテンツ階層、領域宣言文、および委任宣言文を（もし勇気があれば）さらに練り直すと良い。そうすれば、提案された要件がな
ぜそこに含まれていないのか、自信を持って述べることができる。
良いコンテンツ階層を持っていれば、どんな種類のコンテンツタイプが必要になるかを決めることができる。しかし、これは単なる始まりにすぎない。というのは、デザインプロセ
スを通して、常にこのコンテンツタイプのリストが確認され、修正されていくからだ（コンテンツタイプにに関するさらなる情報は、Chapter 27（デザイン・構築編）「コンテンツタイプをデザインする」を参照）。大まかに言うなら、階層の各ノードの終端（子ノードを持たないもの）
が、可能性のあるコンテンツタイプとなる。
コンテンツタイプの仮のリストがあれば、実際の仕事に入ることができる。配信すべきだということが分っているコンテンツと収集した要件から、コンテンツを収集、管理、発行する要件

コンテンツ階層

コンテンツタイプ

コンテンツ - 発行 - システムために利用するシステムのデザインに取りかかることができる。（図 18-2）

オーディエンス
分析

発行物
デザイン

執筆者と
情報源分析

コンポーネントデザイン

どのようにして収集するか？

どのようにして管理するか？

どのようにして発行するか？
スタッフと アクセス構造
ワークフロー分析 デザイン

制約
図 18-2

デザイン

システム

要件とコンテンツ階層は、デザインを始めるためのスタート地点だ。

独自に作成したコンテンツ階層とこれまでに収集した要件は、デザインを始めるためのス

419

Chapter18

タート地点だ。この 2 つに折り合いをつけてやっと、システムの論理的デザインを綿密に実行し始めることができる。論理的デザインは、CMS にしてほしいことに関する無数の質問に答える。デザインのなかで、その答えをいつもの 3 つの分類、収集、管理、発行に体系化することができる。
お分かりのように、ここでたくさんのことが起きている。ビジネスゴールからコンテンツ
タイプの仮のリストまでは、喫茶店で 1 枚の紙の上にすべてができあがる。しかしながら、コンテンツタイプの仮のリストから最終的な段階へ、そして必要とするシステムまで行くのは、別の話である。システムを実装し始める前に、オーディエンス、発行物、情報源、スタッフィ
ング、ワークフロー、そしてコンポーネントを管理するアクセス構造についてより多くを熟知する必要がある。
そんなに膨大な量の仕事があると聞いても、誰も驚かないはずだ。この仕事は単なるとら
えがたく分かりづらいものではないということが、私がここで示した概要を読むことで理解できるようにと願っている。デザインの細かい作業に入っていく前に、このダイアグラムを念頭に（あるいは手元に）置いておくといいだろう。

3-3. デザインを繰り返す
必要な分類の量と、実際に対処可能な分類の量の間には、明確な分け目は何も存在しない（例えば、オーディエンスは 3 つの分類、9 つの分類、それとも 27 の分類に分けるべきだろうか？）。率直に言って、CMS に対する取り組みかたを洗練し改良していくことは永遠に続き、いつまでたってもその仕事が完了したと感じ始めることは決してないだろう。Part4（デザイン・構築編）の「CMS をデザインする」では、最終的には理解しなければならないデザインの基準すべてに関する総覧を提示する。これらすべての制約を一度に理解しようとしても、結局は不完全な分析のまま、泥沼にはまり、混乱して、時間の無駄になってしまうに違いない。
その解決策は、前回よりも内容が深まり、完全なものに近づいてきたと感じるたびに、何度も同じ制約を用いて照らし合わせてみることだ。仕事の予定時間をオーバーしてしまった時にはそのすべての制約について確認する時間がないかもしれないが、その解決策を試みることで、すべての領域において均一で完全な量の詳細を得ることになる。言い換えれば、そのつど深めながら繰り返して、制約事項に取り組んでいくことだ。一連の、デザインの繰り返しを行うスタート位置として、5 回分（5 パス）の繰り返しのプロセス例をここで取りあげる。
パス 1 ̶
̶ プレロード（前処理） デザインの各分類（オーディエンス、執筆者、発行物など）の概説を作るために、これまでに集めたすべてのドキュメントとメモを見直す。たとえば、アナリストによって「およそ 30 人の執筆者がいる。そのすべての執筆者は組織内にいる人間だ」ということが分かるかもしれない。こういった説明書きを作り、推測するしかな
いような知識とのギャップがないか注目することで、最善の判断に用いると良い。
パス 2 ̶̶ ファーストカット（荒加工） Part4（デザイン・構築編）の「CMS をデザインする」において、私が提示したたくさんの質問から、3 つまたは 4 つ程度の質問を選ぶ。これは、自分たちが主要な問題に対して十分だがハイレベルの理解を持っているという確信を420

論理的デザイン得るためであり、それぞれの分類において答えを出すようにすると良い。例えば、パス 1
で得た 30 人の執筆者を、その人たちの実践的な知識とチームへの親密度に応じて分類してみる。2、3 日以内にそれらの質問に対する良い答えを得て、短くてもいいので、包括的なデザインレポートを作成する。そのプロジェクトのステークホルダーと自分たちが同じ土台にいるかどうかを確認するために、そのレポートについての即座のフィードバックを得る。
パス 3 ̶̶ 詳細のデザイン Part4（デザイン・構築編）で提示されたそれぞれの分類を、
詳細なデザインについての制約で埋め始める。最もすばやく答えを得るための最も重要な質問事項に優先順位を付け、最優先の質問事項から始める。そして、詳細は最重要な事
項から、重要でない事項まで次々と並べられる。このパスをより小さな単位に分け、この取り組みをさらに体系化するために、その 1 つひとつに締め切りを設ける。回答が減ってきたとき（この時点ではさらなる努力を続けることは無意味である）に、このパスは終わる。
パス 4 ̶̶ 三角測量 1 つのデザインの制約は他のすべての制約から離れては存在できない。しばしば、互いに矛盾する制約を、やむを得ず再考することで、おそらく分析をより深めることになる制約を見つけるだろう。これは良いことだ。1 つの制約を他の制約と戦わせることによって、そのすべての制約をもっと強力で矛盾のないものにできるということだ。このパスにおいて、デザインのそれぞれの種類が互いにどう影響しあうのかということに気づくことになる。三角測量に関するさらなる情報は、この次のセクションを参照してほしい。
パス 5 ̶̶ 完成

このパスでは、承認を得て、決定するためにすべての制約事項（そろそろ、かなり大規模なものになっているかもしれない）を 1 つずつ順番に検討する。しかしながら、おそらくこのプロセスをたどっている間に、プロジェクトはデザインと仕様の工程の前方に向けて進んでいることになるだろう。

3-4. 制約についての三角測量
地形上のある地点の正確な場所を知るために、測量士は三角測量をする。測量士はまず最初に、1 つの位置からその地点の方角を測定し、次に、異なった位置からその地点の方角を測定する。2 つの位置の間の距離を測定した後に、問題の地点の正確な位置を示す三角形を描くことができる。もし、より正確なものを求め、確認したい場合には、2 つ以上の位置を使うことになる。より多くの位置から測定をすれば、ターゲットとなっている地点の確実な位置
がよりはっきりする。
作成し、管理しなければならない正確なコンテンツタイプを見つけるためには、図 18-3 にあるように、異なった視点からそのタイプを見ることができる。例えば次のようなことだ。
１．収集した要件の視点からコンポーネントを見る

執筆者はどんな種類のコンポーネン

トを作成することができるだろうか。自分たちはどんな種類のコンポーネントを取得
できるか。

421

Chapter18

２．管理要件のレンズを通してコンポーネントを見る

コンポーネントを保管用にアーカイブする、あるいは削除すべき時期についてどのようにして判断するのか。それらにはどんな索引と保管要件があるだろうか。
３．発行物の有利な点からコンポーネントについて調査する それぞれのページにはどんな種類のコンテンツを載せるべきだろうか。オーディエンスはどんな種類のコンテンツを期待するだろうか。パーソナライズするために知る必要があるものは何だろうか。

コンポーネント

収集要件

発行要件

管理要件
図 18-3：コンテンツタイプを定義するために多くの方法を使えば使うほど、そのコンテンツタイプがすべての必要な要件を満たしていることが、しっかりと確信できるようになる。

多くの視点からターゲットにしている同じエンティティを扱うことによって、すべての部分について説明できるようになる。もちろん、同じ概念はシステムの他の部分でも機能する。
例えば、私は、コンポーネント、オーディエンス、およびその情報源の視点から発行物を見ることによって、三角測量できたかもしれない。これはどんな組み合わせでも応用できる。

422

論理的デザイン

三角測量、あるいは、より適切に呼ぶならば相互相関は、単なる興味深いエクササイズ以上のものである。つまり、それはシステムの要件とデザインを確固としたものにするための方法だ。

リファレンス
Chapter 23（デザイン・構築編）の「コンテンツマネジメントの車輪」では、私が「エンティティ」と呼び、CMS 内で相互相関していなければならない様々な視点について、より完全な像を示し出すことができる。

3-5. 詳細を管理する
デザインを完全に膨らませた時に、何百ページ分ものデータがでてきていても驚かないでほしい。それぞれのコンテンツタイプ（数十のタイプを持っているかもしれないが）に対し、エレメント、エレメント値、情報源、目的、オーディエンス、そのコンテンツが出現する発行テンプレート、そのコンテンツにアクセスするようなパーソナライゼーションについて詳述す
るのに、3 ページか 4 ページを必要とするかもしれない。25 のコンテンツタイプに対して、すでに 100 ページになる。
情報量は、たくさんの方法で同じ情報を切り取っていくことができるという事実によって増えていく。例えば、コンテンツタイプを詳述している時は、オーディエンスについて言及する必要がある。しかし、オーディエンスについて詳述している時には、ターゲットとされるコンテンツタイプに言及する必要がある。その組み合せは非常に多くなる。すべての情報を明確にするために、私はいろいろなワープロシステム、スプレッドシートとデータベースを使用する。しかし、XML ほど役に立ったものはなかった。私の現在のバージョンでは、考えられるありとあらゆるデザインの制約を XML スキーマで整理している。制約についての種類
間のリレーションシップ（例えば、オーディエンスとコンポーネント間のリレーションシップ）
は、XML エンティティ間のつながりとして指定される。そのシステムは以下のようなことを可能にしてくれる。
入力した制約がすべて集まる中心地を持つ
制約そのものだけでなく、制約間にあるリレーションシップを扱う
制約を見つけ、それを並び替える
カット＆ペーストしなくて済むような方法で、制約とそのリレーションシップを分けておく
きちんとした書式のレポートを作成する
私のアプローチはあなたにとっては、特にプロジェクトの始めの時期では、行きすぎかもしれない。しかし、このプロセスの最後には、私がリストアップしたものと同じニーズのすべてが必要になると心にとめておいてほしい。だから、あなたが制約事項を入力して、その経過を追うために用いるシステムがどんなものであっても、そのニーズは変わらない。

423

Chapter18

4. 成果物を検討する
論理的デザインプロジェクトの基礎を作り上げるためには、次の成果物を用いると良い。
デザインアタックプランのチャートは、論理的デザインプロセスの進め方を示す。
収集、管理、発行デザインドキュメントでは、広範囲な論理的デザインプロセスの結果をまとめる。
オーディエンス分析の結果では、組織からのコメントや承認を得るための、選ばれたオー
ディエンス一式を表す。
ローカライゼーション計画は、組織の理解と承認を得たローカライゼーションに対して、最も実用的なアプローチと考えられる内容を示す。
リスク評価とプロジェクト計画。以前開発したこれらの成果物を、要件収集と論理的デザ
インプロセスに基づいて更新し、さらに深めることができる。
エグゼクティブサマリーは、組織に情報を伝え、組織から引き続き援助を受けるのに役に立つ。
以下のセクションではこれらの成果物について詳しく記述していく。

4-1. デザインアタックプラン
論理的デザインをうまく開発してドキュメント化するには、たくさんの作業が必要だ（論理的デザインのためにたくさんの Chapter を費やしたのはそのためである）。要件収集の計
画を立てる時には、2、3 のスプレッドシートで終わった。一方、デザインの計画を立てる時には、持っている中で最も優れたプロジェクト管理ツールを用いることを勧める。要件収集が終わるまでは、プロジェクトは比較的小さくて済む。一方、デザインが始まると、爆発的に大きくなる。それは、詳細事項および詳細事項同士のリレーションシップの数が、論理的デザイ
ン中のプロジェクトの仕事量を膨大なものにしてしまうためである。
論理的デザインでは、早い時期に情報を体系化しておくことが望ましい。そして、プロジェ
クトの最後まで「そのやり方を維持する」べきだ。体系化の欠如は、プロジェクト内のこのフェーズを長引かせることにつながり、また、プロジェクト全体の後工程になってから悩ましい問題を浮上させるような、詳細事項やリレーションシップの内容の誤りを引き起こす恐れがある。
デザインアタックプランで主に扱うことは以下の通りだ。
収集と管理の方法収集した詳細情報をどのように集めて、管理するか。この Chapter の

最初のほうで言及したように、もし、データベースか XML システムを一緒に入手できれば、努力が報われるだろう。
収集を支援してくれる人

424

誰が情報を集めて、処理するのを助けてくれるだろうか。明ら論理的デザイン

かに、要件を提供した人たちが、ここでも助けてくれるだろう。しかし、すでにこのプロジェクトのためにかなりの仕事をこなし、他に多くの責任を持っている人々をあてにしないように注意する。もし、これ以上スタッフがいないのであれば、もう 1 人雇う必要があるかもしれない。
データ収集時期の調整

どのようにデータ収集とその処理を行う時期を調整するか。ほんの一例としていえば、発行物からコンポーネントへと逆行して作業することは、コン
ポーネントから発行物へと作業を前方に進めていくのと同じくらい有効だ。どちらの場合であっても、コンポーネントと発行物が最後に完全に結び付けられていることをどのようにすれば確認できるだろうか。これを理解するための方法として、三角測量と繰り返しのテクニックを既に説明した。計画書では、繰り返しをするということだけでは十分ではない。それぞれのサイクルがどれほど長くなり、そして、それが正確に何を達成することなのかを明確にしなくてはならない。
何を成果にするか

私はデザインの成果物に対する一般的な枠組みをここで提示するつもりだが、それをしっかりした計画に変えるのは、自分次第だ。
膨大な量の仕事への対処方法

最初に、詳細事項の情報量が自分たちを圧倒するようなものであることを知っておく。作業を前に進めても思っていたようにうまくいかない時に、要求されたコンテンツと発行物に対する期待をどのようにリセットしていくだろうか。
時間を使い果たしてしまい、そのような状態になってしまうまで待たないようにしなければならない。
私は、デザインプロセスで達成すべき重要なマイルストンをすべて示し出すような、プロジェクト・ガントチャートを使用することを好んでいる。（図 18-4）

発行物
素材の送付



クライアントの回答期間
クライアントの回答期限
IA の分解と整理
ミーティング

ドラフト作成図 18-4： ガントチャートは、デザイン作業中に整理することと目標に焦点を置くことを助けてくれる。

チームと組織にとって最も都合が良いように、ボリュームの大きい論理的デザインドキュ
メントを 1 つ作るか、あるいは、小さなボリュームのものをたくさん作って「一式」として用いることができるようにすると良い。すでに想像していると思うが、私はその情報を、収集
デザイン、管理デザイン、発行デザインの 3 つのパートに分けて説明できるように整理しておく。

425

Chapter18

4-2. 収集デザインドキュメント
収集システムを論理的にデザインするには、コンテンツが CMS の外部から発行物として使用する準備を終える場所まで移動する方法を決め、それをドキュメント化しなくてはならない。
執筆者は誰かそして、その執筆者を CMS とどうつなげていくのか。（詳細は Chapter 28「執筆者に対応する」を参照）（デザイン・構築編）
取得情報源とは何か

また、それを CMS とどうつなげていくのか。
（詳細は Chapter 29（デザイン・構築編）「取得情報源に対応する」を参照）
作られるのはどんなコンポーネントかそれぞれのコンポーネントはどの執筆者と情報源によって、またはどれくらいの頻度で作られるのか。（詳細は Chapter 27（デザイン・構
築編）「コンテンツタイプをデザインする」の「7-2. 計画」のセクションを参照）
どんな変換プロセスが必要か

情報のフォーマットと構造を変えるためにはどんな変換プロセスが必要か。（詳細は Chapter 27（デザイン・構築編）「コンテンツタイプをデザインする」の「7-2. 計画」のセクションを参照）
どんなスタッフが必要か

情報収集のためにはどんなスタッフが必要になり、またそのタスクとプロセスはどんなものになるだろうか。（詳細は Chapter 33（デザイン・構築編）の「ワークフローとスタッフィングモデルをデザインする」を参照）
これらのトピ ッ クについて考えるべきことを判 断するために、参 考として提 供した
Chapter 内の情報を用いることができる。ドキュメントの構成だけでなく、オーディエンスについても考えなければならない。まず最初に、関わるスタッフがそのドキュメントを読みたいと言うだろう。だから、そのドキュメントは各スタッフの役割別に、その責任範囲をはっきり識別できるようなセクション構成になっていなければならない。次に、仕様書を書く役
割の人は、収集システムのセットアップ方法を理解するためにこれを読みたいと考えるだろう。だから、機能性単位（例えば、執筆ツール、変換システム、情報源の取得手順など）にしたがって情報を分けておくほうが良い。最後に、このドキュメントはシステム選択プロセスへのインプットとして利用される。だから、選択プロセスに含まれるべき情報も取り入れる必要がある。
もしあなたが、CMS デザインの作業上、まさに様々なことを節約するために CMS を使いた
いと考え始めているのなら、正しい方向に向かっていることになる。

4-3. 管理デザインドキュメント
管理システムを論理的にデザインするには、コンテンツタイプに対するアプローチを決め、それをドキュメント化する必要がある。このデザインには次のような基本的な情報が含まれる。

426

論理的デザインコンポーネントについての情報

ここには、どのコンポーネントを生成するか、それらに対してどのようにしてメタデータをタグ付けするかといったことが含まれる。私はこれを「コンテンツスキーマ」と呼ぶ。
コンポーネントを列挙し、そこにアクセスできるようにする方法についての情報 ここには、システムがコンポーネントを追跡して発行する際に用いるための階層構造と索引が含まれる。
CMS レポジトリの中で、そのコンポーネントを管理する方法についての情報

ここには、

コンポーネントのライフサイクルを通じていかにそれを追跡し、最終的に撤収するかが含まれる。

4-3-1. コンテンツスキーマ
コンテンツスキーマは、コンテンツをタイプに分け、タイプをエレメントに分割する。このスキーマについて詳しく説明すると次のようになる。
タイプ

管理されるタイプ。

エレメント

それぞれのタイプに対する一連のエレメント。ここにはコンテンツエレメ

ントと管理用エレメントそれぞれ両方が含まれる。
許容値

各エレメントに対して許容された値。

共有されるエレメントのサブセット

これは、多くのコンポーネント間で一貫した名称を保つために、用いられる。例えば、デモ用のイメージに必要なあらゆるコンポーネントに対して、「イラスト」と呼ばれるエレメントを設けることになるかもしれない。
ユニバーサルなエレメントのサブセット これは、すべての（もしくはほとんどすべての）コンポーネントの間で共有され、それらにアクセスし、管理するのに使われる。例えば、
コンポーネントのライフサイクルを追跡できるようにするために、すべてのコンポーネン
トに対して「ステータス」エレメントを設けることになるかもしれない。
コンテンツスキーマを構築するためには、すべての部分を説明できるようになるまで、情報を分割して整理しなければならない。そうすることで、自分で自信を持ってエレメント、
管理エレメント、タイプからなる有用なシステムのことを語れるようになる。

リファレンスコンテンツスキーマについてのさらなる詳細は、Chapter 27（デザイン・構築編）「コンテンツタイプをデザインする」の「7. コンテンツタイプを分析する」のセクションを参照してほしい。
スキーマについて述べるためには、コンポーネント、エレメント、そしてその値についてドキュメント化する必要がある。スプレッドシートかワープロの資料で十分かもしれない。この方法を用いる際の課題は、同じ情報を異なったやりかたでどう扱っていくかということだろう。後のプロセスでの使いやすさに配慮するために、エレメントのみならず、コンポーネントによって分類された情報を伝えたいと思うかもしれない。これは厄介だが、スプレッド

427

Chapter18

シートのアプリケーションを使えば可能である。しかし、ワープロではかなり面倒だ。このような理由で、私は、情報のコンポーネント視点とエレメント視点を簡単に切り替えられる
ようなデータベース、または XML アプリケーションを使うことにしている。
コンテンツタイプがコンテンツマネジメントプロセスの中心であるように、コンテンツス
キーマは論理的デザインプロセスの中心である。これは、コンテンツスキーマがデザインの他の部分まで大きく影響していることを意味する。だから、そのスキーマがすぐに分かり、同じ状態でとどまるとは期待しないでほしい。むしろ、そのスキーマはゆっくりと理解できるようになり、論理的デザインの全プロセスを通じて変化していく。そして、その変化は実装プロセスを通じて（たとえ極めてゆっくりでも）進化していく。システムが動き始めた後になってからも、情報に関するマーケットのニーズの変化に応じて、そのスキーマが変化していくことを予想しておいたほうが良い。その時点では、もちろん、あなたの仕事はデザインをすることでなく、メンテナンスをしていくことになっているはずだ。
コンテンツスキーマは、システムを実装するために使うスキーマと、システム配備のために作成するメタデータ編集ガイドのスタート地点になる。

ノート
もし、レポジトリにリレーショナルデータベースを用いるのなら、このスキーマをデータベー
スのデザインとしてシステムを実装する人に渡すことができる。もし、XML システムを使う
なら、XML の DTD（Document Type of Deﬁnition 文書型定義）あるいはスキーマとして、これを渡すことができる。

4-3-2. コンポーネントアクセス
CMS の論理的デザインにおける重要な仕事は、コンポーネントを正確に列挙する方法を明らかにすることである。それは、コンポーネントを見つけて発行物のナビゲーションを自動的に生成するために用いられる。

リファレンス
アクセスデザインの概念と実践については、Chapter 30（デザイン・構築編）「コンテンツのアクセス構造をデザインする」で詳しく述べてある。
管理デザインドキュメント内のこのセクションがなければ、コンポーネント階層を作ることができない。階層とは、管理するコンポーネントのすべてを分類するためのアウトラインである。この階層を作成することによって、すべてのコンポーネントがまとまって 1 つのア
クセスシステム内に収まることが確認できる。この総合的なコンポーネント階層が、どのようにして各発行物の階層にマッピングされるかを示すことも同じように大切だ。もし、シス
テムが複数の言語でコンポーネントを生成しなければならないのなら、この階層内に各バージョン間の関係を示すことができる。
また、管理デザインドキュメントの中に、次のセクションを含むことができる。

428

論理的デザイン

用語索引

膨大な量の用語を考え出すことよりも、最初に用語のリストを作り、そのマスターリストが今後どのようにして（いつ、誰によって）できあがっていくかを決めるほうが重要だ。また、そのマスターリストを用いることになるすべての発行物の索引に変換する
方法を決めなければならない。
クロスリファレンス体系

ここでのポイントは、クロスリファレンスを作成することではなく、むしろ、クロスリファレンスがいつ必要になるか、それをどのように作るか、各発行物上でそれをどう記載していくのかといったことに関する全体方針について決めることにある。
シーケンス体系

繰り返すが、今はコンポーネントのシーケンスを作成するのに適切な時期ではない。そのシーケンスをどのように表現するのかについての方針を決めることだ。

4-3-3. コンポーネントアドミニストレーション
論理的デザインの最中にコンポーネントのスキーマを構築することに加えて、それらがレポジトリにある間、コンポーネントに応じて特定されることになるスタッフ、プロセス、タス
クについて決め、ドキュメント化する必要がある。次のようなことがこれらのプロセスに含まれる。
編集作業についての定期的なレビュー
メタデータ編集作業についての定期的なレビュー
アーカイブの手順バージョン管理の手順
削除の手順

リファレンス
これらの確認と手順についての詳細は、Chapter 33（デザイン・構築編）の「ワークフローとスタッフィングモデルをデザインする」の「6-2-2. スキルとタスクをジョブにまとめる」のセクションで述べている。
この成果物の形式は自由に決めてかまわないが、論理的デザインの別の部分としてドキュメント化する、スタッフィングやワークフローのドキュメント形式と合わせる必要がある。

4-4. 発行物デザインドキュメント
発行物デザインは、収集デザインや管理デザイン以上に手間がかかる。なぜなら、各発行
物には独自のインターフェイス（本でさえ、紙のインターフェイスがある）があり、ビジュア
ルデザインがあるため、CMS での作成が望まれるたくさんの種類の発行物については言うまでもなく、CMS を使って作成する 1 つの発行物をデザインするのでさえ多くの労力を必要とするはずだ。

429

Chapter18

ノート
CMS以外の分野（例えば、グラフィックデザイン、
ブランディング、体裁の調整、ルック&フィールなどといったもの）にある発行物デザインに関するプロセスやアドバイスは、
私の専門外だ。
その代わりに、直接 CMS によってもたらされる発行物デザインの部分に焦点を当てる（例えば、CMSの外で作成されたブランディング用エレメントを、CMSによって作られた発行物ページにどのように配置すればいいのか）。
発行物デザインでは、CMS によって作成するように求められている発行物のページを定義し、そのプロトタイプを作る。発行物デザインのゴールは ､CMS から効率的に作り出すことができる最上の発行物を生み出すことだ。理想的には、発行物デザインは収集デザインある
いは管理デザインと同時期、あるいはそれより前に着手されるべきだ。収集デザインと管理
デザインは、発行物の裏で実行可能なシステムを確実に作り出すことを保証し、発行物デザ
インはそのシステムが説得力のあるアウトプットを確実に産み出すことを保証するものだ。
発行物デザインからの成果物は、収集および管理デザインプロセスから生じる少量のファイルと比べて、より多くのファイルになる。この成果物は以下を含む。
発行物戦略ドキュメント

これは ､ どのように発行物全般を取り扱って使っていくのかについて記述するものだ。
ページデザインファイル

これは ､ 詳細事項のレベルが上がるに従って、ページをどのような見栄え、あるいは構成にするのかについて定義するものだ。
パーソナライゼーション戦略ドキュメント

これは ､ パーソナライズされたコンテンツをどのようにターゲットし、配信していくのかについて示す。
発行物アドミニストレーションドキュメント これは、立ち上げ時、そして運用段階に入った際に誰が発行物を作成していく必要があるか、どんなタスクを遂行しなければならない
か、どれくらいの頻度で遂行されなければならないかを示す。

4-4-1. 発行物戦略
それぞれの発行物はそれ自体の制約とデザインを持った独自の世界をもっているが、作り出す発行物のセットは統一したものである必要がある。個々の発行物がどのようにして全体として組み合わせるべきかについて考え出すために、これらの成果物を作り出すと良い。
コンポーネントから発行物への分析

このドキュメントは ､ 各コンポーネントについて、

CMS レポジトリ内での中立的な状態から、様々な発行物の表現に至るまでを追跡する。または、各コンポーネントが最終的な発行物でどのように使用されるかを把握して、何の矛
盾もないことを保証する。このドキュメントのコアは、発行物、ページ、コンポーネント間のリレーションシップをまとめた大きな表（ワープロ、スプレッドシート、または望ましく
はデータベースから出力されるレポート）である。

430

論理的デザイン

テンプレートデザインドキュメント

このドキュメントは、発行物テンプレートに至るまでの総合的なアプローチについて説明する。ここでは、別々の発行物用のテンプレートのためのセクションだけでなく、発行物間の共有部分や共通点に関する考察も含む。発行物
仕様に関するセクションには、静的なテキスト、コンポーネント、各ページのテンプレートに含まれるべきナビゲーションテンプレートと同様に、使用されるページテンプレートの名前のリストも含まれる。最後に、このドキュメントは、すぐにコンテンツにアクセスし、また、それを組み立てるためにテンプレートが含めることになるロジックの定義について記述する（テンプレートデザインに関する詳細は、Chapter 31（デザイン・構築編）「テンプ
レートをデザインする」の「3. テンプレートを分析する」のセクションを参照）。

4-4-2.ページデザイン
ページデザインは、発行物のページの見た目、レイアウト ､ 構成を扱う。CMS に最も影響を与えるこのプロセスの成果物は ､ 以下のようなものである。
ページワイヤーフレーム これは、コンテンツが入るボックスでできたページの概略図だ。
ワイヤーフレームは、ページの様々な部分に名前を付け、全体的な配置やサイズを示す。
単純化と詳細の省略化が行われているため、作成しようとしているページの概観を把握するための発行物デザインの最初のステップとして、一連のワイヤーフレームを作るのは良い考えだ。（図 18-5）
ページモックアップ

これは、完成したページの絵であり、最終的なページがどのようなものかを伝えてくれる。ときに「カンプ」と呼ばれるこの絵は、実際の制作の労力を経ることなしに、発行物のページの典型的な例を示してくれる。ただし、そのページモックアップが、あるタイプのページに現れるコンテンツの多様性を適切に反映しているかは確認しておくべきだ。
ページプロトタイプ

実際の発行物のメディアを使って作成されるページモックアップである。例えば、HTML のプロトタイプは対応するページモックアップと同じに見えるかもしれない。しかしながら HTML プロトタイプは、最終的なサイトがまさにそうであるように、実際にブラウザ上で確認できる一方で、ページモックアップは単なる 1 枚の画像であるにすぎない。デザインがうまくいくことを実証するために、また、ページ上に現れるコ
ンテンツの可変性をテストするために、ページプロトタイプを使うことができる。例えば、
特定のタイプのページ上に 1 から 10 のコンポーネントを含める場合は、最終的なページが常にきちんとした見栄えになるように、素早くプロトタイプのページにコンポーネントを付け加えたり、またはそこから取り除いたりすることができる。論理的デザインプロセスの一部として作り出すプロトタイプのページには、通常は、いかなるロジックも他の CMSのプロミングコードも含まない。それらは、対象となる環境でページが表示されるのを確認するために、単にそこに存在するだけだ。

431

Chapter18

図 18-5：ブラウザを使った環境でウェブページ内のエリアの位置とサイズを示す、単純なワイヤー
フレームの例

リファレンス
ページデザインについてのより多くの事例と情報については、Chapter 31（デザイン・構築編）「テンプレートをデザインする」の「2. 発行物とテンプレート」のセクションを参照してほしい。

4-4-3. パーソナライゼーション戦略
たとえ、最初は数組のオーディエンスしかいなくても、唯一の発行物が静的なウェブサイト
であっても、パーソナライゼーションへの取り組み方を学び、ドキュメント化していく価値がある。このアプローチには次の成果物が含まれる。
メッセージング戦略 このドキュメントは、ハイレベルでオーディエンス、発行物、およびコンポーネントを一体化する。それぞれのオーディエンスが各発行物から何を得ることができるようになるべきか、どのコンポーネントと発行物デザインの機能が、オーディエン
スに情報を伝えるために使用されるかを定義する。これはパーソナライゼーション分析
に対するハイレベルな前置きとなるものである。特に外部のオーディエンスを対象とする発行物に対しては、パーソナライズをすることにおけるマーケティングに関する周辺情報を提供する。内部向けの発行物に対しては、メッセージング戦略は、どのタイプの情報
が各オーディエンスにとって適切かを明確に特定する（メッセージング戦略についての詳
細はChapter 26（デザイン・構築編）「発行物をデザインする」の「2-4.メッセージ」
のセクショ
ンにある）
。
パーソナライゼーション戦略

このドキュメントは、厳密に、各発行物においてどのようにパーソナライズをしたら良いのかについて詳細に述べたものだ。発行物、ページ、オー
ディエンス、コンポーネントによる各組み合わせに対するパーソナライゼーションのルー
ルについて言及する。このドキュメントのコアはパーソナライゼーションのルールにある。
ルールは、把握しているユーザとコンポーネントの管理エレメントの値を基にして、CMS

432

論理的デザイン

レポジトリからどのようにしてコンポーネントを取り出せばいいかということを指定する。さらにルールは、発行物のページにどのエレメントを表示すべきか、またどのようにしてそのコンポーネントを配置すれば良いかについても示す。（詳細は Chapter 32（デザイン・構築編）「パーソナライゼーションをデザインする」の「3. パーソナライゼーションを分析する」のセクションを参照）

4-4-4. 発行物のアドミニストレーション
もし、同じコンテンツベースに依存している複数の発行物があるのなら、各発行物に求められるコンテンツやスタッフの関心を得ることを確認するために、すべてのスケジュールと依存関係の調整をすることはとても重要だ。さらに、CMS の論理的デザインの一部として、必要となるスタッフィングとワークフローを決定し、ドキュメントにすべきである。CMS の発行物アドミニストレーションを行う際に作成することになるドキュメントは次のようなものである。
発行物マスタースケジュールは、発行物が依存するコンポーネントのみならず、それぞれの発行物の公開期日案を示す。このスケジュールを使うことで、コンポーネント収集と管理のワークフローが、それぞれの発行物が発行されるまでに終わっていることを確認できる。また、2 つの発行物がコンポーネント完成スケジュール上で、矛盾する制約を発生させないことを保証しなければならない（詳細は Chapter 33（デザイン・構築編）の「ワークフローとスタッフィングモデルをデザインする」を参照）。
発行物スタッフィングとワークフロー計画は、発行物のプロセスに必要となりそうなジョ
ブ、タスク、ワークフローについてのアウトラインを示す（詳細は Chapter 33（デザイン・構築編）の「ワークフローとスタッフィングモデルをデザインする」を参照）。

4-5. オーディエンス分析
オーディエンス分析は、もともと論理的デザインの一部である（Chapter 25（デザイン・構
築編）「オーディエンスを列挙する」ですべて説明している）。私は、オーディエンスについて収集したデータや、そのデータが他の分析とどう折り合うのかということに加えて、オーディ
エンスについての特定の成果物を作ることは良いアイディアだと考える。その理由は以下の通りだ。
視点

オーディエンスについて導いた結論はそのプロジェクトを行う際に常に最優先されるべきであるし、また組織の他の人とその同じ視点を共有しておくべきだ。組織の構成
員には CMS を通して支援する人たちのことを第一に考え、それから自分たちの視点について考えてもらうのが望ましい。
目的

多くの組織に対して、中心となるオーディエンスが誰なのかを簡潔に述べることは意義がある。もし、組織の中で、現在のオーディエンスについて意見の食い違いがあった

433

Chapter18

り、異なったオーディエンスをターゲットにしている場合は、ドキュメントでそのことを明確にしたうえで、公式に承認されたことの 1 つとして扱われなければならない。他の人は、自分たちでオーディエンス分析を行う際に、このドキュメントを利用するか、少なくてもここから方向性を得ることができる。
用途

組織内の人々は、リストそのものの存在だけでなく、収集したオーディエンスに関する情報が、たとえ非常に有効なものではないにしても、少なくとも興味深いものであることに気づく。もし、これが良い仕事であれば、繰り返し発生する同じ調査にかかる費用
から組織を救うことになるだろう。
フィードバック

もちろん、情報は両方に流れる。オーディエンス分析の結果を（きっと、もっと魅力的な名前で）公表して宣伝することで、自分たちがオーディエンスについて知っている以上のことを知っている隠れ専門家からはもちろん、競合相手からもフィードバッ
クを導き出すことができる。
ほとんどの組織では、オーディエンス分析の作業は、真っ先に行われるはずだ。オーディエ
ンス分析以外の分析はある程度焦点が絞りやすいし、これほど綿密なものも求められない。
ここで行う分析は、CMS プロジェクトに大きな力を供給するために、広く、かつ徹底的なものでなければならない。一方で、このプロジェクトの成功は、ここで実施するオーディエンス分
析の結果次第とも言えるため、競合する計画案によるつまらない攻撃からこれを保護しなけ
ればならない。ここで実施した分析がきちんと周知されて支持されれば、他の計画の発議者
は単に自分の計画を支持するだけではなく、この計画に挑戦するために自分の計画の長所を立証しなければならないだろう。
結局、あなたは組織のマーケットのセグメントを定義するような人物になるつもりはない
はずだし、自分の計画と矛盾しているオーディエンスの定義によって制約を受けるのも好ましくない。CMS の発議に対して、組織内の支持者による継続的な判断や調整を得ることができるような、1 プレイヤーであることが好ましい。もし、他の誰かが過去に実施した良い分析
結果を手渡してくれるなら、あなたの仕事は少量で済むはずだ。さらに、CMS の知見を加えることで、他の人が行った分析内容はより深まり、よりはっきりと理解しやすいものになる。

4-6. ローカライゼーション計画「ローカライゼーション」は、コンテンツに対して、それを見る人々の背景にある多様な文化に合わせて理解しやすいものにするためのプロセスである。ローカライゼーションは、CMSの論理的デザインに求められる、重要な要件だ。なぜなら、コンテンツを生成するための執筆、管理、発行プロセスを、言語、地域、考慮して対応しなければならない関係者たちに向けて、理解しやすいものにすべくデザインしなければならないからだ。
コンテンツや発行物のローカライゼーションは難しい。うまく動かすことができないシス
テムの予算の桁を増やすことにもなりうる。極めて効率的なシステムのためであっても、ロー
カライゼーションはスケジュールを引き伸ばし、予算を巨額なものにしてしまう。ローカラ
イゼーションへの期待は、非現実的なほど大き過ぎるか、またはずっと小さ過ぎるかの傾向に434

論理的デザインある。もし、ローカライズすることを計画しているなら、何がいつ必要になるということについて、筋道の通った推測を行ったうえで実施することがとても重要である。

リファレンス
Chapter 25（デザイン・構築編）「オーディエンスを列挙する」の「4. オーディエンスとローカ
ライゼーション」のセクションにローカライゼーションについての完全な説明がある。
論理的な分析はローカライゼーション計画を作成し、公開するための良い機会である。それについての良い情報を得るには十分な時間が経過しているし、それを実装する計画を協議して決定するには早すぎる。
また、ローカライゼーションに関する要件がシステムのデザインに重要なインパクトを与えるという理由からも、今がローカライゼーション計画を作成する理想的な時期だといえる。
理想的な CMS は、最高水準のローカライゼーションを得るためにそれほど大量な仕事を要求しない。言い換えれば、ローカライゼーションのゴールは、ここでデザインされた CMS が、コンテンツを簡単にローカライズできるような柔軟性を持つと確認することだ。ローカライ
ゼーション要件の範囲の広がりは、組織にとってのローカライゼーションの重要度合いに大きく影響を受けながら、システムのデザインを促進する。対応しなければならないコンテン
ツ量や言語の数といった定量的な指標だけでなく、その複雑性や深さといった側面からも検討されなければならない。
ローカライゼーション計画のコアは、対処したいと考える一連の地域（ローカリティ）群がどのようなもので、それらに対してどのように対処したいのかということにある。ローカラ
イゼーションは、論理的デザインとその実装全般を横断するものであるため、以下に示すよ
うに、あらゆる重要な角度からそれぞれのローカリティを検討しなければならないということを覚えておいたほうがいい。
オーディエンス

それぞれのローカリティに対してオーディエンスのタイプを作るのか、

あるいは、それぞれのオーディエンスタイプの中にローカリティセグメントを作っていくのか。（詳細については、Chapter 25（デザイン・構築編）「オーディエンスを列挙する」の「4. オーディエンスとローカライゼーション」のセクションを参照）
発行物

ナビゲーションはローカリティによってどう異なるのか。テンプレートを複製す

るのか、あるいはテンプレート中で分岐させるのか。テンプレートが各ローカリティをまたいで機能するようにするためには、パーソナライズする方法にどのような修正が必要か。
（詳細は Chapter 26（デザイン・構築編）「発行物をデザインする」を参照）
コンポーネント 翻訳されたコンテンツはどのようにして保存されるのか。ローカリティの違いを説明するための特別なコンポーネントエレメントは必要か（Chapter 27（デザイン・構築編）「コンテンツタイプをデザインする」の「4-3. コンポーネント内にあるローカリ
ティ」のセクションに詳細が載っている）
執筆者

各地の執筆者が、別の執筆者グループを選んで構成するべきか、あるいは他の執筆者で構成されるグループを作ればいいのか。（Chapter 28（デザイン・構築編）「執筆者に対応する」の「5-2-4. 各地域の執筆者」のセクションに詳細がある）

435

Chapter18

取得情報源

中心となるローカリティ以外ではどんな情報源が得られるのか。それらの情報源をどのように処理し、中心となるローカリティの情報と合体させれば良いか。
（詳
細は Chapter 29（デザイン・構築編）「取得情報源に対応する」の「4-2-6. 各地域の情報源」のセクションを参照）
ワークフローとスタッフィング

ローカライゼーションに関する具体的なタスクは何か。

それを行うためには、どれくらいの時間がかかり、またどれくらいの人手が必要で、どんな種類の人が必要か。
（詳細はChapter 33（デザイン・構築編）の「ワークフローとスタッフィ
ングモデルをデザインする」の「4. ローカライゼーションをワークフローに適合させる」のセクションを参照）
アクセス構造構造を単に変更するのか、あるいは構造自体をローカライズするのか。
（詳

細は Chapter 30（デザイン・構築編）「コンテンツのアクセス構造をデザインする」の「3-2.
計画」のセクションを参照）
配備

各地域から生み出されたコンテンツは、システムを介してどのように配信されるべ

きか。地域的なコンテンツ、そして各国共通なコンテンツはどのように組み合わされるべ
きか、世界中を網羅するしかるべきサーバに、どのようにそれを展開していけばいいのか。
（詳細は Chapter 19「ハードウェアとソフトウェアを選択する」の「7-2-6. システムの配備」のセクションを参照）
サポート：翻訳やローカライゼーションに対するサポートを、選んだ CMS 製品に期待するのか。（詳細は Chapter 19「ハードウェアとソフトウェアを選択する」の「7-2-3. ローカラ
イゼーション」を参照）
ここに挙げた事項を検討することで、ローカライゼーションにかかる労力の大きさを測るための情報を得る必要がある。覚えておかなければならないのは、もし CMS がうまくローカ
ライゼーションに適応していなければ、あるいはローカライゼーションの要件が非常に広範囲ならば、ある時点で、CMSを2つのシステムに分ける必要があるかもしれないということだ。
これらのシステムのうちの 1 つが、もう 1 つのシステムにコンテンツを提供し、その後、処理と変換が行われる。ここでの目標は、システムがローカライゼーションに適応できるような、
正しいレベルの柔軟性を見つけることで、この二極化の発生を避けることだ。
組織がローカライゼーションに値するレベルでその資金を供給できるように、あるいはロー
カライゼーションの規模についての組織の期待を減らすことができるように、この分析が論
理的デザインの深部から発生し、スポンサーや意思決定者の手に委ねられるようにすべきであることを、分析者は承知しておく必要がある。

436

論理的デザイン

4-7. リスク評価計画
論理的デザインを進めていくにつれ、結果的には正しくない、たくさんの仮説を立てることになる。もし、間違った仮説に多くの時間またはお金をかけているのならば、それは危険なことである。さらに、あなたはうまくいかない戦略を提案しているかもしれない。何としてでもそれを提案してしまう代わりに（さらに最悪なのは、失敗するかもしれないと思うことを提案してしまうことだが）、アイディアには失敗のリスクが潜在的に存在していることを示すべきだ。もしその危険度が高いならば、そのアイディアを捨てることも大切だ。よくあることだが、そのリスクが大きな報酬をもたらすかもしれないし、少しの努力でその失敗を軽減できるのであるならば、それは試してみる価値があるかもしれない。
とにかく、論理的デザインを終える前に、準備評価の一部として作ったリスク評価をもう一度見直すことだ（この内容は、Chapter 15「CMS に向けて準備する」の「4-6. リスク評価」のセクションでカバーされている）。
要件と論理的デザインから起こりうるリスクについて、最初に考えるべきことは以下の通りだ。
システム要件要件の中で矛盾が発生していないか。その問題を手に負えるレベルのものに変えることができたか。
オーディエンス 承認されたのか。あまりにたくさんのオーディエンスを選択していないか。少なすぎないか。それぞれのオーディエンスに対するデータを得ることはできるか。
発行物

多すぎないか。複雑すぎないか。すべてを統合できるか。

コンテンツタイプ

タイプの数は多すぎないか。分類していないタイプがまだあるのではないか。それぞれのタイプに含めることを提案したメタデータを収集できるか。
執筆者

収集した情報を信用できるか。あまりにもたくさんの異なったタイプの執筆者がいるのではないか。彼らはこの仕事をするのに十分なスキルがあるのか。彼らとは、作成したルールに従ってもらえる程度の信頼関係を築いているか。
取得情報源

分析できなかった情報源は存在するか。変換するのに多大な手間が必要なものはあるか。情報源の質や一貫性について信頼できないものはあるか。情報源の数が多すぎないか。
アクセス構造提案したものを作る労力を集結させることができるか。それは、コンテンツを入手しやすい適切なものになっているか。人々は、本当に、正しいカテゴリにコンポー
ネントを割り当てることができるか。発行物のナビゲーションは、CMS レポジトリに置くように計画されているアクセス構造から構築できるか。
ワークフローとスタッフィング システムは、想定以上の努力を要求するか。自分自身の仕事にかかる時間は予想したものに近いか。腕のあるスタッフを見つけることはできる
か、あるいは彼らを訓練できるか。ワークフロー上に進行を妨げるようなものがあるので
はないか。

437

Chapter18

4-8. プロジェクト計画の改訂版
論理的デザインの最終段階では、CMS が果たそうとしていたことについて、知る必要のあ
るすべてが分かる。これは、最終的なプロジェクト計画を立てる上で知る必要があることのすべてではないが、計画を見直すために大切なことだ。もし、私が Chapter15 で述べた CMSのための準備のプロセス（これに関しては、Chapter 15「CMS に向けて準備する」の「4-5. 予
備プロジェクト計画」のセクションを参照）に準じているならば、もうすでに予備プロジェク
ト計画を作成していることになる。要件収集と論理的デザインの後にそれぞれ、あるいは論理的デザインのすぐ後に 1 度だけプロジェクト計画を修正して改訂版を作成することができる。
論理的デザインの後、これまで学んだことに基づき、次のような点を意識して計画を見直さなければならない。
スタッフィング CMS を立ち上げ、運用を行うために必要な人材とタスクについてきちんとしたアイディアを持たなければならない。この新しい情報は計画に現実性を与えてくれる。
量

どれくらいの量のコンテンツを持つべきか、ひと月にどれくらいの数の発行物を生み出していくべきかを正確に把握しなければならない。これはスケジュールを立てたり、予算を組んだりするのに役に立つ。
開発に費やす工数のレベルデザインされた機能性を持つコンポーネントと収集されたシステム要件の両方から、どれくらいのソフトウェア開発作業が CMS プロジェクトに関係しているかという考えをきちんと持たなくてはならない。この時点で、プログラミングやその他の技術的な支援のために必要とする時間、人材、予算について、何らかの基本的な計算をすることができるはずだ。もちろん、ソフトウェア開発のための実装仕様の段階にまでに至らなければ、実際にどれくらいのことが必要になるのか分からないだろう。しかし、この時点で最初のおおよその数値を算出することはできるにちがいない。
スケジュールの見積もり

スポンサーが尋ねる（そして聞かれる）、重要かつ繰り返される

質問は「いつ？」である。あとどれくらいかかるのか、いつ終わるのか。開発の労力に関わるレベルから推定して、どれくらいの期間、開発が続くのかについて、仮の見積もりを準備しておくことができる。その見積もりの大部分が変わるかもしれないし、誰もがこれ
らの予測がこの時点ではあくまでも予測にしかすぎないと感じるかもしれない。しかし、少なくとも、大枠での予測を立てることができる。
インフラのレベル収集されたシステム要件と、作成された論理的デザインの両方から、必要とするハードウェアとソフトウェアの種類と量を見積もることができるはずだ。もちろん、CMS 製品を選定して実装仕様が完成するまで、確実なことは分からない。しかし、この時点で理にかなった見積もりをするための十分な情報はある。
プロジェクトのこの段階では、時間枠と予算枠の範囲内で確実に実行可能なものにするために、プロジェクト計画を改訂することができるはずだ。あるいは、最初にプロジェクト計

438

論理的デザイン

画を改訂した時にあった、豊富な時間と予算の見積りをすでに上回ったことに気づくかもしれない。これは、完全な分析をしたという証拠だ。この場合、より多くの時間と資金を求めるか、あるいはプロジェクトを縮小するかの選択となる。
縮小する必要があると思うなら、やるべきことはプロジェクトの委任内容を見直すことだ。
委任内容にあるもので、何を減らすことができるか。特定の要件を削るか、コンテンツタイ
プと発行物を削るか。もし最初にコンポーネントと発行物を削ることから始めるのなら、次のようなことが起こるだろう。
委任内容と要件について、必死になって作った論理的デザイン上のリレーションシップが持つ一貫性と統一性をあきらめる。
現在の予算の中で組織が失うことになったもののために、さらにリソースの援助を求める
機会を失う。組織にとっては、たとえコンテンツと発行物が削られても、なおかつ当初のゴール（結局、彼らが一番気にしていることだ）を保持するように言うのは簡単だ。彼らが自分たちで設定したゴールをあきらめることは難しい。私の経験において、組織からの最初の返答はこういったものだ。
「もちろん､当初のゴールはすべて成し遂げたい。しかし、そんなに費用をかけたくはない」。これに同意することは、自分自身の将来に対して、悲惨な責任を課すことになる。
必然的に、デザインを縮小しなければならないだろう。縮小に動揺して取り乱すことができるし、その決断を賢い選択ととらえて実装前にデザインのし直しをすることもできる。現在のデザインに、次の実装段階で実現できること以上のものを取り入れておくのは、良いことだ。より広範なデザインは、実装プロセスが現在のニーズに対応していると同時に、将来の準備をしていることについての確信をもたらす。

ヒント
縮小することを敗北だと考えてはいけない。縮小はプロジェクトと組織のために良いことなのかもしれない。大きく広がってしまったシステムの一部を削ることで、あなたが理解している以上に、時間を削減できているかもしれない。そのうえ、いま進めようとしているシス
テムの成功は、削ったものを将来のバージョンに加えることについての、組織の支持を得ることに貢献するだろう。歴史は、コンテンツマネジメントの側にある。結局あなたは、自分がデザインしてきたこと以上のことをすることになる。特に、どのようにすれば良いのか確かでないのなら、たとえあなたが世界中のすべての時間を使えるとしても、すべてのことをすぐに急いでやる必要はない。

4-9. エグゼクティブサマリー
スポンサーやプロジェクトチーム以外の人は皆、論理的デザインから生み出された山ほどの情報をかき分けて進みたいと思っているはずだ。これらの人々のためには、長さ 10 ページ
程度のエグゼクティブサマリーを作成するのがベストだ。ここでは、システムの投資対効果

439

Chapter18の検討結果を提示する必要がある。要するに、投資対効果の記述には、そこで言及されているあるコンテンツが、ある発行物を通じてあるオーディエンスに配信されることにより、組織があるゴールを達成した、というすばらしい展開が記述される。
以下は、そこに含めると良いと思われる項目のリストである。
委任とプロジェクトの主なゴール設定の繰り返し収集された要件の概要
執筆者と情報源の概要
コンポーネント階層の簡略版および注釈付きバージョン
メッセージングとパーソナライゼーションの戦略
最終的な発行物の見た目を示すために選んだページモックアップ数点
主なスタッフの役割とワークフローの概要

ノート
もし、ここに挙げたリストに分からないものがあっても読み続けてほしい。それはあとに続く Chapter（デザイン・構築編を含む）で扱うことになる。
加えて、最新のプロジェクト計画（もしくはその簡略版）を付録として含めるといいだろう。

5. スタッフィングのニーズを検討する
表 18-1 に、論理的デザインを行ううえで必要と思われる人材のリストを示す（これらの職務に関する完全な詳細説明は Chapter 13「CMS のスタッフィング」を参照）。
表 18-1: スタッフィングのニーズ
タスク
リーダー
関係者
説明
デザインアタックプ アナリスト、または 必要に応じて他のア コンテンツマネージャーがこの仕事を監
ランビジネスアナリスト ナリスト全員督する可能性が高い。
エグゼクティブサマ コ ン テ ン ツ マ ネ ー 必要に応じて他のア コンテンツマネージャーがこのドキュメリージ ャ ー、あるいは、ナリスト全員ントを作り、発表するのに一番ふさわし
ビジネスアナリストい。
オーディエンス分析 ビジネスアナリスト 発 行 物アナリスト、ビジネスアナリストはこの仕事を主導す外部のマーケティン るのに一番適した役割だが、マーケティン
グスタッフ、必要に グの専門家、あるいは特定のオーディエン
応じて他のアナリス スに関連する組織内の人の強い関与も必
ト全員
要。
収集デザインドキュ コンテンツアナリス 変換アナリストから もし現実的であれば、2 人のアナリストは
メント
ト、ソフトウェアア の強力なインプット。共同作業で進める。それはそれぞれの専
ナリスト
必 要 に 応 じ て 他 の 門 性を生かしあうことができるからだ。
アナリスト全員から もし、それが非現実的であれば、1 人のアのインプット。リー ナリストが自分のドキュメントを持ち、もダ ー は 必 要 に 応 じ う 1 人がそれに貢献するという形で作業て、コンテンツ寄稿 すると良い。
者あるいは組織の人を呼び寄せる440

論理的デザイン

タスク
リーダー
関係者
説明
管理デザインドキュ コンテンツアナリス 必要に応じて他のア もし現実的であれば、2 人のアナリストは
メント
ト、開発関係アナリ ナリスト全員。
共同作業で進める。それはそれぞれの専スト
門 性を生かしあうことができるからだ。
もし、それが非現実的であれば、1 人のアナリストが自分のドキュメントを持ち、もう 1 人がそれに貢献するという形で作業すると良い。
発行物戦略ドキュメ 発行物アナリストント

コ ン テ ン ツ ア ナ リ ソフトウェアアナリストがテンプレート
スト、必要に応じて に関するセクションに関与する必要があ
他のアナリスト全員 る。
からの強いインプット。

ページデザイン発行物アナリスト

コ ン テ ン ツ ア ナ リ 発行物アナリストが監督する。他のスタッスト、発行物デザイ フは成果物を作り出す役目を負う。コンナー、ページ開発者、テンツアナリストはコンテンツタイプにUI 専門家。
関する分析に主な焦点をあてて仕事をする。発行物アナリストや発行物デザイナー
は、特別なインプットの必要に応じて他のスタッフを呼び寄せる。

パ ー ソ ナ ラ イ ゼ ー 発行物アナリスト
ション戦略

コンテンツアナリス 発行物アナリストが監督する。なぜなら、ト、ソフトウェアア パーソナライゼーションは発行物の構造ナリスト。
に影響を及ぼすからだ。コンテンツアナ
リストはコンテンツのアクセスと検索に関する仕事に従事し、ソフトウェアアナリ
ストはパーソナライゼーションのルールとその実装の仕事に焦点をあてる。マー
ケテイング部門からのインプットもメッ
セージング分析に必要になる。

発行物アドミニスト 発行物アナリスト
レーション

配備アナリスト、必 配備アナリストは発行のワークフローと作要に応じて他のアナ 業におけるインフラ担当スタッフの役割
リスト全員。
の理解を支援する。

プロジェクト計画の コ ン テ ン ツ マ ネ ー プロジェクトマネー アナリストは計画のそれぞれの部分につ
改訂版
ジャー
ジャー、必要に応じ いて責任を持つ。コンテンツマネージャーて他のアナリスト全 はその計画を総括する責任者。難しい妥員。
協案を出したり、計画に関して絶え間ないサポートを提供する。

441

Chapter18

6. まとめ論理的デザインは、CMS プロジェクトのなかで、「腰」の部分にあたる。私が提唱する論理的デザインでは、様々な要件（Chapter 17「要件を収集する」を参照）に基づいて、システムに実施させたいことをはっきりと具体的にデザインすることになる。以下を参考にしてほしい。
論理的デザインを行う際には、そのプロセスを何度も見直し、膨大な量の詳細事項を管理する方法を見出さなければならない。
始める前に、論理的デザインのためのアタックプランを準備しておく。
収集、管理、発行に関する分析結果ドキュメントを準備する（あるいは、すべての論理的デザインの基礎をカバーするアウトラインを付け加える）。
組織の責任者にオーディエンスの成果とローカライゼーション計画を渡す。それについて議論する機会を得、最終的にはそれを承認してもらうためだ。
組織の首脳陣にエグゼクティブサマリーを渡す。それが読みやすいものになっていると、あなたがしようとすることに関する感触をつかんでもらえる。
最後に、論理的デザインの終わりのほうで、最新の考えを反映するために、プロジェクト
計画とリスク評価を見直す。
次の Chapter では、CMS のプロジェクトのなかで最も論議され、ストレスを感じやすいテー
マの 1 つである、ハードウェアとソフトウェアの選択について扱う。

442