吉田真吾(@yoshidashingo)です。Dayのクロージングを聞きながら執筆しています。昨日までの炎天下に比べて10度近く気温が下がったおかげで快適に過ごせています。MarketplaceでWordPressのAMIを販売したり、それを使ったマネージドホスティングを提供しているDigitalcubeさんに「WordPressのユーザー層かつAWSを知らない層かつ、EUでは無名状態のAMIMOTOを広げる為に、第3者目線で問題点の洗い出しを、吉田さんの経験とセクションナインの業務コンサルとして見てもらえないか」と依頼されました。「DigitalCubeではAMIMOTO以外にServerlessな取り組みを積極的にやっているが、それをWordPressに活かしたいと考えているので、そのあたりで第3者としての意見が欲しい」といった依頼もいただきました。ja.amimoto-ami.com2013年,2014年とcloudpackのエバンジェリストとしてラスベガスのre:Inventに出展した経験から、海外で売る難しさはよくわかりますし、すでにMarketplaceでグローバルにプロダクトを販売しているAMIMOTOがどうマーケットとの関係を築けているか、あるいは最近自分の中で最も熱いトピック「Serverless」に対してWordPress界隈でどんな動きがあるかな?といった点に興味があり快諾しました。本来こういった調査レポートは内部報告のみとするものですが、良くも悪くも全て包み隠さず一般公開しても構わないとデジタルキューブさんに許可をいただいたため、他の日本発のプロダクトやサービスが海外を目指す時にも同じように抱えうる問題点や悩みに対する参考情報にしてもらえると嬉しいと思います。ミュージアムの中庭にて。今回はAMIMOTO以外にもう一つ、WordPressのMicroservices化について調査する目的をもって参加していました。WordPressは現在、世界中のWebの26.5%、マーケットシェアで59.5%を獲得している世界最大のユーザー規模を持つCMSです。そのシェアが増えているという状況です。w3techs.comここまでシェアが伸びた理由はいくつもあるでしょうが、そのひとつに、専門的な知識がなくてもテーマやプラグインを追加するだけで見た目の変更や機能追加がすぐにできるという便利さがあったと思います。近年ではプラグインがサンドボックスになっていないことで突かれる脆弱性や、スケーラビリティの確保の難しさが指摘されるようになり、モノリシックであることの弊害が叫ばれるようになりました。それが顕著になるくらいエコシステムのビジネスが大きくなったし、引き続き専門知識がなくても使えるということから、非常に利用者の幅が増えてきたということでしょう。Architecture化」や「Servicefull構成(あまりいい呼び方ではないけど)」、あるいはシングルページアプリケーション(SPA)化ができないものか、あるいはすでにうまくやっているところはあるかといった現状を確認しようと思いました。グローバルにモノを売るということということで、まずは「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ベース)でスタックを管理するメリットは「セキュアなプラットフォーム」で「無限にスケール」して「構成のメンテナンスの手間がかからない」ことです。このメリットを価値を考える人を想定しようとすると「大規模なメディア」や「個人情報/クレカなど扱うコマース」に限定されてきます。ターゲット顧客が限定されてしまうならはじめから限定してしまえばよいですね。ターゲットを絞ったメッセージに変えてみましょう。顧客の大半はインフラエンジニアじゃないうえ、そういうエンジニアはブース以外でも出会えるので、セルフで使う人はターゲットからはずしてみましょう。顧客の中に「メディアやコマースの事業者」と「事業者から制作と運営を請け負っているエージェンシー」が含まれますが、ひとまずここらへんまでをターゲットにしてみましょう。DSS準拠可能でセキュアに個人情報やクレジットカード情報を扱えます検索機能、レコメンドエンジン、WAF、改ざん検知などコマースに必要な機能をビルトイン高機能なのに無限にスケールされる信頼性高いプラットフォームSLAごとに選べるプロサービスやサポートプランだいぶマシになったんじゃないですかね。顧客から見えるものを設計するまた、AMIMOTOのユーザーは利用開始後、直接AWSにログインして操作しないといけないので、複雑な機能性で避けられがちなAWSの管理が面倒と感じない顧客以外から避けられてしまいます。そもそもAMIMOTOとはなにかを理解するために何を見ればいいか考えたとき、MarketplaceなのかAWSの管理画面なのかホームページなのかよく分かりません。「AMIMOTOはまだ半可品」なのです。顧客から見えるものを統一するという意味でどんなことをすればよいでしょう。そのヒントはダッシュボードにあると感じました。AMIMOTOを顧客やエージェンシーにセルフで使ってもらうにしても、フルマネージドで環境を提供するにしても、以下のような情報はつねに顧客が見たいタイミングで見てもらえるようにするべきです。(以下は例)インフラレイヤ99パーセンタイルのレスポンス時間ライブラリの更新通知CPUやメモリ、ディスクの利用状況ドメイン/SSL管理WordPressレイヤワンクリックでのWordPress環境構築ユーザー管理GitHubなどのリポジトリとのインテグレーション複数のステージ管理(本番/ステージ/開発)本体やテーマ、プラグインのアップデート管理アドオンとしての追加機能(検索、CDN、などなど)PHPログアクセシビリティの準拠度合いアクティビティ(ログインや記事更新の履歴)バックアップ管理SEO状況サービスプランのアップグレード支払い履歴WordPressレイヤについては管理画面からプラグインで実装も可能ですが、JINKEIなど複雑なリソース管理が必要になると、一枚にラップするダッシュボードがないとビジネスとしての展開は難しいのではないかと感じます。今回ブースを回って他社のダッシュボードの機能性を確認しましたが、それぞれ見た目もアーキテクチャも個性的だったので、以下で紹介してみたいと思います。Pantheonpantheon.ioエージェンシー(制作会社)向けのホスティングサービスインフラにRackspaceを利用し、その上に独自のコンテナ技術(Dockerは当初使っていたが今は独自技術に変えたらしい)を利用してWordPressのWebのコンテナ、ストレージのコンテナ、DBのコンテナを配置してスケール変更しやすくしている。利用者はダッシュボードからWordPressのサイトをワンクリックでデプロイでき、2分くらいで完了します。サイト自体のインストールはそこからさらにWordPressのインストール画面に遷移して実行する。GitHubとのインテグレーションやテスト環境/本番環境の管理もこのダッシュボードコンテナでのスタックの管理については、彼らの社内向けの別のダッシュボードを見させてもらいました。ダッシュボード上のGUI操作で、ある環境にWebのコンテナやローカルストレージのコンテナをドラッグ&ドロップして適用すると30秒程度で構成に反映されるというデモを行っており、こういう「素早いプロビジョニング」にコンテナ技術を活用し、物理リソースとリソースの割当てを切り離して管理している点が非常に上手いなと感じました。APIによりデータを取得する構成にしていこうという方向性が語られ、APIが注目のトピックだそうです。wordpress.tvモノリスWordPressがモノリシックな構成であることは、簡単にセットアップできるうえ、管理画面さえ見ればなんでもできるというとても便利な利点がある反面、以下のような弊害もあります。弊害1:水平スケールしにくいコンテンツの作成場所(管理画面)と配信場所が基本的に1:1で配備されている。テーマやプラグインなどもサーバー単位でのメンテナンスが必要である。弊害2:プラグイン経由のセキュリティ脆弱性がサイト全体に影響を及ぼす弊害3:モバイル対応がいまいちコンテンツ作成者がWordPressの管理画面にログインしないといけないため、今後よりモバイルネイティブになっていく中で、モバイルアプリでのコンテンツ作成などに対応できない。API上記のような課題に対応するために、すでにコミュニティでは数年間、APIの実装について議論も実装も進んでいるそうで、現状で「コアのAPI」と「APIプラグイン」が利用可能になっています。APIについての考察」についてホワイトペーパーも提供されています。github.com日本語訳:github.comメリット:ヘッドレスCMSの実現CMSとテーマシステムを分離し、「フロントエンドとコンテンツ管理の分離」を実現することで、リッチなUI表現や複数のフロントエンド(PC、モバイル、アプリ、それ以外の可能性も)が実現可能になります。転載コンテンツ管理についても、管理画面を経由せず、モバイルアプリからパブリッシュしたりできるようになる。APIについては、「CMSの実装」としての課題解決方法ですが、ここで「フロントエンドとコンテンツ管理の分離」を目的にするのであれば、われわれにはもう一つの選択肢がすでにあることを思い出しました。それが「サーバーレスアーキテクチャ」による解決です。MoreStaticPressを用いたサーバーレスな「フロントエンドとコンテンツ管理の分離」は、CMSの実装方法による解決ではなく、アーキテクチャやエコシステムを用いて解決する「サービスフルなアプローチ」という意味で第3の選択肢です。Hostingし、CDNなどに載せて配信することで、「フロントエンドとコンテンツ管理の分離」ができ、小さなパブリッシュ用の管理インスタンスを用意するだけで、WordPressを利用せずにグローバルに大規模に配信が可能になります。モノリシック→ヘッドレスCMSほどギャップがないコンテンツ管理側は基本的には現状のまま、スケーラビリティを考慮する必要がない。FormやZopim、Auth0やCognitoに統合するかについては考慮する必要がある。モノリシックからヘッドレス化するための対応コストや、今まで慣れ親しんだテーマを捨てて再度フロントをJavaScriptで実装することに比べて、圧倒的に簡単に実現できる。StaticPressで書き出してCDNから配信すればよいだけだから。その他サーバーレスCMSは、CMSの「コアの実装」ではなく、クラウドサービスやCDNサービスとの組合せが大前提な「アーキテクチャ」であることには注意が必要。今後はこういったアーキテクチャをさらにどれだけ簡単にセットアップできて利用できるかどうかが普及の鍵になるのではないかと思う。WordCampに参加していたユーザーやエージェンシーの人からは「AWSは複雑で難しい」と何度も言われたので、インハウスのエンジニアがいない層にいかにSaaSifyして提供するかといった課題。まとめということで、AMIMOTOの調査に行って色々気づきを得たうえ旅でした。Yoshidawww.slideshare.netセクションナインでは、既存事業のSaaSify、あるいはサーバーレスアーキテクチャを用いて信頼性高く大規模なサービスを展開したい会社をクラウドエキスパートとして、マーケティングの分野まで含めて支援しています。必要に応じてご相談ください。...シン・ゴジラおもしろかった。相談する3/14発売。開催します!HISTORY人気記事Qiitaに投稿した記事yoshidashingoのtips読まれてますスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。