PMBOKはどう使えばいいか - 室長のひとりごち

PMBOKの第1版はB5サイズで、本文は126ページと用語解説は44ページの少し厚い薄い本だ。

それが第6版になるとA4サイズになり、目次と図表の索引で30ページ近く割くようになった。本文は530ページを超え、紙で読みたいと思うようなものではなくなった。

PMI会員であれば、ベネフィットとしてPDF版を入手できるのでPDF版一択である。紙媒体はどうやらコピー対策で可読性がとても酷い状態らしいとamazonの書評で多数書き込みされている。

第2版である2000年版で既に厚く大きいサイズになり、当時から手を余したものだ。

第2版あたりからとても読みづらい本となった。第1版は別に意味、誤訳で読みづらいと聞いたことがあるがそれほど気にならなかったのは、第2版が出る直前で買い、ろくに読んでいないからかもしれない。

知識体系であるから目次も知識エリアごとに統一されており、これが返って読みづらくしている。

体系のツリー構造図、概念から始まり、プロセスのインプット、ツールと技法、アウトプットを繰り返し説明する。プロセスのデーターフロー図は1つの知識エリアに多数含まれるプロセスがあることを証明しているようなものだ。

システム開発を上手くやりたいなら、プロジェクトマネジメントとシステム開発の運営を理解できる本を読んだ方がいい。

目次の中に課題ログと言う項目がある。いわゆる課題管理であり、本文と課題管理で管理したい項目が列挙されている。

箇条書きの項目を見る限り、実際に課題管理に使いたい項目よりは少ないのはPMBOKが業種を横断してプラクティスを集め、それらからどの業界でも使えるように共通項を抜き出したからだろう。

それでも、プロジェクトマネジメントの経験のないエンジニアが課題管理で（最低限の）課題管理をしようと思ってPMBOKを読んだとしたら、これで管理項目は作れるだろう。

統合変更管理での統合変更管理ツールを読むとPMBOKが何であるか片鱗を知ることができるのではないか。考え方としなければならないことの説明が書かれている。

2000年代に日経BPあたりがPMBOKを流行らせたとき、PMBOKがプロジェクトを成功に導く銀の弾であるかと飛びついた経営者達は現場にPMBOKを導入することを求めた。現場はこれでどうしろと言うのだと思ったに違いない。

それはその通りで、日頃から書いているようにPMBOKは器でしかない。考え方だけだ。前述の課題ログのように項目が記載されているだけでもマシなのだ。

PMBOKは体系であるから、業界を問わずプロジェクトとして事業をする業界に適用できるように作られている。

結果、共通項だけになるのはもちろん、体系であるかこそ冗長に書かれる。それをPMBOKではプロジェクトマネジメントを行う側のプロジェクトに合わせてテーラリングを行うことを求めている。

この辺りの考えは標準化をするときと同じである。

EOF2019あたりでも品質のことについて言及があったようだが、エンジニアが開発プロセスでプロジェクトの要求事項を製品なりサービスなりが備えられていることを担保してくれれば、そもそも品質マネジメントなど必要はない。

それができないから、品質マネジメントの切り口で、尺度を定め、データを収集し、分析し、品質の監査を行うのである。

繰り返せば、開発プロセスで品質を考慮しないケースで失敗を繰り返すから、知識体系として品質マネジメントを入れているのである。そうもしないと品質のリスクからプロジェクトが失敗しかねない。

QCDのQはQualityであり、3つの１パーツでしかない。

システム開発においてPMBOKをどう使うか。

それはシステム開発のプロセスから得られるデータや情報に対して、PMBOKの観点でプロジェクトが期待するように進捗しているかをモニタリングする仕組みとして使う。

プロジェクトをモニタリングしたいメッシュで情報を持っていなければならないから、システム開発側では情報を要求される単位で持たなければならない。

言い換えれば、システム開発とプロジェクトマネジメントのインタフェースを決め、そのインタフェースで得られる情報でプロジェクトをコントロールする仕組みを作ればいい。