なぜ僕は WordPress を使わないで Movable Type を使い続けるのか。

書く書く詐欺にならないうちに、ブログ記事を書くとする。この議論はもはや不毛だし不必要に炎上するから、これでこのテーマは最後ね。Movable Type のラスト・サムライとして書いておく(とか)。

• 元Movable Typeユーザー、現WordPressユーザーが考えるMovable Typeの利点 : ARTIFACT ―人工事実―
• 「米国トップ100ブログの7つが Movable Type を使っている」という調査結果への私的考察 - Six Apart ブログ

ちょw 元ネタは「上位100ブログの半数がWordPress...」じゃんと言うのはともかくとして。

※ あ、スタティック云々の話しは書きません。もうお腹いっぱいだし(こんなもんも作ったし)。

※でもね、こいつには Fail-safe のしくみがあるよ。安定して大規模サイトを運用することについては考慮されています。
※といいつつ静的の利点をひとつあげておくと、あるクライアントに言われたひとこと→"いざとなったらFTP経由でDreamWeaverで更新すればいいんだよね?" "うまくいかんかったらいつでもDreamWeaverに戻れるしね"ってのはあるよ。

なぜ WordPress ではなくて Movable Type を使っているのか。楽しいからだよ。

なぜって、楽しいからだよ。楽しいからです。プログラマとして、PowerCMSプロダクトのマネージャとして、プロジェクトマネージャーとして、経営者として。以下、そのことについて少しだけ書きます(少し、なのかw)。

楽しい、の前提について。MTMLについて。

突き詰めて言えば、MTML が楽しいから僕は(そして、アルファサードは) Movable Type を使います。 MTML(＝Movable Type Markup Language)、いわゆるMTMLです。日本で(多分)最も普及しているテンプレート・エンジン。

以下にブログ記事10件をリスト形式で表示するテンプレートを示します。WordPress、Movable Typeではそれぞれ以下のように書きます。

WordPress

<ul>
<?php
    $myposts = get_posts('posts_per_page=10');
    foreach($myposts as $post) :
    setup_postdata($post);
?>
    <li><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></li>
<?php endforeach; ?>
</ul>

Movable Type

<ul>
<MT:Entries limit="10">
    <li><a href="<MT:EntryPermalink>"><MT:EntryTitle></a></li>
</MT:Entries>
</ul>

どちらが良いとかを単純に論じることはしません。

単なるテンプレートの比較ではなく、僕が感じていること、の羅列。

• テンプレートをどこに記述するか? WordPressではファイル中に書きます(.phpファイル)。Movable Typeでは管理画面(テンプレート編集画面)のフォームに記述して管理画面から保存します。
• ロジック(プログラムコード)をどこに書くか? WordPressではテンプレート(.phpファイル)、もしくはプラグイン(.phpファイル)、プラグインに書いた場合はメソッド等をテンプレートからphpコードで呼び出す必要があります。プラグインは.phpのファンクション(関数)として書きます。クラス、メソッドではなく、ファンクションです(つまり、関数名が重複するリスクもはらんでいるといえます)。5月30日追記 : クラス・メソッドとしても書けるらしい。同梱されている Hello Dollyプラグインは単なる function ですが。
• Movable Typeの場合はプラグインとして書きます。プラグインは.yamlファイル(定義ファイル)＋Perlモジュールです。
• Movable Typeでは、テンプレートにロジックを書くこともできます。但しその場合の言語はPerl(PHP)ではなくMTML(MTタグ=Movable Type Markup Language)です。MTMLだけでも例えばFizzBuzzくらいのロジックは書けてしまうのですが、そこにPerlのコードやサーバーコマンドを書くことはできません。
• 上記の例ですが、少なくともMTにおいてはこのような書き方をすることはほぼ無くて、MTEntriesHeader等でループの最初と最後にulタグ(及び閉じタグ)を入れます。WordPressでループの最初と最後を判別する処理を入れるのであれば、PHPでコードを書きます。
• WordPressのテンプレートにはPHPのコードを書くことができます(正確に言えばMovable Typeでも書けますが、あくまでも出力されるアーカイブを.phpにする等して実行できるということで、これは管理側のポリシー的に実行を許可しないことができます。逆に、出力されるアーカイブを.jspにしてJavaのコードを書くこともできます)。WordPressのテンプレートでPHPコードが書けるということは、exec関数でサーバーコマンドが実行できるということです。

分業が前提となる Movable Type、テンプレートとロジックを同時にカスタマイズする WordPress。

Movable Type ではプラグインの中にPerl(PHP)コード、テンプレートにはMTMLを記述します。書く場所が別れており、それぞれの場所に書く言語は別のものです。片方はPerl(PHP)、片方はMTML(＝テンプレート・タグ言語)。

WordPress ではプラグインもテンプレートもPHPであり、どちらにロジックを書くこともできます。できる、ということ＝柔軟である、と考えることもできますが、どちらにどのようにロジックを書き、プレゼンテーションを書くか、が曖昧になりますよね。プラグイン側でプレゼンテーションを組み立ててしまうこともできます。

プログラマの立場から言えば、"案件ごと、その場その場で、楽な方に実装する" ようなことをやってしまう誘惑にかられる可能性が高い。極端に言えば、ひとつのファイルの中にHTML、CSS、JavaScript、PHP、SQLが書かれているようなテンプレートになったりします。ひとりでこれら全部書ける、書けない、ということ以前に、ひとりで書けたとしても見通しの良いテンプレートにするには相当な工夫が必要でしょう。

もちろんWordPress に何らかのテンプレートエンジンやフレームワークを載せてきちんと設計することも可能ですが、それは WordPress というソフトウェアとは少し違うレイヤーの話しです。

セキュリティと権限についての両者の思想の違い。

MT5.13で MTInclude タグのfileモディファイアがデフォルトで無効になったことに現れていますが、Movable Typeでは「テンプレートの編集」権限を持ったロールを「デザイナー」と位置づけています。デザイナーはPerlやPHPでロジックを書くことは許可されておらず、サーバー上の任意のファイルをインクルードして表示させることも許可されていません(デザイナーに"それ"はできるべきではない、が Movable Type のセキュリティと権限に関する思想です。)。PerlやPHPによるプラグラムの実行が許可されているのは、サーバーにプラグインファイルを設置できる権限を持つユーザーのみです。デザイナーとサーバー管理者の役割を明確に分けることができます。

これは、プラグインやテーマを適当に探してきて個人ベースで手っ取り早くCMS管理のブログやサイトを立ち上げたい、といったシーンではあまり意味がありませんが、例えば首相官邸のウェブサイトでは必要とされるでしょう。

また、ここで「静的生成が可能」なCMSの有利さが出てきます。セキュリティ重視の官公庁の案件なんかでは、パブリッシュするサーバーと配信するサーバーを物理的に分けてしまえば格段にセキュリティレベルを上げられます。首相官邸のウェブサイトが何で構築されているか知りませんが、動的CMSを導入するのは非常に敷居が高いであろうことは推測できます。

プログラマとして何が楽しいか。言語を拡張する、面白さ。

サーバーサイトのエンジニアとしての立場で言えば、MTでの開発というのはつまりMTMLという言語を拡張していくことに他ならないわけです。これには「言語を拡張していく」面白さがあります。

言語(を拡張するタグ)を作って、それを他の誰かに利用してもらう。

これって、ただデザインをテーマやテンプレートに適用するお仕事の面白さじゃないです。言語を作る人、Matz とまではいいませんけど、CPANモジュールを作る人とかに近い、自分を含む誰かが使う何かを作る仕事。

例えば、以下はFacebookアプリケーションをMTMLで構築できるように作成したテンプレート・タグです。

<MTIfFacebookLoggedIn>
    <mt:FacebookUserName escape="html">
        さん、ようこそ | 
    <a href="<mt:FacebookLogoutURL>">
        ログアウト
    </a>
<MTElse>
    <a href="<mt:FacebookLoginURL>">
        Facebookでログイン
    </a>
</MTIfFacebookLoggedIn>

例えば、出版社のウェブサイトで、書籍の一覧を表示するためのテンプレート・タグを以下のように定義して実装します(案件固有のタグを作る場合は、Namespaceを指定するなどしますが、汎用的なものはこんな感じで実装します)。

<MT:Books limit="10">
    <li><a href="<MT:BookPermalink>"><MT:BookTitle></a></li>
</MT:Books>

MTMLの実装が済んでしまえば、あとは「デザイナー」にプレゼンテーションのすべてを委ねてしまうことができます。そして、重要なのは、記述する箇所と記述する人が明確に分けられる、ということです。タグを定義するプログラマ、テンプレートを書くフロントエンド・エンジニア(デザイナー)。両者が同じファイルやテンプレートをさわることがありません。そして、MTMLは他の案件でも使えるのです(ロジックの側でプレゼンテーションを組み立てることがないからこそ、再利用できます)。プログラマの立場で言えば、そもそも毎回自分でコードを書かなくても、フロントエンド・エンジニアがたいていのことはやってくれます。プログラマは「怠惰」なのです。毎回同じようなコードを書くなんて、まっぴらなのです(PowerCMSなら、これらのタグさえもノンプログラミングで、管理画面から登録できます)。

マネージャとして、何が楽しいか(1)。チームで構築するスタイルを確立できる面白さ。

サーバーサイド・エンジニアとフロントエンド・エンジニアの作業領域がきっちりわけられるということは、チームで構築するスタイルが確立できるということです。ひとりのエンジニアがテンプレートをさわりながらPHPをゴリゴリ書いてカスタマイズしていくというスタイルではありませんので、必ず開発は違うスキルを持った複数人のチームで行うことになります。

テンプレートにPHPを書いていくスタイルでは、僕の経験上、サーバーサイドエンジニアの方に負担が多くかかるようになります。そもそも作業する人がわかれていなかったりすれば、"誰に負担がかかる"以前の問題といえますが。

また、このご時世、優秀なエンジニアを調達することは容易ではありません。HTMLのスキルに＋してMTタグを理解したコーダーができる範囲が広がるということを考えれば、内製、外注にかかわらず人のアサインすることの敷居も下げてくれます。

マネージャとして、何が楽しいか(2)。人が辞めても慌てなくてもいい。

もちろん、優秀な人材に辞められないようにするってのは経営サイドとして常に考えていかなければいけません。それでも、納品が終わって数年経過したサイトの改修等の相談がきた時、その人が辞めていたら内容の把握すら一からやらなければならない、ってのはすごいリスクです。これに対して、Movable Type ベースで開発することによるメリットは2つあります。1つは、必ず複数名のチームで仕事をしていることです。全員辞めちゃったらさすがにあれですけど、1人に任せっきりなケースと比較したら全然違います。そして、もうひとつ、こっちが本質ですが、Movable Type ベースで開発していれば、改修が必要な箇所の処理を調べるのが非常に簡単です。

1. テンプレートを追っていく
2. 該当のタグ部分のコードを確認する

これで、どこを改修すべきかが特定できます。組織的に開発をMTML＋MTプラグイン方式に一本化していれば、その内容の把握スピード、改修コストも大きく圧縮することができるのです。

実をいうと、2006年以前のアルファサードでは、プラットフォームを特定しておらず、Movable Type をさほど使っていませんでした。案件毎、案件の要求仕様ごとにツールを決めたり、その時在籍しているエンジニアが得意としているものを使うようにしていたのです。Smartyベースのスクラッチ開発、Drupal、Nucleus、WordPress、担当した人が辞めた後に改修の依頼が来た時に、現状把握だけでも大変だった経験があります。当然、良質なドキュメントを用意させていなかった会社側の問題もありますが、Movable Type の場合はドキュメントは最小限でも現状の把握がしやすいメリットがあります。皮肉なもので、Movable Type、PowerCMSをやり出してから、社員の在籍年齢、定着率が向上していきました(そして社員の年収の面でも!)。

経営者として何が楽しいか。ビジネスの側面から。

僕はコードも書くし、組織をマネジメントする立場でもあるから、これまでに書いた部分の面白さはすでに感じているわけですが、経営者としても以下のような面白さを感じています。

• こと日本においては、特にMT3以降、Movable Type で構築されたサイトが多数存在しており、そのサイトを拡張、改修していくという仕事のマーケットが存在する。もちろん、WordPressで構築されたサイトも多数存在するでしょう。リプレースの市場も成長していくと思われます。ただ、バリバリにカスタマイズされたテーマやプラグイン、もしくは WordPress 本体に手を入れて構築されたサイトを引き受けるリスクを考えると(少なくとも私にとっては)、魅力は半減します。
• 今や国産CMSとなっているため、日本語で要望、改善要求できる。開発に対する発言や開発者とのコミュニケーションの容易さ。
• 開発ベンダーが日本にいること、商用ライセンスがあるために、メーカーの協力を得やすいこと。例えば(何度も例に出して恐縮ですが!!)首相官邸のCMS導入の際にどのようなセキュリティに関する対策をとっているか、また第3者によるセキュリティ監査が入るような案件で相談、協力を求めることが可能です。
• 商用ライセンスがある故に PowerCMS のようなビジネスモデル(商用パッケージのライセンス販売)が成立する。商用パッケージのライセンス販売で何が一番良いかと言うと、実は利益ではないのです。当然専任のサポートも必要ですし、開発の人件費も必要です。利益が出るかどうかはあくまでも売れ行き次第。ただし、同じ利益でも、受託の場合は例えば構築2ヶ月の案件で入金されるのは3-4ヶ月後、引き合いのタイミングから計算すると、4-6ヶ月くらいかかるケースも稀ではありません。商用パッケージのライセンス販売は、ライセンス販売時点で売上げが発生するので、資金繰りが大きく改善される。回収リスクもほとんどありません。受託案件で引き合いのタイミングから6ヶ月くらいでやっと納品した仕事の回収ができなかったなんてことがあると目も当てられませんが、そういうリスクがないのです。

Movable Type は実はアプリケーション開発プラットフォームである。

長くなったのでそろそろ仕事に戻りたいと思うけれども、これまでの「WordPress vs Movable Type」論争とはちょっと指向を変えるために、このエントリではテンプレート・エンジンを中心とした開発スタイルに "ほぼ" 絞って言及するにとどめたけれど、実は両者は良く似ているように見えて、内部的にはまったく違っているのです。

Matt Mullenweg が WordPress を本当に「モダンなプラットフォーム」だと思っているとしたらそれはそれでどうかとも思うわけですが(PHP4時代のコードをまったく引きずらない新しい WordPress があるのなら別だけども)、Movable Typeには、MT::Appを拡張してMTを継承したWebアプリを作るためのフレームワーク、ORマッパ(MT::Object)、このエントリで紹介したテンプレートエンジン(MTML)、リスティング・フレームワーク、プラグインによる拡張の仕組み、もしくは(元々は僕が書いた)DynamicMTMLといったフレームワークを内包していて、CMSとしての管理画面からは見えない開発プラットフォームとしての側面を持っています。

かといって、Movable Type が Perl CGI である状態で、MTをモダンなプラットフォームだと言うのも何だかなわけで、MT5.2ではそのあたりに対して何らかの答えが示されると思っています。示されるよ、きっと。