PMBOKを中小受託の現場サイズにテーラリングして実際に使っている話

きっかけは、後輩から「PMBOKって、結局そのまま使えないですよね」と言われたことだった。

半分は同意で、半分は違うと思った。使えないのはPMBOKが悪いのではなくて、あれを中小受託の現場に「そのまま」持ち込もうとするからだ。私自身、昔まさにそれをやって盛大に転んだ経験がある。

だから今日は、PMBOKを分厚い理想論で終わらせずに、私が現場で何を削り、何を残して回しているのかを、知識エリアごとになるべく正直に書いておきたい。フレームワークは目的ではなく道具だ、というのが私の口癖なんですが、その「道具にする」作業の中身を言語化してみる。

教科書通りにやって、管理だけで案件が溶けかけた話

正直なところ、若い頃の私はPMBOKを「全部やるのが正しいPM」だと思い込んでいた。

ある3人チーム・期間2ヶ月の受託案件で、私はプロジェクト計画書、スコープ記述書、WBS辞書、コミュニケーション計画、リスク登録簿、調達管理計画……と、ガイドに載っている管理ドキュメントをひと通り律儀に作ろうとした。テンプレートを揃えて、体裁を整えて、レビューして。

そこで何が起きたかというと、着手して最初の1週間、私はほとんどコードにもお客さんにも向き合わず、ドキュメントの枠を埋めることに時間を吸われていた。ざっくり見積もっても、初期の管理ドキュメント整備だけで30時間近く使っていたと思う。2ヶ月・3人の案件で、である。

【当時：教科書通りに作ろうとした管理ドキュメント一式】

- プロジェクト計画書（章立てフル）
- プロジェクト憲章
- スコープ記述書 + WBS辞書
- コミュニケーションマネジメント計画書
- リスクマネジメント計画書 + リスク登録簿
- 品質マネジメント計画書
- 調達マネジメント計画書
- ステークホルダー登録簿

→ 着手初週がほぼこれで消えた。しかも大半はその後ほとんど更新されなかった。

一番こたえたのは、苦労して作った計画書の大半が、その後ほとんど開かれも更新もされなかったことだった。ドキュメントは作った時点が一番詳しくて、あとは実態とどんどんズレていく。更新されない管理ドキュメントは、ある時点で「嘘が書いてある紙」に変わる。

理屈はそうなんですが、と言いたくなる気持ちは分かる。プロセスを省くのは不安だ。でも、回らない重厚な管理は、やらないより質が悪いこともある——というのが、このとき私が現場で学んだことだった。

何を残し、何を削ったか——知識エリアごとの線引き

そこから何年もかけて、案件のたびに「これは要る」「これは今回は要らない」を判断し直してきた。今の私が中小受託でだいたい落ち着いている線引きが、下の表だ。

線引きの原則はシンプルで、「更新され続けるものは残す、作った瞬間が最新で以後放置されるものは削る」だ。

とくに削って良かったのは、独立した計画書の類いだ。品質計画書や調達計画書を一枚ものの文書にしても、中小案件では読み返されない。判断が必要になったその場で決めて、決めた理由を一行残せば、実務は困らなかった。

逆に、スコープと変更管理だけは規模に関係なく必ず残している。ここが緩いと、あとで「言った・言わない」が必ず火を噴くからだ。

変更要求は、専用の管理表ではなくチケットに落とす

PMBOK的に言えば、変更要求は「変更管理プロセスに乗せて記録し、影響を評価して承認/却下する」ものだ。理屈は完全に正しい。ただ、これを立派な変更管理表でやろうとすると、また更新されない紙が一枚増える。

私たちの現場では、変更要求を全部Redmineのチケットに寄せている。口頭やメールで「ここ、ついでにこうできない?」と来たものを、その場で一件のチケットに起こす。ポイントは、追加作業だと判断したものを、記憶ではなく記録に変えてしまうことだ。

【変更要求チケットの最小テンプレ（Redmine）】

件名: [変更要求] 帳票に取引先コード列を追加したい

- 依頼元 / 依頼日: 先方 田中様 / 7月2日 定例にて口頭
- 内容: 一覧帳票に「取引先コード」列を1つ追加
- 当初スコープとの関係: 契約時の項目定義に無し（＝追加）
- 影響見積もり: 実装0.5人日 + テスト0.5人日、リリース判定に影響なし
- 対応方針: 追加対応として合意 → 次スプリントで着手
- ステータス: 合意済み（先方 7/2 承認）

このチケットを定例でそのまま画面に映して「これは当初スコープ外なので追加でお預かりします、工数はこれくらいです」と一緒に見る。そうすると、変更の承認が会話の中で自然に取れて、記録も同時に残る。別紙の変更管理表を後から清書する手間がまるごと消えた。

今思えば、昔の私は「記録」と「文書を作ること」を混同していた。記録は残すべきだが、そのために専用の重い文書がいるとは限らない。すでに毎日使っているチケットの仕組みに乗せれば、記録は勝手に貯まっていく。

どこまで削ってよいか——規模での判断基準

「削る」と言うと、若手からは決まって「どこまで削っていいんですか」と聞かれる。ここは好みが分かれるところですが、私は案件規模・期間・チーム人数の三つをざっくりした目安にしている。

大事なのは、この表は絶対的な正解ではなく、あくまで初期値だということだ。同じ2ヶ月・3人でも、相手が官公庁で監査が入るなら品質の証跡は厚くする。フレームワークが教えてくれるのは「本来こういう管理項目がある」という抜け漏れチェックの一覧で、そこから今回の案件用に足し引きするのがテーラリングだ。

私が徹底しているのは、削るときに「削った理由を一行だけ残す」ことだ。これをやらないと、次に似た案件を担当する人が、なぜ品質計画書が無いのか分からず不安になる。判断そのものを、小さくてもいいから記録に残しておく。

【テーラリング判断メモの型（プロジェクト着手時に1枚だけ）】

■ 今回の案件属性
  規模: 2ヶ月 / 3人 / 受託 / 監査なし
■ 残す
  - スコープ&変更管理（チケット運用）… 揉め事の火種を潰すため
  - 簡易WBS（半日粒度）… 見積もり精度の担保
  - リスク上位3件のみ
■ 削る
  - 品質/調達の単独計画書 … 中小規模で更新されないため
  - 詳細なコミュニケーション計画 … 定例週1と決裁者の合意で代替

ただ、白状すると、この判断メモの型はまだ半分くらい私の頭の中に依存している。同じ案件属性でも、私が引くのと別のメンバーが引くのとで、残す/削るの線が微妙にズレることがある。ここは明確に改善の余地があって、案件属性から推奨テーラリングが半自動で出てくるくらいまで基準を外に出さないと、本当の意味で「道具」として組織に渡せていない。今まさに社内で整備しようとしているところだ。

振り返って

PMBOKを現場で使えるようにする作業は、覚えることよりも「捨て方を決めること」に近い、というのが今のところの私の実感だ。

全部やろうとした頃の私は、たぶんフレームワークに使われていた。今は、抜け漏れのチェックリストとしてPMBOKを一度広げて、そこから今回はどれを道具として握るかを選ぶ、という順番で使っている。残すものは薄くても更新し続ける、削るものは理由だけ残す。それだけのことなんですが、案件が管理コストで溶けることはなくなった。

次にやりたいのは、さっき書いた判断メモの属人性をなくすことだ。案件の規模や業種を入れたら「今回はここまで削ってよい」の初期値が出てきて、あとは担当が現場を見て微調整するだけ、という状態にしたい。テーラリングそのものをテーラリングできる仕組みにするところまでいって、ようやくこの話は組織の財産になる気がしている。