いちばんやさしいPMBOKの本／深沢隆司
久しぶりの読書ログ。読んでなかったわけじゃないんだからね！ブログに書かなかっただけなんだから！勘違いしないでよね！
内容の前に、そもそもPMBOKてなんぞや
PMBOKは、国際的に標準とされているプロジェクトマネジメントの知識体系（ガイド、手法、メソドロジー、ベストプラクティス）であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する[1]。
PMBOKはプロジェクトマネジメント協会（PM協会、Project Management Institute、PMI）が、PMBOKガイド（A Guide to the Project Management Body of Knowledge、PMBOK Guide）として提供しており、最新版は第4版である。またPMI本部が認定するプロジェクトマネジメントの国際資格に、PMP（プロジェクトマネジメントプロフェッショナル）がある。日本にはPMI日本支部がある。
Wikipediaより。
何言ってるかさっぱりわかりませんね。大丈夫、PMBOK自体何言ってるかさっぱりわかりませんから（！）
で、この本によると、
PMBOK（プロジェクトマネジメント知識体系ガイド）には、「ものごとを成し遂げようとする場合に役立つ事柄や考え方」が整理・記述されています。（まえがきより）
とある。
こっちのほうがいくぶんかわかりやすい気がする。
つまり、お仕事でなにか「プロジェクト」をたちあげて、何事かを成そうとしたときにPMBOKを参考にするとよいですよ、というものらしい。
Wikipediaからの引用にもあるように、PMBOKは「印刷物（デジタルかもしれないが）」の形で提供されている。
したがって、これを読めばプロジェクトマネジメントはうまくいき、炎上知らずだぜ！といきそうだけど、そうもいかない。
どうやら「PMBOK難しすぎワロタwwwwwワロタ・・・」らしい。
ネットスラングを使ってしまったが、とにかくこの文章として起こされたPMBOKは難しいらしい。
そこで、いきなりそのPMBOK本体を読み始めるのではなく、この「いちばんやさしいPMBOKの本」を読んで、どのへんが難しいのかとか、誤解が生じやすそうなところはここだとかを押さえておきましょう、という位置づけ。
じゃあこの「いちばんやさしい〜」はわかりやすいのか
わかりにくい。すごいわかりにくい。通勤電車のなかで読むんじゃなかったと後悔した。
でもこれは、決してこの本が悪いとか、そういうわけではない。
多分、これは何もしらない人に「コンピュータの構成と設計（パタヘネ）」を「これを読むとわかりやすいよ」って言って渡すような感覚に近いんだと思う。
もとがわかりにくいから、わかりやすいといってもわかりにくい。
特に、元がアメリカのものなので、それを日本語で説明しようとしたときにどうしてもカタカナになってしまう。
例えば
ここで、PMBOKでの書かれ方として、注意を要する部分があります。
それは、タイムについてどのように計画を進めていき、監視コントロールや変更管理をしていくのかを文書化した「スケジュール・マネジメント計画書」は、プロジェクト・タイム・マネジメント（第６章）にあるプロジェクトマネジメント・プロセスでアウトプットして新規に作られるのではなく、プロジェクト統合マネジメント（第４章）の「プロジェクトマネジメント計画書作成」プロセスの一部として作られるものとなっていることです。
わかりにくい。一文が長い。たぶんカタカナのせいだと思う。
こういったところが、せっかくわかりやすくと思って書いてある（だろう）本書を読み進める上での最大の妨げになってる。
じゃあどうすればいいと思うのか
id:electricalpeachとしていいとおもう読み方は「理解の放棄」ではないかと。
こうなると元も子もないように聞こえるけど、そこらへんの底の浅いビジネス書を読むときのように、
「何か一つエッセンスを得る」つもりで読む。
そして、この本を読んで「仕事中にあの点を意識してやってみたらちょっとうまくいった」となったら、今度は別のポイントを探して実践してみる。
それを繰り返して、ぼんやりと全体が理解できるようになるのではないかなぁと思った。
もちろんこの本は「PMBOKを読むための本」であるのだから、最終的には本体を理解して実践するのがゴールなんだろうけど。
そこを急ぐと絶対挫折する。
この本に書いてあるPMBOKの要素で大事だと思ったこと
すごくざっくりだけれど、やはりプロジェクトを行う上で「準備が大事」ということ。あまりにも普通すぎるけど、その普通がないがしろになっているせいで世の中のプロジェクトが遅延し炎上してる。
このPMBOKを含め、プロジェクトをいい方向に持って行こうとした場合に、全員のベクトルがほぼ同じ向きを向いている必要がある。
もちろんメンバーのベクトルを揃えるのもマネジメントなんだろうけれども、そこにリソースが多く持っていかれてはいけないと思う。
マネジメントの知識は、マネジメントを「する側」が持っていればいいのではなくて、「される側」にも必要。
だからこそ、下っ端の自分もこういった本でたとえさわりだけでも概念に触れておくことで、マネジメントする側が少し楽になるんじゃないかなぁと思った。
