SREホールディングス株式会社でプロジェクトマネージャ（PM)を努めている鍋谷です。
様々な事情でPMが交代することになった進行中のプロジェクト。
そのプロジェクトにあなたが後任のPMとして就任することになったとき、
あなたはどうしますか？
この記事では、筆者の経験に基づいて、進行中プロジェクトの後任PMの立場になったとき、どういう心構えで何をしたらよいのかをお伝えできればと思います。
対象読者
・進行中のプロジェクトの後任PMになった人
・プロジェクトの引継ぎに関心がある人
・プロジェクトマネジメントのスキルを向上させたい人
前任PMから業務を引継ぐ
最初にすることは、前任のPMからの業務の引継ぎです。
業務の引継ぎは、プロジェクトの概要、現在の状況、現在に至る経緯、成果物や体制など広範囲にわたります。しかし、進行中のプロジェクトにおいて、ドキュメントにこれらがきれいに整理されていないことがあるため、口頭でのヒアリングによる引継ぎが中心になります。
ヒアリングで気をつけたいのは、プロジェクトマネジメントで不備があったとしても責任の所在については追及しないことです。人は追及されると責めを感じ、自身の解釈を優先します。そのことで知りたい事実が曲がって伝わってくることがあるのです。グッと我慢して事実確認にとどめましょう。
また、表面に現れていない問題の火種にまだ気づいていない場合もあります。その場合は当然、引継ぎされることはありません。引継ぎに過度な期待はせず、不都合な情報は引継ぎされないものと割り切ってのぞみましょう。
ただし、最低限聞いておきたいことはあります。
モノとヒトをおさえれば、あとは何とかなるものです。
プロジェクトの状態を把握する
引継ぎの次はプロジェクトの状態を把握します。プロジェクトの状態は口頭で聞かされると思いますが、見えるもので確認したいところです。そこでプロジェクトでの管理資料を参考にします。確認するものは以下の３つです。
それぞれの管理資料で何を確認すればよいでしょうか？
-
スケジュール・日程表
スケジュール・日程表はどこのプロジェクトでもたいてい存在するでしょう。ここで確認するのは、スケジュール・日程表にのっているタスクの粒度はどの程度か、そのタスクに対する担当や期限がきちんと記入されているかを確認します。タスクの粒度は、そのタスクの日程の長さで適正かどうかがわかります。
１つのタスクは１～２週間以下が適正です。１か月を超えるようなタスクがあれば、
そのタスクの粒度は荒く、管理する粒度も荒くなっています。
担当や期限が記入されていないスケジュール・日程表は意味をなしません。
その状態が放置されていれば、管理する強度が低いといえます。 -
体制図
体制図は最新に更新されているかを確認します。
最新化されていない場合には、分担や責任があいまいになっている可能性があります。
分担や責任があいまいになると、宙ぶらりんのタスクが発生している、
問題が発生してもエスカレーションされない状態になっているのを疑うべきでしょう。 -
課題管理表
課題管理表は解決していない課題の発生日を見てください。
発生日が何か月も前のものであれば、タスクが分解されていないか、課題のゴールが決まっていないかのどちらかです。
プロジェクトの推進力（旗振り）する人の力量が弱い、プロジェクトのキーマンが回っていないなどの原因が考えられます。
開発システムの品質を把握する
進行中のプロジェクトでは、設計書やマニュアルなどのドキュメントは正確でない前提で見ましょう。進行中のプロジェクトでは、実装を優先し、ドキュメントは追いついていないことがよくあるからです。また、ドキュメントがあいまいな記載が多くあるのも特徴です。
そのため、開発システムの品質を知るには、実物のシステムを確認するしかありません。
実際に開発システムを自分で触ってみてください。
画面や動作を体験したときの違和感を感じてください。
そして、なぜそうなっているかを開発者に聞いてください。
そうしてシステムの真実（＝本当の品質）を把握するのです。
あるべき姿を想像し、正しいゴールに向かう
開発システムの品質を把握したら、つぎに開発システムの本来あるべき姿を考えます。
このプロジェクトのゴールです。
そのとき、
進行中のプロジェクトでは、できることしかやっていない、都合のよい仕様に変更しているなど、開発側の論理でシステムが作られてしまっている場合があります。
正しいゴールに向かって進まないと、あとから方向転換は難しくなります。
どうマネジメントするか
正しいゴールへの方向性が決まり、プロジェクトを動かすとき、あなたはどうマネジメントしますか？
あれもこれもマネジメントしたい気持ちが湧き上がっていませんか？
しっかりマネジメントすれば問題も発生しないはずです。
それは正常なプロジェクトでは正しいでしょう。
しかし、プロジェクトの途中でマネジメントをガチガチに変更すると、悪化します。
マネジメントされる担当者の負担となり、担当者が本来やるべきことができないのです。
つまり、プロジェクトの状態と開発システムの品質を考慮して、この範囲だけはしっかりマネジメントすると決めてしまいます。
その範囲だけは、ミクロにマネジメントしてもかまいません。
（例えば、品質に弱点があるA機能の不良対策は作業プロセスを見える化して、1件ずつ期限とステータスをマネジメントする、など）
それでもゴールの形は変わっていく
正しいゴールに向かって進んでいても、ぶち当たる壁があります。
スケジュールとコストです。
プロジェクトの納期が決まっており、期限をずらせない、これ以上お金をかけられないなど、プロジェクトでの制限が立ちはだかります。
正しいゴールの方向には向かってほしいのですが、やむを得ず一部をあきらめなければならない場合もでてくるでしょう。
その場合は、関係者でその都度合意形成して、その時点での最善を選ぶことです。
例えば、あるアプリケーション機能の品質が悪くて、とても納期までに間に合わせそうにない。しかし、その機能は代替手段の運用で逃げられる。そんなとき、思い切って納期までの完成は見送りできないか、関係者と話し合います。
やめるもの、あきらめるものを調整して決めていくことがPMの役割です。
経緯がわからなくとも
引き継いだ後のプロジェクトでは問題が発生することがあります。
その問題の原因が、引継ぎ前の期間に埋め込まれたもので、経緯がわからないものが出てきます。
合意したつもりのものが、合意していない。言った言わないで、揉めてしまったりします。
文書で経緯が残っていればよいのですが、そのような問題に限ってまず残っていません。
そんなときでも「経緯がわからないから」で逃げないでください。
過去のことを人のせいにして問題解決を避けてはいけません。
問題解決の全責任はPMが受け持つ覚悟が必要です。
過去は変えられませんが、未来はつくることができます。
未来志向で問題解決を進めましょう。
やれることをやる
未来志向で問題解決を進めていく心構えは大事ですが、現実はなかなか厳しいものです。
過去から継続している問題に対してミラクルな解決策が見つかることは、まずありません。
（そのようなものがあれば先人がすでにやっています）
ではどうすればよいでしょうか？
問題解決に向けたアイデアをToDoに整理し、実行に移すだけです。
ToDoをやるうちに、新しいアイデアや糸口が見つかったりするものです。
まとめ
進行中のプロジェクトを引き継いだ後任PMは、とにかく腹をくくってどんな困難にも前に進もうとするタフな精神力が必要です。
この記事を見て、不安に思ったかたもいらっしゃると思います。
しかし、苦労が多い分、プロジェクトをやりきったときには、何とも言えない充実感、解放感を味わうことができます。
このときの経験はきっとご自身の財産となることでしょう。
ヒトは苦労した分、成長します。
もしあなたが同じような役割を担うことになったときには、本記事が少しでも参考になれば幸いです。
Discussion