プロジェクトの課題は顕在化する前に倒すということについての考察

私はかれこれ二桁年数程度のプロジェクトマネジメント経験を持つのだが、課題に対しての向き合い方に関しては周りのPM勢と比較しても慎重に行ってきた自負はある。

コツは「違和感を感じる気がするかもしれないと思った時点でその何かを倒す」というだけなのだが、実はなかなかに難しいし、とても抽象的な話である。

今日はこの辺りの、課題と違和感について深掘りしていく。

課題が顕在化した時点で既に負け試合

プロジェクトマネジメント観点だと、課題管理表とWBS、リスク管理表が三種の神器と呼ばれるが、課題管理表の出番が来た時点で負け試合だと思っている。

炎上プロジェクトの多くは課題が顕在化した状態であり、課題管理表には山のように課題が積まれており、これらを倒すことを消火と呼ぶことすらある。が、そもそも課題なんてものは無いに限る。

顕在化した課題があることで、判断にノイズが入ってしまい、健全なプロジェクト運営が出来なくなるからだ。

つまりは、課題に気を取られるあまり、平時だと行わないような判断をしてしまい、結果としてプロジェクトの進行を妨げてしまうことが頻発するのである。

炎上が炎上を呼ぶのはこれが大きな理由なのだが、火中にいると自分の狂った判断に気付けなくなる。

それ故に、課題が顕在化している状況で行うべきは2つしかない。

ひとつは、課題を倒すことだけに集中し、平時を取り戻すこと。

もうひとつは、全てを無理やりリセットすること。

通常は前者を選択し、PMが変わるタイミングなどでドサクサに紛れて行うのが後者となる。

ここで言いたいのは、課題が顕在化してから倒しても遅いということである。

課題が顕在化する→原因を突き止める→倒すというフローを進めている間に、平時では無い判断が増え、結果としてプロジェクト全体としての課題が雪だるま式に増えてしまうからだ。

ゆえに、課題が顕在化する前に倒す必要があるのだが、ではどのタイミングで倒すべきなのかというのが、このエントリの要諦である。

問題が発生した時点で倒せば良いのか？

課題と問題の区別はさておき、これでは明らかに遅い。

何かの問題が発生した時点では、既に対処療法しか行えず、ゆえに根本解決には一定の時間がかかってしまう。

課題として判断する前に倒すことができれば一手早いが、課題が顕在化してから倒すのと大差ない。

問題に繋がりそうな違和感の発生時に倒す？

これでも遅い。

違和感がある時点で問題発生は時間の問題であり、多くの場合に予防的な対処が間に合わず、結果的に問題が発生してしまう。

そのため、予防と対処の両方の工数がかかってしまう可能性も高く、工数の観点から見るとあまり美味しくはない。

運よく問題発生前に倒せれば予防的な対処の工数のみで済むためコストパフォーマンスが高く見えるが、ただのギャンブルと変わらない。

違和感が発生する気がしたタイミングで倒す？

ベストなタイミングはここ。

例えば、なんらかのあまり関係なさそうな噂を小耳に挟んだとか、メンバーがいつもより帰る時間が遅い気がするとか、新製品発表がありそうな噂がたったとか、そんな感じのかなりフワッとしたタイミングである。

この時点で違和感を言語化し、それに対してのリスクを考え、対処が必要であれば事前に予防的な対処を入れておく。

この時点であれば、多くの場合は「こんな気配があれば早めに報告が欲しい」といったレベルの予防的対処で十分であり、コストも無に等しい。

とはいえ、多くのPMがこのタイミングを逸してしまうのは、「これくらいなら大丈夫だろう」と、違和感を言語化する前に感覚を閉じてしまうからに他ならない。

違和感から逃げず、ひとまず立ち止まり、一手先を読んで考えるだけで、基本的には後手後手にならずに済む。

つまりは、リスクを日常的にアップデートしていくということ

プロジェクトのリスク管理は、なぜかプロジェクト開始前だけに行われるケースをよく見てきた。

とはいえこれは圧倒的な悪手で、「違和感を感じる気がした」瞬間にリスク管理表をアップデートし、それらのリスクについては少なからず一度は認識し、考慮済みにしておくことが望ましい。

そのために必要なことは、リスクを察知するための目を増やすことであり、これはすなわち日々メンバーと対話を積み重ねるということに他ならない。

PMの仕事の多くは雑談であり、そして、それだけで十分にプロジェクトはまわる。

-------

P.S. どちらかといえば本業のプロジェクトマネジメント話を書くとそれなりに真面目に見えるアカウントがこちらです。

Tweets by library_fit