「Web制作者のためのCMS」は、なぜクライアントの利益にもなるのか
「これもできますか?」とクライアントに聞かれて、一瞬、頭の中で工数を計算してしまう。やれなくはないけれど、ここで安請け合いすると後が大変そう。
そう思って、つい無難な案に寄せてしまった経験はないでしょうか。
それは決して、あなたのやる気の問題ではありません。実は、ふだん使っているCMSの構造が原因に一つかもしれないのです。
この記事は「打ち合わせ」だけの話ではありません。
CMSの「実装のしやすさ」という、ふだんあまり意識されない要素が、提案の幅や納品物の質、ひいてはクライアントの満足度にまでどう効いてくるのか。
かつて私たちが掲げた「Web制作者のためのCMS」という言葉が、なぜ巡り巡ってクライアントの利益になるのか。
a-blog cms をつくっている私たちの視点から、あらためて考えてみたいと思います。
かつて掲げて、引っ込めた「Web制作者のためのCMS」
a-blog cms が 1.0 をリリースした頃、私たちは「Web制作者のためのCMS」というキャッチコピーを掲げていました。ところが、このコピーは早い段階で姿を消すことになります。
理由はシンプルでした。制作会社がクライアントに提案する場面で、「作る人のため」というメッセージがあまり好まれなかったのです。
「私たち(クライアント)のためじゃないの?」
そう受け取られてしまうのは、無理もないことだと思います。お金を出すのはクライアントなのに、なぜ制作者の都合を優先したCMSを選ぶのか。一見、もっともな疑問です。
けれども、それから十数年が経った今、CMSの選定は事実上、制作会社が主導するものになっています。クライアントが自分でCMSを比較検討して指名するケースはむしろ稀で、「いつもお願いしている制作会社が得意なもの」「制作会社が薦めるもの」が採用されるのが一般的です。
この変化を踏まえると、かつて引っ込めたあのキャッチコピーが本当は何を言おうとしていたのか、もう一度きちんと整理して伝える価値があるように思うのです。「Web制作者が無理なく作れるCMS」は、本当にクライアントにとって不利益なのでしょうか。私たちは、むしろ逆だと考えています。
そのCMS、実はWeb制作会社であるあなたが選んでいます
Webサイトのリニューアル案件でCMSの話題が出るとき、クライアントから具体的な製品名が指定されることは、実はそれほど多くありません。「WordPressで」と指定されるケースはありますが、それすら「他のCMSと比較した結果」というよりは、「名前を聞いたことがあるから」という理由であることが大半ではないでしょうか。
実際の選定プロセスを観察すると、だいたい次のような流れになります。
まず、制作会社が要件を整理します。更新頻度、運用する人のリテラシー、サイトの規模、予算、納期。そうした条件に対して、自社で扱い慣れたCMSの中から最適なものを選んで提案する。クライアントはその提案を見て、機能と費用感に納得できれば承認する。
つまり、CMSの良し悪しを判断する一次情報を持っているのは制作会社であり、クライアントは制作会社の判断を信頼することで意思決定をしているわけです。
これは決して悪いことではありません。専門家に任せるというのは、合理的な選択です。手術器具を選ぶのに患者が口を出さないのと同じで、判断材料を持っている側が決めるのは自然なことです。
だからこそ、「制作者にとって扱いやすいCMSかどうか」は、巡り巡ってクライアントの利益に直結します。CMSを選んでいるのは、ほかでもない制作者自身なのですから。
CMSの「実装のしやすさ」は、工数だけの話ではありません
「実装のしやすさ」と聞くと、工数が減る・コストが下がる、といった話を思い浮かべる方が多いかもしれません。もちろんそれもありますが、私たちがもっと大事だと感じているのは、制作者の中に生まれる「心理的な余裕」のほうです。
実装に無理がないと、制作者は要望を恐れなくなります。要望を恐れない制作者は、打ち合わせや提案の場で前のめりになれます。前のめりな制作者は、クライアントがまだ言葉にできていなかったニーズまで引き出して提案できます。この連鎖の出発点にあるのが、CMSの「実装のしやすさ」です。
逆も同じです。実装が大変なCMSを使っていると、制作者は要望を警戒するようになります。警戒している制作者は、提案の場で受け身になります。受け身の制作者からは、クライアントの期待を超える提案は出てきません。これもまた、出発点はCMSの「実装のしにくさ」にあります。
つまり、制作者に余裕が生まれるかどうかは、単なる工数の問題ではないのです。提案の幅、納品物の完成度、そしてクライアントの満足度まで、すべてに影響する変数だと、私たちは考えています。
余裕があるWeb制作者は、提案の幅が変わる
もう少し具体的な場面で考えてみます。
仮に、プラグインで機能を拡張していくタイプのCMSを使っているとします。もちろん、多くの要望はプラグインで気持ちよく解決できますし、その手軽さこそがこのタイプのCMSの大きな魅力です。問題になりやすいのは、プラグインの仕様を少し超える要望が出てきたときです。そんなとき、制作者の頭の中では、無意識にこんな計算が走ります。「標準機能でできる範囲なら、追加コストはほぼゼロ。でも、その範囲を超えるとなると、コードを改修するか、別のプラグインを探すか、場合によっては自作することになる。そうなると工数が読みにくくなる」。
この計算が働くと、提案の態度は自然と保守的になります。「こういうこともできますか?」と聞かれたとき、それがプラグインの守備範囲内ならスムーズに「できます」と答えられる。でも範囲外だと、内心で「ここで安請け合いすると後が大変だ」と身構えてしまう。結果として、できるだけ要望が広がらないように、無難なところへ着地させようとする力が働きます。冒頭で書いた、あの感覚です。
a-blog cms を使った制作現場の話を聞くと、ここに対照的な光景が見えてきます。
a-blog cms は、プラグインに頼らず、本体に組み込まれた機能の組み合わせで多くの要望を実現する設計になっています。カスタムフィールド、モジュールID、ユニット、ルールといった汎用的な仕組みが標準で用意されていて、それらを組み合わせることで「カテゴリごとに表示を変える」「特定の条件下だけバナーを出す」「複数のコンテンツを横断して一覧にする」といった要望に、プラグインを追加することなく対応できます。
これが制作者の振る舞いに与える影響は、想像以上に大きなものです。
制作者は「こういうこともできますよ」「だったら、こんな見せ方もできます」と、能動的に選択肢を広げる側に回れます。「こんなことできない?」と聞かれて身構える必要がなく、「やれます。ついでに、こんなパターンも作っておきますか?」と返せる。要望を抑える場ではなく、アイデアを膨らませる場に変わっていきます。
そして、この進め方の違いは、最終的に納品されるサイトにも表れてきます。選択肢が狭まりやすい進め方からは、要件をそつなく満たしたサイトが生まれます。選択肢が広がりやすい進め方からは、それに加えて、クライアントのビジネスに一歩踏み込んだ提案までを盛り込んだサイトが生まれやすくなります。
ここで誤解のないように補足すると、これはプラグイン型のCMSが劣っているという話ではありません。拡張のしかたについての設計思想が違う、というだけのことです。ただ、その設計思想の違いが、制作者の心理や提案の幅にまで及んでいる。その事実は、CMSを選ぶうえで知っておいて損はないと思うのです。
「制作者のゆとり」と「クライアントの利益」は、ちゃんと両立する
ここで強調しておきたいことがあります。
制作者の利益とクライアントの利益は、しばしば対立するものとして語られがちです。「制作会社が儲かるなら、クライアントは損をしているはずだ」という、ゼロサム的な発想です。
けれども、CMSの選定に関しては、この発想は当てはまりません。むしろ逆で、制作者が無理なく作業できる環境は、クライアントへの提供価値を高める方向に働きます。
理由は、制作費の大部分が「人の時間」と「精神的なリソース」だからです。時間と気力を節約できれば、同じ予算でできることが増えます。あるいは、節約できた分を提案や品質の向上に振り向けられます。どちらに転んでも、クライアントが受け取るものは良くなります。
「Web制作者のためのCMS」という言葉が誤解を招いたのは、それが制作者だけの利益を語っているように聞こえたからでした。でも実際には、制作者が前向きに取り組めるかどうかは、クライアントの満足度に直結する変数です。両者は対立しているのではなく、同じ方向を向いているのです。
まとめ CMSを選ぶときに、もう一つ持っておきたい視点
制作会社が要望に対して消極的に見えるとき、それは担当者のやる気の問題ではないかもしれません。
使っているCMSが、要望を受け止めにくくしているのかもしれない、ということです。
逆に、提案が次々と出てきて、想像を超えるアイデアが飛び交うような打ち合わせは、制作者がそのCMSを扱いやすいと感じていると言えます。
CMSを選ぶときには、機能リストや価格表だけでなく、「これを使うWeb制作者が、どれだけ前向きになれるか」という視点もぜひ持ってみてください。
その先に、クライアントの利益も見えてくるはずです。
制作者が無理なく作れること。
それは決してクライアントを軽視する話ではなく、つくる側とつかう側の双方にとって、持続可能なものづくりの条件なのだと、私たちは考えています。
ウェブ制作会社アップルップル代表。2000年に日記のCGIを公開、2004年にはブログを開発。四半世紀にわたりWebサイトを更新するシステムに関わり続けてきました。自社開発CMS「a-blog cms」は5,000サイト以上で採用され、現場視点のUI改善や勉強会の開催にも取り組んでいます。
@kazumich関連記事
この記事のハッシュタグ から関連する記事を表示しています。