費用・体制・向き不向き
ソフトウェアは無料です。値段にあたるのは、サポート契約が存在しないことと、障害を自分たちで調べる体制です。
Kiln は MIT ライセンスのオープンソースで、使用料はかかりません。それで話が終わらないのは、商用サポートが存在しないという事実を、値段として扱う必要があるからです。向かないサイトの条件まで含めて書きます。
費用の形
金額は組織によって変わるので、埋める欄として置きます。筆者はまだ自社以外の移行を手がけていないため、工数の相場は【未検証】です。
| 項目 | Movable Type での現状 | Kiln にした場合 |
|---|---|---|
| ソフトウェアのライセンス | 年額の製品ライセンス（現状の金額をここに） | 0円（MIT ライセンス） |
| 公開サーバー | Perl とデータベースが動く環境の月額 | 静的ホスティングの月額。小規模なら無料枠で収まることが多い |
| 記事を書く環境 | 公開サーバーと同じ | 編集担当者の PC、または社内サーバー1台 |
| 移行の初期費用 | — | テンプレートを読める人の工数。プラグインの数でほぼ決まる |
| 障害対応 | ベンダーまたは制作会社への委託費 | 社内か制作会社。製品サポートの費用はゼロで、調べる工数が代わりに乗る |
| バックアップ | 公開サーバーごと委託先が取っていることが多い | 社内の責任に移る。記事のデータとテンプレートの両方 |
ランニングコストはたいてい下がります。下がった分を、障害が起きたときに自分たちで調べる体制に回す必要があります。そこが実質的な価格です。
移行の初期費用は、2段階目の報告が出た時点で確定します。それまでは仮の数字で置いてください。テンプレートが標準に近ければ小さく、プラグインの機能を作り直すなら、そこが工数の大半になります。
記事を書く環境に、サーバーは必ずしも要らない
公開側にサーバーが要らなくなる代わり、記事を書く管理画面はどこかで動かすことになります。ここは情報システム部門の承認が絡むので、分けて書きます。
編集担当者が1人か2人で、同時に書くことがないなら、その人の PC で動かすだけで足ります。常時稼働は不要で、書くときに立ち上げます。
社内サーバーが要るのは、複数人が同時に記事を書く場合、または編集履歴を全員で共有したい場合です。このときは常時稼働の1台と、そのバックアップの責任が発生します。必要なのは Node.js が動く環境で、Windows でも Linux でも構いません。
サポート契約が無い、ということの意味
問い合わせ窓口はありません
不具合を見つけたら GitHub の Issues に書く形で、返答の期限も担保もありません。本番が止まったときに電話をかけられる相手が契約上必要な組織では、現時点で採用できません。
これは「まだ無い」ではなく「設計としてそうである」部分です。オープンソースとして公開し、ソースコードは全部読めて、直して使うこともできます。その代わり、誰かが責任を持つ契約は存在しません。
開発が止まったらどうなるか。これは役員が必ず聞く質問だと思うので、先に答えます。Kiln は個人が開発しているソフトウェアで、会社が後ろにいるわけではありません。開発が止まる可能性は十分あります。そのとき失われるのは今後の改善で、動いているサイトではありません。公開されるのは HTML ファイルで、Kiln が無くても配信は続きます。コードは MIT ライセンスなので、社内に抱えて自分たちで直すことも、制作会社に引き取ってもらうこともできます。乗り換えが必要になった場合も、記事のデータは JSON またはデータベースに平文で入っていて、取り出せます。
MIT ライセンスについて法務に説明する必要がある場合は、自社利用・改変・再配布がいずれも可能で、義務は著作権表示を残すことだけ、という内容です。
もう一つ正直に書いておくと、文書はほとんど英語です。設計の判断や検証の手順を書いたものが21本あり、日本語はインストールマニュアル・ユーザーマニュアル・Cloudflare の調査メモの3本だけです。担当者が交代したときに読ませる日本語の資料は、その3本とこのサイトの4ページ。テンプレートの互換性や公開の仕組みを細かく追う段になると、残り18本の英語を読むことになります。これ自体が導入の障壁になり得ると考えています。
比べる相手を Kiln に限らない
このサイトは「MT のままか、Kiln に移すか」の軸でだけ書いています。MT クラウドへの移行や、他の CMS への乗り換え、他の静的化の手段との比較は、こちらで判断材料を持っていないので扱いません。意図的な線引きです。
| 判断軸 | MT のまま続ける | Kiln に移す |
|---|---|---|
| 公開の待ち時間 | 記事数とともに伸びる | 変更の影響範囲だけなので伸びにくい |
| 公開側の停止リスク | CGI とデータベースが止まると閲覧も止まる | ファイル配信なので止まりにくい |
| URL の維持 | 変わらない | 変わらない（1件ずつ照合して確かめる） |
| 障害時のサポート | 契約で担保できる | 担保できない |
| フォーム・コメントの受け付け | そのまま動く | 移し先を別に用意する |
| サイト内検索 | そのまま動く | 動く。公開のときに索引を書き出す方式に変わる |
| 実運用の実績 | 長年ある | 無い |
この表を見て、サポートと実績の2行が自社にとって譲れないなら、答えは「いまは移さない」です。それは正しい判断だと筆者は考えています。
向いているサイト、向いていないサイト
向いているのは、記事数が数千を超えて再構築が運用の邪魔になっていて、テンプレートが標準に近く、公開側のセキュリティ対応に毎回追われているサイトです。ウェブサイトの下に複数のブログを置いた構成も、まとめて引き取れます。社内に Git を使っている人がいるかどうかも効きます。テンプレートがファイルになる利点は、その文化がある組織でだけ利点になります。
次のどれかに当たるなら、いまは見送ったほうがよいと筆者は考えます。
- 本番停止時に契約上の問い合わせ窓口が必要
- 会員限定ページや Basic 認証を MT 側で持っている
- コメントを今も受け付けている（過去のコメントは移行して表示できます。受け付けだけが外部サービスになります）
- プラグインの機能がテンプレートに深く入っている
- 記事を書くのが公開サーバーの管理画面でなければならない
MT のバージョンが 8.8.1 より古い場合は、確かめてから決めてください。読み込めない項目は作業中にすべて報告に出るので、1段階目を回せば判断できます。
いま決めてほしいこと
本番を載せ替えるかどうかではありません。検証環境で1段階目と2段階目を回すかどうかです。
| 決めること | 検証環境で読み込みと突き合わせを行うか |
|---|---|
| 判断の材料 | 2段階目の報告（通らないテンプレート、足りないプラグイン機能、消える URL の件数） |
| 必要なもの | MT のデータベースの写し1つ、テンプレートを読める人1人 |
| MT の本番への影響 | なし。触りません |
| やめる場合の費用 | 調査の時間のみ |
| 先に決めておくこと | フォームとコメント受け付けの移し先 |
自社のデータとテンプレートで実際に比べてみるまでは、このサイトに書いた一致の数字は他人の環境の話にすぎません。逆にそれを回せば、自社のテンプレートが通るのか、プラグインの機能がいくつ足りないのか、URL が1件も消えないのかが、事実として分かります。
その結果を見てから、並行運転に進むかどうかを決めてください。手順は移行の進め方と引き返し方にあります。