MTDDC 2017に参加してわかったMT7のことと、今後のあれこれ

2017年10月6日に開催されたMTDDCに参加してきたので、そのレポートです。懇親会のLTの資料はこちら。

• [MTDDC] JPGダイエットをする3つの理由、画像ファイルはしっかりと軽量化しましょう！

個人的に感じた点や、雑感などをまとめていきます。当日は実況Tweetしている感じだったので、細かいところが聞けていなかったかも。

• ハッシュタグ #MTDDC (Twitter)

MT7のコンテンツタイプ

もっとも注目されるのがこの「コンテンツタイプ」というものでしょう。標準のMTをブログツールとして利用している場合は、多分必要ないです。CMSとして「コンテンツを格納する箱」と考えている場合は、大きく設計が変わります。他システムと連携している場合は、自由度が上がると思います。

これは、いわゆるアセット周りが新たに独立したコンテンツとして管理ができるようになった、と捉えています。今までは、ブログのアイテム、ウェブサイトのアイテム、として登録されていました。これらを独立したものとして設計できるように。

その気になれば、この機能を利用して、顧客情報を管理したり、商品を品番ベースで在庫管理したりすることができます。ただ、今は複数のシステムを連携して、それぞれのシステムの良い部分を生かすエコシステムな時代ですので、「MTでここまでやりました！」みたいなことはなさそうな気もします。いや、やったら面白いとは思います。昔のように「MTでこんなの作った！」みたいな熱があるのは大好きです。

MT7の新機能

こんな感じで、新しい機能が入るみたいです。

• コンテンツタイプ
• ワークフロー
• アセット周りの強化

あとは、Data APIがコンテンツタイプ対応するとか、Perlのバージョンが新しくなるとか。弊社のプラグインもワークフローとかは機能がかぶりますね。アセット周りも、Exifを削るとかなんとか。どうなるのか楽しみです。

この３つの機能は、MT6までは各社のプラグインとして実装されていたので、どうやってシステムリプレースまたはメジャーバージョンアップするかが課題ですね。ずっとMT6ってわけにもいかないですし。個人的には標準機能として追加されるのはメリット（ベンダーがサポートするので）と思っています。

管理画面はまだまだ変わるはず

Bootstrapベースの管理画面に変わりました。Bootstrapベースなので、管理画面のカスタマイズも柔軟にできるようになりそう。管理画面が必要なタイプのプラグインは、対応必須ですね。メジャーバージョンアップのときはいつも対応が必要ですが、PC/SP対応となるとちょっと億劫かも。Bootstrapベースなので、モバイルブラウザでも対応できないこともない。。。

まだプラグインの管理画面変更の作業は「できない」状態です。

MTDDCの運営お疲れさまでした

MTコミュニティのMT東京にいるので、運営も気になりました。というか、運営が気になりました。

シングルトラックなのと、登壇される方はシックス・アパートの方々なので、登壇者ケアは最小限で済みそうでした。複数トラックで社外登壇者の場合だと、気持ちよくご登壇いただけるようにすることが重要です。イベントは登壇者様ありきなところも多くあります。

会場となったグローバルビジネスハブ東京も広かったですし、人数もちょうどよい感じで、導線やサイドモニタの配置など、問題なさそうでした。後ろの方の人は、もしかしたらちょっと厳しかったかも？すべての人に平等にとなると背もたれにモニタをつけるとか飛行機の座席みたいになっちゃうので、早めに受付して前の方の席をとる！というのが人気イベントでは鉄則です。

本編〜懇親会も滞りなかったですし、受付も混雑することなく、テキパキと流れていました。司会のリードもよく、声も会場にしっかりと届いていました。

運営のみなさま、本当にお疲れさまでした！

その他

個人的に職業柄というか経験上、以下のことを思いながら参加しました。

1. バージョンアップする場合、どのあたりがネックになるか
2. 必須システム構成はかわるのか
3. バージョンアップで顧客メリットはなにか

個人サイトならともかく、企業に入れている場合は予算との兼ね合いが必要です。そして、新規でMTを入れるケースよりも、バージョンアップのほうが経験上としては多いです。これは、そう簡単にシステムリプレースなんてできないから、というのが多くの理由だと思います。

データ移行、機能定義、運用設計、テストなど、システムリプレースでは本当に時間がかかります。特に、「現行から変更NG」なんてこともザラにありますし、その確認作業が途方もない。ソースコードレベルでやるにしても、数万以上の記事があったら、アーカイブも含めて大変な確認作業が必要になります。エンプラ案件になったら、開発費用よりもただの「確認作業」の方が費用がかかるかもしれないのです。

システムリプレース自体は否定しません。メリットがあるならばやるべきです。MTも、どこかのシステムからリプレースしたケースもあるわけですし、その反対も十分考える必要があります。とくに、CRM連携やSFA、SNS周りの機能を求めるケースはよくあります。管理しているコンテンツを最大限に活かす必要性も考えていくべきでしょう。

ひとまず、上記３点について思いつくものを上げていきます。内容的には顧客目線です。顧客が予算獲得するのに十分な説明が必要なので、そのあたりで突っ込まれそうなところ特に。

バージョンアップする場合、どのあたりがネックになるか

1. バージョンアップすると、どういうことができるの？
   →MT自体に大きく変わったところはコンテンツタイプの部分なので、「こういうことができるようになります」という提案をしていけば良い。
2. コンテンツタイプ使う必要性あるの？
   →同じ見た目、同じ機能ならば、利用する必要がない。
3. いずれはMT6のサポートがなくなる
   →今のバージョンをずっと使うことはできない。システムリプレースするよりは、バージョンアップする方が費用はかかりづらい

必須システム構成はかわるのか

1. Perlのバージョンが、推奨が5.18系になる
   →Windowsサーバでどうなるか。Strawberry Perl は推奨版が5.26系なので、ダイジョブそう？
2. MySQLからMariaDBへ変更
   →これは問題なさそう。
3. PHPのバージョンも、推奨が7系になる
   →MTがというよりも、同じサーバで動いている別のもの（WPとかね）が気になる。動的生成なければもともとPHPなくてもMTは動くので。

バージョンアップで顧客メリットはなにか

1. 顧客にとっての「コンバージョン」は上がるのか
   →ただのバージョンアップでは、コンバージョンはたぶん上がらない
2. 追加された機能を利用したプラスアルファの提案が必要
   →何も変わらないものにお金を払う人はいないので、どんどん提案すべき
3. セキュリティ対策という名目では予算が出る
   →しばらくMT6も並行するのですぐにではないですが、ゆくゆくはセキュリティ上、バージョンアップしないといけない

その他のまとめ

• バージョンアップついでに、新しい機能実装や付加価値の高い何かを提案しよう。
• セキュリティに敏感な企業には、積極的にアピールしていこう。
• MT本体だけじゃなく、プラグインもMT7対応するか情報を集めよう
• バージョンアップか、システムリプレースか、どちらのほうがメリットがあるか考えよう。

という感じです。

なににせよ、MT7は楽しみです。さて、MAMPで動かしてみようっと。

懇親会のLTの様子。歳とったなぁｗ