こんにちは。ブックマイヤーです。
「誰も教えてくれないプロジェクトマネジメント」の要約をします。
システム開発プロジェクトに携わる方向けの本となります。
本書は、PMBOK知識体系は読んだけど実践できないという方の為に、具体的な行動に落としこめる内容となっています。既にプロジェクトマネージャーとして経験がある方なら理解が早いと思います。これからなりたいという方には少々取っつきづらい内容かもしれませんが、読んで損はないと思います。
プロジェクトの大きな流れと役割
PMBOK（プロジェクトマネジメント知識体系）では、「立ち上げ」「計画」「実行」「監視・コントロール」「終結」となっていますが、
本書では
「企む（たくらむ）」「段取る（だんどる）」「やる」「視る（みる）」「振り返る」
と、わかりやすく言い換えています。
システム開発プロジェクトではフェーズという考え方があると思います。システム化構想フェーズ、要件定義フェーズ、設計フェーズなどです。これらフェーズそれぞれに、この5つのプロセスを実行していきます。
5つのプロセスをざっと紹介します。詳しくは本書を読んでみてください。
企む（立ち上げ）プロセス
キーワードは「共通認識」です。このプロセスでは、プロジェクトの目的や目標を共有する事、大まかなアウトプット、大まかなプロセスを決めておく事が重要となります。そのためには関係者へのヒアリングが必要になります。
本書では、ヒアリングについて、誰に、何を、いつ聞くのか、や、「6R」というフレームワークを使った手法を紹介しています。
プロジェクトマネージャーとして注意する点としては、プロジェクト自体を前に進める事を目的化してしまう事です。プロジェクトでは常に真の目的（上位目的）を意識し続ける必要があります。
この上位目的の考え方は本ブログの別の記事でも紹介しています。
書籍「シンプルに結果を出す人の5W1H思考」はうまく企画提案や問題解決したい方にオススメ
プロジェクトの目的
プロジェクトが立ち上がるときは「基幹システムの刷新」というようにWhatは明確な事が多いです。
大まかなアウトプット
プロジェクトスポンサーやステークホルダーとの認識の違いをなくす為、この段階で大まかなアウトプットを決めておきます。WBSを使って大まかなアウトプット（成果物）を決めておきましょう。
大まかなプロセス
要件定義、概要設計～製造、テストなど大まかなプロセス（フェーズ）を定義します。ここで重要なのは、各フェーズの完了基準を明確にする事です。
段取る（計画）プロセス
「どうやって目標達成するか」を計画するプロセスです。
ポイントは、わかってる情報で詳細化していく事です。詳細がわかってから計画を立てるのではありません。わかってからではいつまでたっても計画を立てる事ができないからです。
プロジェクト計画を立てる際に重要視されるのがWBSです。WBSは成果物WBSと作業WBSがあります。成果物WBSは前の章で書いた通り、成果物を構造化したものです。作業WBSとはプロジェクトを時系列の作業にブレークダウンしたものです。システム開発プロジェクトに携わった方にはお馴染みかと思います。
ただし、本書ではこの作業WBSをオススメしていません。なぜかというと、プロセス（仕事の進め方）を知らないと作れないからです。よくあるのがWBSに漏れが発生しており、後からそれに気がつく事があるかと思います。それもプロセスを知らない事が起因していると考えられます。
本書ではその代わりの方法として、戦略を行動に翻訳する手法や、計画するための思考法、プロセスフローダイアグラム（PFD）の使い方を紹介しています。
やる（実行）プロセス
実行中はプロジェクト内外でコミュニケーションを活発に行います。
視る（監視、コントロール）
実績が計画と乖離していないかチェックします。
プロジェクトでは進捗管理を行うかと思います。進捗会議で「オンスケです」とか「2日遅れています」だとかを報告してもらうアレです。本書ではこれらの進捗管理はやめろと言っています。なぜなら、この進捗管理の元となっている計画や見積自体に不確実性がある（正確にはわからない）仮に正しくない見積を元に進捗を合わせようとすると、そこで無理が発生するというわけです。そして、どんどん計画を乖離していき、計画の修正が繰り返される。そして最後にはデスマーチへと。。
ではどうすれば良いのか、以下の３つのポイントがあります。
「あとどれくらいかかるか」をみる
過去を見ようとするのではなく、未来を見ようとします。既に遅れた進捗は事実でしかありません。変えられるわけでもありません。プロジェクトのとっては、あとどれくらいかかるか？の方が重要となります。
時間を「枠」で管理する
期限までに間に合うか？という視点ではなく、時間枠（与えられた時間）に対してタスク達成にかかる時間が見積と逸脱していないか？を見ます。
予実の差を前提とした計画を立てる
最初に見積った工数は正確ではない事を前提に、「予実のずれを吸収できる」ように計画を立てます。ようはバッファをもうけます。ただし、バッファは計画時に見積とは明確にわけるべきだと本書では書かれています。人間の心理学的に？一緒にしてしまうとバッファを食いつぶしてしまう事になるからです。
本書ではこのバッファについて細かく記載しています。
振り返る（終結）
プロジェクトの最後に、うまくいったこと、うまくいかなかったことなどを振り返り、次のプロジェクトに活かします。プロジェクトは「やったことがないこと」を取り組みます。その不確実性を乗り越えていくためにはこの振り返りを行い、経験を蓄積していく必要があります。本書ではKPTという振り返りの手法を紹介しています。
KPTによる振り返り
「Keep」・・・次もやりたいことや、うまくいったこと
「Problem」・・・問題、うまくいかなかったこと
「Try」・・・次にやってみたいこと
この観点で、プロジェクトでおこった事をメンバー全員で振り返ります。
感想
この本を読んで、すべて実践するのはハードルが高いと感じました。私もここまで細かくはやっていませんが、参考になる箇所はあったので部分的にやってみようと思います。一つでも実践できそうなものがあれば、「読んでよかった！」と思えるのではないでしょうか。
コメント