前回(方法論は正しくなくてよい、大切なのは「使えるかどうか」)は、先が見えない「暗闇プロジェクト」では、プロジェクトマネジメントの方法論やフレームワークがかえって混乱を招く恐れがあることを紹介した。

 今回はその続きである。フレームワークは使い方によっては非常に有用だが、その有用さがかえって逆効果をもたらす場合がある。それを避ける三つのセオリーを紹介する。

セオリー1
フレームワークを使った「素早い仕事」に要注意

 大手コンサルティング会社からIT企業のB社に転職してきたS氏。叩けば響くような頭の良さの持ち主である。B社のマネジャーは期待を込めて、ある顧客向けプロジェクトの企画フェーズから、S氏をメンバーに加えた。

いつまで待ってもアウトプットが出てこない

 手始めに簡単な仕事を依頼すると、アウトプットが出てくるスピードが非常に早い。経験が不足しているので、そのまま顧客に提出できるほどの品質ではないにしても、ここまで仕上げてくれたらマネジャーとしては文句はない。

 しばらくして、マネジャーは少し難易度の高い仕事をS氏に依頼した。今回は少し時間がかかるだろうな、と思って待っていると、思いのほか早くアウトプットが出てきた。早すぎて不安になるくらいである。

 アウトプットを確認してみると、マネジャーの不安は当たった。内容が、ネットで少し調べれば分かる程度のレベルにとどまっている。経営トップが概要を把握するための資料なら良いかもしれないが、S氏が作ったのは顧客の担当者向けの資料である。こんな資料を出しても、先方から「今さら何を言っているのか」と指摘されるだけだ。

 マネジャーはS氏に対し、「明日までとは言わないから、もう少し細かい資料を頼む」と依頼した。すると、今度は1日や2日どころか、いつまで待ってもアウトプットが出てこない。