プロジェクトは課題解決をしなければならないが、チームは課題解決ばかりしてはいけない

プロジェクトは課題解決をしなければならないが、チームは課題解決ばkりしてはいけない

矛盾しているか、矛盾していないと思うか。

プロジェクトの場合、課題はプロジェクトの進捗上の障害であるから、解決しなければならない。

ことの起こりとして、課題はアクティビティの予実の較差や制約条件の取違もしくは前提条件の未達など、こう進められるはずだ、こう出来るはずだ、が実現しないと見込まれるか、実際、できなかったから課題になる。

であるから、プロジェクトの課題は解決しなければ、プロジェクトはQCDSのいずれかを達成できな可能性がある。よって、プロジェクトは課題を解決しなければならない。

一方、チームはどうか。課題解決ばかりして、なぜいけないのか。

業務の活動には、課題はつきもので、それは運用をしているから生じる。業務運用を設計したときのデザインがもともと悪い、チームの対外が変化して影響を受ける、チームの体制が変わるなど、運用は生き物である。

プロジェクトのチームではどうか。プロジェクトのチームなら課題を解決しなければならないのではないか。

一見、そう見えるが必ずしもそうではない。運用の不都合は改善した方が良いのは当然だが、（色々と課題になるくらいの問題が内在しているとはいえ）運用は回っているのである。

ではどうして課題解決ばかりしてはいけないのか。

それはチームが近視眼的な思考に縛られて、チームとしてのToBeを蔑ろにしてしまうからである。プロジェクトや業務のどちらのチームであったとしても、チームの活動として達成したい目的を持っている。それはプロジェクトの目的の達成だったり、チームのビジネスの目的を達成だったりする。

その目的を達成するために、チームとしてなりたい姿がある。それに近づくには、チーム全員で目的を理解し、同じ方向に進まなければならない。そのとき、手間の課題ばかり解決していると『なんのために』やっているか目的を見失う。

１件ごとの課題として認知するが、それを解決することで、チームの目的を達成できるかはまた別である。チームは、その課題を解決することでチームの目的を一番達成できる課題を解決した方が良い。つまり、チームの存在にとって、優先しなければならない課題であるか、それを選択する見識を持って挑む必要がある。

しばしば、ロールの帽子や目線や俯瞰などと表現される、アレである。