普段業務で、MTのサイト設計工程を担当することが多いです。 MTはバージョン7でコンテンツタイプの概念が導入されて、管理対象にあわせたイチからのデータ定義や、別のコンテンツタイプとのリレーションが張れるようになり、RDBのテーブルを考えるような感覚で設計するようになりました。

自己流ですが、普段行っているCMS構造やコンテンツタイプを設計する工程について自分なりに整理してみました。

タイミングとしては、ワイヤーフレームや運用要件が確定したあたりから設計に入ります。

要素の洗い出し

各ページに必要な表示要素や、表示しないが内部処理上必要そうな管理情報を、一旦全部書き出します。繰り返し要素、重複、他のデータを組み合わせれば導出可能な要素は取り除きます。この段階で、ざっくりデータ型を割り付けていきます。

洗い出した要素をグルーピング（コンテンツタイプ）

従属関係を考えながら、要素を別グループに分割したり、ひとつにまとめたりします。

例えば、イベント・セミナー情報に関するデータのうち、"イベント名”や担当講師が誰か?" は、そのセミナー自身に属する情報です。しかし、担当講師の「氏名」「プロフィール」「所属会社名」は、「講師」自身の情報であって、イベントに直接属する情報ではありません。これらは「講師」という別グループに分けます。

同様に、セミナー会場そのものに関する情報を、「会場」情報として切り離します。ここで分けたグループが、それぞれコンテンツタイプの単位になります。「氏名」や「プロフィール」などの各要素がコンテンツフィールドにあたります。業務システムで見かける「講師マスター」「会場マスター」みたいな感じです。

無闇に分割すればいいかというとそうではなくて、例えば記事本文データのように、大きな入力フィールド一つで中身はユーザが自由に入力できた方が運用も管理もしやすい、なんていうことがあるので、データの利用先、生存期間、管理権限など様々な条件を考えながら決めていきます。

先の例でいうと、コンテンツタイプ「セミナー情報」の"担当講師" から、コンテンツタイプ「講師」を参照して、講師名やプロフィール情報を得よう、という風に参照関係を定めていきます。

この辺りの過程がRDBフレイバー漂う工程ですが、一つMT固有の注意点は、参照には方向性があって相互参照はできない点です。つまりイベント・セミナー情報から講師情報への参照を定義したとして、逆引き（この講師が担当するイベントはどれとどれか？など）は今のところできないです。

参考: Advent Calendar2日目の安部さんの記事で解決できるっぽいです。ステキっ(╹◡╹)♡

ここまででコンテンツのデータ構造が決まりました。続いてテンプレート構成を決めて出力側を固めます。

リレーション関係や参照の方向性の見える化は、 Lucidchartというツールを使い ER図風にまとめます。

Lucidchartは最近使い始めたのですが、ER図やフローチャートのテンプレートが使いがってよく、ドラッグ＆ドロップでさくっと美しいリレーションが張れるので、複雑なデータ構造を決めるときも、検討過程が効率よく進みます。オススメです。

例えば、MT用のサンプルテーマ Jungfrau のセミナー・イベント情報は、こんな感じになります。

ウェブマスターや運用担当者とCMSの構造を共有する目的で、コンテンツタイプの図に、さらにデータフローを追加して次のような感じにまとめることもあります。これは、コンテンツデータ（入力）が、MTテンプレートを通して、ページのどこに反映されるか（出力）を表現した図になります。

これだけだと、実装担当者に渡すには細かい情報が足りないので、最終的にはExcelなどに詳細を展開することもあります。

以上が一連の流れになります。エンジニアとしての素養があるわけではなく、冒頭にも書いた通り自己流なので非効率なことしているかもしれませんけどね。少しでも参考になれば幸いです。

ではでは、皆さん楽しいMTライフを！ Merry Xmas (╹◡╹)♡