ウェブサイトに独自CMSが必要になるのはいつ？

記事を最初から最後までたどる

チームがCMSで記事を書けても、承認のためにファイルをメールでやり取りしていたり、後日の修正がメインサイトには反映されても別の言語には反映されなかったりするなら、システムを入れ替える前に、まず一つの記事を公開まで一通り進めてみましょう。どこで作業が止まるかを見れば、何を変える必要があるのか分かります。

CMS（コンテンツ管理システム）は、ウェブサイトで使うコンテンツを準備し、管理する場所です。独自のCMSが必要かどうかは、公開後も含め、どのような作業を支える必要があるかで決まります。

二つのウェブサイト向けに、二言語の記事を準備する架空の出版社を考えてみましょう。ライターが記事を作成し、編集者が確認し、公開担当の編集者が公開時期を決めます。その後、チームは事実を訂正し、記事の一部を別の記事に再利用します。架空の記事を使い、実際に作業する人たちと一緒に、この流れを最初から最後までたどってください。

作成：コンテンツを使いやすく保管する

ライターに、見出し、本文、画像、キャプション、クレジット、別のページで必要になる情報を入力してもらいます。次に、それらを検索して更新してもらいましょう。クレジットがキャプションの中にしかない場合、画像を再利用するときに見つけられるでしょうか。

構造化コンテンツとは、著者、イベントの日付、製品仕様などを個別のフィールドに保存し、システムが一貫して使えるようにすることです。こうしたフィールドが必要だからといって、それだけで独自CMSが必要になるわけではありません。たとえばWordPressは、コンテンツの種類ごとに使えるカスタム投稿タイプをドキュメントで説明しています。

現在のCMSを保守している人に、例の記事をどう扱えるか実演してもらいましょう。フィールドが足りない問題と、同じ元記事を各言語版に関連付けられないといった、より根本的な問題を分けて考えてください。必要な変更は大きく異なるかもしれません。

レビューと修正：判断の流れを明確にする

編集者に修正依頼を付けて原稿を差し戻してもらいましょう。ライターが修正して再提出します。二人とも、どの版が確認中か分かりますか。公開担当の編集者は、ライターに公開権限を与えずに、その版を承認できますか。

既存のCMS製品には、すでに役割を分ける機能があります。WordPressの権限とロールに関するドキュメントには、編集、公開、管理それぞれの異なる権限が記載されています。したがって、編集者が複数いる場合は権限を確認する理由になりますが、それだけで再構築が必要とは言えません。

ロールだけでは、承認プロセス全体を確認できません。この例では、承認後に段落を変更して、どうなるか確かめましょう。変更後に再レビューが必要か、誰が例外を認められるか、チームがその判断をどう確認できるかを決めてください。ライターと編集者が実際に使うアカウントで、サプライヤーに実演してもらいましょう。

公開予約：公開される版を確認する

公開担当の編集者に、承認済みの記事を予約してもらいましょう。予定時刻の前に、最後の修正も加えます。どの版が予約されていますか。翻訳版の準備もできていますか。一方のウェブサイトだけ先に公開できますか。

ソフトウェアを試す前に、望む結果を書き出しましょう。出版社によっては両方の言語を同時に公開したいかもしれませんし、別々の予定で公開してもよいかもしれません。どちらも編集上の選択として妥当です。CMSは、今後の動きをチームに示し、適切な人が変更できるようにする必要があります。

有効な実演では、記事の公開延期と、予定する各掲載先の公開プレビュー確認も行います。日付フィールドがあるだけでは、公開プロセス全体が機能するとは言えません。

訂正と再利用：公開後も作業は続く

この例では、翌日に読者が事実誤認を見つけます。公開中の記事をそのまま残した状態で、編集者に訂正文を準備してもらいましょう。誰が変更を承認できるか、以前の文章を復元できるか、訂正理由をどう記録するかを確認してください。

次に、訂正が他の言語やウェブサイトにも反映されたか追跡します。チームには、対応が必要な版と担当者が分かる必要があります。共通の日付や仕様は自動更新に向くかもしれませんが、翻訳文は人が修正して承認する必要があるかもしれません。何を共有し、何に個別の編集判断が必要かを決めましょう。

最後に、段落と画像を新しい記事で再利用します。その段落は元記事との関連を保つべきでしょうか。それとも独立したコピーにしますか。元記事が再び変更されたとき、新しい記事も変更するのか、通知を出すのか、そのままにするのかも決めましょう。また、チームに素材の再利用権があることを確認してください。CMSの機能によってコンテンツの権利が得られるわけではありません。

実演結果を課題一覧にまとめる

各段階で実際に起きたことを記録します。各項目に、必要な動作、現在の設定で実演できたこと、不足している点、提案する変更、その後の保守担当者を記録してください。現在使えている機能も一覧に残し、変更案でも維持できるようにします。架空の出版社なら、たとえば次の項目が考えられます。

現在のCMS、拡張機能、独自開発を比較する

まず現在のCMSで課題一覧を確認します。設定、より分かりやすい編集画面、既存機能の使い方の変更で、一部を解決できるかもしれません。実際に使っているバージョンと設定で結果を確認してください。

残る課題については、対応済みの拡張機能で何ができるか尋ねましょう。承認後の修正や公開後の訂正も含め、同じ記事の流れをサプライヤーに実演してもらいます。拡張機能の保守担当者、CMS更新後の確認担当者、互換性の問題を直す担当者を明確にします。公開や訂正が失敗したとき、誰が気づき対応するかも決めましょう。機能を追加すると、誰かが保守する作業も増えます。

重要なルールを許容できる形で実現できない場合や、必要な追加によってチームが無理なく保守できない構成になる場合、独自開発を本格的に検討できます。既存CMS向けの専用拡張機能か、独立した独自システムが選択肢になるでしょう。課題一覧を使えば、どこまで開発する必要があるか明確になります。

初期費用だけでなく、更新、権限、バックアップと復旧、編集者の研修、サポート、利用終了時のコンテンツ書き出しなど、継続的な作業も比較してください。サンプルのエクスポートを依頼し、必要なフィールド、関連付け、メディア、言語版、有用な修正履歴が含まれるか確かめましょう。既存製品と独自開発案のどちらにも同じ確認を行います。

英国政府のテクノロジー調達ガイダンスでは、ニーズや継続的なサプライヤー管理とあわせて、既存製品の改修とソフトウェアの開発を検討しています。より幅広い質問をする根拠にはなりますが、この出版社に合うCMSを選んでくれるものではありません。

公開サイトのリニューアルは別の判断にする

読者が見るのは記事ページ、ナビゲーション、検索です。編集者が使うのはフィールド、レビュー手順、公開管理です。どちらも大切で、連携することもあります。しかし公開サイトのデザインが古いからといって、編集システムの交換が必要とは限りません。

公開サイトの変更と編集上の課題を分けて説明しましょう。それぞれ独立して進められる作業と、相互に依存する部分を確認します。これにより、新しい記事レイアウトの話が、今も機能している公開プロセス全体の入れ替えにすり替わるのを防げます。

当社は独自CMSの開発を提供しています。何を変えるべきか一緒に整理したい場合は、代表的な記事を一つと、その作成から公開までの課題一覧をお持ちください。範囲、ライセンス、引き継ぎ、継続的な保守は個別のプロジェクトごとに合意します。

CMSを選ぶ前に確認したいこと