PoCで技術スタックを決める

「うちが慣れているから」で守られる技術選定は、正しいこともありますが、検証できることは決してありません。PoC（技術検証）はそれを検証可能にします。ただし、プロダクトの早期バージョンとしてではなく、判断の手続きとして回した場合に限ります。

00 / PoCとは期限のついた問い

プロトタイプと分けるものは3つあります。「いいえ」と答えてよい問い、誰かがコードを書き始める前に合意された評価軸、そして終わる日付です。どれか1つでも欠けると、PoCは静かにシステムの初版になります。デモがそのまま出荷され、問いは誰も読み返さず、スタックはサンクコストによって決まります。

問いは失敗できる形でなければなりません。「Xで作れるか」は失敗できません。時間さえあれば答えは常に「はい」です。「本当に不安な部分について、Xは2日で何を要求してくるか」は失敗できます。

01 / 比較できる比較にする

同じ課題、同じ期限、同じレビュアー。そして評価軸と重みは最初のコミットより前に書いておきます。課題には、実際に不安なものを選びます。気になっているクエリ、並行処理、ドキュメントが薄そうな連携先。どの候補でも同じように書けるエンドポイントではありません。

うまくいかなくなる道は3つ、どれもよくある形です。

候補ごとに、それを最初から推している人が実装する。
候補によって使える時間が違う。たいてい先に着手したほうが有利になる。
評価軸が結果のあとに書かれ、驚くほど勝者に合っている。

02 / 会議を生き延びる評価軸

ケーススタディにあるコンシューマー向けプロダクトでは、バックエンドの言語は好みではなく複数のPoCを経て選ばれました。評価軸は4つ、スケーラビリティ、保守性、速度、そしてそのコードベースがAI活用開発とどれだけ噛み合うかです。Goはそのバランスから出てきました。スタックのほかの部分も同じやり方で決めています。

4つのうち3つはありふれた軸です。いずれも形容詞のままにせず、答えの出る問いに変えておく価値があります。

スケーラビリティ — 想定の10倍、100倍の負荷で何が起きて、そこでいくらかかるのか。測ってください。ベンダーのページから推論しないことです。
保守性 — そのコードを書いていない人が、小さな変更を安全に入れるまでにどれだけかかるか。これは数字になりますし、コードベースがまだ1時間で読める大きさのPoCの時期が、それを測るいちばん安いタイミングです。
速度 — システムの速度と、チームの速度の両方。速いランタイムでも、チームの誰も流暢に書けないなら遅いのです。

03 / ほとんど誰も試さない評価軸

4つ目の軸は明示的に扱う価値があります。いまは多くのチームが、良いほうにも悪いほうにも、これを確かめずに信じているからです。問いはこうです。このスタックのコードベースは、その多くがアシスタントによって書かれたとき、どこまで持ちこたえるのか。

これは試せます。そして見るべきは出力ではなくレビューです。同じ機能を候補ごとにアシスタントへ渡し、次を観察します。

返ってきたもののうち、正しかったのはどれだけで、もっともらしく誤っていたのはどれだけか。
人間が見る前に、コンパイラや型システムが何をはじいたか。誤ったコードがビルドで落ちるスタックは、そのまま動いて後で壊れるスタックより安上がりです。
アシスタントが依存関係を引いてきそうな場面を、標準ライブラリが埋めていたか。補完が選んだ依存関係は、誰も下していない保守上の決定です。
整形がツールで確定しているか。差分がスタイルではなくロジックの話になります。
できあがったものをレビューするのにどれだけかかったか。チーム規模とともに効いてくるのはこの数字です。

公開されたコードが豊富であることは助けになります。ただしそれがすべてではありません。言語の表面積が広いほど、自信をもって間違えられる場所が増え、それを捕まえるためにレビュアーが頭に置いておくものも増えます。

04 / 「いいえ」と答えてよいこと

PoCは「すでにあるものを残すか」にも答えます。その案件には1年以上前に一人の開発者が書いた既存のコードベースがあり、これから始める範囲に対しては足場としてほとんど機能しませんでした。これも正当な結論であり、ほかと同じように書かれた問いと期限が必要です。そうでないと、議論はコードではなく前の書き手のほうへ流れます。

問いに答えが出たら、PoCは消すか、やり残した部分の計画を添えて意図的に育てるかのどちらかにします。「参考までに」置いておくと、コピーされます。

05 / PoCが覆わない半分

その案件の言語選定はAI活用開発を織り込んでいました。一方で、それをどう進めるかのワークフローは最初から標準化されておらず、成果物がチームの共通の期待に合わないことがしばしばあり、手戻りが生じ、全体の品質を下げました。私が違うやり方をするとすればここで、これはツールの問題ではありません。

技術評価が答えるのはどの道具かです。どう働くかには答えません。アシスタントに渡す前のタスクはどういう形か、レビューはこれまで見ていなかった何を見るのか、どこは手で書くのか、どこは二度読まずにマージしないのか。2つ目の問いは1つ目と同じだけ意図的に扱う価値があり、たいてい何も与えられません。週末に見せられる成果物がないからです。

根拠をもって選び、そのうえで選んだものの使い方を書き残してください。簡単なのは前半のほうです。