9月23日に書いた記事「CMSの管理画面でクラス名を変更できるようにしたことを後悔している」の続きです。

この記事を読んだプログラマの友人に
「モジュールに設定したクラス名一覧を資料化すればいいのではないですか？」
と聞かれました。

当初はこれについても書くつもりでしたが、結論から言うと諸々の問題で難しいのと、ますます記事が長くなるので追記しなかったのでした。

この件について改めて書いてみたいと思います。

モジュールID一覧を作ったことはある

一時期、管理画面で表示されている「モジュールID一覧」のHTMLをPDFに書き出し、資料として納品時にお渡ししていたことがありました。

a-blog cmsは、CMS内の設定（IDがnewsのカテゴリーのエントリーを5件呼び出す）に名前をつけて「モジュールID」として使い回すことができます。DrupalのViewsも同様だったと思います。
これもクラス名と同様、管理画面でしか参照できないものです。なので友人の指摘の通り、資料化しようと考えたのです。

ですが、これには以下のような問題がありました。

予算がつかない

これはウェブ制作全体の問題ですが、「サイトマップ」「マニュアル」以外の資料には、あまり価値を見いだされません。企画を重視していない案件では「カスタマージャーニーマップ」さえ予算がつくのが難しいでしょう。それ以前に私は受注制作がメインなので、予算に関われる案件はまずありません。

もしこちらから「モジュールID一覧もお送りしますね」と言っても、たぶん「いやー、いらないですよ！」と返事が来ます。
なので、できるだけシステム化して、こちらの見積内に組み込むことになります。よほど効率化しないとタダ働きになります。

やっぱり使われない

そうやって頑張って作成しても、サイトの改修自体がないことが多いです。私自身も完全納品だと、その後は声がかからないので使うことはありません。前回の記事のように、常時改修をお手伝いさせてもらっている案件もまれにありますが、全体の一割くらいです。
もしかすると、多くの納品先が、このような資料を必要としていたのかもしれません。しかし何も言われないのでわからないのです。あー、SNSでつながっている方、その後必要だったかこっそり教えて下さい…

サーバーと同期されない

オフラインの資料にしてしまうと、管理画面の内容を更新したときに資料も更新しなければなりません。資料と最新の状態が食い違うのはまずいです。 これは友人も指摘していました。むしろ資料作成を重視するプログラマさんやSIerさんは、こっちを気にすると思います。

管理画面の情報を常に閲覧できればいいのでは

そこで「管理画面に、モジュール関連の必要な情報だけを一覧できるテンプレートを作ればいいのでは？」と考えました。
テーマ内に含むようにできれば、毎回資料を作成する手数もなくなります。

a-blog cmsなら簡単にできるかもしれないと、管理画面にざっと書いてみたテンプレートがこれです。

<!-- BEGIN_MODULE Admin_Module_Index -->
<!-- BEGIN module:loop -->
mid: {mid}<br>
モジュールID: {identifier}<br>
<!-- BEGIN status#open -->
<span class="acms-admin-label acms-admin-label-info admin-status-label acms-admin-text-nowrap"><!--T-->有効<!--/T--></span><!-- END status#open --><!-- BEGIN status#close -->
<span class="acms-admin-label acms-admin-label-danger admin-status-label acms-admin-text-nowrap"><!--T-->無効<!--/T--></span><!-- END status#close -->
<br>
	<!-- BEGIN_MODULE\ Admin_Module_Edit ctx="bid/%{BID}/mid/\{mid\}" -->
	説明: \{description\}<br>
	追加クラス: \{module_exclass\}<br>
	追加属性: \{module_exattr\}<br>
	<!-- END_MODULE\ Admin_Module_Edit -->
<hr>
<!-- END module:loop -->
<!-- END_MODULE Admin_Module_Index -->

Admin_Module_Indexモジュールは、モジュールIDの最低限の情報を一覧表示するモジュールです。
ループ内でエスケープされているAdmin_Module_Editモジュールは、指定したモジュールIDの詳細情報を出力し、GET送信すれば編集可能にするモジュールです。
いずれも管理画面専用です。

• mid
• 識別名
• 有効／無効
• 説明文
• 追加クラス（モジュールのカスタムフィールド）
• 追加属性（モジュールのカスタムフィールド）

ここまで一画面で表示できればかなり便利になると思ったのですが…
残念ながらAdmin_Module_Editに属性値でIDを渡すことができないようで、説明文やクラスは表示できませんでした。何か間違えているのかもしれませんが。

となると、PHPを書いて、データベースへの直接のアクセスが必要になります。さすがにそこまでする必要があるかは微妙です。

リッチCMSに備えないといけない

かつては汎用CMSとは、本格的なエンタープライズCMSではなく、ごくごくシンプルなものでした。
ですが利用者が多いWordPressであっても、納品後にもコーディングに関与できる「リッチCMS」の採用が当たり前になっています。

制作側もこれまでのように作るだけで終わらせず、納品から半年後、一年後の改修で無駄な工数を食わないよう、対策を講じなければならなりません。
消化不良ですがこの話題はまたいつか。

先月の「WCAN 2018/10」で、講師の谷口さんが、WordPress 5.0のGutenbergに対する懸念と同時に、小規模のコーポレートサイトはこれまでのWordPress一択ではなく、ASP型のシンプルなCMSへ移行していく選択肢もあるというお話をされていました。

コーポレートサイトの軽量化が進む中でも、CMSで構築すべきコンテンツはいくつかあります。そのひとつが「ユーザー事例」「導入事例」などの、事例コンテンツです。

事例コンテンツは、クライアントの業種、業態などで適したパターンが異なるので構築の最適解がありません。だいたいはすでに決まっているワイヤーに添って構築することが多いですが、私が中間の制作会社さんに「このパターンはこういうリスクがありますが大丈夫ですか」と提案したり、逆に意見を求められることもあります。

だいたい、5パターンに分けられると思うので、今後のために特徴と構築手法をまとめてみます。

ワイヤーがかなり縦に長いので、少し読みづらいですがご容赦ください。画像はクリックで拡大できます。

リッチテキスト型

冒頭にお客様の画像と名前が入り、その後はリッチテキストの自由文となります。
最も軽量なパターンで、特別なフィールドもお客様名くらいですから、JimdoなどのASP型も含め、どのCMSでも実装可能です。

このパターンの欠点は、データの再利用性が低いこと、リッチテキストであるためウェブ担当者のセンスに左右されることです。固定ページとほぼ同じですね。

データベース型

すべての項目をカスタムフィールドでがっちり構築し、事例の情報を細かいデータとして開示します。

大手企業さんで数回経験しました。すべての情報の再利用性を考えていることや、大きな社内で投稿ルールを統一するのが難しいからではないかと思います。

上記の通りデータの再利用性が高い、つまりAPI連携、リニューアルにめっぽう強いことが長所として挙げられます。一方で例外が許されなかったり、この事例だけ思い切り推したい、ということができないのが欠点です。このため、中間のテキストをリッチテキストの自由文にして、HTMLを書けるようにしておくという「逃げ」を考えたりします。

工数も多くなりますし、CMS本体への負荷も高めです。そういう意味でも大企業向けなように思います。

ギャラリー型

画像とキャプションがグループになった「繰り返しフィールド」を作り、カルーセルとして表示します。繰り返しフィールドについてはまとめで後述します。

jQueryが普及した頃から現在まで人気があり、コンパクトで、クライアントのOKも出やすそうなパターンですが、私はこのパターンにあまり良さを感じません。

このパターンは、最初に画像が集中しているため、画像と文章を対比して見ることができません。文中に「キッチンのタイルのあしらいは…」と書かれていて気になっても、ページの最初まで戻って、カルーセルをめくらなければならないのです。

また、スマートフォンの普及で画面が狭くなり、かつ訪問者の滞在時間が少なくなったため、2枚目以降を見てもらいにくいです。縦長の素材が多いとますます見づらくなってしまうのも難点です。文章は少ないけど良い写真がたくさんある、というなら採用しても良いかと思います。

リピートフィールド型

前項のギャラリー型の変形です。画像、キャプション、見出し、本文がセットになった繰り返しフィールドを重ねてページを作成します。見出しやキャプションは必ずしも必要ありません。

縦長の画像にも対応できたり、画像と文章を対比できるなど、ユーザビリティに利点があります。更新担当者にも説明しやすいパターンですが、同じパーツの繰り返しなので、そうとう文章に力を入れなければ単調になってしまいます。 また、途中に任意のコンテンツを割り込ませることができません。

画像に力が入っているならギャラリー型、文章に力が入っているならリピートフィールド型がいいのかなと考えています。

ユニット型

本文中のすべてのパーツを「ユニット」として自由に並べていくパターンです。

このブログへ何度か来られた方はすでにご存知かと思いますが、a-blog cmsが最も得意としているパターンです。concrete5も実質このパターンになります。WordPressのGutenbergやMovable Typeのブロックエディタも…近い、とは言えます。

例外対応ができる、段組ができる、事例専用のユニットを追加できるなど、なんでもありですが、a-blog cmsのエバンジェリストとして敢えて言うと「データの再利用性が低い」「手厚い導入説明が必須」という問題があります。このため、急ぎ案件やまとめてインポートをしたい場合には向きません。

また、これはリッチテキストエディタと同質の問題でもありますが、投稿ルールを決めておかないと、各ページがカオス化しがちです。

まとめ

以上、事例コンテンツのパターンをまとめてみました。いつものように突っ込みを待つことにします。

繰り返しフィールドは、「リピートフィールド」「フィールドグループ」などと呼ばれ、a-blog cmsはコアでこの機能を持っています。WordPressでは「Advanced Custom Fields」プラグインのPROライセンス、Movable Typeでは「FreeLayoutCustomField」で可能です。

個人的にはデータベース型はけっこう好きだったりしますが、サイトのレイアウトがデータに大きく縛られてしまうため、やはり繰り返しフィールドと単体フィールドの併用が良いのかなと思います。

すべてのパターンに言えることですが、事例を「インタビュー」としていた場合は「インタビューに応じてくれる寛容なお客様が、今後どのくらいいるのか」について検討しなければなりません（私はこれを「希望的観測問題」と呼んでいます）。なので、インタビューと通常事例でカテゴリー分けをして、通常事例はギャラリー型などにすることが考えられます。

なんにせよ、なぜ事例コンテンツを作りたいのか、事例を通して訪問者（将来の顧客、もしくは掲載された顧客）に対してどのようなユーザー体験を与えたいのか、この二点を明確にしてから進めたいものです。

2016年2月27日に札幌市で開催されたCMSの合同イベント「CMSMix Sapporo」で、基調講演をさせていただきました。

CMSMix Sapporo 〜Web制作の幅が広がる！プロジェクトの傾向から考える、2つ目・3つ目のCMS選び〜 | Peatix

ジャクスタポジション西山さん

昨年秋の、名古屋のセミナーイベント「WCAN」での私のセッションに、札幌のMovable Typeのパワーユーザー、西山さんが興味を持ってくださいました。

WCAN2015 Autumnで、CMSディレクション全般について話しました | CMS | ウェビンブログ

これがきっかけで、a-blog cms・concrete5・Drupal・Movable Type・WordPressのパワーユーザーが集まる、貴重なイベントが実現しました。ありがとうございます。

2015年9月12日(土)に開催される「WCAN 2015 Autumn」で「Web制作の幅が広がる！プロジェクトの傾向から考える、2つ目・3つ目のCMS選び」というテーマでお話をすることになりました。
秋のWCANはコマ選択方式になっており、私は2コマ目を担当します。

WCAN 2015 Autumn | WCAN 名古屋近郊のイベント情報

また、女性フリーランサーの情報サイト「Rhythmoon」で、東京以外の地方都市で働くフリーランサーのインタビュー連載に掲載していただきました。

【新連載】愛知県在住 Webエンジニア 口田聖子さん | コラム | Rhythmoon（リズムーン）

よろしくお願いします＆ありがとうございますm(__)m