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」の採用が当たり前になっています。

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

突然「#10年間を振り返る」というハッシュタグが盛り上がっているのですが。

成功自慢か不幸自慢かネタ以外は流れていくだけの場で書く内容ではないでしょうよ。

という正論で殴りつつ、ブログに書きます。

10年前の写真。POKEN覚えてる？

10年間を振り返る

いろいろなコミュニティと関わりましたが、全体にはa-blog cmsとともに歩んだ10年間だった気がします。人生にも影響するとは思わなかったな…

2009年　34歳　CSS Nite LP6参加
2010年　35歳　a-blog cms Traning Campではじめて愛知県へ行く
2011年　36歳　CSS Nite in Sapporoの実行委員になる
2012年　37歳　Facebookページ本の執筆に参加
2013年　38歳　愛知県へ移住
2015年　40歳　baserCMSテーマコンテストでグランプリを受賞
2016年　41歳　北海道へ帰郷、a-blog cmsエバンジェリストになる
2018年　43歳　CSSフレームワーク「echo.css」を公開
2019年　44歳　ふたたび愛知県へ移住

私生活の10年間

ひとくちに「10年間」と言っても、公私では内容が異なります。上の10年間で、2014年と2017年が空いていますが、私生活ではいろいろあった年でした。

2014年はこれまで溜まってきた自分のダメな部分が出た年で、体調を崩したうえに、仕事でもコーディングでスランプに陥って、毎晩Ingressをしていた記憶しかありません。
いっぽう2017年は、私生活を良くしていこうと考え始めた年で、友人にヨガを習ったり、うさぎを飼いはじめたり、ゲーム用の自作PCを作ったりと、ほんわかした記憶が多いです。

今年は6月に、長年闘病をしていた母が他界しました。とても寂しいですが、これもまた節目でもあります。

私生活は、本人と近しい人以外にはどうでもいいことですし、面白くも興味深くもありません。ですが本人には、いいことも悪いことも、その後の表につながっていくのだろうと思います。

この先の課題

こうして10年間にやったことを書き出してみると、ここ数年は10年前の目標だった「a-blog cmsの案件増加」と「年収の安定」を達成できているものの、新しいスキルをあまり勉強できていません。
来月からまた愛知県民です。落ち着いたら次の10年間につながるようなことにまた挑戦していきたいです。

コーディングとCMSのテーマ設計の話です。かなりCMS構築に慣れていないと理解しづらい内容になるので、順を追って説明します。

モジュール型のサイト設計

CMSで運用されるサイトは、トップページや下層ページのサイドバーで、投稿の新着やナビゲーションなどの「モジュール」を埋め込む前提で構築やコーディングをします。
ここでは「モジュール」としていますが、CMSによって名称は異なります。よく知られているのはWordPressの「ウィジェット」です。

コーディングにについては、以前書いた記事「CMSの構築を考慮したコーディングとかクラスの命名規則の話」で詳しく書いていますが、つまりはこの場合、それぞれのモジュール（＝ウィジェット）はクラス名が付与されたdivで包括される前提となります。

例えば、WordPressの人気テーマ「Lightning」のトップページで、新着記事を表示している箇所は以下のようにマークアップされています。

<div class="widget widget_vkexunit_post_list" id="vkexunit_post_list-13">
（新着記事リスト）
</div>

自由モジュールであることを示す「widget」、テーマ専用パーツであることを示す「widget_vkexunit_post_list」のクラスに加え、一意のIDが付与されています。
これによって似たようなモジュールをページに複数配置しても、クラスかIDで区別してCSSスタイルを調整できます。

モジュールのクラス名を自由に決められるようにしてみる

DrupalのBlockやViewsでは、先述した包括divに付与するクラス名を変更できる機能があります。コーダー側のコーディングルールを活かせるので、とても魅力的な機能です。

ヘッダ、フッタのボタン、包括divの属性を変更できるようにした例

このクラス名変更機能を、a-blog cmsのモジュール設定に組み込んだのが、二年ほど前に公開したテーマ「echo_zero」でした。

モジュールの外観のカスタマイズ | はじめての方へ | 解説資料 | echo_zeroデモサイト

このテーマは当時はかなり満足していて、安定したウェブサイトをサクサク構築できるので、いくつかの案件にそのまま採用していました。
…が、二年が経って、一部の案件でこの機能が足を引っ張るようになってしまいました。

クラス名を見つけられない

完全納品ではなく、納品後も改修をお手伝いする案件だと、半年ほど経ってコンテンツが増えてきてから、二段階目の改修を依頼されることがあります。
モジュールの追加やデザイン変更などが発生しますから、コーディングも変わってきます。以前はイベント新着関係のモジュールが一個しかなかったのに、似たようなモジュール（関連イベント・現在位置から近い順）が増えたりします。

半年も経つと、自分の作ったテーマでも細かい構造は忘れています。このクラスは、どのモジュールで使用していたろうかと、テーマをクラス名の一部、例えば「module-event」などで検索してみても…見つかりません。
クラス名はCMS側で管理しているので、ローカル環境のエディタの全文検索ではヒットしないのです。
こうなると、a-blog cmsの管理画面に入って「モジュールID」の一覧から該当のモジュールを探すことになります。かなりの手間です。

CMSで何もかも管理すればいいわけでもない

一般に配布するテーマであれば、クラス名を変更できる機能は非常に便利です。
利用する人の大半は、モジュールごとに細かくCSSを調整したり、コーディングルールにこだわったりすることがないので、メリットの方が大きいでしょう。

ですが、自分がいちからテーマを作成していて、改修も多い場合は、修正すべき箇所をローカル検索できないというのは、毎回の時間のロスは大したことがないものの、けっこうストレスが貯まります。

そんなこんなで最近は、多くの人がやっているように、記事リストを呼び出す箇所を共通のインクルードファイルにして、クラス名や繰り返すコンポーネント名を変数で渡す構築になっています。
以下はa-blog cmsの場合です。a-blog cmsはJSON形式で変数を渡せます。これなら検索にもヒットします。

@include("/include/module/summary.html", {"class": "c-module-event-top", "mid": "summary_event_top", "loop": "event"})

ここまで書いて、どのくらいの人にこの文章が伝わっているのだろうか…と思いはじめていますが…

よく考えたら、モジュールの包括divを、制作者以外が変更できるようにする必要は基本的にないわけです。配布テーマでは便利でも、制作者が不便になるような機能は制作段階で外しておかなければと、改めて反省しています。

2019-09-30追記
デモサイトの公開を終了しました。
microCMSで「画像のリサイズ」が可能になりました。また、boolean（チェックボック）フィールドが追加されました。

ASP型のヘッドレスCMS「microCMS」のベータテストが始まっています。
通常は月額8,500円が必要ですが、試用期間は無償で使い放題ということで、事前予約をしていました。

https://microcms.io/

「ヘッドレスCMS」については後述しますが、これまでのCMSと概念が異なるため、使いどころが難しいです。実際にサイトを構築してみるしかないだろうと、コンセプトから考えてきっちり作ったので、体験レポートをします。

サンプルサイト

「動画投稿サイトから人気が出たブレイク直前の男性アーティスト」という、どこかで聞いたような人物のオフィシャルサイトです。
試用期間が終了する、2019年9月30日まで限定公開します。

（公開は終了しました）

Tsuyoshi.さん、かっこいい写真をありがとうございます。またジンギスカン食べましょう :D

基本的に静的サイトですが、以下の3箇所で、JavaScriptでmicroCMSに投稿したデータを表示しています。

• Home＞What's New
• Home＞Discography最新
• Discography

ヘッドレスCMSとは

話を戻して、ヘッドレスCMSについてざっと説明します。

これまでの主要なCMSは、管理画面＝投稿部分と、テンプレートエンジン＝表示部分で構成されていますが、ヘッドレスCMSは表示部分を持っていません。そのかわりAPIが提供されていて、各ユーザーがAPIから取得したデータを加工して利用します。

利点は、ユーザー側が好きなスクリプト言語を使用でき、かつウェブサイトに限らず、スマートフォンアプリ・デジタルサイネージと、様々なプラットフォームに使えるというところです。

一方で欠点は、ノンプログラマには利用できないところです。また、アーカイブを考えなければならないブログやコーポレートサイトでの利用では、便利さを感じにくいでしょう。

管理画面の印象

APIのセット＝サイトやプロジェクト名を新規作成すると「スキーマ」を作るように言われます。「フィールド」のことらしいです。入力例がないので何のことなのかしばらく悩みました。
上の画像はDiscographyのスキーマの一部です。

フィールドタイプは、現状、5種類しかありません。「ラジオボタン」「セレクトボックス」「チェックボックス」がないのは、かなりきついです。正式版までに実装されると願いたいものです。NewsやDiscographyのカテゴリーラベルは文字列の直打ちにしました。

booleanフィールドが追加され、チェックボックスでの選択が可能になりました。

日時は、タイムスタンプ＝公開日時のことはありません。タイムスタンプはデフォルトで提供されます。公開日時を変更可能にしたい場合は、フィールドを作る必要があると思います。

スキーマを作ったらすぐ入力を始められます。画像フィールドに編集アイコンがありますが、画像のサイズを変えることはできません。また、現時点ではアップロード時のリサイズ生成ルールもありません。ここでは公開サイズに編集してからアップロードしています。

APIリクエスト時にクエリを送ることで、画像をリサイズできるようになりました。

開発の方からTwitterで教えていただいたのですが、画像サイズについては早めに対応を考えているとのことです。開発ロードマップは、管理画面で見ることができます。

コンテンツの表示

入力はすぐできたので、静的サイトを作って、いよいよAPIの取得・表示部分に取り掛かりました。

サンプルサイトのスキーマは複雑なので、「タイトル・日付・画像・テキスト」を持ったスキーマ「post」を表示するサンプルをGistで公開しておきます。
かなり雑なスクリプトですが…

APIを見て気付いたのが、API側でできることが、指定したフィールドの取得・表示件数・非公開記事を表示するかの選択くらいしかないことでした。

つまり、以下のようなことは自分でスクリプトを書いて実装しなければならないということです。

• 並べ替え
• フィールドの内容による絞り込み
• ページネーションの生成

私はJavaScriptを専門にできるほどのスキルはまだありません。なので、Gistの内容を実装するまででも2時間くらいかかりました。テンプレートエンジンを知っていればもっとスムーズだったかもしれませんが。

microCMSのトップページの導入ケースに「デザイナー」がいるので誤解しがちですが、少なくともデザイナー向けのCMSではないです（そう書いてもいません）。

使えそうな状況

私はコーポレートサイトの制作が多いので推測レベルですが、以下のようなコンテンツに向いていそうです。

• 静的サイトのごく一部にしか使用しない
• データを表示したい対象が、サイト、アプリ、デジタルサイネージなど多数ある
• データ構造がシンプル
• ページネーション、検索、アーカイブなどの必要性が薄い

パッと浮かんだのが、スマホゲームアプリの開発会社です。公式とアプリの両方にお知らせを出しつつ、多数のゲーム用のアカウントを作る感じです。APIは30本まで作れるので、単純に30タイトルまでいけるということになります。
ゲームアプリを作るくらいの人たちであれば、ゲーム内にお知らせを組み込んだ方が楽なのかもしれないですが。

今回、アーティストのサイトを作ったのは、アーティストのサイトは、最初はSNS中心で小さく始めて、売れるに従って規模が大きくなっていくケースが見られるからです。

microCMSのライバル

身も蓋もない話になってしまいそうですが、ASP型CMS「MovableType.net」でもData APIが使えます。
使用したいサイトが1個だけであれば、こちらの方がコスパが良かったりします。

https://movabletype.net/support/setting/data-api.html

ただし、MovableType.netはあくまで、ウェブコンテンツの管理が主であり、API利用に特化するなら必要ない機能も多いです。microCMSのようにサクッと立ち上げることは難しいでしょう。そのあたりで差別化ができそうです。

私の業務内容からすると、microCMSはまだまだ縁が薄そうなのが残念です。でも、スキーマや表示部分を自分を組み立てていくのはとても楽しかったです。APIや管理画面の機能が改良されていけば、これまでになかったCMSとなるだろうと期待しています。

ハンズオンをすると漏れなくピカブイにまみれることができます

先週、8月31日は「CMSMix Sapporo Vol.13・a-blog cmsの回」を開催しました。

札幌での勉強会の参加は、今週末の「CSS Nite in Sapporo, vol.23『北海道限定！ブランディング』」で、当分お休みになります。二年以上に渡ってCMS Mixを共同運営していた、西山さん、白根さん、ありがとうございます。俺流のザンギは最高です (๑´ڡ`๑)

さて、Vol.13のテーマは、a-blog cmsの「組み込みJS」について、ハンズオン形式で紹介しました。
a-blog cmsには、インストール時点で制作を補助するJavaScriptライブラリが、多数読み込まれています。これらは簡単なclassやdata属性の付与で起動することができます。

ハンズオンで使用したバージョンから一部修正した学習用テーマを、GitHubで公開します。

https://github.com/webbingstudio/acms_builtin_js_handson

インストール直後のa-blog cmsにこのテーマを反映するだけで、画面の指示に従って以下のライブラリを体験できます。

• 指定した管理画面URLをポップアップで表示
• スムーズスクロール
• コンテンツの折りたたみ
• 動画のポップアップ
• 最低限のタグのみ使用できるリッチテキストエディタ
• カスタムフィールドの文字数をカウントする
• 表を簡単に入力できるカスタムフィールドを作る
• 組み込みJSの設定を変更する

組み込みJSの立ち位置

勉強会で「この組み込みJSを使うということは、うぇびんさんは、CMSのサイトを作るときにJSも書くんですか？」と聞かれました。制作会社とフリーランスの温度差を感じる質問でした。

CMSを扱う制作会社の場合、コーディング担当とCMS構築担当という切り分けになることが多いですが、私のようなフリーランスの制作者は「ワンストップでやってほしい」と、しばしば希望されます。やはりその方が手戻りが少ないからで、コーディングが完了したデータをいただいて作業するのは、大企業さんの案件くらいです。

問題は、ウェブサイトにはJavaScriptの演出が欠かせないというところです。ライブラリを探して組み込んで、デザインを合わせる工数だけでもばかになりません。私はある程度JavaScriptを書くことができますが、デザイン＋HTML＋CSS＋WordPressというスキルセットの制作者はいつも大変です。

そういう、JavaScriptを通常業務としていない人でも、ある程度の演出を気軽に使用できるのは、a-blog cmsの強みではないかと思います。また、a-blog cmsは公式テーマでサイト構造だけ作ってからデザインを考える手法を勧めているので、イメージしている演出を組み込みJSでさくっと組んでしまうこともできます。XDみたいな感じですね。

逆に、コーディングが先にあって、かつJavaScriptのスキルが高い人だと、必要のないライブラリが多数読み込まれてしまうa-blog cmsの仕様は不便に感じるかもしれません。

ハンズオン素材を作る目的

勉強会では、時間が許す限りハンズオン素材を制作しています。また、素材は配布可能にしたいと考えています。
これは勉強会を楽しく進めるのに必要なのはもちろんなのですが、少なからずいる、勉強会に物理的・時間的な理由で来られない人にアプローチしたいからです。

というか、そういう潜在的な参加予備軍の方がはるかに多いはずです。「勉強会に行くと参加者とつながりができたり、そのCMSを使わざるを得なくなるのでめんどくさい」という、現実的な理由があるのも察しています。
そういう人たちにも気軽に使ってもらって、「a-blog cms便利だな！！」となってもらえるとうれしいです。他のCMSのユーザーの人も偵察にお使いくださいw

勉強会の後半ではヘッドレスCMS「microCMS」を試しました。それはまた次の記事で書きます。