フェーズで変わる技術選定の基準

「どの言語を使うか」「どのクラウドを選ぶか」という問いに、一般的な正解はありません。同じ技術が、ある会社では合理的な選択になり、別の会社では足かせになります。違いを生むのは技術の優劣ではなく、その会社が今どのフェーズにいて、何を最優先しているかです。

本記事では、フェーズごとに技術選定の基準がどう変わるかを整理します。技術者向けの比較ではなく、発注する側が「この選定は今の自社に合っているか」を問うための材料としてお読みください。

基準は一つに絞る

技術選定の議論が長引くのは、複数の基準を同時に満たそうとするからです。速さ、安さ、性能、拡張性、採用しやすさ、運用の容易さ。これらはしばしば相反します。

実務では、今のフェーズで最優先の基準を一つ決め、残りは「許容範囲かどうか」で見ると判断が速くなります。フェーズごとの最優先は、おおよそ次のように整理できます。

以下、それぞれを見ていきます。

シード — 速く捨てられるかで選ぶ

検証段階では、作ったものの大半が捨てられます。これは失敗ではなく前提です。したがって選定の基準は、「捨てるときのコストが低いか」になります。

捨てやすさは、次のような形で現れます。

• 一つの塊として動いていて、部分的に切り離さなくても丸ごと止められる
• 外部サービスとの契約が短期で、解約に費用がかからない
• 環境構築が短時間で終わり、作り直しの心理的な負担が小さい
• 運用のために誰かが常時見ている必要がない

この段階で「将来の拡張性」を理由に複雑な構成を選ぶのは、多くの場合に割に合いません。利用者がまだ少ない時期に、大量のアクセスを想定した分散構成を組んでも、運用の手間が増えるだけです。管理サービス（マネージドサービス）に任せる構成のほうが、捨てやすく始めやすいと言えます。

同時に、捨てる前提が当てはまらない部分もあります。データの持ち方、認証、決済まわりは、作り直しの影響が事業側に及びます。ここだけは、MVPの段階から標準的な形を選んでおくと後が楽です。捨てる前提と残す前提の分け方はMVP開発とはで整理しています。

シリーズA — 人を増やせるかで選ぶ

調達して人を増やす段階になると、基準が変わります。ここでの問いは「新しく入った人が、どれだけ早く戦力になるか」です。

この観点で見ると、シード期に合理的だった選択が足かせになることがあります。たとえば、創業エンジニアが慣れているという理由で選んだ、国内では使う人の少ない言語やフレームワーク。一人で書く間は速くても、採用の母集団が小さければ、増員のたびに苦労します。委託先を探すときも同じです。

判断の材料になるのは次のような点です。

• その技術を扱える人を、採用市場と委託の両方で見つけられるか
• 公式のドキュメントと日本語の情報が十分にあるか
• 構造が説明しやすく、新しい人に全体像を伝えられるか
• 検証と配信の仕組み（CI/CD）が整えやすいか

人を増やす段階で効いてくるのは、技術そのものより「読める状態になっているか」です。人が増えるほど、コードを読む時間の総量は書く時間を上回ります。技術的負債を放置したまま増員すると速度が上がらないのは、この読む時間が膨らむためです。

想定例：シード期に一人のエンジニアが素早く作ったサービスが伸び、シリーズAで四人を増員したとします。ところが構成に一貫した方針がなく、画面ごとに書き方が違う。新メンバーは既存コードの読解に時間を取られ、三か月経っても一人分の成果が出ません。この会社が取った対応は、技術の移行ではなく、書き方の方針を文章にし、新規の部分からそれに沿わせることでした。選定の問題に見えて、実際には共有の問題だった例です。

シリーズB以降 — 止まらないかで選ぶ

顧客の業務がプロダクトに乗っている段階では、基準は可用性と回復の速さに移ります。「速く作れるか」より「壊れたときに短く収まるか」です。

ここで問うのは次のような点です。

• 障害の原因を特定できる記録（ログ、監視、追跡）が揃っているか
• 一部が壊れたときに、全体が止まらない構成になっているか
• 元に戻す手順（切り戻し）が用意され、実際に試したことがあるか
• 依存している外部サービスが止まったときの代替が決まっているか

この段階になると、選定は「何を使うか」より「どう運用するか」の比重が大きくなります。非機能要件として、どの程度の停止なら許容できるかを事業側が決め、それに見合う構成と費用を選ぶ形になります。過剰な可用性は費用に跳ね返るため、「止まってはいけない範囲」を絞ることが実務的です。

コンテナを使うかどうかも、この段階では運用の観点で判断します。環境の再現性と切り戻しのしやすさが得られる一方、運用できる人が要ります。小規模チームでの現実的な構成はコンテナとクラウドの活用にまとめています。

AIをどう組み込むかも、フェーズで変わる

プロダクトにAI機能を入れる場合も、同じ考え方が使えます。

シード期は、既製のAI APIをそのまま呼ぶ、もっとも単純な形で十分です。精度が足りなければ使い方を変えるか、その機能自体をやめる。捨てやすさが基準なので、複雑な仕組みを組む理由がありません。

シリーズA以降になると、費用の予測可能性と、提供事業者を乗り換えられるかが問われます。特定の事業者のAPIを画面のあちこちから直接呼んでいると、料金体系や仕様が変わったときに広範囲の修正が必要になります。呼び出しを一箇所にまとめておくだけで、乗り換えの余地が残ります。自前で基盤を組むという話ではなく、呼び出し口を整理するという程度のことです。

前のフェーズの基準を引きずらない

技術選定の失敗の多くは、選定そのものの誤りではなく、基準の更新漏れから生まれます。シード期の「速く捨てられる」という基準のまま人を増やせば、読みにくい構成が拡大します。シリーズBの「止まらない」という基準を検証段階に持ち込めば、まだ顧客のいない機能に過剰な手間をかけることになります。

対策は単純で、調達のタイミングなど区切りのよい時期に、選定の基準を見直す機会を作ることです。そのときに問うのは「今の構成は、今のフェーズが要求することに合っているか」の一点です。合っていない部分が見つかっても、全体を作り直す必要はありません。事業の足を引っ張っている層だけを特定して手を入れる順序については、レガシーコードのモダナイズもあわせてご覧ください。

現在の構成が今のフェーズに合っているかを外部の目で確かめたい場合は、Webシステム開発やインフラ構築・運用の観点からご相談に応じます。お問い合わせからお気軽にどうぞ。ご相談・お見積りは無料です。