システムアーキテクチャ選定（完結編）～プロダクトを成功に導く

こんにちは。

[前編リンク：なぜ「正解」の技術を選んでも失敗するのか？] では、技術を選ぶ前に自社の「制約」と「非機能要件の優先順位」を血眼になって言語化しよう、という話をしました。

後編となる今回は、いよいよ実践編。集めた情報をもとに、どうやって選択肢を絞り込み、チームやビジネスサイドを納得させ、そして「決断」を歴史に残していくのか。私が実際に修羅場をくぐり抜ける中で研ぎ澄ましてきた、綺麗事抜きの「意思決定のプロセス」をお届けします。

1. 選択肢を絞り込む「プロトタイピング（PoC）」のリアル

前編のプロセスを経て、あなたの手元にはいくつかの候補（ロングリスト）が残っているはずです。「Next.js + Vercel + PostgreSQLの王道構成か、あるいはGo + AWS Lambda + DynamoDBの爆速・高スケーラブル構成か」といった具合に。

ここから2〜3案（ショートリスト）に絞り込むわけですが、カタログスペックや技術ブログの「使ってみた」記事を信じてはいけません。自分たちの手で、コア機能に絞った「捨てられるコード」を書く。 これがすべてです。

「動くゴミ」を作る重要性

ここでのPoCは、綺麗なコードを書く場所ではありません。私たちが検証すべきは、その技術の「最も尖っている部分」と「最も懸念される部分」の2点だけです。

PoCコードは、選定が終わったら容赦なくディレクトリごと rm -rf できる割り切りが大切です。本番に流用しようとした瞬間、PoCはただの「技術的負債の前借り」に変わります。