（１） 競合調査をする
当たり前ですがしっかり競合調査をしましょう。
同じようなウェブサービスが世界に存在しない場合、そのサービスに本当に価値があるのかどうか周りとよく相談しましょう。なぜなら、価値があるのなら既に同じようなウェブサービスがどこかに存在している可能性が高く、価値がないから存在していない、という見方もできるからです。周りとよく相談した上でそれでも大きな価値が認められ、かつ同じようなウェブサービスが世界に存在していないなら、それは天からの授かりものだと思って大切にすると良いでしょう。
また、同じようなウェブサービスが世界のあちこちに存在する場合、それらのサービスの欠点やあったら良いなと思われる機能を洗い出し、差別化の方向性を慎重に検討しましょう。少なくとも既存のサービスとは異なる、もしくは上回る何かがなければ、たくさんのユーザーがそのサービスを利用することはありません。
（２） ユースケースやシナリオを定義する
まず、ユースケースやシナリオをしっかり定義し、ユースケースのそれぞれに対して、ユーザーに過度なストレスを強いる部分がないかどうか検証しましょう。「面倒くさい」「大変そう」「何の意味があるの」「分からない」 といった反応が少しでも予想される部分があれば、それは癌です。設計に入る前にそのユースケースやシナリオを見直しましょう。
経験的には、世界に挑戦する以前の話となりますが、この （２） の時点で既に先の失敗が予想されるサービスが多いように思います。ユーザーが過度なストレスを乗り越えてでもそのサービスを利用してくれる、といった甘い期待は捨てましょう。とかく、コミュニケーションのプロセスが煩雑なサービスは失敗しやすいので、そういった部分がないかどうかは入念にチェックします。
（３） 設計する
スケールが容易なインフラに乗せることを前提に、後の拡張が容易なように設計しましょう。サービスのパフォーマンスやセキュリティに影響が出ない範囲で、疎結合、各機能のコンポーネント （API） 化を心がけると良いと思います。
また、（２） と （３） の時点で、Twitter や Facebook、iPhone にどのように対応させていくかも予め検討しておきましょう。どのようなサービスを作るにせよ、上記の 3 サービスは 3 種の神器です。対応させて困ることは何もありません。予め、プラットフォームに依存しないオープンな設計を心がけることで、各種のプラットフォームへの対応が非常に容易になります。
（４） 実装する
実装します。ちなみに （１）、（２）、（３）、（４） はもちろんウォーターフォールではなくイテレーションで進めても構いません。が、イテレーションで進めなければならないほどのサイズであることには注意が必要だと思います。（リリースの時点で本当にそんなにたくさんのユースケースをカバーする必要があるの？）
（５） 多言語化する
当たり前ですが最低でも英語には対応しましょう。また、多言語化するということは、当然その言語でのユーザーサポートが必要になるということです。ユーザーサポートのコストは非常に高くつくので、多言語化する際にはそれ相応の覚悟で望みましょう。
（６） リリースする
リリースしましょう。また、リリースの際のプロモーションはするに越したことはないですが、大規模なものは必ずしも必要ないと思います。上記の 3 種の神器に対応することで多少は人の目に触れることが可能なので、もしそのサービスに本当に価値があるのなら、いずれ口コミで大きく広がっていくでしょう。むしろプロモーションに多大な労力を注ぐよりは、地道なデザイン／機能改善やユーザーサポートに力を注いだ方が賢明です。
—-
以上、正直な話、ある意味ではドメスティックなウェブサービスの作り方とほとんど変わらないですね。また、偉そうに言っているけどハートレイルズではどのくらいできているんだ？みたいな突っ込みが入りそうですが、はい、ハートレイルズでも全然できているとは言い難い状況です。（全然できていない状況にも関わらず、ブログなどでハートレイルズのサービスを紹介してくださっている海外ユーザーの方々には本当に感謝しています。）
最近は初心に立ち返り、世界に向けてガツンとかましてやるかといった気持ちで一杯になってきているので、そう遠くないうちに、目に見える形で色々とアクションを起こしていきたいと思っています。何か一緒に世界向けにやらないか、といった話も大歓迎なので、そういう志を持っている方はぜひ一度お声掛けください。みんなで楽しんでウェブサービスを作りましょう。
“世界に挑戦するウェブサービスの作り方” への1件のフィードバック