「完璧なCMSは存在しない」リボルバー×コンセントが語る、失敗しないCMS選定の判断軸──必要なのは自由度か、安定性か。

Webサイトのゴールは、「公開すること」ではありません。成果につながる運用まで見据えるなら、プロジェクトに最適なCMSを選べるかどうかが、その後を大きく左右します。その判断においては、CMS本体の導入費用だけでなく、更新体制、メンテナンス負荷、セキュリティ対応、将来的な拡張性まで、検討すべき要素は多岐にわたります。

では、いま現場では、どのようなCMSが選択肢に挙がり、何を基準に選ばれているのでしょうか。今回はBtoB向け国産SaaS型CMS「dino」を開発する株式会社リボルバーの取締役COO・西宏司さんと、株式会社コンセントのウェブディレクター・山﨑貴史さん、フロントエンドエンジニア・小山直樹さんによる鼎談を実施。多様化する企業Webサイトのニーズを前に、制作現場ではどのような視点でCMSを選定しているのか。そのリアルな判断基準に迫ります。

目次

「CMSを入れたい」とは言われない。現場に届くのは「サイトの課題」

──まずは「dino」がどのようなCMSなのか、教えてください。

西宏司(以下、西) 「dino」は、もともとオウンドメディア運用のためのCMSとして、2014年に開発されました。開発当初からレスポンシブWebデザインに対応しており、一貫してSaaS型で提供しています。サーバ管理やセキュリティ対応は、私たちリボルバーが担う形で、10年以上提供を続けてきました。

──リリース初期からSaaS型だったのですね

西 はい。近年はオウンドメディアだけでなく、企業サイト全般で情報発信の重要性が高まっています。そこで、より幅広いBtoB企業のニーズに応えられるようプロダクトを再整理し、2025年10月からあらためて提供を開始しました。

株式会社リボルバーで取締役COO兼プロダクト&マーケティング統括を務める西宏司さん

──コンセントから見て、制作現場ではどのようなCMS案件の相談が多いのでしょうか

山﨑貴史(以下、山﨑) クライアントから、最初に「CMSを導入したい」と相談されるケースは、実はそれほど多くないんです。多いのは、「古くなったコーポレートサイトを刷新したい」といった相談にあわせて、「情報発信のスピードを上げたい」「セキュリティを強化しながら運用したい」「部門ごとに更新体制を分けたい」といった、より具体的な課題が寄せられるケースです。そうした課題への解決策を検討した結果、CMS導入にたどり着く流れが多いですね。

株式会社コンセントでウェブディレクターを務める山﨑貴史さん

小山直樹(以下、小山) すでに何らかのCMSを導入している企業からご相談をいただくこともあります。その場合は、現行環境を活かすのか、それともリプレイスするのかを見極めるところから始まりますね。

──ご相談に来られるクライアントには、どのような方が多いのでしょうか。

山﨑 かなり幅がありますね。たとえばマーケティング部門の担当者であれば、MAやCRMとの連携を前提に、CMSに求める機能や運用体制まで具体的にご相談いただくケースもあります。逆に、CMS自体にあまり馴染みがなく、基本的な役割や仕組みからご説明するケースも少なくありません。

小山 Web専任ではなく、ほかの業務と兼任されている担当者も多いですし、他部署から異動して着任したばかりという方も少なくありません。いわゆるメガベンチャーのように、社内に知見が蓄積されている企業はごく一部。実際には専門知識を持たない担当者の方が多数派だと感じます。

株式会社コンセントでフロントエンドエンジニアを務める小山直樹さん

予算・体制・機能要件……CMS選定を難しくする判断材料

──要件を整理したうえで、CMSの導入やリプレイスを検討する段階では、どのように選定を進めていくのでしょうか。

山﨑 まず確認するのは、サイト運用の体制です。更新作業を自社で内製したいのか、外部パートナーに依頼するのかで、適したCMSは変わってきます。あわせて予算も重要です。初期導入費だけでなく、月額利用料や保守費用まで含め、年間でどの程度のコストになるのかを見ながら、現実的な選択肢を絞っていきます。

小山 出発点としては、「そもそもCMSが必要なのか」をしっかり見極めることですね。更新頻度はどれくらいか、継続的な情報発信を想定しているのか。加えて、承認ワークフローの有無、ステージング環境の必要性、静的構成と動的構成のどちらが適しているかなど、要件を一つずつ確認していきます。そのうえで、優先順位の高い要望から整理し、現実的な選定につなげていきます。

──そうして要件を絞り込んだうえで、具体的なCMSを選んでいくわけですね。

山﨑 そうですね。一般的には、小~中規模で大がかりなシステム開発を伴わないことが多いと思います。そうしたケースでは、自由度や拡張性を重視するのか、あるいはテンプレートベースで制約はあるものの、運用負荷やセキュリティ対応をサービス側に任せられるSaaS型CMSを選ぶのか、といった判断になります。

加えて、「特定の制作会社やベンダーでないと運用しづらい状態は避けたい」というベンダーロック回避の要望もよく挙がります。そういった場合には、WordPressやMovable Typeのような導入実績が豊富なCMSが有力候補になることが多いです。

小山 セキュリティ要件については、クライアントの基準によって、オンプレミス型が適するのか、SaaS型が適するのかが変わることもあります。SaaS型CMSであれば、保守やメンテナンスの責任範囲をサービス提供側に切り出せる点はメリットです。一方で、独自のクラウド利用基準を設けているクライアントの場合には、SaaSサービス自体の導入が難しいケースもあります。

西 その点は、本当に企業ごとに考え方が違いますよね。最近は、以前よりもSaaSへの理解が進んできた一方で、業界や企業規模によっては慎重な判断が続いている印象です。

山﨑 逆に、WordPressのようなオープンソースCMSが、社内のセキュリティポリシーに抵触して採用できないこともあります。CMS選定は、機能比較だけでなく、導入企業側の事情まで踏まえて判断する必要があるんです。

CMS選定をフラットに進めるために、押さえておきたい前提条件

──WordPressの話も出ましたが、ここからは、より身近な選択肢であるWordPressを含め、小〜中規模案件ではどのようにCMSと向き合うべきか、さらにうかがいたいです。

山﨑 私たちコンセントは、特定のCMSを強く推す立場ではなく、お客様の要件に応じて最適な選択肢をご提案することを基本姿勢にしています。そのため、複数のCMSを比較しながら、それぞれのメリット・デメリットをあわせてお伝えし、クライアントがフラットに判断できる状態をつくるようにしています。

小山 場合によっては、プロトタイピングの機会をご用意することもあります。たとえば弊社側の環境で実際に構築してみたり、SaaS型CMSでテスト環境が使える場合は、実際に触っていただいたりします。管理画面の使い勝手は、資料だけでは伝わりにくいですから。

西 制作会社の皆さんが、どういう基準でWordPressを選ぶのか、あるいは別のCMSを提案するのかは、率直に気になるところです。

わかりやすい判断軸としてコストがありますが、WordPressは本体こそ無償でも、サーバーOSやPHP、データベースといった実行環境を常に最新の状態に保つ必要があります。加えて、セキュリティ監視を継続していくなど、「環境を維持するための見えにくいコスト」は別途考えなければなりません。

これを企業が自社で、あるいは制作会社様が継続的に担っていくのは、一定の負担とリスクを伴う領域でもあります。

一方で、dinoであれば月額5万円(最小構成)からの利用料の中に、こうした保守管理が含まれています。制作会社様が個別に対応してきた管理負荷を軽減できる点は、運用面での大きなメリットです。トータルで見れば、コストと安全性のバランスという観点でも、合理的な選択肢の一つになるのではないでしょうか。……と、私の立場から言うと、少しポジショントークに聞こえるかもしれませんが(笑)。

「今求められるCMS」をテーマにディスカッションする3人

山﨑 確かに、そのあたりは後から効いてくる部分ですよね。

──制作会社として、WordPressに慎重になるのは、どういう場合ですか

山﨑 まず、クライアントのセキュリティ要件やガバナンス方針と、WordPressが合わないケースですね。特に大企業や公共性の高いプロジェクトでは、CMSの機能性だけでなく、脆弱性対応、変更管理、運用責任の所在まで含めて評価されます。そうした条件では、責任分界点が明確にしやすいインストール型CMSやSaaS型CMSが選択肢に入りやすくなります。

小山 あとは、求められる編集体制や運用設計とマッチしないケースもあります。WordPressは自由度が高い反面、運用ルールまで含めて厳格に統一したいプロジェクトとは、必ずしも相性がいいとは限りません。更新担当者のリテラシーに左右されず、迷わず操作できることや、入力項目を整理した管理画面を重視する場合には、別のCMSをご提案することもありますね。

西 そうですね。結局、「多機能であること」と「使いやすいこと」は、運用の現場では往々にしてトレードオフになります。

WordPressで独自に作り込めば、理論上は何でも実現できます。ただ、その分、管理側の負荷や教育コストは増えますし、属人化のリスクも高まっていきます。

目先の構築のしやすさだけでなく、「5年後も同じ品質で更新し続けられるか」という視点で、自分たちの運用体制の限界を見極めることが重要です。そのうえで、編集者が迷わずコンテンツ制作に集中できるよう、あらかじめ「制約と標準化」が設計されたツールを選ぶ。これこそが、導入時に慎重に検討すべきポイントだと思います。

人為的ミスを防げるか。見落とせない権限管理と保守体制

──WordPressか、それ以外のCMSかを考えるうえで、保守面など他に意識すべき観点はありますか?

小山 WordPressは拡張性が高い一方で、プラグインや独自カスタマイズが増えるほど、将来的なアップデート対応や互換性確認など、保守の負荷も大きくなりやすいです。数年単位で安定運用していくことを重視するなら、有償で長期運用を前提に設計されたCMSが候補に挙がることもあります。

また、IR(投資家向け情報)のように、取り扱いに慎重さが求められる情報を扱う場合もあります。そうしたケースでは、「誰が、どこまで操作できるか」といった権限管理を標準機能として備えているCMSは、有力な選択肢になります。

──この点、dinoはいかがでしょうか?

西 dinoは、サイト構造を定義するための管理画面と、日々のコンテンツを更新する編集画面を、完全に分けて設計しています。それぞれに対して個別のアカウントを発行できる仕組みです。

──構造設定と日常運用を切り分けたうえで、権限管理もしやすい設計なのですね。

西 その通りです。たとえば、サイト構造側の管理画面は制作会社のみに開放すれば、運用担当者が誤って触れてしまうリスクを防げます。

一方、記事制作側の画面でも、「自分の記事だけ編集できる」「全記事を編集できる」「編集はできるが公開権限は持たない」といったように、ユーザーごとに細かく権限を設定できます。結果として、誤操作など人為的なミスを防ぎやすくなります。

実際に、運用体制やガバナンスを重視する企業様にdinoをご採用いただくケースも多く、そうした要件との相性は評価いただいていると感じています。

リボルバーが開発・提供する国産SaaS型CMS「dino」。ユーザーごとの細かな権限設定にも対応し、人為的ミスを防ぎやすい点も特徴。

山﨑 権限管理は、実際によくいただく要望の一つです。標準で機能を備えていないCMSの場合、プラグインを組み合わせて後から実装する必要があります。その点、標準機能として備わっているCMSであれば、制作会社としても安心して提案しやすいと思います。

──システム上の継続的な安全性は、CMS導入の成否にかかわります。

小山 そこは「CMSのアップデートがいかに重要か」という点ですね。サーバへインストールするオンプレミス型の場合、アップデートのたびに検証が必要になりますし、ときには手動対応の工数も発生します。SaaS型の強みは、そうした保守の手間をサービス提供側が担えることです。

山﨑 ただ、国産CMSのなかには、セキュリティパッチや細かなアップデート対応について、不透明に見えてしまうものもあります。

西 dinoはSaaSとして、私たちリボルバーが責任を持ってアップデートを行っています。ただ、実はアップデート内容を細かく公表しすぎると、それ自体がリスクになりかねない面もあって……なかなか難しいところです。

山﨑 たとえば「こういうライブラリを使っているのか」と、必要以上の情報まで見えてしまう可能性がありますからね。

西 はい。ただ、何もお伝えしないことが、ユーザーの不安につながってしまうというご指摘も、ごもっともだと思っています。社内のエンジニアに怒られるかもしれませんが、開発や運用に関するアナウンスの仕方は工夫していきたいですね。

“完璧なCMS”はない。だからこそ、運用まで支えてくれる選択肢を

──Web制作会社から見たとき、「WordPressか、それ以外か」と悩む案件で、率直にdinoが選択肢になる可能性はいかがでしょうか。

西 dinoはクラウド型CMSなので、必要な環境は私たちが用意します。導入後のシステム運用やセキュリティ対応を過度に気にせず、コンテンツ制作に集中しやすいのがメリットです。不具合があれば、リボルバーに問い合わせていただければいい。そうした責任の所在を明確にできる点は、導入企業にとっても、実装を担う制作会社にとっても利点なのではないかと考えています。

山﨑 日頃からCMS導入や運用を支援している立場から感じるのは、「完璧なCMSは存在しない」ということです。だからこそ、困ったときに相談できるか、継続的に伴走してもらえるかといったサポート体制が手厚いCMSほど、強みは大きいですよ。

小山 あとエンジニア目線で気になるのは、dinoの実装時や運用時に、どの程度エンジニアが動く必要があるのかという点ですね。

西 基本的にdinoでエンジニアの出番は、HTML/CSSやJavaScriptを用いた見た目の調整など、フロントエンド領域が中心になります。もともと、カテゴリやディレクトリのような階層構造を前提とせず、記事をタグで整理して一覧化する設計です。そのため、後から構造を見直したり整理したりする際にも、柔軟に対応しやすい。運用を続けながらサイトを改善していけるのが特徴です。

たとえば、サイト公開後に「このトピックが伸びている」とわかった場合でも、ディレクトリ構造を組み替える必要はありません。タグを付け替えるだけで、特集ページのような見せ方をすぐに作ることができます。こうした「データに基づいた機動力」こそが、Webサイトをグロースさせていくうえでの、dinoの強みの一つだと考えています。

小山 ありがとうございます。今まであまり馴染みのなかったCMSでしたが、徐々にdinoの実装イメージが湧いてきました。

山﨑 最終的には「自由度を優先するのか、運用性や安全性を優先するのか」で判断は変わります。後者を重視する場合、dinoを知っていることで、これまでになかった選択肢が増えると感じました。

西 ありがとうございます。私たちとしても、“dinoありき”で考えていただきたいわけではありません。ただ、目先の管理コストを優先して、セキュリティやメンテナンスを後回しにしてしまうと、万が一の際にかえって大きな損失につながることもあります。そうした運用負荷やリスクを、組織としてどうコントロールしていくか。その観点で考えたときに、dinoは合理的な選択肢になるのではないかと思っています。

本来の目的であるサイト運用に集中するためにも、足元でつまずかないために、先々まで見据えた判断のお手伝いができればと思っています。

取材・文:遠藤義浩 写真:黒田彰、企画協力:株式会社リボルバー
※本記事は株式会社リボルバーとのタイアップ企画です。

  • URLをコピーしました!
目次