新規プラットフォーム立ち上げで、最初の90日に決めること

「新基盤を作る。まずはモダンな構成で。」——ワクワクは分かる。だが0→1で最初に壊れるのは技術選定ではなく、何をプラットフォームと呼ぶかと誰が運用で起こされるかだ。

スタック比較に8週間使ったあと、「では何を載せるのか」で止まる現場を何度も見てきた。

最初の90日で固定するのは、プロダクト境界・運用責任・止め方の3つだ。 美しさは二の次でよい。

結論：90日で残すもの

観点	90日以内に決めること	まだ決めなくてよいこと
境界	何を載せ、何を載せないか（1枚）	将来の全マイクロサービス分割
運用	誰がオンコール／障害判断するか	完璧なSRE組織図
止め方	失敗時に捨てる／縮退する条件	5年ロードマップの詳細
観測	最低限のログ・指標・アラート	フルオブザーバビリティ

「とりあえず作ってください」の延長で基盤だけ先行すると、載せものが決まらずコストだけが残る。

事例1：過大設計で半年遅れた立ち上げ

匿名化した一例。新規B2B向けの共通基盤。最初からマルチテナント・高度な権限・イベント駆動を要件に入れ、設計だけで4ヶ月。事業側の最初のユースケースは「1テナント・単純なCRUD」だった。

分岐点は1ヶ月目のレビューだった。「最初の利用者は誰で、何が動けば売上検証になるか」を先に書き直したチームは、8週間で薄い縦スライスを出し、学習を回収した。过大設計を続けたチームは、半年後も本番利用者がゼロだった。

事例2：基盤ゼロで機能だけ積み上げて詰んだケース

逆の一例。基盤を後回しにし、画面とAPIを個別最適で量産。3ヶ月後、認証・監査ログ・環境差分で全部が止まる。境界を決めない「速さ」は、結合の負債を前借りするだけだ。

週次で決めること（目安）

1. 週1–2: 最初の利用者と成功指標（1つ）を固定する
2. 週3–4: 載せないもののリストを経営と合意する
3. 週5–8: 薄い縦スライスを本番相当で動かす
4. 週9–12: 運用責任と止め方（Kill基準）を文書化する

技術選定はこの流れに従属させる。選定会議を主イベントにしない。

判断軸：今すぐ立ち上げ伴走を入れる／まだ社内だけでよい

やる	やらない
境界と運用責任が曖昧なまま実装が始まっている	載せるユースケースと成功指標が既に1枚で合意済み
「基盤」と「最初のプロダクト」の区別が社内で揺れている	既存プロダクトの延長で、新規境界の議論が不要
止め方がないまま投資だけが増えている	四半期末のGo/No-Goが既にカレンダーにある

次に確認すること

1. 最初の利用者と成功指標は一文で書けるか
2. 載せないもののリストはあるか
3. 障害時に起こす人と判断者は決まっているか
4. 90日時点のKill／継続基準はあるか
5. スタック比較に何週間使う上限を置いたか

まとめ

新規プラットフォームの最初の90日は、技術の博覧会ではない。境界・運用・止め方を固定し、薄い縦スライスで学習を回収する期間だ。そこが決まれば、スタックも発注も速くなる。

---

新規プラットフォーム立ち上げの相談は、お問い合わせフォーム からどうぞ。