新しいプロジェクトを始めるとき/ツールを導入するとき、テンション上がって「よっしゃ、コード書くぞ！」ってなりますよね。でも、PoC（Proof of Concept）をスキップすると、後から地獄が待ってるかもしれません...という話です。
「後でなんとかなるっしょ」の末路
実際のところ、いろんな大人げないの事情で見切り発車することはよくあります。が、自分の経験上そういうときは痛い目に合うことが多いです。
パターン1. 想定外の問題にどはまる
構築するものを一度は一通り触って把握していないとよくあるやつです。特にプロジェクトで進めている場合、本来は関係ない要素も絡んできて、複雑性が増しがちです。その結果問題解決に多大な時間を取られてしまうというのはよくある話です。
特にテックリードなど新しいフレームワークやツールを導入する立場/プロジェクトを牽引する立場にあるなら、しっかりテストする時間を確保することをおすすめします。開発初期の段階で手を動かして検証しておくと、後になってコストのかかる問題を回避でき、チーム全体の負担も減らせます。
パターン2. リリース直前にリリースブロッカーとなる重大な欠点が発覚する
開発ではこういう「そんなこと起きることないでしょ」ということがまれによくおきます。以前、認証システムをリリース直前に丸ごと作り直さなければならなかったことがありました。理由は、当初使っていた認証ツールが同一ドメイン/別サブドメインである複数アプリ(prod1.abc.com, prod2.abc.com)に対応していなかったからです。PoCの段階で複数環境構築のステップをきちんと確認していれば避けられたはずでした...。
パターン3. 見積もりを見誤る
PoCがないと、上記のような自体が発生し、プロジェクトの所要時間、作業量、リスクを正確に見積もるのが難しくなります。その結果、納期が守れなかったり、開発コストがオーバーすることも珍しくないです。
効果的なPoCを作るために
このような辛い経験を経て、今は以下を意識してPoCを作るようにしてます。
1. 目的を明確にする
何を検証するのかを具体的に決めます。例えば、「APIが1000件の同時リクエストをさばけるかを確認する」や「認証フローが複数アプリケーションで動作するかを確かめる」といったものです。
2. 検証をシンプルにする
PoCでは、細かい部分に時間をかけすぎないのがミソです。
- レスポンスが必要なら、モックを使うことを検討する
- 主要な機能にだけ集中する。マニュアル作業も検討する
- 必要のない機能やデザインはスキップする
3. テンプレートを用意しておく
プロジェクトの種類ごとにスターターテンプレートを作っておくと、PoCを作る時間がぐっと短縮できますし、一貫性も保てます。自分はNode.jsやCDKのプロジェクト用テンプレートをGitHubに用意してます。
4. 記録を徹底する
自分やチームのためにも、何をしたかしっかり記録を残しておく。
- 参考にしたリンクや、LLMとのやり取り、実行したターミナルコマンドを記録
- 発見した制約や課題をメモ
- 問題の回避策や解決策も書き残す
5. 時間を決めて取り組む
PoCに費やす時間は、プロジェクトへの投資の一部です。ただ、時間をかけすぎては本末転倒です。あらかじめ時間を決めておくことで、スコープが膨らむのを防ぐことができます。
6. 早めにフィードバックをもらう
PoCがある程度できたら、早めに同僚やステークホルダーに共有します。第三者の視点が加わることで、自分では気づかなかった問題点を発見できることがあります。
ちなみに...
PoCはチームを説得するのにも非常に有効です。やっぱり動いているものを見ると、納得感があります。机上の空論ならぬ空中戦をする前に、動くものを見せてものごとを前に推し進めるのが一番!
