Practical AI Series — Vol.4

PoCで終わらせない
AIプロジェクトの進め方

手を動かす PM の、通す線と、止める線

決裁は下りない。データがあるかは誰も知らない。効果の測り方も決まっていない。
理由ははっきりしています。AI エージェントは、発注できる対象ではない。 プロジェクトマネジメントの標準を、実務の記録の側から読み直します。

2026年9月発売予定目次を見る Vol.3 を見る

コードは 1 行も載せません／主役は判断表・書式・チェックリスト・対応表

19章

8付録

24図

411ページ（A5）

The Problem

順序が、逆転している

通常の開発なら、何を作るかを決める人とそれを届けきる人を分けられます。 AI は違います。実現可能性が、データを見るまで、動かしてみるまで分からない。すると「何を作るか」の決定が、データ理解やモデル評価の途中でしか下せなくなります。

Wall 01

発注できる形になっていない

仕様は現場の観察からしか出ず、価値は実データでしか測れない。要件定義書を書いて渡す、という手順がそもそも成立しない。

Wall 02

「データはあります」が信用できない

その返事は、ほぼ常に「テーブルはあります」の意味。行数・有効行数・鮮度・到達権限の 4 つを数えるまで、計画は立てられない。

Wall 03

PoC が溜まって、止まりも進みもしない

やらないものを落とせていないから資源が分散し、どれも本番に届かない。Gartner は「生成 AI プロジェクトの 30% 以上が PoC の後に放棄される」と出しています（2024-07-29）。

Wall 04

生成は速くなったが、検証は速くならない

人の誤りは間違って見えるが、AI の誤りは正しく見える。生成速度とレビュー速度の比が壊れていて、忙しい PM ほどその差で損をする。

The Twist

題名と中身の、意図的なねじれ

本書の題は「PoC で終わらせない」ですが、中身の半分は「終わらせる」話です。 00 章で最初に断ります。読者の期待を一度裏切ってから、なぜそれが同じことなのかを説明します。

PoC で終わらせないための最短経路は、終わらせるべきものを早く終わらせることである。

— 第00章「はじめに」より

02 章の「やらない理由を先に 3 つ書く」と、Part 5 の「畳む」は、残った 1 本を本番へ届けるための工程です。

The Method

全 19 章を、この 6 段のゲート反復で通す

例外を作りません。PM の職務は作ることではなく、作らない判断を安く下せるようにすることだからです。

誰の何が
困っているか

現場に張り付いて観察する。スコープ・費用・関係者の 3 つを握ったまま現場に座れるのは PM だけ。

やらない理由を
先に 3 つ書く

標準が立上げに置いたプロセスはいちばん薄い。その薄いところが、本書で最も重い。

データが存在するか
実測する

アジャイルのスプリントは前へ進む。データのスプリントは、後ろへ戻る。戻る回数が最も多い段。各章は「戻った回数」を必ず書きます。

最小で作って
本番の一部に当てる

PM が手を動かす目的は実装力ではない。仕様の曖昧さを、実装が通るかどうかで判定すること。

作る前に決めた式で
測る

効いたかの式は、作る前に決める。後で決めると、必ず自分に都合よく決まります。

続ける／畳む／
人に返す

各章末の「やってみる」の直前に、この章のものをどうやって畳むかを 1 節置いています。

Table of Contents

目次 — 全5部 19章＋付録8本

各章末には必ず「やってみる」を置いています。標準の用語は、章の中で 1 回だけ名前を出す目印であって、章の主役ではありません。

Part 1立場を決める

はじめに

発注できないものを、発注しようとしていた

PM が FDE になる

現場に張り付く権限は、もともと PM が持っている

やらない理由を先に 3 つ書く

立上げは、断る技術である

Part 2データから計画する

データスプリントは、機能スプリントではない

後ろへ戻る反復を計画に書けないと、全ての見積もりが外れる

データがあるかを、着手前に数える

行数・有効行数・鮮度・到達権限の 4 つを数えるまで計画を立てない

前提は数ヶ月で腐る

計画の再ベースライン。前提には「いつ引き直すか」を書く

費用は、モデルの値段では決まらない

渡している文脈の量と、枠の取り合いで決まる

Part 3作って通す

PM の朝を、1 コマンドにする

複数案件を横断して 1 枚にする。人間の起動そのものを消す

PM が書くコードは、仕様書の代わりである

動くものが、最短の仕様確認になる

入口は広く、中身は 1 つ

業務設計としての合流。広げる交渉は PM にしかできない

稟議を通す

AI 案件の説明は、できないことから書く

値付けと解放範囲

社内にも「買う理由」が要る。使う条件・開く範囲・見せる範囲が価格表

Part 4測る・止める

効いたかの式を、作る前に決める

受益者 × 業務カテゴリ × 期間、そして信頼度。単価は推定せず申告させる

自分が書いていないものを承認する

「AI が書いた」は説明にならない。承認したら自分の成果物である

達成状態で完了を判定する

台帳が壊れる 3 条件。要望の「文面」ではなく「達成状態」で判定する

Part 5終わらせる

外へ届ける

何を書き、何を書かないか。載せない基準を先に持つ

共通化はいつ決めるか

横展開という終わらせ方。早すぎる共通化は、間違った抽象を固める

自分が抜けても回るか

畳む判断。作った本人が異動したら止まるものは、成果ではなく負債である

おわりに

PM が作れる範囲は、権限で決まる

Appendix付録 — 8 本

7 ドメイン × 6 フェーズ対応表全文

42 セル全部を判断つきで展開。本書の目玉の完全版

標準の早見表（プロジェクトマネジメント）

6 原則 / 7 パフォーマンスドメイン / 5 重点分野 / 40 プロセスの内訳

標準の早見表（AI のライフサイクル）

6 フェーズの入出力と、どこで前フェーズへ戻るか

やらない理由の書式集

02 章の書式を、10 パターンの実例つきで

完了条件テンプレ集

「完了の定義」の型と、レビューの落とし穴 9 点のチェックリスト

既刊との読み分け・核の所有権表

Vol.3『AIエージェントの設計図』付録 H と対になる

用語表

標準用語の日本語訳と、英語原文の併記

出典一覧

各件に出典名・何を示すか・n と手法・発表日・取得日。採らなかった数字とその理由も

What You'll Get

通す線と、止める線を
自分で引けるようになる

やらない理由の書式集 — 10 パターンの実例つきで、断り方を型にする
着手前にデータを数える 4 項目と、そこから計画を引き直す手順
効いたかの式のテンプレと、完了条件・レビューの落とし穴 9 点のチェックリスト
7 ドメイン × 6 フェーズ対応表 — 標準と AI ライフサイクルの 42 セル全展開

コードは 1 行も載せていません。実装が要る箇所は Vol.1 と Vol.3 に送っています。これが、読者層の分裂を防ぐ唯一の手段だと考えました。

写真は制作中のイメージです。ページ数・造本は最終版で変わることがあります。

Who It's For

こんな人に

事業会社の PM / PdM / PMO

AI 案件に巻き込まれ、可否を判断させられている人。

PoC が溜まっている組織の人

止め方も終わらせ方も決まっていないまま、本数だけ増えている人。

エンジニア出身の PM

「作らせる側」に回ったことに違和感がある人。

既刊を読んだ人

「作り方は分かった。で、それをどう通すのか」と思った人。

本書は標準の解説書ではありません。PM が手を動かした記録に、標準の名前を後から付け直した本です。

Same Series

同じシリーズの本

読む順序はありません。どの巻からでも単独で読めます。

Vol.3 — 発売日未定

走りながら描く AIエージェントの設計図

本書が決める側なら、こちらは設計図を引く側。本書がコードを載せない代わりに、実装はすべてこちらにあります。

Vol.2 — 発売中

Claude Codeと働く1年目の教科書

こちらは AI と働く側。朝の型・タスク台帳・依頼の型で、1 日を回す型をつくる本。

Author

著者について

Hidekazu Nozawanzw

AI活用のチームマネージャー／SaaS開発のプロダクトマネージャー

PMP®

生成AIを用いたPoCや分析業務の傍ら、AIエージェントを設計・運用している。
バイブコーディング／AI駆動開発を日常的に実践し、AI と一緒に「機能」ではなく「伴走できる存在」を作ることに興味を持っている。
PMI日本支部のコミュニティ「AI@Work」に所属。

プロフィールシリーズ一覧 X

本書は特定の標準化団体の公式書籍ではなく、著者個人の実務経験に基づくものです。事例に登場する社名・人名・製品名は架空のものです。発売日・ページ数・形態・価格は変更になる場合があります。

PoCで終わらせないAIプロジェクトの進め方