CMSを考える時の15個くらいのテーマ
こんにちは。年末で普段の経理や総務の業務も一段落しちゃったので、「CMS（コンテンツ・マネージメント・システム）」について少しまとめてみようかなって思います。
普段目にするWebサイトには、おおよそ、その後ろ側に何らかのCMSが存在しています。CMSはそのドメインに所属する人間が目的をもって意図的または恣意的にコンテンツを操作・管理するための機能を提供します。CMSへの要求／要件は運営するWebサイトの目的に応じて様々です。ほとんど何も考えずに実現できちゃう場合もあれば、ここに書いたこと以外にも考えなくちゃいけない事が出てくる場合など多様です。CMSが必要になった時にちらりと見てもらい（チェックリスト程度に）何かのご参考になればと思います。
最近は『Web3』という新たなムーブメントが起きていますね。関連する記事に触れると、とても楽しくワクワクします。Web3とは少し違うかもしれませんが、今年は『ChatGPT』にも驚きましたね！将来振り返ると、ChatGPT前と後で線が引けるくらいのインパクトだったかもしれません。すっごく遊んじゃいました。2023年もWeb周辺のテクノロジー世界はとてもエキサイティングで楽しそうです。残念なことに私が知っているのはWeb1.0からWeb2.0までです。また、仕事で一番長く携わったのはメディアサイトであるため、後段のCMSのポイントはやや偏りがあり内容も古いかもしれません（モダンな事はわからない）。ご了承ください。
前置きが長くてすみません。それでは、以下にCMSを考えるときのポイントを項目ごとにまとめます。
CMSは必要か？
このnoteのシステムも広い意味ではCMSになります。YouTubeだってInstagramだってTikTokだって使い方によっては立派なCMSです。もしも、単に情報発信をしたいというだけであれば、これらプラットフォームを利用する（組み合わせる）ことで目的を達成できるかもしれません。プラットフォームに依存しない独自のCMSが欲しい理由がある場合にも「CMSは必要か？」を一度、自問してみるのは必要かもしれません。軽量な物でもCMSを準備するのはそれなりに労力が必要ですし、CMSを作ることが目的になることはまず無いためです（CMSは永遠の手段です）。
1.コンテンツ管理
コンテンツの種類
コンテンツのタイプ、動画、画像、インタラクション、コメント、UGCなどなどコンテンツの種類と見せ方を整理しましょう。コンテンツの種類を明確にして、欲しい機能を考えていくアプローチです。また、コンテンツの種類が分かってくるとCMS上でのデータモデルが決まってきます。
例えば文章中心の「記事」を主のコンテンツにする場合、それが取材記事なのかコラム記事なのかインタビュー記事（対談形式）なのかや、学術的なものなのか、まんがやクイズや占い的なものなのかなどなど深堀していってタイプを分けていきます。そして企画している内容に沿って表示する要素が変わる可能性があるものを洗い出していきます。
可能ならタイプに応じてどのような要素（タイトルや日付、作者名や説明文等）があるかも整理をしておくと後々役立ちます。
整理したコンテンツの種類やタイプ、構成要素からCMSに必要な設計やデザインを進めていくことができます。
マークアップとテキストデータの分離
コンテンツ（文章など）にマークアップ（HTML等）を含めるかどうかを検討しましょう。例えば、CMSにHTMLタグを含めた記事を入稿する場合、そのサイト上ではHTMLに基づいたテキスト表現ができます。しかし、外部へ配信をした際には、そのHTMLが原因で表示崩れが発生する可能性があったり、サイトリニューアルをした際に、新しいデザインの邪魔になってしまう場合があります。表現力と機能のトレードオフになります。なるべくテキストとマークアップは分離をすることでコンテンツの再利用性が高まるかなと思います。最小限のマークアップを使い両立する方法もあるかもです。エンジニアと要相談ですね。
コンテンツの履歴管理
変更履歴を残せる形にしておくと、問題が発生した際の検証に役立ち、コンテンツの校正情報としても貴重なデータになります。将来役立つかもしれません。いっぱい取っておくとデータが肥大化しストレージを圧迫していきがちですが取っておけると良いかもです。
2.読者の管理
ユースケース
サイトに会員機能を設けようと考えた場合、会員の5W1Hをイメージしておくとよいです。会員管理はサイトのビジネスモデルやサービスの特性、グロース戦略に直結する場合が多いため、しっかりイメージしておくことでCMSの設計にも余白を設けておくことができます（たとえ会員管理機能をCMSから分離する構想だったとしても）
「だれ（Who）がいつ（When）会員になるの？」
「なぜ（Why）会員になるの？」
「どのように（How）動いて何を（What）得るの？」
「どこで（Where）何を（What）するの？」
などを整理していきます。これらはCMSも含めたWebサイトのユースケースとして設計に役立ちます。
個人情報
2022年4月に改正個人情報保護法が開始されました。個人情報の取り扱いは、国内外ともに年々要件が厳格化していきます。個人情報の管理は何よりも優先して考えておく必要があります。適切に管理ができていなければどんなに良いサービスでも、個人情報漏洩で一発アウトです。会員獲得をする際にどの個人情報をどこに保管して管理していくか（利用目的などの明確化）も合わせてイメージをしておきましょう。
そのうえで、会員の利便性を考えログイン方式（ソーシャルログイン）や独自IDなどを考えていきます。
3.デザイン・テンプレート
サイトデザインはサイトの目的やコンセプト、読者やビジネス、運用などの観点から考えていくことでしょう。Webデザインはある程度体系化されており、いくつかの基礎や原則、デザイン思考など理論的に整理されています。デザイナーと話をするために軽く理論を調べておくと話が弾んでよいかもです。Webデザイナーはこれらの理論をもとに、コンセプトを分解したり、必要があればペルソナを分析し、そこに感性やオリジナリティーを加えデザインを作っていきます。時には流行に沿って「〇〇デザイン」とか「△△効果」といったトレンドを組み込んでいくこともあります。デザイナーと良好なコミュニケーションが図れたと感じられた場合は、思い切って余計な口出しはせずにお任せしてしまうのもよいです。
CMSでは「テンプレート」の実装という点からデザインに対して次の事を考えておくことよいです。
ページ要素の統一
一般的には、「コンテンツの種類」で抽出した要素が、ページの種類によってバラバラだとその分テンプレートが増えていきます。テンプレートが増えればコーディング（デザインをコード化する作業）の工数は増え、保守も大変になっていきます。時にはデザインと要素のトレードオフが必要です。
モバイル対応
MFI（モバイルファーストインデックス）への対応は必須でしょう。レスポンシブデザインにするかアダプティブデザインにするかは意見が分かれるところです。それぞれにメリット・デメリットがありますが、どちらにしてもモバイル対応の要否や考慮をしていきましょう。
対象ブラウザ
コーディングの前に対象ブラウザを決めましょう。今時はフロントエンドの開発環境（トランスパイラーや他タスクランナー）が素晴らしく進化しているので一昔前よりは格段にコーダーの苦労も減っています。しかしながら沢山のブラウザを対象にすると将来にわたって工数は膨らみます。マイナーなブラウザは切り捨てる勇気も必要です。
Core Web Vitals
Googleの検索結果にも影響があるのでSEOの面でも重要ですが、読者がコンテンツを見るにあたって快適な体験を作りましょうというのがCore Web Vitals（コアウェブバイタルズ）の本質かなって思います。表示速度や反応速度、視覚的安定性などを意識したテンプレート実装が求められます。不必要な視覚効果や処理系の排除、処理系の非同期化やコード全体の圧縮などを検討する必要があります。テンプレートの実装の段で、もしくはコーダーへの要件としてCore Web Vitalsへの対応を検討しましょう。
デザイン・テンプレート関連ではこの本おすすめです。
4.ペイウォールや決済
これから作るサイトにサブスクや課金型コンテンツを考えている場合、一般的には決済の仕組みはCMSと別のシステムで検討・実現すると思います。ただし、ペイウォールや課金の発動をCMS側で制御したり、課金の有無によってサイトの挙動をかえる場合、事前にその内容を整理してエンジニアに相談をしておくとよいと思います。（ユーザーユースケースで整理もしておく必要がありますね）
オンライン決済・課金を代行提供するサービスは沢山あります。
クレジットカード情報の保護を目的とした国際規格にPCI-DSSというものがあります。大規模なサイト以外は自前でクレカ決済システムを作ることはないでしょうから、PCI-DSSに準拠したオンライン決済サービスを比較して、どれを組み込んでいくか選ぶことになるかなと思います。
余談ですが、オンライン決済の経理処理は、入金方法やタイミング、役務の提供期間によっていろいろ変わります。もし、所属組織に経理担当がいるのであれば、検討時に仕訳けの相談をしておくと安心です。
5.広告関連
こちらもCMSと切り離されて考える部分ですが、Webサイトに広告を掲載したいなと考えた際にはアドサーバーの検討が必要です。アドサーバーの主な役目は広告枠の管理や広告在庫の管理や計測です。アドサーバーにもいろいろありますが、基本的には広告枠の設定をすると、「アドタグ」というものが払い出されるので、このアドタグをテンプレートなりCMSのデータベースに記録をしておき、サイトにアクセスがあったら出力されるようにします。アドサーバー自体でも様々な条件によって広告の出し分けをする機能がありますが、新しくCMSを作りWebサイトを運営する場合には、事前にどんなディスプレイ広告を組み込もうとしているのか考えておきましょう。アドネットワークでは広告のサイズ（横幅何ピクセル縦幅何ピクセル）が決まっていたり、時代や目的に応じて流行りのサイズなどもあります。流行りのサイズは出稿数も多いため広告収益につなげやすいかもしれません。サイズが分かると違和感なくサイトに組み込めるデザインがつくれます。昨今の広告はビューアビリティーというのを重視する傾向にあります。ビューアビリティーを調べておくのもGoodです。
6.コンテンツ配信力
「コンテンツ配信力」ってなんだよ？という感じですが、コンテンツをなるべく多くの人に見てもらうためにCMSで検討しておきたいキーワードを箇条書きします。
キュレーションサイトへの対応
大手のポータルサイトやキュレーションサービスでは、コンテンツ掲載を受け付けるための窓口や様式を準備しています。サイト公開当初は大きなサイトにコンテンツを掲載してもらうことで、新しい読者の獲得や知名度アップを期待できるかもしれません。様式が準備できれば運営側のある程度の意図に沿ったコンテンツ配信ができるようにもなるかもしれません。カスタマイズができるRSSフィードが出せる仕組みなんかが準備できるとベストです。
動的配信／静的配信／キャッシュなど
一般的に動的配信はサーバー負荷が高く、静的配信はコンテンツ管理が面倒です。コンテンツがバズり、アクセスが集中した場合、動的配信の方が静的配信よりも先に悲鳴を上げます。せっかくアクセスがあったのだからできるだけ多くの人にコンテンツを届けたいものです。ただし、潤沢な設備を準備しておくと日々のランニングコストに跳ね返ってきます。「毎月これくらいの金額内で、最大でここまでのアクセスに耐えられるようにしたい」というイメージをもっておくといいかなと思います。エンジニアがサーバーメモリーの活用やCDN利用の提案、仮想サーバーやコンテナのオートスケーリングなどを考えてくれるでしょう。アクセス集中時にサーバーダウンは仕方がない！として必要最低限の設備で運営し、実際にダウンした際はSNSや他のプラットフォームで読者にアナウンスをしていくという作戦も場合によってはありかもしれません。CMSを提供するクラウドサービスの中には、アクセス集中時の負荷分散をそもそも考えなくてもよいものもあります。それらを検討するのもありですね。バランスですね。
7.マーケティング
SEO
SEOは超重要です。SEOには大きく内部施策と外部施策がありますが、CMSが担うのは主に内部施策です。検索エンジンのロボットに運営側の意思を伝えるために制御ファイル（robots.txtやsitemap.xml）を準備したり、適切なHTMLタグを出力したり、metaタグに運営者の意図を反映できる機能があったりすればまずはOKです。CMSによってはSEOパッケージやSEOプラグインが準備されているものも多いので、それらができることを確認しておくのも大切です。
SNS連携と運用
CMS側でSNSの運用をどこまでカバーするかを考えておきます。よくあるのは、コンテンツの公開と一緒にSNSにURLを投げ込む機能です。個人的には、CMSにSNS連携機能はあまり必要ないかなって考えています。以前、エンゲージメントを計測するダッシュボードが実装されたCMSを見たことがありますが、SNS側でのAPI仕様変更がおこなわれるたびに対応に追われ大変そうでした。SNS運用は様々な専用ツールがあるのでそれらを活用するのが良いかなと思います。もちろん「欲しい機能を提供するツールが無い！」とか「利用料が高額！」などあればもちろん自前で実装してくことも戦略上ありです。
アクセス解析ツール
こちらも、直接CMSの機能ではありませんが、Google Analytics 4などのアクセス解析ツールは自分のサイトを客観的に分析していくために必要です。ビジネスによっては、CDPやDMPやBigQueryなどが必要になってくる場合もあります。CMS側にはタグマネージャーのタグを設定し、計測用のタグはタグマネージャー側に設置するというのが今時のよくある形かもしれません。
アクセス解析ツールの標準タグを入れただけでは分析できることも限られてきます。ここはある程度、専門的な知識も必要になってくるので場合によっては、ウェブ解析士やデータアナリストへ相談が必要になる場合もあります。
8.ユーザー管理
CMSを使うユーザーの管理についてです。
入稿・公開のワークフロー整理
入稿→編集→確認→公開（停止）などのワークフローを考えます。
こちらも、誰が何をする？公開（停止）は特定の権限がある人しかできない？などを5W1Hでユースケースを作り整理していくといいかもです。
ユーザーグループと権限
出版社や新聞社の組織でイメージするなら、「ライターグループ」、「デスクグループ」、「校閲グループ」、「制作グループ」などの役割に応じたグループをCMSに定義するかどうかを検討します。これらグループごとにアクセスできる機能やコンテンツの権限（ACL）を整理していきます。
ログイン方式・アクセス方法
不正アクセスなどで情報漏洩したら大変です。CMSを乗っ取られたら一大事です。２要素認証やアクセスログの管理を検討しましょう。
9.ファイル管理
コンテンツ素材
例えば、別々の記事で同じ写真を利用するということは、よくあります。同じ写真なのに記事ごとにアップロードしていたら、画像URLも複数できちゃいますし、ストレージも圧迫していきます。万が一に、第三者の著作権や肖像権を侵害するような画像が紛れいていた場合、適切な管理ができていないと対応も遅れます。なるべくルールに沿って階層的・時系列的に検索できるようになっているのが理想です。
記事に関連する画像をアップロードすると、CMS側でサムネイルやSNSに最適化されたサイズにトリミングやリサイジングする機能が欲しくなったりします。この辺は、実際に運用を行っていく中で利用者の声を反映して追加機能開発ができるとよいですね！
アセットファイル
サイトデザインで使う画像やCSS、JavaScriptなどをここではアセットファイルと呼びます。これらも一般的にはCMSで管理する対象になってきます。
CSSやJavaScriptはサイトの運営によって肥大化し管理や保守が大変になっていく傾向にあります。その為、それぞれに設計思想（BEMやらFLOCCSなどなど）やフレームワーク（VueやReactやらTypeScriptなんか）やツール（Webpackやnpmやnvmなど）が考えられています。プログラマやコーダーの管理しやすい方法を採用してうまくCMSに連携ができるとよいですね。
Embedコンテンツ
ファイル管理から少し外れますが、YouTubeやInstagram、Twitterなどの埋め込みコンテンツをどこまでCMSで管理するかというのはたまに議論になります。ファイルと同様に素材としてCMS上で管理されていると再利用などの面からいいかもです。サイトの特性によって判断かもしれません。
10.URLの構造
これから作るWebサイトのURL構造を考えておくのも大切です。あまりに長いURLや、一貫性のないURL体系だと、読者やクライアントが混乱したり、シェアするときに苦労したりもします。コンテンツの階層やグループ分けのイメージを明確にしておく感じです。記事のカテゴリーや特集、コラムに応じたディレクトリーを設けるのか？著者、タグなどによるコンテンツ一覧ページを作るか？（コンテンツのメッシュ化など）、記事のページネーション要否など事前に整理をしておきましょう（サイトマップを作りましょう）。動的配信CMSの場合、コンテンツの公開URLに「?id=hogehoge」というようなパラメータが付いたり、URLは固定だけれどページ遷移に応じてコンテンツ内容が変わるという場合があります。これでも別にいいのですがあまりプロっぽさを感じません。URLはコンテンツ毎に一意なものしてGETパラメータなどが無い形が好きです（個人的な意見）。
11.プレビュー・開発環境
公開前のコンテンツのプレビュー機能は欲しいところです。
ワンタイムパスを使うものや、静的なWebページを出力するもの、プレビュー専用のCMSユーザーを作るものなど実装は様々かもしれませんが、どちらにしても公開後の見え方を公開前にチェックができるといろいろ便利です。
また、大規模なリニューアルや新機能の追加などをする環境もあるとベストです。エンジニア的にはローカル環境を除き、以下が欲しいところです。
プロダクト環境
一般公開している本番環境
テスト環境
軽微なバグ修正やマイナー機能の追加、新コンテンツの準備環境
開発環境
大きな修正やリニューアルなどを行う環境。サンドボックス的な環境
12.ユーザビリティ―（操作性）
CMSのユーザビリティー（操作性や分かりやすさ、間違えにくさ）は重要なのですが、割と諦めがちで後回しにされる部分です。「理想の形でサイトが公開できるなら操作性が悪い部分はマンパワーや慣れで克服し、開発費は別のところに掛けましょう！」となるからです。コンテンツ制作者の本来の仕事は、取材や文章作成、魅力的な写真・動画を作る事なので、CMSの操作性はなるべく良くし、入稿時の生産性を高めていきたいところです。
前述のユーザー管理のところに書いたワークフローの整理が、操作性を考える上でのユースケースとして役立ちます。
CMSの入力画面にリッチエディター（WYSIWYG（ウィジウィグ））を導入するかどうかが議論になることがあります。WYSIWYGを導入すれば、入力者はHTMLを理解していなくても、文章の強調や見せ方を変えられます。またマークアップとテキストデータの分離はされませんが、規則正しいマークアップがされることで、手入力でHTMLを指定するよりも再利用性は高まります。ただし、WYSIWYGで指定できる書式が増えれば増えるほど、実装はカオスになりますしコンテンツの再利用性も下がります。また、コンテンツの装飾が属人的になりがちです。その為、個人的には「WYSIWYGは賛成だが、書式はできる限り少なくするべき」と考えています。noteやmediumのエディタはそういった意味でも素敵だなと思います。
13.拡張性・保守性・継続性
Webのトレンドや法令・ビジネスモデルは刻々と変わります。導入するCMSに拡張性・保守性・継続性がありそうかを確認しておくことは大切です。スクラッチで作るCMSにはブラックボックスは無いので拡張性は高いですが、エンジニア確保の観点では必ずしも保守性や継続性は高いとは言えません。エンジニア体制が構築できていればどうにでもできちゃう点はかなり優位性が高いです。オープンソースのCMSはコミュニティーや市場シェアなどによってまちまちですが、市場シェアが高いものは拡張性・継続性・保守性は高めです。ただし、セキュリティーの標的にもなりやすく、保守の労力がかかる場合もあります。
クラウド型は勝手に機能が拡張されたり、保守もしてくれたりで安心ですが、継続性があるかどうかはそのビジネスモデルによるところもありますし、機能拡張が必ずしも希望するものかはわかりません。
14.データの永続性
もし、CMSをクラウド上に構築しようと思った際には、クラウドサービスが提供するストレージやデータベースに永続性が確保されているかは必ず確認しましょう。有名なクラウドだからといって安心してはいけません。設定が間違っていれば、何かのはずみでインスタンスが再起動したときに、データも初期化されます。クラウド事業者やクラウドインフラに長けたエンジニアにデータの永続性を確認しつつ、BCPやDRなどに備えデータのバックアップ＆リカバリーも検討しましょう。
15.開発体制
個人的に最も重要でありもっとも難しいと感じているのが、開発体制の構築です。専任のエンジニアやデザイナーでチームを作り、インハウス（内製）で開発ができれば、スクラッチだろうがOSSを使おうが、おおよそ成功したようなもんです。一説によればアウトソースして開発したものをインハウスに戻すためにはアウトソース開発で発生した工数がそのまま再び発生するといわれています。アウトソースはアンコントローラブルなリスクも内在します。その為、海外（主に米国）では「内製」が主流だったりするそうです。人件費はかかりますが、体制構築も検討をしていただきたいと思います。
けれど、やはりこれはとても難しい課題です。費用もそうですがエンジニアやデザイナーは早々すぐには集まりません。スタートアップだとなおさらかもしれません。今時は、副業エンジニアやクラウドソーシングでスキルを調達することもできますが、タスクを細分化すればメリットは高いかもしれませんが、丸ッとお願いできるかというと中々難し部分もありそうです。そうなると、親身に相談してくれる開発会社や、体力のありそうなSIer、親しい友人を頼っていかざるを終えません。
長々と書いちゃいました。Webサイトを作りたい！となった時に何かのヒントとかになればいいなって思います（あんまり役に立たなかったらすみませーん）