H M

「とりあえずPoCを作ってみよう」 「MVPで検証しよう」 「ダメなら直せばいい」 そのノリで始めたプロジェクトが、 気づいたら誰も止められない状態になっている。 データが溜まり、ユーザーが増え、課金が始まった瞬間—— 誰が最終責任を持つのか、曖昧なまま。 何が起きたら止めるのか、決まっていないまま。 そして、止まらないシステムが炎上する。 ⸻ 私は17年間、プラスチック成形の世界でPMをやってきました。 この世界には、ITにはない絶対的なルールがあります。 「金型を一度切ったら、後戻りできない」 金型は安くても数百万円、高いと数千万円。 一度作ったら「やっぱり変更」は許されません。 だから私たちは、 モノが存在しない段階で壊れる場所を予測します。 •この形状、量産で歪まないか •この寸法、公差を保てるか •この材質、温度変化に耐えられるか 過去の失敗事例、類似形状、現場のクセ。 それらを総動員して、壊れる未来を先に想像する。 私はこれを「ファーストQA」と呼んでいます。 ⸻ ITに来て、最初に違和感を覚えたのがPoCでした。 「作りながら考える」 「失敗から学ぶ」 「アジャイルだから柔軟に」 一見正しそうに聞こえるこの文化。 でも、ソフトウェアも、ユーザーが乗った瞬間に「金型を切った状態」になります。 SLAが発生し、運用が回り、データが溜まり始めたシステムは、 もう気軽に「やり直し」はできない。 多くのPoCが炎上するのは、技術の問題ではありません。 「誰がGo/No-Goを決めるのか」 「問題が起きたとき、誰が責任を持つのか」 「運用コストを誰が引き受けるのか」 これが、金型を切る前に決まっていないからです。 ⸻ 私と普通のIT PMの違いは、ここにあります。 多くのIT PMはこう考えます。 •要件を満たすか •技術的に実現可能か •スケジュール通りに進むか 私はこう考えます。 •量産（本番運用）に耐えるか •止まらずに使われ続けるか •責任の所在は明確か コードを書く前に、壊れる場所が見える。 それは、製造業で17年間、 「後戻りできない判断」を何百回もしてきたからです。 ⸻ 私がPoCフェーズでやるのは、コードレビューではありません。 判断と運用のQAです。 •この要件、本番で変わらないか •この設計、3年後もメンテできるか •この運用、属人化しないか •問題が起きたとき、エスカレーション先は誰か 製造業では当たり前の「量産前QA」を、 ソフトウェアとAIの世界でやっています。 ⸻ PoCを「実験」で終わらせず、「量産の入り口」に変える。 それが、私のTechnical PMとしての仕事です。 ⸻ 一度、あなたのPoCの設計図を見せてください。 それが量産に耐えるかどうかは、コードを書く前に分かります。