プロジェクトマネジメントの基本が全部わかる本

目的

進捗会議では順調だった。テストに入った途端に話が変わり、期日が動く。顧客にも説明がつかない。

管理が甘いのではなく、遅れが見える場所と、生まれる場所が離れている。本書を読む目的は、工程全体を一本で見る目を持つことにある。

論点1 遅れが見えた時点で、原因は過去にある

本書は要件定義から保守までを通して扱う。そこで分かるのは、曖昧さは前半で生まれ、遅れは後半で見えるという時差だ。

• 要件定義 … 決めなかったことが残る
• テスト … 数か月後に遅れとして現れる

テスト工程で人を足しても効かないのは、原因がそこにないからだ。巻き返しより、前半で何を決めなかったかを見る。

いちこ

進捗が順調という報告は、何を見ていたんでしょう。

シュン

作業の進み具合だね。決まっていないことの数は、そこに出てこないんだ。

論点2 点で約束すると、調整の余地まで差し出す

見積もりを「3か月」と出すと、1日超えただけで遅延になる。本書が勧めるのは幅と前提をセットで出すことだ。

• 点で出す … 1日でも超えれば遅延になる
• 幅で出す … 「3〜4か月。要件が月内に固まる場合」

幅が縮むのは、前提が消えたときだ。営業の立場でも、顧客に幅のまま伝えられるかで後半の交渉が変わる。

不確実性を幅で扱う考え方は エンジニアリング組織論への招待 のほうが理論寄りに扱っている。

論点3 進捗より先に、決まっていないことを共有する

本書が実務として重く扱うのが、未決事項の管理だ。決めていないことを一覧にして、いつ誰が決めるかを置く。

• データ移行の範囲 … 今週 / 情シス
• 既存連携の扱い … 未定。ここが後半で揉める

営業が顧客から持ち帰るべきものは、たいていこの表の中にある。

いちこ

「決まっていないこと」を出すのは、怒られそうです。

シュン

後半に全部まとめて出てくるほうが怒られるよ。早く出したほうが安いんだ。

この本の限界と、次に読む本

網羅的で、通読には時間がかかる。期日と範囲の考え方だけなら アジャイルサムライ のほうが短い。発注側の責任範囲なら 06 対象 / 発注者の視点 に並べている。