この記事はRachel Lovinger著「Content Modelling: A Master Skill」の抄訳です。
This article is a translation of "Content Modelling: A Master Skill" By Rachel Lovinger.
前回の記事ではコンテンツストラテジストのマスタースキルについての話をしましたが、今回は私のお気に入りのスキルについての話です。私は最近、コンテンツモデルがコンテンツストラテジーの最も重要なスキルの1つだと考えるようになりました。コンテンツモデルは、コンテンツの意図やステークホルダーのニーズ、ユーザーエクスペリエンスデザインの要求事項を、CMSの開発者が構築できる機能に翻訳する時に使われます。コンテンツモデルは、コンテンツビジョンを実現する手助けをしてくれるのです。
コンテンツモデルとは？
コンテンツモデルでは、あるプロジェクトで要求される全てのコンテンツタイプについて記述します。これにはそれぞれのコンテンツタイプの詳細な定義や、コンテンツタイプ同士の関連などが含まれます。全体的な構造を記述するために組織図スタイルのダイアグラムを使ったり、スプレッドシートを使って詳細な情報を記述したりします。どのレベルの情報をモデルにするかは、そのモデルをどんな目的のために使うかによって決定します。
シンプルな組織図スタイルのコンテンツモデル
上のモデルは、音楽関連のWebサイトで使われるコンテンツタイプと、それらがどのように関連しているかを示したものです。セールスのチャートに含まれる要素には、関連する曲、アーティスト、アルバムなどのページへのリンクが含まれるでしょう。アルバム、アーティスト、曲ページには、さらにそれぞれのページへのリンクが含まれます。このモデルはステークホルダーにコンセプトを提示するために使われ、また情報アーキテクトやデザイナーにサイトのフローに関する情報を提供します。
このような簡単なモデルが必要なときもありますが、実際はもっと詳細なコンテンツモデルを必要になることがほとんどです。詳細なモデルでは、それぞれのコンテンツタイプをさらに細かいコンポーネントに分解し、フォーマットなどの情報を記述します。上記の例では、」さらに詳細なモデル（アルバムやアーティスト、曲についての更に細かい情報を含めたもの）を作ることで、ページデザインやCMSの設定に必要な情報を提供できます。そのようなモデルは、最終的にコンテンツ製作者のトレーニングにも使うことができるでしょう。
コンテンツモデルの重要性
コンテンツモデルは他チームの作業に影響し、また影響されもします。コンテンツモデルは要件を明確にし、デザイナー、CMS開発者、コンテンツ製作者の間のコラボレーションを促進します。
情報アーキテクトとデザイナー – コンテンツモデルは、ページデザインが全てのコンテンツモデルに対応しているか判断するのに使われ、またページに掲載されるテキストやメディアについての詳細情報を、情報アーキテクトやデザイナーに提供します。またコンテンツモデルは、デザインによって提示されるコンテンツ、レイアウト、機能をサポートする必要があります。もし画像にキャプションがレイアウトに含まれていたら、その情報は画像のコンテンツモデルに含まれていなければいけません。もしイベントがカレンダーの日付順にソートできるとしたら、日付は独立した項目に、ただのテキストデータとしてではなく、ソート可能な日付データとして記述されなければいけません。サイトの複雑さにもよりますが、デザイナーへ渡す情報は、大まかな概要、または少し詳細なもので十分な場合が多いでしょう。
開発者 – コンテンツモデルは、開発者がCMSを構成する時に、どのようなコンテンツがあるか、またどのような要件があるかを理解するのに役立ちます。色々なタイプのCMSがあるため、同じ結果を実現するのにも様々な方法があります。もしコンテンツモデルが、あるCMSでは実現が難しい要件を含んでいることがわかれば、開発者はアプローチを変えて問題に対処することができます。開発者にはとても細かいレベルのコンテンツモデルが必要です。もしコンテンツストラテジストが詳細情報を提供しなければ、開発者は自分でモデルを解釈し、詳細情報を作り上げてしまうかもしれません。また開発者はデザイン要件やコンテンツ製作者のニーズを常に把握しているわけではないため、コンテンツモデルを通じてこれらの要件を伝える必要があります。
コンテンツ製作者 – コンテンツモデルは、コンテンツ製作者がどんなコンテンツを作るのか、またどのようにコンテンツをCMSへ入力するのかを示すガイドラインになります。コンテンツ製作者は通常、コンテンツモデルの作成プロセスに関わることはありませんが、毎日CMSへコンテンツを入力する人間の声を考慮するのはとても重要です。コンテンツ製作者のために、コンテンツモデルは直感的でわかりやすく、一貫していて、余分なものを最小限に抑えたものにしましょう。どのようなコンテンツモデルにするかによって、彼らの作業がとても簡単になったり、逆に非常に大変になったりするためです。
コンテンツモデルの作り方
コンテンツモデルを作る時に考慮すべき3つのポイントがあります。
- アセンブリモデル：コンテンツ製作者がWebページやキャンペーン、ドキュメント等のコンテンツプロダクトを作成するために、個々のコンテンツを組み合わせる方法。
- コンテンツタイプ：システム内で1つのタイプとして識別されるコンテンツの構造
- コンテンツ属性：各タイプを構成するコンテンツとメタデータ、またそれらの相互関係。
アセンブリモデル
CMSにはそれぞれ「クセ」のようなものがあり、それを理解するのは重要です。CMSはコンテンツをある「単位」として扱うように設計されており、そのコンテンツ単位を制作するために最適化されています。例えばブログアプリケーションなら投稿がその単位になりますし、Sharepointならドキュメント、Webコンテンツ管理ツールならWebページが中心となるコンテンツ単位です。通常はCMSを様々に構成してコンテンツを利用、または再利用してダイナミックなサイトが作られます。
FatWireを使ったプロジェクトでのこと。私はページの要素がどのように組み立てられるかスケッチを始めたところ、ある開発者が近くに来てすぐに、「なんかInterwovenみたいなやり方だね。FatWireでは実現出来ないよ」と言ってきました。Interwovenは別のCMSで、コンテンツアイテムの中にある反復性のある属性のまとまりを特定できるシステムです。例えば、FAQには質問と答えで構成されており、オプションとしてイメージやリンクを追加できます。FAQページを作る時、コンテンツ製作者はその属性のまとまりを何度も複製することによっていくつものFAQアイテムを作り、ページを完成させます。FatWireではそのように自由に複製することができません。FatWireではFAQアイテムの最大数を決めてフィールドを作るか（ユーザーはその内の余分なフィールドは使いません）、またはFAQアイテムを別のコンテンツタイプとして定義し、それをリストとしてFAQページに組み込まなければいけませんでした。
このような決定を下すため、コンテンツをどの程度細かい「部品」に落とし込むかを考える必要があります。プレスリリースのようなコンテンツは、それ自体が自己完結型で、それぞれのプレスリリースが1つのページとなるでしょう。しかしその他の場合は、いくつもの再利用可能なコンテンツを部品として利用し、1つのページを組み立てることになります。FAQの例では、もし同じ質問を複数のFAQページで使いたいと思ったら、それぞれの質問・答えのペアを1つのコンテンツアイテムとし、それを手で集めてリストにしたり、または複数のタグを付けてそれぞれのトピックのFAQページに表示したり、という判断ができるようになります。
また、アセンブリモデルを考える時は以下のポイントも考慮しましょう。
- コンテンツはどのように構成される必要があるでしょうか？ ソートやフィルタリングで使われるような、一意性があり識別可能なデータは必要ですか？
- コンテンツはどの程度柔軟である必要があるでしょうか？ ページにはどんな要素が、どのくらいの数で、どんな順番で含まれるか予測できますか？ または、どのようなコンテンツでも自由に構成できるような仕組みをサポートする必要がありますか？
- コンテンツにはどの程度の再利用性が求められるでしょうか？ 再利用される部分を独立させることで、他のページと共通で使うことができるようになりますか？
- コンテンツ製作者は、時間のかかる作業をどのくらい忍耐強く進めることが出来るでしょうか？ もし、彼らにバラバラに構成されたコンテンツを、特定のデータフィールドに分解してほしいと頼んだら、彼らはそれをする時間がありますか？ もしかしたらそういった作業に慣れているかもしれませんが、コンテンツを分解するのは非常に時間のかかる作業のため、目的に見合った工数だと判断できる場合にだけ依頼するようにしましょう。
この段階では、このような質問に正確に答えようとする必要はありません。これらの情報は次の2つのステップで判断を下すためのガイドラインになるものです。そのため、もし全てのメンバーと合意が取れなくても、これらの質問について考え、話し合うだけでも意味があるのです。
コンテンツタイプ
コンテンツがどのように構造化されるべきかという質問は、様々なコンテンツタイプを区別するのに役立ちます。もしコンテンツが構造化されていなければ、単純に1つだけコンテンツタイプを定義して全てをその中に入れてしまえばいいでしょう。これがブログ投稿の裏にある前提です。とても柔軟性がありますが、全く構造化されていません。
しかし多くの場合は、ある程度構造化されたコンテンツタイプが必要になるでしょう。そうなると、コンテンツを抽象化して似たようなパターンを探す必要があります。どのような要素がコンテンツを構成し、どのような属性が共通しているか考えましょう。例えば、レシピはスライドショーとは明らかに違いますが、バンドのプロフィールは俳優のプロフィールと似ているので、これらが基礎となる「プロフィールタイプ」から生まれた2つの要素だと考えることができるかもしれません。
コンテンツタイプとして分ける方法は他にもいくつかあります。
- ユニークで再利用可能な要素：例えば本についてのコンテンツなら、それぞれの著者の名前、バイオグラフィーや写真をまとめて著者タイプを作るでしょう。このタイプは人間が書いたものに関するコンテンツならどんなものとも関連付けられます。
- 機能要件：例えばビデオは、ビデオプレーヤーを用意しなければいけないなど、別の機能を必要とするため、別個のコンテンツタイプとしたほうが良いでしょう。
- 組織的要件：プレスリリースは他の一般的なコンテンツと同じように見えますが、ニュースルームにしか表示されません。このような要素も独立したコンテンツタイプとしておくと管理が楽になります。
あるコンテンツタイプは常にオプショナルな要素を含むといった場合あるため、コンテンツタイプの間に明確な線を引くことは難しいこともあります。「他と違うという時に、どの程度の違いがあればいいのか？」ということに悩まされることもしばしばあります。もしそのような状況に陥ったら、開発チームやビジネスアナリストチーム等に相談して、一番良いと思えるアプローチを一緒に考え出せると良いでしょう。
コンテンツ属性
最後のステップでは、それぞれのコンテンツタイプに含まれる要素を明確にします。これには目に見えるコンテンツと、目には見えないメタデータとが含まれ、また他のコンテンツタイプとの関連性も含まれます。例えば、独立した著者コンテンツタイプを作ったとしたら、本のレビューは著者に関連するコンテンツタイプとなるでしょう。
いくつかの要素はすぐにわかるでしょう。例えばプレスリリースにはタイトル、あればサブタイトル、そしてオプショナルな画像と本文が含まれます。しかしある情報のかたまりを、他と区別すべきかどうかを決めるのが難しい場合があります。以下の場合を考えて見ましょう。
- レイアウト：いくつかの要素が、他と全く違ったスタイルや場所に表示される必要がある場合、それは異なる要素となるでしょうか？ マークアップやスタイルをコンテンツと一緒にするのは避けるべきなので、理想的には異なる表示をする要素はそれぞれ独立した要素として扱うと良いでしょう。例えば、サブタイトルを独立した要素ではなく本文の一部としておいた場合、編集者にそれを太字にするよう依頼することはできますが、RSSフィードやモバイルデバイス上ではどうなるでしょうか？独立した要素とすることで、様々なアウトプットに対応することができます。
- 再利用：独立した要素は他の部分で再利用することができますが、全てを本文としてまとめてしまうと、再利用することはできません。
- ソートとフィルタリング：もしコンテンツを日付順にソートしたり、コンテンツを特定のキーワードでフィルタリングしたりする場合、これらの情報は1つの要素とすることで、ソートやフィルタリングに対応できるようになります。
それぞれの要素を特定したら、どのようなフォーマットで表示されるか、それは必須情報かなどを決める必要があります。例えば、あるコンテンツを日付順にソートする場合、そのコンテンツは必ず日付を含まなければいけませんし、その日付のフォーマットは統一されていなければいけません。ここでも開発チームと協力して、彼らがシステムを構築するのに必要な情報が含まれているか確認しましょう。
コンテンツモデルの文書化
コンテンツモデルは異なる読者、異なるフェーズで使われるため、生き物のようなドキュメントと考えた方が良いでしょう。プロジェクトが終わり、更新を止めた時でもそれは完璧にはなり得ません。そのため、完成させる成果物というよりは、更新し続けるドキュメントと捉えるほうが良いと思います。コンテンツモデルのライフサイクルでは、多くの人がインプットを加え、それぞれのフェーズで異なるチームによって管理されることもあります。私が経験した過去のプロジェクトでも、プロジェクトのある時点ではコンテンツモデルの更新をアナリストチームや開発チームにお願いしたことが多くあります。
ほとんどの場合、プロジェクトチームはコンテンツモデルを内部資料として使います。ステークホルダーが作業中のコンテンツモデルをレビューしたいと言ってきたことはほとんどありません。もしそうしたとしても、彼らが特に何か指摘することはないでしょう。彼らが気にすることは、CMSがデザイン要件、技術要件、ビジネスニーズを満たし、それを使う人が便利だと感じるかということです。コンテンツモデルはその実現に役立つ資料となります。
場合によっては、ステークホルダーにインプットや意思決定を依頼しなければいけない時もあります。そのような時は、目立つところを1つずつ提示するのが良いでしょう。そうすれば彼らはその特定の問題に集中でき、コンテンツモデル全体を理解しなくても良くなります。
またCMSトレーニングやコンテンツ制作ガイドラインを作る時、コンテンツモデルはとても良い開始点になります。情報を抜き出すのも簡単ですし、フォーマットし直して、ユーザーフレンドリーな体裁に整えることも出来ます。根本的にはCMSを直感的で簡単に操作できるように努力すべきですが、現実にはそれより少し複雑になってしまう場合がほとんどです。そのため、CMSユーザーに適切なガイドラインを提供することは、そのプロジェクトが成功と見られるか、失敗と見られるかに関わるほど重要なものになることが多くあります。
まとめ
コンテンツモデルはとても役に立つツールで、デザイン、編集、技術チームとの間でのコミュニケーションを促進します。アセンブリモデルやコンテンツタイプ、コンテンツ属性を明確に定義することで、コンテンツストラテジーがコンテンツ製作者によって実現されるよう促すことができます。最近のプロジェクトではコンテンツモデルへの需要はどんどん増えてきています。コンテンツストラテジーにとって必ず価値のあるスキルとなることでしょう。
Translated with the permission of A List Apart and the author[s].
