プロジェクトマネジメントの基礎

現在の某飲食店のPJに管理者として入ってから早８ヵ月。
参画当初はまだ詳細設計工程だったPJも、
現在は無事に(?)リリースが完了して運用フェーズに。

初めてのPJ管理で、正直上手く進めていないと感じて凹んだ事も多々あった。

本当に今さらだが、ようやくPJ的にも時間にゆとりができてきたので、
上司に相談して、ここで改めてPJマネジメントを座学で学ぶことにした。

PJマネジメントは、IT企業特有のもの？

この研修、某ITベンダー企業が実施しているものなので、
ベンダー側の人間ばかりが参加するのかと思っていたが、実態は違っていた。
周りの人間は情シス、営業、運用担当といった人たちばかりで、
どうも、最近の傾向として開発側だけではなく発注側の人間も
システム開発におけるPJ管理を学ぶらしい。良いことだとは思う。

実際に研修を受講してみて

講義で取り扱った内容は、本当にPJマネジメントの概要のみで、
正直、これくらいならAmazonで書籍を買って読んだ内容と大差ないような・・・

「プロジェクトマネジメント」実践講座

ただ、いくつか学んだ内容もいくつかあったので、
その内容を忘れないようにメモしておく。

PRINCE2との関係

最初の項がいきなりテキストには載っていない内容だが・・
以前から気になっていたPRINCE2との違いを空き時間に調査。
PMBoKとの主な相違点としては以下の通り。

• 日本ではPMBoKが主流だが、EUではPRINCE2のほうが主流になっている
• PMBoKがPMを中心にPJの推進方法を記載
• PRINCE2は組織のエグゼクティブまでを含めた形で記載
• PMBoKは定義する期間がPJのスタートから終わりまで
• PRINCE2は事業の立案～価値創造までと、PJ終わった後についても記載

注意したいのは、どちらのほうが優れているというわけではなく、
お互いがお互いの内容を補完するものだと考えていいらしい。

プロジェクトの定義

①有期性　　　：どのPJにも、明確な始まりと終わりがある
②独自性　　　：基本的に、PJが成果物が創造する成果物やサービスは唯一無二のもの
③段階的詳細化：PJには必ずリスクがつきまとう。ステップを踏んで、不確実性を小さくする

PJに参画していても、「PJって何？」って言われると答えるのに困る人は多いと思う。 PMBoKではPJの定義を①、②と定義。2つに加えて、研修では③も定義に含めていた。
③の定義が良いかどうかは置いておいて、①、②は確かにそうだと思う。
終わりがなくて、過去と全く同じ作業であれば、それはPJではなくてルーチンワークに当たると思う。

PMの役割

PMの役割は、PJの計画、実行、監視・コントロール、終結に責任を持ち、PJを成功に導くこと

上記がPMの役割の定義。
ただ、講師の人が話していて共感したのは、PM作業の9割が他者とのコミュニケーションだという事。
結局はコミュニケーション力が鍵だと言うのは、確かに実体験から自分もそうだと痛感している

コスト見積り

以前はPJ管理費用をWBSに含めず全体規模の×10%みたいな形で算出していたが、
最近はWBSに落とし込むことも増えているらしい。
理由としては、①WBSに記載がないと顧客への説明が難しい、
②WBSに明記することで、メンバーからリーダーへの報告を意識させる、
という狙いがあるらしい。

品質管理

• 「品質保証」と「品質コントロール」は異なる。品質保証はプロセス自体の監視
• 品質管理ではまず「基準値」と「許容範囲」を定める
• 許容範囲に収まらない場合は、3現主義で実態を把握する
• 逆にほとんどが許容範囲に収まらない場合は、そもそも計画を見直す必要がある

リスク管理

• リスクの洗い出しにはブレーンストーミング、デルファイ法、識者へのインタビューを実施
• 計画書を起こす場合は、組織としてのリスク許容度、選好度を加味する必要がある
• リスクに優先度を設け、対応する順番を決める
• リスクは「回避」「転嫁」「軽減」「受容」の順番で対応策を検討する
• 受容で対処する場合は、あらかじめ時間と資金、資源をコンティンジェンシー予備として設定する

PJ計画書の扱い

• PJ計画書は契約書ではないが、開発元が作成してユーザーが承認した文書のため、「覚書」に相当
• PJ計画書の通りに進んでいない場合は、ユーザーは裁判を起こして争うことも可能
• PJ計画書に何を記載するのか、記載する文言をどうするかは極めて重要になる

PJチームマネジメント

コンフリクトが発生したら？

まずはメンバー同士で解決に動いてもらうのが前提。
それでも解決できない場合は、下記のほうほうを検討する

1. 撤退や回避・・・問題の先送り
2. 鎮静や適応・・・意見の異なる部分ではなく同意する部分を強調し、相手のニーズを認める
3. 妥協や和解・・・関係者全員がある程度納得できる解決策を探し、対立を一時的に解消する
4. 強制や指示・・・相手を犠牲にして自分の主張を押し付ける。権力を利用して緊急事態を回避
5. 協力や解決・・・協調性のあるオープンな姿勢と対話から合意と確約を得る

4はできるだけ取りたくない手法だが、PJの緊急時には有効な方法でもある。

スコープ妥当性確認

成果物を受入してもらう段階で、受入否認となる場合は理由を文書化する。
変更要求が発生した場合は、統合変更管理のプロセスで処理する。
→この仕様変更がどくれくらい生じているかを分析するのが大事。
　要件が漏れていたのか、暗黙の要件だったのか、新たな要求だったのかで次のPJに繋げられる。

コスト・コントロール

アーンド・バリュー

予算と予定の観点から、PJの進捗状況を定量的に把握するための手法。
最近は確かに、PJでこの手法を取り入れるPJが増えてきた。
また、会社的にも少し前に工事進行基準という形で、PJの工数を管理するように変わっている。

品質コントロール

PB曲線

テストの残件数とバグの発生件数からテストの実施状況を把握する手法。

まとめ

最後のほうは時間がなくて記載が雑になってしまったが・・
時間があればまた、一つ一つを掘り下げて記載したいと思う。
ひとまず、本日の復習はこれまで。