基本的には「悪手」です。
ただ、稀に「必要悪手」になるケースがあるので、慎重な考察が必要です。
とはいえやっぱり結局は「悪手」なので、運用に用いる場合、限りなく慎重に扱う必要があります。
…っていう前置きを山盛りでおかなきゃいけないようなお話を一席(苦笑
いつものごとく笑覧くださりませ。
まずは「防御的プロジェクトマネジメント」の手法を簡単に説明あるいは定義しましょう。
プロジェクトにかかわるメンバーを、大まかに「身内」と「それ以外」に切り分けます。
大雑把「自分の管理下にいる人間」が身内、となります。それ以外は、それ以外。
で、「それ以外」が存在するあたりから予想できるとおり、この手法を選択するのは「プロジェクトの最終責任者たるプロジェクトマネージャ」ではなく、「プロジェクトのある１部分(大抵は、システムないしデザイン)を担当するプロジェクトリーダクラス」です。
稀に「プロジェクトマネージャ」が選択する場合、それ以外とはおおよそ「クライアント＋ステークホルダー」になります。
この手法の基本は「身内のタスクをすべて明文化する」ことにあります。
あらゆるタスクは「明文化された指示に従ってそのとおりに行い」、一切の「明文化されていないタスクについては着手をしない」のが、基本にしてすべてです。
一見「ある程度的を射ている」ように見える、と思う人もいるかとは思うのですが。
実際問題として「プロジェクト」は事実上すべてが「未知との遭遇」なので、どうしてもある程度「相互の協力」が不可欠です。
が、防御的プロジェクトマネジメントではそういった「曖昧なタスク」の一切を許しません。
ぶっちゃけますと。
「防御的プロジェクトマネジメント」を選択した瞬間に、ほぼ確実にプロジェクトは崩壊します。
理由は比較的簡単で。そもそも「すべてを見越せる」ような状態が不可能である以上、相互の協力は不可欠なものなのですが、「防御的プロジェクトマネジメント」には、その「相互協力」が存在しません。
「気付いた問題点を教えてくれ」と言ったところで、帰ってくるのは「問題点が明確になり、それがうちのタスクであることが明らかになりましたら、指示を、文書でお願いいたします」というみもふたもない反応です。
ちなみに「問題点を調査、気付いたものを報告する」というタスクの場合。
どう言葉を飾ったところで、平たくならすと「問題点の基準が不明瞭なので命令は受け付けられませんでした」で終了。
基本的に「一切の協力的姿勢を拒否する」のが基本なので、その辺に期待をしちゃいけません。
ひとつにはいわゆる「さらりまん」な方々がチョイスをする手法で。
とりあえず使えないものは、使えるようにするか使えるのと交換するか、ってのが定石です。
まぁこの辺は、どの角度かは置いておくとして、ばっさりこんと。
問題なのは「やむを得ず、防御的プロジェクトマネジメントを選択せざるをえなくなる」ケース。
これが「必要悪手」になる可能性がある原因。
「防御的プロジェクトマネジメント」を選択した場合のメリットははっきりしていて「瑕疵範囲が明確になります」。
言い方を変えますと「上流の設計や営業の放言安請け合いや政治的あれこれその他プロジェクトを失敗させる要因のすべてを現場に100%瑕疵で押し付ける、という、極めて稀な*1事象」に対する保険をかけることができます。
…まぁ見方を変えると「ケツまくりに入ってる」だけなので、やっぱりプロジェクトは成功しませんが。
この場合「身内を守ることができる」という、明確なメリットが存在します。
基本的に、「防御的プロジェクトマネジメント」は、悪手です。
少なくとも「プロジェクトに対して、明示的に失敗の方向に導く」ことになるという点において。
しかしそれでもなお「周りの魑魅魍魎や品性下劣なモノ」を前提に「必要悪手」として「用いざるをえない」瞬間ってのもまた、存在します。
…「そんなのは必要ないよ」と朗らかに言える日が、いつか来るとよいのですが orz
*1:察して…お願い orz
