やらない判断・計測・本番化の実践ガイド
決裁は下りない。データがあるかは誰も知らない。効果の測り方も決まっていない。
理由ははっきりしています。AI エージェントは、発注できる対象ではない。
プロジェクトマネジメントの標準を、実務の記録の側から読み直します。
実装の作り方は書きません／ 載せるのは実際に出した指示文・設定・コマンドと、判断表・書式・チェックリスト
判断材料を持たない人が、判断させられている。
— 第00章「発注できないものを、発注しようとしていた」より
通常の開発なら、何を作るかを決める人とそれを届けきる人を分けられます。 AI は違います。実現可能性が、データを見るまで、動かしてみるまで分からない。 すると「何を作るか」の決定が、データ理解やモデル評価の途中でしか下せなくなります。
仕様は現場の観察からしか出ず、価値は実データでしか測れない。要件定義書を書いて渡す、という手順がそもそも成立しない。
その返事は、ほぼ常に「テーブルはあります」の意味。行数・有効行数・鮮度・到達権限の 4 つを数えるまで、計画は立てられない。
やらないものを落とせていないから資源が分散し、どれも本番に届かない。Gartner が挙げた中止の理由はコストの膨張・価値の不明確さ・リスク統制の不備の 3 つ（2025-06-25）。本書は中止率の予測そのものは引きません。
人の誤りは間違って見えるが、AI の誤りは正しく見える。生成速度とレビュー速度の比が壊れていて、忙しい PM ほどその差で損をする。
本書の題は「PoC で終わらせない」ですが、中身の半分は「終わらせる」話です。 00 章で最初に断ります。読者の期待を一度裏切ってから、なぜそれが同じことなのかを説明します。
PoC で終わらせないための最短経路は、終わらせるべきものを早く終わらせることである。
— 第00章「はじめに」より
02 章の「やらない理由を先に 3 つ書く」と、Part 5 の「畳む」は、残った 1 本を本番へ届けるための工程です。
例外を作りません。PM の職務は作ることではなく、作らない判断を安く下せるようにすることだからです。
現場に張り付いて観察する。スコープ・費用・関係者の 3 つを握ったまま現場に入れるのは PM だけ。
標準が立上げに置いたプロセスはいちばん薄い。その薄いところが、本書で最も重い。
アジャイルのスプリントは前へ進む。データのスプリントは、後ろへ戻る。戻る回数が最も多い段。計画には、戻ってよい回数の上限と、当たったときの行き先を先に書きます。
PM が手を動かす目的は実装力ではない。仕様の曖昧さを、実装が通るかどうかで判定すること。
効いたかの式は、作る前に決める。後で決めると、必ず自分に都合よく決まります。
各章末の「やってみる」の直前に、この章のものをどうやって畳むかを 1 節置いています。
各章末には必ず「やってみる」を置いています。標準の用語は、章の中で 1 回だけ名前を出す目印であって、章の主役ではありません。
実装の作り方は書いていません。載せたのは、実際に Claude Code へ出した指示文、 ナビに与えたルール、サーバーで流したコマンド、設定のファイルです。 エージェントの作り方そのものは Vol.1 に譲りました。
写真は制作中のイメージです。ページ数・造本は最終版で変わることがあります。
AI 案件に巻き込まれ、可否を判断させられている人。
止め方も終わらせ方も決まっていないまま、本数だけ増えている人。
「作らせる側」に回ったことに違和感がある人。
「作り方は分かった。で、それをどう通すのか」と思った人。
本書は標準の解説書ではありません。PM が手を動かした記録に、標準の名前を後から付け直した本です。
読む順序はありません。どの巻からでも単独で読めます。
Kindle 版とペーパーバック版があります。シリーズのほかの巻を読んでいなくても読めます。
