153冊目：「プロジェクトマネジメント 現場マニュアル（改訂版）」

総評：★★★★☆　良かった。
面白い度：★★★☆☆　面白さとしては普通。
読みやすい度：★★★★☆　専門書的なものの中ではかなり読みやすい。
ためになる度：★★★★☆　いい感じにためになった。
また読みたい度：★★★★★　今度プロマネ業務をやることになった時に。


前回と同じく職場の同僚に勧められた本。

プロジェクトマネージャとしての現実的な対応などが書かれたマニュアル本。
この前、プロジェクトマネージャの資格を足掛け5年くらいでやっと取ることができたのだが、その試験では、方法論的なことが一般的に問われる試験となっており、具体的なこの場合はこうするといったハウツーは試験には出てこなかった。

でも方法論として覚えるのと実際の現場の状況は結構違ったりする。この場合はこうすればいいと方法論では書かれてはいても、実際思ったような効果が出なかったり、そもそもその施策を実施できないことだってあったりすると思う。
この本は実際の現場の具体的な問題に対して、どのようにプロマネとして振舞ったらいいかとなかなか現場目線のハウツーが書かれていた。

パッと見思ったのが、こんな本を待っていた！という感想だった。この本で出てくる（仮ではあるが）問題の起こっているケースは、これ実際にある！とかあった！とかかなりリアルな状況であり、その所がいい感じに親近感が湧いた。
プロジェクトは概ね思い通りにいかないし、問題なんか次から次へと出てくるものである。こんな状況ってやっぱり他でもあるんだよね？と少なからず救いも得られた本でした。

一通り見た感想としては、やっぱりプロジェクトは上流工程でかなり準備をしておくことが必要なんだなと思った。そして、一番思ったのが、「標準の作成」であった。
それぞれの章で問題のあるケースが出てくるのだが、それらの解決方法でよく「標準を作りメンバーと共有し、プロジェクトでそれを遵守する」といった内容のものが多かった。
標準は今までかっちり作ってあったのはあまりなかったし、それは漏れなどもあったりしたが、その標準があるとプロジェクトってうまく回る可能性が高くなるんだな〜と思った。

上流工程で色々考えるのはいいが、下流工程で上流工程で決まったことの前提を覆すようなことが起こったらどうするんだろうと自分としては前々から不安に思っていたのだが、そういったことはしっかり標準を作るとそういったこともなくなっていくのではないかなあ思った。
なので、この本では標準を作ることの重要性とその大切さということが分かりましたとさ。


そんなんで、この本を読んで興味深かったことを抜粋する。

・しかし、取り上げた題材において、業種、業務を問わず共通して一番重要なのがスコープ変更と仕様変更のリスクであると考えてください。

・スケジュールを管理するためには、工期を決めている最も長いパスを集中的に管理することが工数短縮をするためには重要です。TOC（Theory of Constrains：制約条件の理論）では、このパスのことを"クリティカルチェーン"と読んでいます。クリティカルチェーンは、タスクの順序の依存性に加えて、重複するリソースの優先順位を考慮して、作成されたスケジュールです。
　このクリティカルチェーンの短縮を図るために、人の行動特性に依存する遅れも考慮して、TOCでは以下の考え方、手順を取ります。
　各作業者に割り当てられた作業が50%の確率で完了できる期間を申告させます。ぎりぎりでできるかどうかにチャレンジさせるわけです。ぎりぎりのスケジュールのため、遅れそうになると作業者はすぐにプロジェクト・マネージャに報告し、相談します。また、遅れないように作業に集中すると共に創意工夫をして、作業の効率を上げることとなります。その結果として、作業者の能力は高まり、プロジェクト・マネージャとの信頼関係が築かれるわけです。
　しかし、ぎりぎりのスケジュールにしたために、プロジェクト全体としての余裕度がなくなってしまい、想定外の作業増大には対処できません。そこで、CCPMでは、「プロジェクト・バッファー」「合流バッファー」という概念を導入しました。
　プロジェクト・バッファーは、各工程が見積もり確度を50%から100%にするために取っている余裕時間をひとまとめにしてプロジェクト全体で管理するもので、ネットワーク図の上ではクリティカルパスの後ろに置かれます。個々のタスクで遅れが発生した際にはプロジェクト・マネージャがプロジェクト・バッファーを原資に対応する時間を捻出し、各作業者に与えます。各タスクが予定通りに完了する確率は50%になるが、それでもすべてのタスクで遅れが発生するわけではないので、プロジェクト・バッファーで遅れを吸収することができます。
　また、合流バッファーは、クリティカルパス上にない工程がクリティカルパスに合流する部分に設置される安全時間で、これに余裕のあるうちはクリティカルパス（すなわちプロジェクト全体の完了期日）に影響を与える可能性はありません。〜（中略）〜
　そのため、計画段階でリソース競合に注意することが必要となります。競合が起きているリソースはすなわちボトルネックになっていると考えられますが、TOCではボトルネックになっているタスクの能力を最大限引き出すことがポイントとなります。そのため、まずは複数のタスクや他のプロジェクトで競合しているリソースに対して、仕事の優先順位を明確にし、掛け持ち作業に陥らないようなスケジュールを作成することが重要です。
　このように、クリティカルチェーンに配慮したスケジューリングを行ったら、プロジェクト・マネージャの仕事は、プロジェクト・バッファーや合流バッファーなどのバッファー・マネジメントに集約されます。すなわち、各タスクの締め切りの管理に注力する必要がなくなり、バッファーがどれだけ消費されたかを管理することになり、バッファーの残りが少ないとか、減るスピードが速い場合に対策を取ればよいようになります。

・まず最初にやっておかなければならなかったのは「プロジェクト標準」をメンバー全員に理解させることです。
　プロジェクト標準とは、メンバー間の共通ルールや行動原理を規定したものです。「共通」「プロジェクトマネジメント規約」「システム開発環境規約」「システム開発規約」「システム運用規約」で構成されます。〜（中略）〜
　一方、「プロジェクトマネジメント規約」は、プロジェクト全体のコントロール方法を決めておくものです。「進捗管理ガイドライン」「リスク管理ガイドライン」「外部委託管理ガイドライン」「構成管理ガイドライン」「品質管理ガイドライン」「変更管理ガイドライン」などで構成します。
　これらガイドラインはPMだけが使うものではなく、すべてのメンバーが必要に応じて参照します。それぞれのガイドラインは独立して存在しているわけではありません。それぞれのガイドラインは他のガイドラインと結びついてプロジェクト全体が機能します。
　要件定義は、十分なヒアリングや議論の過程を経て合意、確定します。確定した要件は「構成管理ガイドライン」に従って管理します。正規の手続きに沿って承認した設計書やプログラムなどの成果物を"ベースライン"と呼びますが、要件定義書一式もその一つです。ベースラインを変更する際は「変更管理ガイドライン」で規定された手順を踏みます。
　各工程ごとに成果物の品質を維持するために使うのが「品質管理ガイドライン」です。設計書などのドキュメントをレビューする方法やタイミング、必要に応じて講じるべき是正措置などが記載されています。
　ベースラインの変更や品質維持に伴う是正措置によって、開発規模、工数、スケジュールなどに与える影響が大きい場合は、プロジェクト計画を変更します。その際「進捗管理ガイドライン」を参照します。
　その工程でもトラブルは発生し得るため「リスク管理ガイドライン」はすべての局面で随時参照します。

・問題管理は、進捗管理の一環として実施します。プロジェクトに影響を及ぼす可能性のある日々の問題を分類して管理することで、早期に対策を立て被害の拡大を最小限に抑えます。
　問題管理で重要なのは、問題ごとに責任者や期限を明確に決めることです。
　リストアップした問題は、担当者間で共有します。対応できるリソースには限界があるからです。また、問題は多く発生するほど一つひとつが埋没してしまいます。すべての問題を担当者間で共有し、優先順位をつけて対応することが重要になるのです。〜（中略）〜

　こんな事態を避けるには、進捗会議の進め方を工夫することです。まず、問題の報告を受ける場合には、解決案も一緒に考えて報告させるようにメンバーに指導します。担当者が特定できる問題なら、関係者のみで別途会議を開催するのもよいでしょう。また、重要な問題は進捗会議を待たずに迅速に対応してしまいます。

・上流工程で要件をしっかり確定しておかないと、あと工程での手戻り、品質の悪化など多大な影響を及ぼします。
　（要件が決まらない場合はどうするかという）回答のヒントは、会話の中にちりばめられています。解答は「スキルが不足している」「マネジメント・プロセスが実施されていない」「ユーザーの参画が不足している」「作業プロセスが明確でない」「成果物のレベル感が統一されていない」です。要件をいつまでも確定させられないPMはこれらのすべてもしくは一部に問題がないかを確認してみましょう。


抜粋としてはこんなところでしょうか？
同僚から勧められて見た本だが、自分用に一冊買い、今後プロマネをやることになった時はもう一回見直してみようと思う。
そんなんで以上☆