使い続けられるMVPのための技術スタックの選び方

多くの創業者は、技術スタックについて逆向きの問いを立てています。何が一番速いか、新しいか、スケールするか。けれど本当に大事なのは、「現実的に採用できるチームで、3年後も気持ちよく保守し続けられるのはどれか」という問いです。MVPは使い捨てのプロトタイプではありません。うまくいけば、それがそのままプロダクトになります。そして最初の1週間で取った近道は、その後毎週支払い続ける「税金」になるのです。

ここでは、コードを1行も書く前に、私たちがお客様と一緒に使っている判断の枠組みをご紹介します。

1. ツールではなく、課題から考える

予約プラットフォーム、マーケットプレイス、社内向けダッシュボードでは、求められる形がまったく違います。まずは、プロダクトが初日から必ずできなければならないことを3〜4つ書き出し、それぞれが扱うデータを整理しましょう。そのリストのほうが、どんな比較表よりも適切なスタックを教えてくれます。

• 主にコンテンツとフォームで構成されるなら、モダンなWebフレームワークとマネージドデータベースで十分です。
• お金を扱うなら、成熟した決済ライブラリがあり、監査証跡を明確に残せるツールを選びましょう。
• チャット、リアルタイムの位置追跡、共同編集といったリアルタイム機能があるなら、最初から計画に入れておきましょう。後から付け足すのは大変です。
• ユーザーの大半がスマートフォンから使うなら、ネイティブアプリが必要なのか、高速でインストール可能なWebアプリで十分なのかを早めに決めましょう。

2. あえて「退屈な」技術を選ぶ

「退屈」とは、古いという意味ではありません。よく理解されている、という意味です。広く使われ、ドキュメントが充実し、たいていの問題の答えがすでにどこかに書かれている。今日のほとんどのWebプロダクトであれば、TypeScript、Next.jsなどのフレームワークと組み合わせたReact、そしてマネージド環境で動かすPostgreSQLやMongoDBといった主流のデータベースがそれに当たります。

メリットは技術的な美しさではありません。深夜2時に何かが壊れても検索すれば解決策が見つかり、2人目の開発者が必要になったときに、数か月ではなく数週間で採用できることです。スタックに珍しい選択をひとつ加えるたびに、そのシステムを扱える人材の母数は小さくなっていきます。

新しいことに挑む予算は、裏側の配管ではなくプロダクトに使いましょう。お客様がデータベースを目にすることはありません。見ているのは、それがちゃんと動くかどうかだけです。

3. 採用のしやすさも判断材料に入れる

技術者ではない創業者にとって、スタック選びは人材の問題でもあります。提案された技術については、3つの問いを投げかけてください。自社の市場でそれを扱える開発者はどれくらいいるか。その人件費はどの程度か。新しく入った開発者が、最初の1週間でコードベースを理解できるか。開発会社のお気に入りでも、ほかの誰も扱えないスタックを選べば、知らないうちにその会社から離れられなくなります。

だからこそ私たちは、すべての開発をドキュメントに残し、主流のツールで構築しています。将来、開発を内製化したくなったり、別のチームに移りたくなったりしたときには、それができるべきです。そしてその選択肢があること自体が、私たちを含む全員に健全な緊張感をもたらします。

4. 本業でないものは「買う」

認証、決済、メール配信、ファイルストレージ、検索、分析は、すでに解決済みの課題です。マネージドサービスに任せれば、1週間かけて自前で書いたコードよりもうまく処理してくれますし、MVPの規模ならコストもごくわずかです。これらを自作することこそ、最初のバージョンのリリースが遅れる最もよくある原因です。

• 決済：銀行との個別連携ではなく、自社の市場で使える主流の決済ゲートウェイ。
• メール：パスワード再設定や領収書のメールが確実に届く、トランザクションメールの配信サービス。
• コンテンツ：開発者がいなくてもチームでページを編集できる、ヘッドレスCMS。
• ホスティング：誰かが付きっきりで面倒を見るサーバーではなく、プッシュのたびに自動でデプロイされるマネージドプラットフォーム。

目安はシンプルです。プロダクトの差別化につながる部分だけを自分たちでつくり、それ以外はすべて借りる。何が必要なのかがはっきりした段階で、サービスはいつでも置き換えられます。

5. 10年先ではなく、3年先を見据えて設計する

創業者は、まだ抱えてもいない規模の心配をしがちです。主流のスタックでしっかり構築したアプリケーションなら、最初の数万人のユーザーには余裕で対応できます。それで足りなくなる頃には、売上も、実際の利用状況のデータも、何を最適化すべきかについてのはるかに明確な見通しも手に入っているはずです。マイクロサービス、Kubernetes、マルチリージョンのデータベースが解決するのは、いずれ抱えられたら喜ぶべき種類の課題です。

早い段階で投資すべきなのは、変更のコストを下げる地道な規律です。分かりやすいフォルダ構成、型付きのコード、自動デプロイ、エラー監視、そしてお金や個人情報を扱う部分を中心とした、いくつかのテスト。

決める前の簡単なチェックリスト

1. 主要なツールそれぞれについて、なぜ選んだのかを一文で説明できますか？
2. 自社の市場で、このスタックを扱える開発者を1か月以内に採用できますか？
3. 認証、決済、メールは、実績のあるサービスに任せていますか？
4. プッシュのたびに自動でデプロイされ、ロールバックの手段も用意されていますか？
5. エラー監視を導入し、お客様から指摘される前にバグに気づける体制になっていますか？
6. コードは自社のアカウント配下のリポジトリにあり、名実ともに自社のものになっていますか？

6つすべての答えが「はい」なら、そのスタックで十分です。そして今四半期にリリースされる「十分」は、来年の「完璧」に勝ります。検討中のスタックや受け取った提案書についてセカンドオピニオンが欲しい場合は、ぜひお送りください。率直な見解をお伝えします。