スケーラブルなMVP(Minimum Viable Product)を構築するには

MVP(Minimum Viable Product)の開発にはスケーラビリティに対する考慮が必要だ，とErik Duindam氏は主張する。MVPは技術的にスケーラブルでなくてはならない。MVPが多くのユーザの獲得に成功した時に素早く拡張できるよう，計画を持っておく必要がある。考えられるパフォーマンスボトルネックを認識し，MVP開発時に常識を働かすことが成功の秘訣だ，と氏は言う。

UnboxdのCTOであるEric Duindam氏はAgile and Software Architecture Symposium 2016 (ASAS)で，チームと技術のスケーリングについて講演を行なった。InfoQではこのイベントをQ&Aや要約，記事を通じてお伝えする。

Mediumの記事“How I built an app with 500,000 users in five days on a $100 server”の中で氏は，MVP開発時のスケーラビリティの問題を論じている。

スタートアップの世界には，MVP(minimum viable product)の開発時には技術的なスケーラビリティについてあまり考慮すべきではない，という一般的なコンセンサスが存在するようです。(...) 技術的にスケーラブルな製品を作ることに，時間とお金を無駄にする必要はありません。考えるべきは仮定をテストし，市場を検証し，勢いづけることなのです。スケーラビリティはもっと後で考えればいいのです — 残念なことに，このような盲目的とも思える信念は，手ひどい失敗につながることが少なくありません。

スケーラブルなMVPを開発するためのプログラム言語の選択について，Duindam氏は次のように提案している。

サーバに潤沢な費用を掛けられない限り，リーンで高速な言語を選ぶことがスケーラビリティには重要です。MVPは短期間に開発する必要があるので，さらに重要なのが，有用なライブラリが数多く入手可能な言語を選ぶことです。NodeJSやScala，そしてGoは，この２つの要求をともに満足する優れた言語です。いずれもパフォーマンスに優れたツールを多数提供してくれます。

MVPは高い負荷を処理できるように開発されなくてはならない，とDuindam氏はASASの講演で主張している。MVPに100万人のユーザがいる場合に何が起きるか考え，それを扱うことができるかどうかを確認する必要がある。ボトルネックが何であるかを理解し，よいコードを書くための常識的なテクニックを適用して，技術的問題を防止するべきだ。

Duindam氏は，データのフェッチ時にMongooseのlean()関数を用いることで，サーバ負荷の90%を削減した事例を提供している。コードに問題があれば，サーバの追加を続けなくてはならないが，これは受け入れられる解決策ではない，とDuindam氏は言う。

InfoQはErik Duindam氏にインタビューして，MVPが技術的にスケーラブルでなければならない理由や，スケーラブルなMVPの設計および開発の方法を聞くとともに，スケーラブルなMVPを開発するツールに関するアドバイスを求めた。

InfoQ: なぜMVP(Minimum Viable Product)は，技術的にスケーラブルでなければならないのでしょうか？

Erik Duindam: MVPの目的は，最小限の労力で検証結果を収集することにあります。実質的にこれは，検証プロセスに直接的に寄与しない機能や技術の開発に時間を費やすべきではない，という意味になります。従って美しいコードやアーキテクチャ，スケーラビリティに時間を使うというのは，一般的には意味がありません。自分の製品がSpaceXロケットのように発射すると信じる — そのためにスケーラビリティ技術をたっぷり詰め込む — というのは，SpaceXロケットの発射がすべて成功すると思い込むようなものです。それは理想的なシナリオですが，おそらく実現することはないでしょう(Zuckerburg氏に聞いてごらんなさい)。ですが，時間を掛けなくても，ほんの少しだけスケーラブルにできるとしたらどうでしょう？そして，もし，あなたのロケットが発射に成功したならば？

製品を販売するためにランディングページを立ち上げたものの，実際には販売しなかったリーンスタートアップとMVPの実例はたくさんあります。実際にシステムを開発して販売するのではなく，ビジネスや市場を調査するためにEメールアドレスを収集することが目的なのです。この例は分かりやすいのですが，MVPでは多くの場合うまく行きません。その技術や製品の最初のバージョンをテストしなくてはならなかったり，動作する製品を試してもらうユーザを実際に獲得する必要があるからです。このようなシナリオでは，速やかにスケールアップするための計画が必要になります。少なくとも製品のMVPバージョンが実務に使用されるかも知れない，という可能性は考慮しておかなくてはなりません。多くのメディアに取り上げられたり，その他の予期される，あるいは予期しない反応によって，多くのユーザを得ることになる可能性を考えておく必要があります。成功した場合のことを考えておかなくてはなりません。

InfoQ: スケーラブルなMVPを設計し構築するために何ができますか？

Duindam:最も重要なのは，MVPにとって何が“成功”なのかを，開発者が理解していることです。パフォーマンス上のボトルネックになり得るものが何か，急激に拡大した場合にはどう対処すればよいのかを，あなたと開発者が前もって理解しておかなくてはなりません。そのために私はまず，小さな計画を立てるようにしています。

第２には，スケーラビリティ上の困難な問題の多くが，怠惰と設計不足によるものであるという点です。そのよい例が，多数の開発者がデータベースからデータを取り出す方法です。開発者の多くは，自身のコードの中である種のデータベース抽象化を使用して，全面的にそれに固執しようとします。例えば，高速なJOINクエリを書けばよい処理を，何となくクリーンに見えるから，オブジェクト指向的だから，あるいは単純に“Railsのやり方”だから，といった理由で，ループ内でデータベースクエリを実行する方法を選ぶのです。私の経験から言えば，これは主として，開発者側の不安感に基づいています — データベース抽象化ツールを違う方法で使用しても問題がないということに，確証が持てないでいるのです。ですから，自分のプログラム方法がパフォーマンスに与える影響さえ認識できれば，問題はほとんど解消できていると言ってもよいでしょう。常識を使って開発することで，仕事の進み具合は大きく違ってきます。

InfoQ: スケーラブルなMVPを開発するためには，どのようなツールを使用するとよいのでしょうか？

Duindam: 特定のテクノロジやツールを推奨するのは好きではありません。同じような問題を解決する場合でも，パッケージによって少しずつ方法が違うからです。自分のプログラム言語やデータベース，ユースケースなどに最適なツールを自分自身で調査しなくてはなりません。言語やユースケースにマッチしたパフォーマンステストツールを探すのは，それほど難しいことではありませんが，もう少し汎用性のある話をしてみましょう。

重要なのは，ユーザ数が合理的なレベルであれば，どのプログラム言語やフレームワーク，データベースシステムでも拡張可能である，という認識です。スケーラビリティが理由でプログラム言語やデータベースシステムの選択肢が限られるような企業は，オランダの技術系会社ではごく一部に過ぎません。その他の企業には，スケーラビリティが問題になるほどの規模はないのです。Telegraaf.nlやNU.nlなどのWebサイトでは，Varnishなどのリバースプロキシを前面に置いたテクノロジ上に構築されている場合があります。あるいはbol.comのようなWebサイトは，前面のサイトをバックエンドプロセスから分離するためにマイクロサービスを利用しています。これらはすべて，どの言語やプラットフォームでも可能なことです。ですから言語やツールやライブラリの選択は，スケーラビリティではなく，プログラマやオープンソースコードの調達に基づいて行なうべきです。