トラブルの種を見つけるタイミング

トラブルがないプロジェクトなんて見たことがない
大なり小なり、プロジェクトとして動き出せば、そのプロジェクト特有のトラブルは付き物で、トラブルを回避したりすることなんてできないものだ。トラブルも、最初はちょっとした課題くらいのはずだったのに、大したことないと思って、期限を遅く設定して置いたら、その直前になって、影響範囲が大きかったとか、根が深くて脂汗を流したなんて、見に覚えがあったりするのでは。

トラブルの種を見つけるタイミング
プロジェクトのトラブルは、それが起きる前はリスクであって、それを識別する(identify)タイミングは、2回ある。1つは見積時で、もう一つはプロジェクト計画を立てるとき。厳密には、プロジェクト終了まで、リスクコントロールをするから終わりまでだけど。

言葉にだまされない
リスクをコントロールするリスクマネジメントはとても言葉の響きが良いと感じていて、感じすぎるから言葉に惑わされるのではないか、という疑念があって、実は、警戒して使うようにしている。それで、周りの人が普段使っていると

「どれだけわかって使っているのかな〜」

と斜に構えて伺う。大体にして参考になることがあまりなくて、とても残念。

裸で突撃しないために
プロジェクトのトラブルは、リスクの予見と識別が肝であって、コトが起きてから何かするのは“裸で突撃”するようなものだ。“竹やり”さえ持っていないで。このような状況になる懲りない人たちは、往々にして、見積もりなり、プロジェクト計画なりを俯瞰して観ることをしないか、上辺だけをなぞって終わりにしている。その懲りない人たちは、決して、

「自分に指を指して、自分が当事者として厳しい問いかけをしない」

ものだ。だって、自分はかわいいものね。辛いのは嫌だもの。当事者のつもりで見積もり担当やプロジェクトマネージャに厳しい質問を投げかけるのだって、本当は面倒だし、“そこまで聞くの？”的なことだってある。だけど、

「聞かれないと考えないでしょう？」

なので、仕方なく聞くのである。
＃レビューイ各位、ご了承ください。

ココロの引っかかりに正直に
リスクを予見、識別する領域は、“時間、予算、品質、スコープ”の4つだ。それを構成する“人と物”でセンシングして、心に引っかかることがないか、違和感を持つことがないかを正直に自分に聞く。大概は、大したことがなくて、コントローラブルなことに識別されるが、まれに、やばいことを見つけられたりする。それを見積もり担当やプロジェクトマネージャと相談して、