エンタープライズCMSは黒歴史になったらしい。
だが、CMSは甦る。CMSの現在の実装がどんなに腐っていようと、その概念自体は、人類の夢を表現しているからだ。
Webバブルは甦った。DHTMLはAjaxへ、コミュニティはSNSへ、プッシュはRSS配信へとそれぞれ名前を変えたが、その中身はまぎれもなく、Webバブルの夢だ。「ウェブをテレビのようにする」という夢もやはり甦り、その地歩を固めつつある。最後にして最大の夢、小額決済も、近いうちに敗北から立ち上がるだろう。今度もまた敗れるかもしれないが、彼らは何度でも立ち上がる。何兆円の損害を積み上げても、彼らを止めることはできない。何度でも呼び名を変えては投資家をあざむき、金をドブに流し込み続けるだろう。それが人類の夢だからだ。経済活動が経済合理性を作り出すのであって、経済活動が経済合理的に行われるのではない。
さて、エロゲーである。
いま私の手元には、某エロゲーの開発用データがある。ファイル数は11,776個、サイズは0.98GB。これが小さすぎて参考にならないと思えるのだとしたら、たぶんあなたはコンシューマ機用ゲームの開発者なのだろう。
この経験を元に、エンタープライズCMSのあるべきユーザモデル（そのシステムの動作についてユーザが抱く世界観）と実装について私見を述べる。
まず、ユーザモデルから。
コンテンツの基本的な単位はファイルであるべきだ。
ワークフロー情報（バグ追跡やバージョン管理）は別として、コンテンツ自体はファイルを基本的な単位とすべきだ。
一般人の知能からいって、ファイルがこれほど理解されていること自体が奇跡だ。ユーザがMITかベル研でないかぎり、ファイル以外の単位が理解されると考えることはできない。
ファイルが基本的な単位なので、CVSやSubversionのように、リポジトリを使うことになる。
作業用コンテンツ（ファイル）は、CVSやSubversionのように、ローカルディスク上にコピーすべきだ。
これは実装の詳細ではなく、ユーザモデルだ。ユーザモデル上、ローカルディスクとネットワークストレージは別物だ。（認証がなく、非共有の、ユーザが一人しかいないネットワークストレージなら、速度しだいではローカルディスクとみなせるかもしれない）
「ファイル本体はサーバ上にあって、リッチクライアントで編集する」というのは妄想だ。メールの読み書きくらいは素人でもする仕事だが、プロがコンテンツを作るのは、まったく別のことだ。雑誌の付録を組み立てるようなつもりでは、自動車のエンジンを組み立てることはできない。
変更のコミットは、ファイルの保存とは別動作であるべきだ。
理由は2つある。1. コミット時にコメントを書くことで、その更新の意図を記録できる。2. やりかけの状態をコミットして、リポジトリやワークフロー情報を汚すことがない。
ファイル名の変更管理はCMSの核心である。
人間は不適切なファイル名をつける。どんなに完璧な命名規則を作り、どんなに賢いファイル名監視システムを配備したところで、無駄だ。不適切なファイル名は必ず発生する。不適切なファイル名が発生したら、対応策は2つしかない。ファイル名を適切なものに変更するか、あるいは変更せず放置するか、だ。
変更する場合には、変更前と変更後のファイルが内容的に同一のものであることをユーザに知らせる必要がある。それも、変更時に通知して終わりではない。変更情報が必要になった瞬間に通知が目に入る必要がある。また、ファイル名が変更されたときには、ワークフロー情報もそれを同一のものとして追跡する必要がある。
CMSが、独立した部品の寄せ集めではなく、システムとして統合されたものである必然性は、ここにある。
リポジトリ内のファイルには必ずワークフロー情報が付随するが、逆は真ではない。つまり、まだ存在しないファイルについてのワークフロー情報は存在しうる。
たとえば、リポジトリにアクセスしない作業者のために、発注・納品・リテイクというワークフローに対応する必要がある。納品まではファイルは存在しないが、ワークフロー情報は存在する。また、納品後のファイルから納品前のワークフロー情報をたどれる必要がある。
こういうユーザモデルをどのように実装すればいいか。
手始めに、作業用コンテンツ（ファイル）のための専用ファイルシステムが必要だ。
これは第一に、ファイル名の変更管理のためだ。ファイル名の変更を超えてワークフロー情報を追跡するには、ファイルシステムと関わることになる。TortoiseSVNはWindowsシェルのプラグインという形でこれをやっているが、動作の重さなどで、あまりいい印象がない（今はよくなっているかもしれない）。
また、専用ファイルシステムを使うことで、リポジトリからの差分取得の方法を細かくコントロールできる。たとえば、差分取得をバックグラウンドで動かしたり、ファイルが開かれるときまで遅延させたりすることができる。
コミットや差分取得のUIは、TortoiseSVNのようにWindowsシェルのプラグインとしてもいいが、それだけですべての作業をやるのは損だ。専用のアプリケーションのほうが使いやすい。ファイルを読み書きするときはExplorerなどで普通に開き、ワークフロー情報を見たり更新をコミットしたりするには専用アプリケーションを使う。
ワークフロー情報は、うっかりすると、途方もなく複雑な代物になる。ばっさりと単純にしなければならない。一例として以下のルールを示す。
・ワークフロー情報は、掲示板のスレッドのように、コメントの連続という形をとる（ワークフロー・スレッド）。それ以外の形式のワークフロー情報は存在しない。
・ワークフロー・スレッドのコメントには、ファイルを添付することができる。この添付ファイルは変更できない。
・1個のリポジトリ内ファイルには、必ず1個のワークフロー・スレッドが対応する。
さてここまで、CMSというと必ず出てくるようなことを、ほぼすべて省略してきた。検索・作業のアサイン・審査と承認・Webテンプレート・ストリーミング・Web掲示板などなどだ。
こうしたことはすべて、まったく重要でない。
これらの機能は、ユーザモデルを構築しない。ユーザモデルの上にどう載せるかが問題になるだけで、ユーザモデルを別物に変えるよう迫ることはない。たとえばWebテンプレートは、ファイルとファイルの関係として扱える（それ以外の設計はすべて呪われている）。作業のアサインはワークフロー情報中にWiki的な記号で書ける。承認は電子署名だ。検索はインデックスを、Web掲示板はRDBを扱う必要があるが、いずれにせよ正規化されている。正規化されているというのは、ファイル名に悩まないということだ。名前に悩まないような問題は、大した問題ではない。
そうそう、いうまでもないが、Webサーバを中心にしたCMSはすべてクソだ。あれらはWebテンプレートとWeb掲示板からスタートしている。機能は提供するが、管理とは無縁だ。「箱から出してすぐ使える」的な擁護も的外れだ。ここまで縷々書いてきたようなリポジトリ型CMSでも、「箱から出してすぐ使える」初期状態で配布することは簡単だ。しかもテンプレートなどがローカルファイルとして編集できる。「PHPで書いてあるからホスティングサービスで使いやすい」？ では、CVSやSubversionは、どうしてもC言語で書かなければならないのか？ 専用ファイルシステムが必要なのはクライアント側だけだ。サーバサイドはどんな言語でもいい。
以上、CMS業界の常識からはかけ離れた話をしてみた。
だが、CMS業界の常識よりは私のほうが、未来に近い。CMS業者は何万行もの糞の山を抱えており、しかもそれを売らなければならない。私はいまのところ一行も持っておらず、おそらくこれからも持たないだろう。
私は挑戦者を待っている。
参考：
巨大な格差「ザ・グレート・デバイド」／データベースは20世紀の代物
CMSはジャングル状態にある