Movable Typeとの出会い, 僕のウェブ屋としてのプロ意識。

実のところ、僕がMovable Typeを初めて触ったのは昨年の夏以降のことです。まだ一年経っていません。プラグイン書いたりあれこれ学び出したのは秋以降です。"自分の中では"「埃を被っていたPerl」を過去の記憶から引っ張り出してきて、今や「このツールでウチのクライアントの要求は100%解決できる」自信があります。

きっかけは、去年の春に遡ります。

「CMSを導入したい。予算はあんまりない(←ありがち?)」

ここで、ウチのスタッフにオープンソースのCMSを中心に商用製品も含めて調査せよ、要件にあう物をピックアップせよと指示を出しました。

ここで選択肢に上がったのが Drupal, Nucleus。Drupalは実際にある案件で導入もしました。

この時口を酸っぱくして言ったのは「オープンソースを使うのならば、そのオープンソースコミュニティに自分がコミットしていくくらいでなければ駄目だ。クライアントが望むことがそのCMSで実現できなければ "お前が解決する" そのくらいの意識でないと駄目なんだ。」ということです。

オープンソースでなく商用製品の場合も「選択したお前が責任を持つこと(もちろん最終的には僕が責任を持つ)」を求めました。

結局、様々な条件を検討した結果(主にスタティックなファイル生成の必要が必須であった理由から) MTを選択することになりました(MODxやTypo3も選択肢にあがりましたが(注1)。

さて、そこからです。

クライアントの要望、担当者のやりとりについて報告を受けているときに「それはできません」が結構多いことが気になりました。例をあげると「ページの表示順をコントロールできない」ことや「"ゴミ"ファイルができてしまう」ことなどです。

特に、「PDFファイルをアップロードして「新着情報」に載せる時、新着情報に掲載するためにダミーのエントリーを生成して追記(more)欄にPDFのURLを入力する」みたいなトリッキーな方法(文章だとわかりにくいかもしれませんがMT使っている制作会社系の人はわかると思います)で設計するものですから、PDFひとつにつき1つのゴミ(ダミー)HTMLファイルが出来る。

表示順の制御は概要(excerpt)欄に番号を入れる。入れ替えることを考慮して番号は「001-0010」「001-0020」...(こうしておくと順番の入れ替えが可能だから)。

「ありえんやろ!」

これは上司である僕の見解です。担当者にしたら「MTじゃ出来ないんだよ。無茶いいやがって気楽な身分だよなあんたは。」という気分だったことでしょう。

もちろんコストの問題や納期の問題はあるにしても、クライアントが「できるんじゃない?」といったこと(しかもすごく合理的で良くあるであろう要求)が出来ないと簡単に言うことが僕には苦痛です。クライアントから期待されているプロなのだから。

MTについて自分で色々やりはじめたのはそこからです(結局その時点の彼(担当者)はプロではなかったし、その責任はもちろん僕にあります)。

カスタマイズや拡張できる方法はないか? 結果、殆どのことは出来ることがすぐにわかりました。ライセンスの問題はあるにしてもPerlスクリプトなのですからソースを追っていけばどのように動いているかは理解できますし、APIのリファレンスも公開されています。検索すれば様々なノウハウも公開されていますから。

この時以来あれこれ制作してきましたが、そのあたりを再度整理し直したものがこのページで紹介しているものです(一部です)。

自分たちが選択したのだから自分たちはその製品のプロである必要がある。結局、僕の「プロ意識」っていうのはそういうところにあるのでしょう。もしMT3.3のセキュリティ脆弱性が発見された時にSixApartがサポートを終了していたら、僕はパッチを書いて送りつけるでしょう。それで自分の顧客が不利益を被るのであればそうします(注2)。

オープンソースであればパッチを送るもなにもなくさっさと直せば良いのです。そういう面で僕はMTが(製品とは別の何かであっても)GPL化されることに期待しています。

注1)
アウトソースも検討して実際にTypo3やMODxについて扱っている(とWebサイトで謳っている)何社かに声をかけました。でも結局僕の問いに明確に答える程ツールを熟知している人ではありませんでした。つまり、僕の定義する「プロ」ではなかったということになります。

注2)
MTのような「既にコードにアクセスできる」ものがオープンソース化される場合というのは例えばNetscapeのソースコードが公開されたっていうのとちょっとニュアンスが違います。MTの場合はソース自体はこれまでも誰でも見ることができました(よって、どこに問題があるかは第三者が見つけることが可能です。もちろん修正方法を見つけることも可能です)。あとは純粋にライセンスの問題です。
但し、コードをオープンソースにすることの価値においては、それがCだろうがPerlだろうが変わりはないと思います。

このエントリーを書くきっかけとなったページ

• Movable Type 3のサポート期限での議論にみるウェブ屋としてのプロ意識というもの
• Movable Typeが優れものであることとシックス・アパートへ要望があることは別な話
• Movable Type 3のサポート期限での議論にみるウェブ屋としてのプロ意識というもの その2

関連するかもしれないこのブログ内の他のエントリー

• Movable Typeのオープンソース化(Web屋的見解)。
• だからMTのGPL版について少しは建設的な議論をしようぜ。
• Web受託1.1。
• 「プロ」について。シンプルに考えよう。
• かくして、ウェブ屋1.0は職を失う。

---

ちょっと補足。

Mobavle Typeを顧客に導入しているウェブ屋の大半が同様なんじゃないかな。SI業界だったらありえないだろうな。まだまだウェブ業界は未成熟ということなんだろうけど。

from: Movable Type 3のサポート期限での議論にみるウェブ屋としてのプロ意識というもの その2

iwaiさん流の表現なんだろうと思うわけですが、どうなんでしょう? 業界の人。
はい皆さん(誰?)「Movable Typeとの出会い, 僕のウェブ屋としてのプロ意識。」というお題でエントリーを書くこと。宿題ね(嘘)。

この話題はGPLとの件とは違うわけですが、以下のOgawaさんのご指摘にも繋がることなんだろと思っています。MT3→MT4の変化が劇的であればある程混乱する現場が出てくる。

あとはオープンソースってどうなるのでしょう。オープンソース版を商用利用するSOHO業者がGPLを理解できないせいで発生するであろう混乱が今から目に見えるようです。面白いので私の公開しているプラグインもGPLにしてやろうかな（笑）。

from: Movable Type 4ベータテスト - Ogawa::Memoranda

石川さんとは今度飲みに行って(笑)お話するとして(札幌かぁ...)、このあたりは(特にプラグインの話)はやっぱり脇が甘かった(僕ほどじゃないけど)かも...というか、プラグイン公開している人にすると, 例えばフリーで公開しているプラグインなんかにサポートとか新バージョン対応を求められても困る。かといって、これをシックス・アパート側に言うのも違うでしょう。

○実現したいページ生成・動作を、あれこれたくさんのプラグインを使って解決している ○「管理画面をより使いやすく」といったオーダーが結構ある
ゆえ、シックス・アパートに確認した、
Q3：サードパーティのプラグインは正常に使えるのですか？

from: Movable Typeが優れものであることとシックス・アパートへ要望があることは別な話

プラグインの作者へ不信感を表明するわけにもいかないでしょうから「プラグインの導入」についても「ライフサイクル」や「サポート」について考えておかないといけない。そういう点で選択したお前が責任を持つこと(もちろん最終的には僕が責任を持つ)ということになるわけですね。

かといって、サポートが云々で何でもかんでもリスク避けて...ばっかり考えていても面白くない。それ以上にそのツールに惚れ込んだのならそこは一歩踏み込んで行くのが面白いのだし自分たちの成長、他社と比較した優位性につながっていくのだと思うのです。

だからウチの場合は「基本的にプラグインは社内開発。その他のサードパーティーのものを入れる場合はライセンスを要確認(いざとなったら改編可能なら自社責任で導入OK、そうでなければ導入はNG)」となります。

あとは、ちゃんと対話すること(粘り強く, 前向きにね)。MT4Betaについてはこれまでに3通フィードバックしましたがちゃんとすべてに明確な返事をいただいています。バグレポートだけじゃなくて、今後もプラグインに関する互換性の持たせ方とかデベロッパーへの情報提供とかを求めていくつもりです。またそれだけじゃなくて僕は僕なりに分かったことをこのBlogなりで今後も書いていこうと思います。