トラブルプロジェクトなのであれば、緻密な管理は必要ない。

やっかいな状況に陥ったプロジェクトに呼ばれたときに、意外によく勘違いじゃないかと指摘しているのだが、

問題・課題や、遅延が満載だと、ついつい状況を詳細に把握しようとして、タスクを細分化し、WBSに細かいメッシュを入れて各人のTODOを全てデジタルにチェックしていこう、などど緻密な管理を目指そうとする人に出会うのだが、私は基本それには反対だ。

気持ちはわかる。だけど緻密な管理をしようとすると、必ず「管理のための管理工数」が増えて、破綻するリスクは高い。

ただでさえすごい遅れや品質不良を昼夜祭日問わず一生懸命対応しようとしている人からすれば、むしろ不愉快な話になりかねない。よほどその人たちに対してすごい成果をすぐに出してあげられるなら考えようもあるが・・・トラブルプロジェクトなのだったら、そんなすぐには緻密な管理での改革はできないと思うのだ。少なくとも私には無理（苦笑）。よほど上手で経験豊富な人じゃないと、できないと思う。

要点は、

緻密に管理するのでなく、作業の優先順位とアサインメントを調整する方が優先だ。確かにタスクは適切な大きさにはブレークダウンするが、それは「デジタルに」進捗をみたいからで、無理やり「一日」「時間」単位に分解する必要はない。「いつからいつまでに誰がどうやって」やるかを把握しておけばよい。

「経過」の把握も大事だが、無理に刻む必要なんかない。例えば、その日に予定していた作業が順調に経過したかどうかを「どうやって確認するか」の手順だけ明らかにしておけばいい。

課題も同様だと思っている。課題自体もタスク化して、WBSで一緒に管理すれば大丈夫。課題もまさに、「いつからいつまでに誰がどうやって」やるか、順調に経過したかどうかを「どうやって確認するか」を理解しておけばまずは十分。

品質は、レビューだ不具合だの分析・評価をしないわけにもいかないが、定性的に評価しても悪いわけではない。状況を集計して、傾向や原因を分析することは、できるのならやればいい。でも、できないのであれば、定性的でいいから根気強く毎日各所の状況をチェックして回るのだ。いろんな人の意見や状態を総合していけば、必ず問題・課題のあぶり出しができる。それの変化を毎日追いかけていくのだ。

トラブルプロジェクトの場合、緻密に管理するというよりも、「根気強く」何度も問題ありそうな箇所を確認しては、短期施策について指示や依頼を的確に行う方がよいと思う。それを丁寧に繰り返していくことと、「心を込めて」トラブルに巻き込まれたメンバー達に向き合っていくのだ。だから基本的には、それまでの管理手法を大きく変更したり詳細化するよりも、粒度にこだわらずに「デジタルに進捗をみる」だけのことだ。よほど目を覆いたいくらい管理方針・手続きが欠落していない限り・・・