「自社でCMSを作っているのに、ブログは別のもので動いているんですね」
先日、そう言われました。
そのとおりです。
このブログはDrupalで動いていて、今回は弊社が開発している独自CMSを使っていません。
隠すような話ではないので、最初に書いておきます。
むしろ、自社製品を作っている会社だからこそ、なぜ別のCMSを選んだのかを説明できなければいけないと思っています。
製品を使っていない理由が残っていなければ、後から見た人には「自社製品を使えない理由があるのでは」と見えてしまいます。
そこで今回は、なぜ弊社ブログに独自CMSではなく、WordPressでもなく、Drupalを選んだのかを記録しておきます。
自社製品を使わない、という選択
「自社製品を持っているなら、自社サイトでも使えばいいのでは？」
そう思うのは当然です。
実際、自分で使っていない製品には気づけない不便さがあります。
だからこそ、自社製品を使わないのであれば、その理由を説明できる必要があります。
今回、Drupalを選んだ理由は大きく3つあります。
製品を必要以上に大きくしないため
これが一番大きな理由です。
ブログには、記事の分類、タグによる横断、関連記事の表示、URLの自動生成など、記事が増えるほど必要になる仕組みがあります。
自社ブログのためにこれらをKinfuuCMSへ追加していけば、当然ながら製品そのものが大きくなります。
しかし、独自CMSが想定している利用環境では、そこまで複雑な機能が必要になるケースばかりではありません。
更新頻度は月に数回。
担当者は1人。
サーバーは共用レンタルサーバー。
そうした環境では、機能を増やすことよりも、迷わず更新できることの方が重要です。
使わない機能は、ないのと同じではありません。
画面を複雑にし、更新時の確認箇所を増やし、保守するコードも増やします。
だから、ブログのためにKinfuuCMSへ機能を追加することはしませんでした。
ブログをDrupalに分けたことで、この線引きを保てます。
Drupalと独自CMSでは、想定している条件が違う
独自CMSは、意図的にいくつかのものを使わない構成にしています。
Composerを使わず、データベースサーバーも使わず、FTPで配置できる構成です。
これは「技術的にできないから」ではありません。
使う環境を考えたうえで、そうしています。
共用レンタルサーバーに納品する場合、SSHが使えるとは限りません。
顧客がコマンドラインを操作できるとも限りません。
だからこそ、FTPで配置して更新できることに価値があります。
一方、独自ブログシステムの環境にはその制約がありません。
サーバーにはSSHで入れますし、Composerも使えます。
更新や保守も自分たちで行います。
制約を外せる環境で、あえて制約のある構成を選ぶ必要はありません。
どちらが高機能かではなく、どの環境に置くのか。
それで選択が変わります。
壊れる範囲を分けるため
これは実務上かなり重要な理由です。
ブログは、本体サイトとはデータベースもディレクトリも分けています。
そのため、ブログの構築中にサーバーエラーを起こしても、影響範囲はブログ側に限定できます。
実際、構築中には何度かエラーを出しました。
それでも会社概要、サービス紹介、問い合わせフォームなど、本体サイトは動き続けました。
実験する場所と、止めてはいけない場所を分けておく。
これはCMS選定というより、システムを運用するうえでの基本的な考え方です。
「うちの製品で全部できます」と言わない
ここが今回の記事で一番伝えたいことかもしれません。
製品を売る立場になると、どんな相談にも自社製品を当てはめたくなります。
「それもうちでできます」と言えば、話が早いからです。
しかし、できることと、向いていることは違います。
できるからといって、最適とは限りません。
向いていない道具を使えば、動作はしても使いづらいシステムになります。
そして、その使いづらさを負担するのは、最終的には利用者です。
私が自社ブログでDrupalを選んだのは、こうした線引きを自分自身にも課すためです。
自社製品を使わない場面を実際に持っておく。
そうすれば、お客様に対しても、
「今回は独自CMSより、こちらの方が合っています」
と言えます。
これは製品の問題ではなく、信用の問題だと考えています。
では、独自CMSはどこで使うのか？
誤解のないように書いておくと、自社サイトの本体部分は独自CMSで動いています。
独自CMSを使っていないわけではありません。
むしろ、使う場所と使わない場所を分けています。
独自CMSが向いているのは、たとえば次のような環境です。
- 共用レンタルサーバーで運用したい
- 更新担当者は1人
- 担当者はITが専門ではない
- 更新頻度は月に数回程度
- 複雑な機能より、迷わず更新できることを重視する
逆に、大規模な会員制サイトや細かな権限設計が必要な案件では、Drupalを勧めます。
プラグインを利用しながら機能を拡張していきたい場合は、WordPressが向いているケースもあります。
CMSは「何を使うか」から決めるのではなく、どんな環境で、誰が、何をするのかから決めるべきです。
内製するか、既存のものを使うかを決める3つの質問
この考え方は、自社製品の話だけではありません。
何かを自分たちで作るのか、既存のものを使うのかを決めるときにも使えます。
7-1. それは自社の強みに直結するか
自社の強みに直結しない部分なら、すでにあるものを使った方が速く、安く済むことがあります。
強みではない部分を自作すると、開発が終わった後に保守だけが残ることもあります。
7-2. 作った後、誰が保守するのか
作る労力だけで判断してはいけません。
5年間、10年間と使い続けるなら、その間の保守もコストです。
ここを考えずに自作を始めると、後から身動きが取れなくなることがあります。
7-3. それを作ることで、本業の時間は減らないか
自作は楽しいものです。
だからこそ、目的を忘れやすい作業でもあります。
「作れるから作る」のではなく、作ることで何が良くなるのかまで考える必要があります。
まとめ
自社製品を使わない選択は、製品への不信ではありません。
道具を目的に応じて選ぶという、当たり前のことをしているだけです。
むしろ、使う場面と使わない場面を明確にした方が、製品の輪郭ははっきりします。
何にでも使えることを目指すと、結果として何にも最適化されていない製品になることがあります。
独自CMSは独自CMSに向いている環境で使う。
DrupalはDrupalに向いている環境で使う。
WordPressが適しているなら、WordPressを使う。
その判断ができること自体が、CMSを扱う側に必要な能力だと考えています。
Drupalについて、このブログを構築した情報を詳しく知りたい方はこちらの記事もご参考ください。
共用サーバーにDrupalを構築する際に実際に詰まった箇所も記録していますので、同じ構成を検討している方は参考にしてください。
CMS選定のについて詳しく知りたい方は、環境と目的から一緒に整理します。