先月以降 2009年7月の Adobe Edge ニュース(下記リンク)から、このサイトに来る方がときどきいらっしゃいます。

• CMS導入は誰のため？ 〜CMS百花繚乱時代に、改めて考える〜

この記事の中で、国産CMSのひとつとして CMONOS.JP が紹介されていました。国産CMSの一角に数えていただき、光栄です。ありがとうございます！

さて、この記事の中にわが意を得たりと思う文章がありました。

一般企業の担当者にとっては、Movable Type の管理画面でさえ難しく感じる という声をよく聞きます。...(略)...

現状では、Movable Type だけでなく、他の新興 CMS も制作者主体の管理画面となっているため、一般企業の担当者には、たくさんの見慣れない用語、運用上必要でない情報、入力フローや出力画面と異なる画面構成など、CMS を運用していくという面では、あまりやさしいとは言えません。

運用する人にとってやさしい管理画面を提供できるかは、CMS が生き残っていく際の大きなポイントになるはずです。

CMONOS.JP の書き込み画面はとてもシンプルです。それはまさに「運用する人」にやさしいシステムをめざしているからです。

CMONOS.JP のシンプルな入力画面。運用する担当者は、更新したいコンテンツのアイコンをクリックするだけで、入力画面にたどりつきます。制作者にのみ必要な設定項目を、運用者が目にすることはありません。

CMONOS.JP の画面がシンプルであることには、開発過程で遭遇した一つの事件が影響しています（CMONOS.JP は株式会社化してから公開されましたが、開発そのものは約10年前から始まりました）。

それはまだブログが一般化していない頃、テストのために運用していた身内のコミュニティサイトで、それまで掲示板システムを流用していた日記システムをブログライクに変更したときのことです（これが「ホームページメーカー」の原型となりました）。

この変更は、当時のユーザーから拒絶反応といってもいい猛反発を招きました。よかれと思って配置した「最近の記事」や「更新日時」に視線がまどわされ、"おそろしく"使いにくくなったと言うのです。「最近の記事」や「更新日時」だけで、ですよ！

あまりの不評に正直落ち込みましたが、このことから、プログラマーが好みがちの過剰な情報表示はユーザーを混乱させる、と言う教訓を得ました。

今でこそ、一画面に記事以外の雑多な情報があふれかえるブログを、誰もが何の苦もなく読むようになりましたが、かつてはそうではなかったのです、たぶん。

なぜ、かつては拒否されかねなかった、ところせましと情報を並べるレイアウトが受け入れられたのでしょうか。それは、ブログ画面のどのカラムが重要で、どこは無視していいのか、ある種のブログ文法が、だんだん浸透してきたからでしょう。逆に言えば、どこを見るべきかわかるようにならない限り、過剰な情報はユーザーを混乱させるだけ、ということです。

CMS の画面も、本格的なものになればなるほど、その多くが複雑です。便利な情報がところせましとあふれかえっています。慣れたひとなら今どこを見るべきか分かっていますからそれでよいのですが、初心者にとっては何を見るべきかでまずつまづいてしまいます。（そして、サイトを運用する人は制作者に比べてはるかに初心者であることが多いのです。）

そこで CMONOS.JP では、運用する人に見せなくてよい情報は徹底して隠しています。作業は画面の上から下へなぞるだけ。更新したいページのアイコンをクリックする、テキストボックスに入力する、そして、保存。とてもシンプルです。

（入力項目が原則として縦にのみ並ぶのは、横方向に配置したときユーザーが見逃すケースが多かったためです。）

ただ、画面がシンプルであることは、デベロッパーとしては、実のところ諸刃の剣です(＾＾；。実際に使用する段になるとシンプルさを好む運用者も、CMS を選ぶときには「なんだかよくわからないけど機能がいっぱいありそうな画面」を好むからです。

しかし「画面がシンプル = できることが少ない」というのは誤解です。CMONOS.JP は、制作者には柔軟なカスタマイズを可能にします。

たとえば、CMONOS.JP のカスタムフィールドは「タイトル」と「本文」の"おまけ"ではありません。CMONOS.JP は、むしろカスタムフィールドこそが"核"となったシステムです。つまり、「タイトル」と「本文」もカスタムフィールドのひとつにすぎません。また、CMONOS.JP のカスタムフィールドは、コメントやトラックバックを実現するプラグインでもあります。

CMONOS.JP のカスタムフィールドは、他にあまり見られない高いカスタマイズ性を実現しています。そのため制作者は、あらかじめカスタムフィールドを整えておくことで、より運用する人にやさしい、サイト更新システムを構築することができます。

入力フィールド設定の詳細設定画面。テキストボックスの大きさは、どの程度の長さの文章を入力するべきなのかを暗示する、制作者から運用者へのメッセージとなります。上画像のように大きなテキストボックスであれば長めの文章を、逆に小さなテキストボックスであれば短いコメントを入力するべきだと分かります。

CMONOS.JP の文字列フィールドには、テキストボックスサイズの設定以外にも、文字種の強制や、語句を統一するための文字変換など、運用する人のミスをあらかじめ防止するさまざまな機能が用意されています。

制作者はカスタムフィールドの設定を細かく調整することで、運用する人に適切な入力を促すことができます。

サンプルサイトの会社情報ページ入力画面。必要な項目のみが並び、記入漏れを防ぐことができます。もちろん郵便番号による住所検索にも対応（画面ではダミーデータが入力されています）。

またこの例では、制作者によってあらかじめテンプレートが設定されているので、運用者がテーブルなどでレイアウトを整える必要がありません。

ここで、上記管理画面をもう一度見てください。どこかに「CMONOS.JP」という文字があるでしょうか？

実は、どこにも「CMONOS.JP」という文字はありません。ロゴすらありません。

なぜなら私たちは、サイトを運用する人に「CMONOS.JP をいじっている」という感覚を持ってほしくないからです。私たちは、サイトを運用する人に「"自分自身のサイト"をいじっている」と感じてほしい、と考えています。

完成したウェブサイトは制作者と運用する人の作品です。「CMONOS.JP」は一道具に過ぎません。道具の名前がいちいち画面にでしゃばっては、道具がサイト運用の主人公のようです。否！　サイト運用の主人公は運用する人であるべきです。

あえてロゴを飾り立てない、徹底してシンプルな画面には、私たちのそんな思いが込められています。