最初のSaaSの技術スタック選び：創業者のための率直なガイド

最初のSaaSにどの技術スタックを使うべきか十人のエンジニアに尋ねれば、十五通りの答えが返ってきます。そのうち三つは信仰のような確信をもって語られるでしょう。答えのほとんどは正しいのです——それを語る本人にとっては。どれもあなた自身、あなたの資金的な余裕、まだ獲得していない顧客についての話ではありません。創業者としてこの決断を前に少し気分が悪くなっているなら、誰も口に出さない事実をお伝えします。スタックは、あなたが信じ込まされてきたよりはるかに重要度が低く、それが本当に効いてくる数少ない場面は、ネットで人々が争っている論点ではないのです。

私はかなりの数の初めての創業者が、スライド資料から実際の人々がお金を払う製品へと進むのを手伝ってきました。そのほとんどは技術畑の人ではありませんでした。そしてほとんど全員が、恐ろしいほど大量のスタックにまつわる俗説を吸収して現れました——マイクロサービスが必要だ、ある特定のフレームワークは「終わった」、選択を誤れば破滅する、と。そしてほとんど毎回、スタックはその年に下した決断のうち最も影響の小さいものの一つでした。プロジェクトを殺すのは、スコープ、責任の所在の曖昧さ、そして誤ったものを美しく作り込むことでした。フレームワークではありません。

ですからこれは、一行のコードを書く前に私がそうした創業者たちに渡すガイドです。特定のスタックを使えとは言いません。あなたの事業を知らずにそれを約束する者は、何かを売りつけているからです。代わりに、考え方をお渡しします——そうすれば、あなたが何を選ぼうと、チームが何を提案しようと、神経質にうなずく代わりに、大人として正気の判断ができます。

なぜこの決断は実際より難しく感じるのか

スタックの問いが巨大に感じられるのは、それがあなたの下す最初の「取り返しがつかなそうに聞こえる」選択であり、しかもあなたが話せない言語に包まれているからです。Postgres、React、Kubernetes、サーバーレスといった言葉が、まるでそれらの選択が建物の基礎を選ぶようなもの——間違えれば全体が崩れる——であるかのように飛び交います。

しかしソフトウェアは建物ではありません。料理をしながら改装できるキッチンにずっと近いものです。成功している企業は絶えずスタックの一部を書き直しています。最初の百人の顧客を見つける製品のバージョンが、最初の十万人を支えるバージョンであることはまずありません。あなたの最初のスタックの目的は、永遠に持つことではありません。そもそも誰かがこれを欲しがるのかを学べるだけの速さで、作り、変え、出せるようにすることです。それは「次の十年に完璧」とはまったく別の——そしてはるかに低い——ハードルです。

それを受け入れた途端、重圧は半分に減ります。もはや未来を予測しようとはしていません。動く製品と課金ユーザーへたどり着ける、合理的で後戻り可能な賭けをしようとしているだけです。そして合理的な賭けは、非技術系の創業者でも十分に評価できるものなのです。

「スタック」とは本当は何か、平易な言葉で

何かを決める前に、この言葉の神秘性を解いておくと役立ちます。技術スタックとは、ソフトウェアを作り、動かすために使う道具の集まりにすぎません。四つの層として捉えられ、どの層も深く理解する必要はありません——存在していると知っていればよいのです。

• フロントエンド——ユーザーがブラウザやアプリで見て、クリックする部分。誰もがあなたを判断するのはこの部分です。
• バックエンド——サーバー上で動くロジックとルール。誰が何をできるか、それをしたとき何が起きるか、お金がどう動くか。
• データベース——情報が実際に存在する場所。ユーザー、注文、サブスクリプションなど、失えば打ちのめされるすべて。
• インフラ——上記すべてをオンラインに保ち、バックアップし、午前三時でも到達可能にしておくサーバーとサービス。

誰かが「モダンなJavaScriptスタックを使う」「Postgres上のRails」と言うとき、それはこの四つの層にわたる選択を述べているのです。それだけです。二人の副業プロジェクトから上場企業まで、あらゆるSaaSはこの四つを積み重ねた何らかのバージョンです。大層に聞こえるアーキテクチャ図も、ただこれを箱を増やして描いたものにすぎません。

本当に重要なこと（そして重要でないこと）

ここで、ほとんどのスタック助言は道を誤ります。最初の二年に影響しないことを最適化し、影響することを無視するのです。両方のリストについて率直にお話しします。

本当に重要なこと

誰が作り、保守できるか。 唯一最大の要因は技術ではなく、人です。あなたにとって最良のスタックは、あなたのチーム（あるいは雇うパートナー）が今日この時点で実際に流暢に扱えるものです。希少な専門家一人しか理解しない「完璧な」スタックは、有能な開発者なら誰でも引き継げる退屈なスタックより悪い選択です。採用と継続性は、毎回、理論的な優美さに勝ります。

どれだけ速く変えられるか。 初期のあなたは、自分の製品について絶えず間違えます。スタックの本当の役目は、考えを変えることを安く済ませることです。成熟して十分に文書化され、大きなコミュニティを持つ道具は、問題への答えがすでに存在するため、速く動けます。最先端の道具は、あなたをバグの発見者にしてしまいます。

それで採用できるか。 マイナーなものを選べば、あなたの未来はそれを作った人に縛られます。ありふれた退屈なものを選べば、次の開発者、次の代理店、次に引き継ぐ人を常に見つけられます。事業がそれに依存するとき、退屈さは長所です。

言われるほど重要ではないこと

純粋な性能と「スケール」。あなたにスケールの問題はありません。まだ誰も使っていないという、正反対の問題があるのです。数百万ユーザー向けに設計されたアーキテクチャは、十一人しかいないあなたを遅くします。あなたが真似ている有名企業は、まず単純な版を作り、後で——成功を元手に——作り直しました。あなたもそうすべきです。

今年どのフレームワークが「勝っている」か。フレームワークは流行のサイクルで浮き沈みしますが、それはあなたの請求SaaSをうまく作るかどうかとほとんど関係ありません。主流で広く使われている選択肢ならどれでも仕事をこなします。トレンドはノイズです。退屈で人気のある真ん中から選び、先へ進みましょう。

なぜ「退屈な」技術がたいてい勝つのか

経験豊富な作り手の間には、新参者ががっかりする静かな知恵があります。新しい事業に最良の技術は、たいてい退屈で、実績があり、少し時代遅れな類のものだ、というものです。新しい道具が悪いからではなく、あなたが下すすべての選択が新しさの限られた予算——あなたの小さなチームが一度に扱える、未知で、サポートのない、驚かされる物事の数——を使うからです。

その予算は、あなたの事業を特別にするもの——実際の製品、あなただけが持つ洞察——に使いなさい。モダンに感じたいだけのために、誰も聞いたことのないデータベースに使ってはいけません。退屈で成熟したスタックは、問題が以前に解決済みで、文書が存在し、採用が容易で、唯一の保守者が興味を失っても来年に消えない、ということを意味します。退屈さは、報われる場所——顧客——にすべての熱意を注がせてくれます。

ここはAIが少し絵を変える場所でもあります——ただし誇大宣伝が示すような形ではありません。AIのコーディング補助は、退屈で人気のある技術が圧倒的に得意です。それらについての十年分の公開された回答で訓練されているからです。主流のスタックを選べば、あなたのチーム（そして道具）は無料でより速い助けを得ます。風変わりなものを選べば、最も余裕のないまさにそのときに、あなたは独りになります。

実際に使える意思決定の方法

原則はもう十分です。自分で選ぶにせよ、フリーランサーに依頼するにせよ、代理店の提案を評価するにせよ、結論にたどり着く具体的なやり方を示します。どれもコードを書く必要はありません——正しいことを尋ね、答えを比べるだけです。

1. 1
   技術ではなくチームから始める

   問うべきは、今後二年間これを作り保守するのは誰か、です。彼らがすでによく知っているものが、あなたの強力な既定値です。トレンドを追ってスタックを乗り換えても、流暢さに勝つことはまれです。
2. 2
   既定で主流かつ実績あるものを選ぶ

   各層の人気があり、十分に文書化された真ん中から選びます。ある道具についてチュートリアル、求人、大きなコミュニティをすぐに見つけられないなら、それは長所ではなく警告と捉えなさい。
3. 3
   スケールではなく変更に最適化する

   製品の編集を安く速くする選択を好みなさい。あなたは製品について繰り返し間違えます——スタックの役目は、間違いを生き延びられるものにすることです。
4. 4
   アーキテクチャを可能な限り単純に保つ

   データベース一つ。バックエンド一つ。フロントエンド一つ。実際に測定された問題が手を強いるまで、マイクロサービスも、巧妙な分散の何かもなし。単純さは妥協ではなく目標です。
5. 5
   なぜそれを選んだか書き留める

   一段落で。誰が作るか、何を選んだか、見直すには何が変わる必要があるか。このメモは、誰かが過激な意見を読むたびに決断を蒸し返さずに済ませてくれます。

他に何も従わないとしても、ステップ一と四には従ってください。手元にいる人々で、機能する最も単純なアーキテクチャの上に作りなさい。この組み合わせは、ほとんどの最初のSaaS製品を沈める二つの失敗様式——保守できる人がいない、規模の割に複雑すぎるシステム——を静かに回避します。

スタックを提案する相手に尋ねるべき質問

ほとんどの創業者はスタックを一人で選びません——開発者、代理店、あるいはCTOの友人が提案します。技術を自分で検証する必要はありません。いくつか質問をし、彼らがどう答えるかを聞けばよいのです。平易な言葉での自信ある答えは良い兆候です。防御的な専門用語はそうではありません。

• 「なぜこれで、退屈な人気の選択肢ではないのですか」——良い答えは、流行ではなくあなた固有のニーズについてのものです。
• 「もしあなたがバスにはねられたら、他の誰かがどれくらい簡単に引き継げますか」——答えは、その選択がどれほど希少で危ういかを明かします。
• 「このアーキテクチャの、それでも機能する最も単純な版は何ですか」——単純さに手を伸ばすか複雑さに手を伸ばすかを見なさい。
• 「これのために次の開発者を採用するのはどれくらい簡単ですか」——一般的なスキルは健全な市場を、風変わりなスキルは依存を意味します。
• 「三か月後に中核機能を変える必要が出たら何が起きますか」——変更が安いと聞きたいのであって、恐れられていると聞きたいのではありません。

良いアイデアに見えるよくある落とし穴

あまりに頻繁に出てくるので名指しする価値のあるパターンがいくつかあります。どれもその瞬間には責任あるものに感じられ、後で高くつくからです。

持っていない規模のために作る。 「ちゃんとやろう」という衝動は、十人もいないうちから数百万ユーザー向けに設計させます。その将来への備えの一つひとつが、来ないかもしれない問題を解くために、今、時間とお金で支払う複雑さです。次の百人のユーザーのために作りなさい。成長が必要にしたとき作り直し、それを嬉しい問題にしなさい。

最新を追いかける。 先月リリースされたピカピカのフレームワークには実績がなく、文書は薄く、コミュニティは極小です。製品を作る代わりに、道具のデバッグで夜を過ごすことになります。早期採用者は他の人に任せなさい。あなたには世に出すべき事業があります。

最も安い相手に、相手の好きなもので外注する。 最安の入札は、しばしばその一チームしか知らないマイナーなスタックを伴います。袂を分かつ日、あなたの製品は他の誰も到達できない孤島になります。先は安く、後は破滅的。外注するときでも——いや外注するときこそ——主流で採用可能な技術を主張しなさい。

本当にスタックを見直すべきとき

これらは「決して変えるな」という意味ではありません。想像ではなく測定された、本当の理由のために変えよ、という意味です。本当にスタックを進化させる時だと分かるのは、具体的な兆候が現れたときであって、ブログ記事に不安をあおられたときではありません。

パターンに気づいてください。本当の理由は、あなたの実際の事業における測定された痛みについてのものです。偽の理由は、流行、比較、落ち着かなさについてのものです。本当の兆候が現れたら、一度に一つずつ変えなさい——すべてを半年止める英雄的な書き直しで、スタック全体を変えるのではなく。革命ではなく進化です。

よくある質問