どうも、セクションナイン の 吉田真吾（@yoshidashingo）です。
ウィーンからこんばんわ、WordCamp EUのContributor Dayのクロージングを聞きながら執筆しています。昨日までの炎天下に比べて10度近く気温が下がったおかげで快適に過ごせています。
今回6/24〜26にオーストリアのウィーンで開催されたWordCamp EUに参加しました。
2016.europe.wordcamp.org
経緯
AMIMOTOという、AWS MarketplaceでWordPressのAMIを販売したり、それを使ったマネージドホスティングを提供しているDigitalcubeさんに「WordPressのユーザー層かつAWSを知らない層かつ、EUでは無名状態のAMIMOTOを広げる為に、第3者目線で問題点の洗い出しを、吉田さんの経験とセクションナインの業務コンサルとして見てもらえないか」と依頼されました。
また「DigitalCubeではAMIMOTO以外にServerlessな取り組みを積極的にやっているが、それをWordPressに活かしたいと考えているので、そのあたりで第3者としての意見が欲しい」といった依頼もいただきました。
ja.amimoto-ami.com
2013年,2014年とcloudpackのエバンジェリストとしてラスベガスのre:Inventに出展した経験から、海外で売る難しさはよくわかりますし、すでにMarketplaceでグローバルにプロダクトを販売しているAMIMOTOがどうマーケットとの関係を築けているか、あるいは最近自分の中で最も熱いトピック「Serverless」に対してWordPress界隈でどんな動きがあるかな？といった点に興味があり快諾しました。
本来こういった調査レポートは内部報告のみとするものですが、良くも悪くも全て包み隠さず一般公開しても構わないとデジタルキューブさんに許可をいただいたため、他の日本発のプロダクトやサービスが海外を目指す時にも同じように抱えうる問題点や悩みに対する参考情報にしてもらえると嬉しいと思います。
22時。ミュージアムの中庭にて。
もうひとつの目的
今回はAMIMOTO以外にもう一つ、WordPressのMicroservices化について調査する目的をもって参加していました。
WordPressは現在、世界中のWebの26.5%、マーケットシェアで59.5%を獲得している世界最大のユーザー規模を持つCMSです。しかもいまだにそのシェアが増えているという状況です。
w3techs.com
ここまでシェアが伸びた理由はいくつもあるでしょうが、そのひとつに、専門的な知識がなくてもテーマやプラグインを追加するだけで見た目の変更や機能追加がすぐにできるという便利さがあったと思います。
近年ではプラグインがサンドボックスになっていないことで突かれる脆弱性や、スケーラビリティの確保の難しさが指摘されるようになり、モノリシックであることの弊害が叫ばれるようになりました。それが顕著になるくらいエコシステムのビジネスが大きくなったし、引き続き専門知識がなくても使えるということから、非常に利用者の幅が増えてきたということでしょう。
AWSのエキスパートとして、そういった課題に対して、機能単位でAPIシステムや他事業者のサービスにオフロードする「Microservices Architecture化」や「Servicefull構成（あまりいい呼び方ではないけど）」、あるいはシングルページアプリケーション(SPA)化ができないものか、あるいはすでにうまくやっているところはあるかといった現状を確認しようと思いました。
1. グローバルにモノを売るということ
ということで、まずは「AMIMOTO」の話です。
AMIMOTOブースでよかった点は、AMIMOTOのエバンジェリストの西川さんのビジネスにおけるコミュニケーション能力が非常に高かったため、正しくサービスやプロダクトの意図や開発経緯が伝わっていた点です。わざわざ書かかせてもらいたいくらい素晴らしいコミュ力でした。
日本国内のイベントの出展ブースだと顧客の課題を聞かずに製品説明をひたすら行っている人がいたりしますが、少なくともこちらのお客さんは自分たちの抱える課題や意見を積極的に話してくれたうえで、それに対して出展者がどういう解決方法を提供するか、あるいは提供しないか（スコープが違えばその段階でそれ以上のものは提供しない）といったレベルの会話ができており、とても建設的でよかったなと感じました。
ではそれ以外はどうだったかというと、正直シブかったなと言わざるを得ない場面が多かったです。他社のブースに人が殺到していても、AMIMOTOブースに人が殺到することはなく、「何のサービスかわからない」ことにより避けられてしまっていたということが明らかでした。
何のサービスかわからない
AMIMOTOと言えば、日本ではAWSとコマーケティングしたり、積極的に都内や地方に巡業して勉強会やハンズオンを開催したり、各地方でのアンバサダー・マーケティング（網元起動隊）をしたりと、いまや日本国内においてはWordPressをAWSで稼働させるという点において知らない人はモグリだと言えるレベルで成功しているといって問題ないと思います。
ただし海外での知名度ががないうえに、以下2点のような原因から顧客の背中が押せてないと感じました。
まずブースのぱっと見で何モノかわからない
ブースにいくつかメッセージが書いてありますが、文章中心で、ブースのビジュアルで「自分たちが何モノであるか」語りかけるものがありませんでした。
とくに、サービスなのか、ホスティング事業なのか、ソフトウェアなのか、という単純な違いからしてメッセージを発信できていなかったかなと思います。
ブースに人がくるためには、遠くから見てもそのサービスやプロダクトが何なのかが分かり、お客さんの抱える課題に「あれ、もしかしてあそこのサービスは〇〇な課題に対してエレガントな解決方法を知ってるかもしれない」という程度には語りかけられる必要があります。
そしてサービスの説明が長い
海外での知名度がほとんどないので、ブースの雰囲気を見て興味が湧いたお客さんがブースに内容の説明を求めにくるのですが、ソフトウェア（AMIをセルフサービスで利用）と、マネージドホスティングがあること、ソフトウェアについてはさらにモノリシックな構成のものからマイクロサービス化された構成（JINKEI）まで自由に展開できること、といった主旨を話すのに10分以上かかり、聞き終わる頃にはお客さんの中には興味が薄れてしまう場合が多くありました。
- 「チューニング済みAMIプロダクト」なのか「AWSのマネージド・サービスを駆使したブループリント」なのか「デベロッパーや顧客がインフラレベルを意識しなくてもよいフルマネージドホスティング」なのかわからない
- 上記はそれぞれ顧客にとって何を解決するから価値があるのか
象徴的なできごと：とある有名CEOからのアドバイス
ブースに来たとある有名CEOに以下のようなことを言われました。
- 何をしているサービスか分からない
- ホスティングサービスなのかプロダクトなのかわからない
- これは誰に対して売りたいもの？
- エンジニア？開発者？エージェント？カスタマー？
- エンジニアにならAWSを使っているというだけで価値が分かるかもしれないけど、そうじゃなければよしなに動いていればいいと思うよ。
- そもそもインフラはAWSじゃなくてもいいと思ってるお客さんのほうが多くて、各国のドメスティックなVPSとかを使っているのがほとんどだよ、AWSが簡単にスケールできるというなら、そういうピーキーなアクセスがあるメディアにだけターゲットを絞ってやったほうがいいと思うよ
- そもそもユーザーストーリーみたいなのはある？
SaaSifyのスコープはプロダクト開発のみにかぎらない
AMIMOTOという強力なプロダクトでさえ海外だとあまりささっていないという状況を客観的に見てみると、マーケティングの重要性に気づかされます。
「一つのことをうまくやり、設定したペルソナに対して利用上の弊害を徹底的に排除する」というベストプラクティスでさえ、そばで見ているがゆえになかなか気づきにくいものだなと感じました。
そういうものがまだしっかりとしていない段階で出展することは、調査目的などの別の意図がないかぎりはかなり厳しい忸怩たる思いを持ち帰ることになるかなと思いますし、スコープを広く取るスタンスであれば、海外においては「販売代理やプロジェクトマネジメントを肩代わりしてくれるエージェンシー（広告代理店、制作会社）」が多数あるので、そちらがわとのつながりを強化する戦略なども合わせて考えてみたほうがよいだろうと思います。
AMIMOTOの価値はなにか
AMIMOTOの大きな特徴に「チューニング済みのAMIが提供される」「CFnによりスタックが管理できる」「マネージドホスティングもやっている」というのがありますが、これは機能ではあっても顧客に届ける価値ではないので、これを顧客の価値に合わせたメッセージに変える必要があります。もちろんAWS上にホストされていることすら、それ自体は価値ではありません。
現段階の顧客に対する価値を書き出してみると、以下のようになります。
- チューニング済みのWordPress環境がすぐに準備できて、無限にスケールする環境を「自分かお任せで」構築できる
- おまかせで信頼性高くホスティングをしてくれる
これだとあまり魅力的じゃない気がしませんか。
たとえばJINKEI(CFnベース)でスタックを管理するメリットは「セキュアなプラットフォーム」で「無限にスケール」して「構成のメンテナンスの手間がかからない」ことです。当然このメリットを価値を考える人を想定しようとすると「大規模なメディア」や「個人情報/クレカなど扱うコマース」に限定されてきます。ターゲット顧客が限定されてしまうならはじめから限定してしまえばよいですね。ちょっとターゲットを絞ったメッセージに変えてみましょう。また、顧客の大半はインフラエンジニアじゃないうえ、そういうエンジニアはブース以外でも出会えるので、セルフで使う人はターゲットからはずしてみましょう。顧客の中に「メディアやコマースの事業者」と「事業者から制作と運営を請け負っているエージェンシー」が含まれますが、ひとまずここらへんまでをターゲットにしてみましょう。
- 絶対に落とせない大規模メディア事業者専用プラットフォーム「AMIMOTOメディア」
- 全世界どこからアクセスしても同一体験が可能なグローバルCDNネットワークをビルトイン
- ノイジーネイバーに邪魔されない専用環境
- 大量のトラフィックが来てもエラーを返さないオートスケールがビルトイン
- SLAごとに選べるプロサービスやサポートプラン
- セキュアで高機能でスケールするコマース専用プラットフォーム「AMIMOTOコマース」
- PCI DSS準拠可能でセキュアに個人情報やクレジットカード情報を扱えます
- 検索機能、レコメンドエンジン、WAF、改ざん検知などコマースに必要な機能をビルトイン
- 高機能なのに無限にスケールされる信頼性高いプラットフォーム
- SLAごとに選べるプロサービスやサポートプラン
だいぶマシになったんじゃないですかね。
顧客から見えるものを設計する
また、AMIMOTOのユーザーは利用開始後、直接AWSにログインして操作しないといけないので、複雑な機能性で避けられがちなAWSの管理が面倒と感じない顧客以外から避けられてしまいます。また、そもそもAMIMOTOとはなにかを理解するために何を見ればいいか考えたとき、MarketplaceなのかAWSの管理画面なのかホームページなのかよく分かりません。つまり「AMIMOTOはまだ半可品」なのです。
では顧客から見えるものを統一するという意味でどんなことをすればよいでしょう。そのヒントはダッシュボードにあると感じました。
AMIMOTOを顧客やエージェンシーにセルフで使ってもらうにしても、フルマネージドで環境を提供するにしても、以下のような情報はつねに顧客が見たいタイミングで見てもらえるようにするべきです。（以下は例）
- インフラレイヤ
- 99パーセンタイルのレスポンス時間
- ライブラリの更新通知
- CPUやメモリ、ディスクの利用状況
- ドメイン/SSL管理
- WordPressレイヤ
- ワンクリックでのWordPress環境構築
- ユーザー管理
- GitHubなどのリポジトリとのインテグレーション
- 複数のステージ管理（本番/ステージ/開発）
- 本体やテーマ、プラグインのアップデート管理
- アドオンとしての追加機能（検索、CDN、などなど）
- PHPログ
- アクセシビリティの準拠度合い
- アクティビティ（ログインや記事更新の履歴）
- バックアップ管理
- SEO状況
- サービス
WordPressレイヤについては管理画面からプラグインで実装も可能ですが、JINKEIなど複雑なリソース管理が必要になると、一枚にラップするダッシュボードがないとビジネスとしての展開は難しいのではないかと感じます。
また、今回ブースを回って他社のダッシュボードの機能性を確認しましたが、それぞれ見た目もアーキテクチャも個性的だったので、以下で紹介してみたいと思います。
Pantheon
pantheon.io
- エージェンシー(制作会社)向けのホスティングサービス
- インフラにRackspaceを利用し、その上に独自のコンテナ技術（Dockerは当初使っていたが今は独自技術に変えたらしい）を利用してWordPressのWebのコンテナ、ストレージのコンテナ、DBのコンテナを配置してスケール変更しやすくしている。
- 利用者はダッシュボードからWordPressのサイトをワンクリックでデプロイでき、2分くらいで完了します。
- サイト自体のインストールはそこからさらにWordPressのインストール画面に遷移して実行する。
- GitHubとのインテグレーションやテスト環境/本番環境の管理もこのダッシュボード
- コンテナでのスタックの管理については、彼らの社内向けの別のダッシュボードを見させてもらいました。ダッシュボード上のGUI操作で、ある環境にWebのコンテナやローカルストレージのコンテナをドラッグ&ドロップして適用すると30秒程度で構成に反映されるというデモを行っており、こういう「素早いプロビジョニング」にコンテナ技術を活用し、物理リソースとリソースの割当てを切り離して管理している点が非常に上手いなと感じました。
Flywheel
getflywheel.com
- インハウスのデザイナーやフリーランサーに人気があるホスティングサービス
- インフラはDigitalOceanなので利用可能なリージョンはDOがあるところのみ
- 共有サービスとのことなので、サイトは2分くらいでできるがおそらくモノリシックなヴァーチャルホストでの構成
Stacksight
http://stacksight.io
- WordPressやDrupalサイトにおいて、ログやバックアップ、アクティビティ（管理）、SEOなどが管理できるダッシュボード
2. モノリス対API → 第3の波：サーバーレス
さてさて、話題は変わってもう一つの調査目的「モノリシックからAPIセントリックに変わっていく世界におけるWordPress自体の変化」についてですが、WordPressの作者「Matt Mullenweg」のQ&Aセッションで、今後はフロントをJavascript化してRESTful APIによりデータを取得する構成にしていこうという方向性が語られ、APIが注目のトピックだそうです。
wordpress.tv
モノリス
WordPressがモノリシックな構成であることは、簡単にセットアップできるうえ、管理画面さえ見ればなんでもできるというとても便利な利点がある反面、以下のような弊害もあります。
弊害1：水平スケールしにくい
- コンテンツの作成場所(管理画面)と配信場所が基本的に1:1で配備されている。
- テーマやプラグインなどもサーバー単位でのメンテナンスが必要である。
弊害2：プラグイン経由のセキュリティ脆弱性がサイト全体に影響を及ぼす
弊害3：モバイル対応がいまいち
- コンテンツ作成者がWordPressの管理画面にログインしないといけないため、今後よりモバイルネイティブになっていく中で、モバイルアプリでのコンテンツ作成などに対応できない。
API
上記のような課題に対応するために、すでにコミュニティでは数年間、APIの実装について議論も実装も進んでいるそうで、現状で「コアのAPI」と「APIプラグイン」が利用可能になっています。
WordPress APIs
WordPress APIs « WordPress Codex
WordPress REST API(Plugin)
ja.wordpress.org
REST API Whitepaper
また、Human Madeという会社のメンバーが中心になり、「WordPress REST APIについての考察」についてホワイトペーパーも提供されています。
github.com
日本語訳：
github.com
メリット：ヘッドレスCMSの実現
- CMSとテーマシステムを分離し、「フロントエンドとコンテンツ管理の分離」を実現することで、リッチなUI表現や複数のフロントエンド（PC、モバイル、アプリ、それ以外の可能性も）が実現可能になります。
※ https://github.com/humanmade/rest-api-white-paper より転載
- コンテンツ管理についても、管理画面を経由せず、モバイルアプリからパブリッシュしたりできるようになる。
フロントエンドとコンテンツ管理の分離についてのもう一つの選択肢「サーバーレス」
ヘッドレスCMSの実現のためのREST APIについては、「CMSの実装」としての課題解決方法ですが、ここで「フロントエンドとコンテンツ管理の分離」を目的にするのであれば、われわれにはもう一つの選択肢がすでにあることを思い出しました。それが「サーバーレスアーキテクチャ」による解決です。
Serverless WordPress = StaticPress + Static Site Hosting + CDN + More
StaticPressを用いたサーバーレスな「フロントエンドとコンテンツ管理の分離」は、CMSの実装方法による解決ではなく、アーキテクチャやエコシステムを用いて解決する「サービスフルなアプローチ」という意味で第3の選択肢です。
Shifter: The Jamstack WordPress hosting platform.
すでにたくさんのユーザーに活用されているStaticPress
StaticPressのプラグインをインストールし、静的ファイルに書き出し、Amazon S3などでStatic Site Hostingし、CDNなどに載せて配信することで、「フロントエンドとコンテンツ管理の分離」ができ、小さなパブリッシュ用の管理インスタンスを用意するだけで、WordPressを利用せずにグローバルに大規模に配信が可能になります。
モノリシック→ヘッドレスCMSほどギャップがない
- コンテンツ管理側は基本的には現状のまま、スケーラビリティを考慮する必要がない。
- 技術的に静的ファイルにしにくい「問合せフォーム」や「ユーザー認証基盤」をどの段階でGoogle FormやZopim、Auth0やCognitoに統合するかについては考慮する必要がある。
- モノリシックからヘッドレス化するための対応コストや、今まで慣れ親しんだテーマを捨てて再度フロントをJavaScriptで実装することに比べて、圧倒的に簡単に実現できる。StaticPressで書き出してCDNから配信すればよいだけだから。
その他
- サーバーレスCMSは、CMSの「コアの実装」ではなく、クラウドサービスやCDNサービスとの組合せが大前提な「アーキテクチャ」であることには注意が必要。
- 今後はこういったアーキテクチャをさらにどれだけ簡単にセットアップできて利用できるかどうかが普及の鍵になるのではないかと思う。WordCampに参加していたユーザーやエージェンシーの人からは「AWSは複雑で難しい」と何度も言われたので、インハウスのエンジニアがいない層にいかにSaaSifyして提供するかといった課題。
まとめ
ということで、AMIMOTOの調査に行って色々気づきを得たうえ旅でした。
あと昨日のLTのスライド
www.slideshare.net
セクションナインでは、既存事業のSaaSify、あるいはサーバーレスアーキテクチャを用いて信頼性高く大規模なサービスを展開したい会社をクラウドエキスパートとして、マーケティングの分野まで含めて支援しています。必要に応じてご相談ください。
https://sec9.co.jpsec9.co.jp
