はてだBlog(仮称)

私的なブログど真ん中のつもりでしたが、気づけばWebサイト系のアプリケーション開発周りで感じたこと寄りの自分メモなどをつれづれ述べています。2020年6月現在、Elasticsearch、pandas、CMSなどに関する話題が多めです。...ですが、だんだんとより私的なプログラムのスニペット置き場になりつつあります。ブログで述べている内容は所属組織で販売している製品などに関するものではなく、また所属する組織の見解を代表するものではありません。

CMSを選ぶ時に消去法が有効(ノックアウト条件)

はじめに

CMS(Content Management System)を選ぶ時、などというと随分限定的な話になるが、そのような経緯はともかくとして、やたら製品数や選択肢が増えて、それぞれ機能が増えて◯×の数も多くなり、何を選んでわからなくなるものの一つがCMSだと思う。

だれかが◯×をまとめてくれているのを参照させてもらえばいいが、それはそれで、◯×△の加減の具合がはっきりしないことも多く、限りなく◯に近い△なのか、それとも×に近いのかと、かえって悩みを増やしてしまうことになる。

こういう時は、(今更偉そうにいう話ではないが、)消去法で消しこみしていくと良い。

ここでいう消去法は、重要だと思われる機能や仕組みが具備されているかを確認し、NGなら一旦選択肢から削ってしまうというものだ。

一方、消去法はわかったが、重要だと思われる機能や仕組みが選べれば苦労しないよということになる。

そのとおりだ。

なので、一般に重要だと思われる機能を一般的な優先度に従って並べたリストに従って見ていけば.... というところだが、実のところ、これは冒頭の○×のチェックリストの話に戻ったようなものだ。

また、そこまでいかずとも、「WYSIWYG編集」はあるかというようなマルっとした大きな条件でこれは重要だというところから入ると、コモディティ化された分野の製品だと×が付くものがほとんどなく絞り込みがかからない。

これでは解決にならない。

前置きが長くなった、そろそろまとめる。

まず、本来は重要だと思われるものにフォーカスするのは消去法に限らずもの選びの基準だろう。

ただし、それ自体が難しい。

では次の策として何があるかというところだが、これまでの個人的な経験からいうと、CMS界隈では少し法則めいたものがあるような気がしている。

今後もどれほど当てはまるかは保証できないが、というか今でも保証できないが、この順でノックアウト条件をチェックしていくと、どうやら用途にあったCMSがいっきに絞り込まれてくるというぞというものを発見的した気がしている。

ということで、この真偽のほどはともかく、次節にそれを書き並べてみる。

CMSノックアウトチェックリスト

ここでは、CMS製品を並べて○×をつけることはしない。

また、カタログはそれほど信頼ならん、用語の定義や解釈しだいなので、できるだけ製品担当者や有識者に確認することを前提とする。

裏返すと、有識者に質問する際に切り分けの質問として、できるだけそのまま使えるようなクローズドクエスチョン風のフレーズにした。

消去法、ノックアウト条件による振り分けなので、1番から順にそれが重要でない場合はスキップして、重要な場合は、有識者らにその製品がYESかNOかを聞く、NOが出たら一旦はその製品はノックアウトで予選落ちだ。

(A) CMSとして実現したいもののコンセプト(ひとえにCMSと言ってもサイトの役割によっていろいろある)

少し話の流れに反する面もあるが、一応サイトの位置付けとのすり合わせをした方が良い。誰かにきくというよりは自問自答しておく類の観点かもしれない。

  1. 入力フォームのあるページをノンコーディングで実現できるか。
  2. サイトの大半が上流システムから流れて来るデータを定型表示する(例えば「ネジ」の製品紹介サイトなど大規模カタログ型のサイト。PIM(Product Information Management 商品情報管理)の
  3. EC用の機能がフルセットで存在するか。在庫連携は相手があるので別途になるかもしれない。
  4. 予約など
  5. 会員向けサービスが提供したいが可能か。
  6. これは製品担当者に聞くというよりは逆に聞かれるかもしれないが、企業サイトか。特定商品サイトか。なんらかのキャンペーンサイトか。それ以外か。期間限定かどうかもひとつ。
  7. 実は社内ポータルなど、内輪限定か。
  8. 実質コンテンツらしいコンテンツは持たず、関連サイトへのリンクポータルというべきものではないか?

(B) 管理のコンセプト、マルチサイト、マルチユーザ関連

  1. 管理画面は存在するか。管理画面が存在しないものも無いわけではない。裏返すとそのようなものは構築の手間はあるがAPIなどが用意されており、管理画面自体を自作できる土壌がある製品といえる。(そうでないものもあるが)
  2. サイトがマルチテナント型に対応しているか。
  3. マルチテナントの限界数があるか。あるいは100テナントの実績はあるかような具体的な数字で問い合わせても良い。なお、サイト表示の方は大丈夫でも、管理画面の表示が遅くなったりコンテンツリストの類の表示時にハングするということもあるので、怪しい場合は、管理画面側について確認してみるのもありだ。
  4. 1つの管理機能のインスタンスで複数のドメイン違いの複数サイトを管理できるか。あるいは同一ドメインの中でも特定ディレクトリ配下ごとに別のテナントとして扱えるか。
  5. 前項などにおいて、各テナントやディレクトリ単位に、オーナーが異なるような方式にできるか、逆にオーナーをばらけないようにできるか。
  6. マルチユーザか。シングルユーザ前提か。
  7. ノンコーディングであるいは許容される程度の工数であらかじめシステム側として定型登録画面を用意できるか。
  8. 定型登録画面に対応した実際の公開ページはURLあるいはURLの特定の階層以下で何らかルール化や特定の条件に逸脱しないような枠組みをもうけられるか。例えば、地図表示ページはURLのファイル名がmap.htmlとするなど。

(C)実際の管理方法や操作の仕方に関わる

  1. 管理画面は、サイト、ディレクトリ(フォルダ)、ページのような構造か。そのままの構造かどうかよりも、これを例に当該CMSのデータの管理の構造を掘り下げて聞いて、ピンと来るかどうかを確かめると良い。ピンと来ないようであれば不運にも会話の相性の可能性もあるが、あとが続かないのでノックアウトされることもある。
  2. 前項のようなデータ管理構造だとして、管理画面の対象データへ検索やタグ付けによる特定コンテンツのページの編集画面に直接アクセスできるか。
  3. 前項のようなデータ管理構造だとして、それをWindowsexplorermacのfinderのようにツリー構造・フォルダ構造をドリルダウンしていきながら対象データにアクセスしていくことはできるか。1. 実際の内容が静的なコンテンツは静的HTMLとしてパブリッシュできるか。

(D)公開制御関連や承認関連

  1. 編集者と承認者を分けられるか
  2. 保存するとそのまま公開されてしまうか。下書き機能はあるか
  3. 一度公開したものを削除せずに非公開にできるか。
  4. 日付を指定した公開予約ができるか。また公開終了の予約ができるか。「期間限定」に対応できるか。
  5. 公開予約や下書きデータは、非公開領域に保持されているか、それともURLを知っていればアクセスできるなど概念上はインターネットからアクセス制限なしにアクセスできてしまうか。
  6. 公開予約や下書きデータを別の方法で伝えたパスワードを使ってCMSにログインすることなくインターネットから参照できるか。
  7. 公開中のものに影響を与えずに次版の下書き作成ができるか。
  8. 「削除」した際に、データは物理削除されているか。
  9. データのユニークキーはURLか、それ以外か。
  10. データのユニークキーがURLの場合、公開するURLを変えることができるか。それとも運用操作としてはコピー等をしつつ、別データとして対応するか。(公開するURLを変えられると別の混乱があるので、前者に対応していても必ずしも良いとは限らないことに注意)
  11. htmlとそのページの画像の関係はどうなっているか。もっと端的にいうと、ページ(html)のデータに画像がぶら下がるような管理方法か、それともそれぞれ別の資材として登録して、あとで紐づける方式か。※この観点についてはもう少し説明を付け加えるべきだが、この程度の雑な聞き方でも話が通じるかどうかで、相手のCMSに関する知見が透けて見える類の質問かもしれない。
  12. 複数の公開予約ができるか。ちなみにその場合の複数の単位や串刺しキーや各予約のユニークキーは?
  13. 承認ワークフローはどのようなものが実現できるか。キーワード:分岐、合流、グループへのアサイン、差し戻し、コメント引き継ぎ、都度アサイン方式かルートによってアサイン先が固定か、退職や休職で袋小路になった時に強制解除できるか
  14. 承認ワークフローにおいて、排他制御やアクセス制御ができるか。

(E) 編集機能そのもの(もちろんこれが一番大事だという話もある)

とりまとめ中

補足事項(言い訳など)

ほぼ前項の言い換えに該当するものも挙げている。これは言葉のアヤなどでお互いに都合よく解釈されてしまった場合のミスマッチの軌道修正のためだ。

また、言い換えとは逆に、要件や用途によっては、上記の書きっぷりと逆の方が望ましいというものもある。 上にある例だと定型登録画面で登録するページはURLの体系などに条件を設けたいという方を「期待する」ような例としたが、逆にURLの体系に縛りがあっては困って完全にフリーな方が良い(ただし重複はこまるのでチェック機構は必要)というようなものもある。

冒頭で、これさえYES/NOが分かれば、いっきに絞り込みができる...と言ったがあれはウソだ。 いやウソではないと思っているが、「そのまま程よく質問しやすい」粒の大きさを意識して書いたため、件数が増えてしまった。ごめんなさい。

繰り返しになるが、上から順にCMSをノックアウトさせていくことを意図した順序である。 前の質問に大きく先祖帰りしたような質問が後から出て来るというのは無いようにしたが、機能や体系に合わせて、上位から下位のようなピラミッド型で並べたものではない。

CMSを選ぶ時に有識者らに問い合わせしながらというストーリーでまとめたが、自分が誰かに良いCMSを紹介・仲介する際に、紹介相手に対して、何が重要なのか確認するリストとしても使える。 ただ、多少言い方を変えた方が良いものもある、マルチユーザが〜のような聞き方よりは、何人ぐらいのグループで回しますかなどと利用シーンをイメージしやすい聞き方にするのだろう。