進捗確認をやめると上手くいく
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。
このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。
誰かのプロジェクトマネジメントの参考になればと思います。
※ 進捗管理が不要という話ではありません
進捗確認の定義
このエントリでの進捗確認は下記の定義とします。
複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為
少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。
なぜ進捗を確認したくなるのか
プロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあります。この納期を守るために、進捗管理が必要です。そして、その手段の一つに「進捗確認」を取り入れる人も多いと思います。
ではそもそもなぜ進捗確認が必要だと感じるのでしょうか。
その理由の多くはPMの不安からです。
納期に間に合わないのではないかという不安を払拭するために、逐一進捗状況を共有させるわけです。
ただ、本当にその行為には意味があるのでしょうか？
進捗確認には時間がかかるうえ精神的負担が大きく、さらには何も生み出さない
進捗確認で忘れがちなのは、それそのものにかかるコストです。
メンバー・PMそれぞれの時間が取られるのは当然のこと、PMとしては気軽に聞いたつもりの「進捗どうですか？」という質問は、メンバーにとってはかなりの精神的負担を伴います。
タスクなんて遅れるのが通常ですし、とはいえ遅れていることを素直に報告すると怒られてしまうことも多々あります。
つまり、「進捗どう？」という単純な言葉を投げかけるだけで、メンバーの生産性を大きく下げる上、その質問に対して回答している間の作業は全て止まってしまいます。
さらには進捗状況が悪い時に「なぜ進捗が悪いのか」といった質問を投げかけるPMも数多く見てきましたが、この質問は本当に無意味です。
普通に仕事に取り組んだ結果として進捗が悪いわけで、詰めるような質問を投げかけられたところで答えようはありません。
PMが満足いく答えに辿り着くまでその問答が続くことはよくありますが、これは本当に時間の無駄です。その時間に少しでも多くの作業を進めた方が、プロジェクトは確実に前に進みます。
さらにはこの「進捗どう？」という質問は、下記のような事象を引き起こします。
正確な進捗を隠すようになる
作業の見積もりに嘘が増える
作業そのものの質が下がる
つまるところ、進捗確認に対しての恐怖ゆえに進捗を隠したり、よりバッファを積んだ見積もりにしたり、見た目の進捗を間に合わせるために質の悪い作業になったりと、本当に良いことがありません。
[補足]
進捗率という意味のわからないものを使っているプロジェクトがあったとしたら、即刻廃止してください。無駄です。進捗率の定義が出来ているならまだしも、その定義すらなく感覚でN％と会話しているチームをよく見かけますが、本当に意味がありません。
定量的な数値として90%と出せるようなタスク（ex. 100個のネジを作る作業で90個作り終わった状態）ならまだしも、そうではない場合は進捗率という言葉はなんら意味を持ちません。定性的な言葉はブレが多く、具体的な状態を何も示さないからです。
また、進捗率の定義があったとしても、あまり意味をなさないことには変わりありません。せめて「全体で10個タスクのうち7個終わりました」といった形で会話する方が良いです。
進捗確認をしなければならない状況をいかにして避けるか
上述のように、進捗確認にはマイナスの効果が大きいです。では、どのように進捗を管理していけば良いのでしょうか。
タスクの粒度を変える
まず大切なのがここです。進捗確認が必要なほどタスクの粒度が大きいことが一番の問題です。
ひとつのタスクの粒度は長くても1日、通常であれば半日程度で終わる量に分割すべきです。
タスクの粒度がどうしても大きくなってしまう場合は、そのタスクを細分化した子タスクを上述の粒度で作るようにしましょう。
そうすることで、そもそも進捗状況を確認するという状況がほとんどなくなります。タスク表を見れば状態がわかるようになるためです。
タスクの進め方を変える
進捗確認ばかりしているPMを観察していると、タスクを丸投げしているケースが目につきます。
丸投げせず、きちんとタスクを分割した上で、さらにはその内容や背景をメンバーに共有した上でタスクを進めるようにしましょう。
リスクを正しく管理する
進捗が遅れるケースの多くの理由はリスクの読み間違いです。
にも関わらず、プロジェクト開始当初にリスクの洗い出しをきちんと行うPMは稀です。PMBOKに書いてあるのに、です。
リスクが正しく管理されていれば、リスクとして想定された状況が出てきた場合でもきちんと対処できるようになります。（実現が難しかったA案ではなくB案を採用する等々も、リスクへの対処のひとつです）
進捗ではなく困り事を聞く
上述のリスクの話と近しいですが、メンバーには困り事を聞くようにしましょう。困っている状態というのは、「目に見えなかったリスクが顕在化した状態」と言い換えることができます。
適切にリスク管理ができて前もって全てに対処できていれば、そもそも困ることはないですからね。当然そんな完璧にリスク管理ができている状態なんてあり得ないわけで、だからこそ早めに困り事を確認しておく必要があります。困り事への対処、支援によって、結果的にプロジェクトを前に進めることができます。
ツールを活用して一次情報をとる
スプレッドシートのようなものでプロジェクト管理をするのは限界があります。WBS等は全体の概要把握には役立ちますが、日々の進捗の管理には不向きです。
その理由は、具体的なタスクの状態とWBS等がリンクしないからです。
例えば、「何か開発する→WBSを更新する」という流れがあった場合、更新忘れや更新までに時間がかかる等の状況は多々発生します。つまり、その間は正確にプロジェクトの状況を把握できていないことになります。
そうではなく、ソフトウェア開発であればGitHubのPullRequestの状態を見たり、チケット上でなされる質問のやり取りを見たり、一次情報にあたるべきです。そうすることで、より正確な状況が「誰かに質問しなくとも」把握できるようになります。
他にもいろいろな手段がありますが、他にも何かを聞きたい場合は個別にご連絡ください。チーム状況やメンバーのスキル等によって取るべき手段は当然に変わるため、そこを見させていただいたのち、何かお伝えできればと思います。
（記事公開後の追記）
思ったより反響があったので念のため追記。
この内容はどちらかといえば初心者向けです
どちらかといえば小規模プロジェクト向けで書かれています
大規模プロジェクトでは無理みたいな話は当然です。管理手法がそもそも違います。
自社プロダクトとクライアントワークでも管理手法は異なります
タイトルは多少の煽りが入っています
前半の例は、私が見てきた残念なPMの人たちを元にして書かれた空想物語です。良くない例として参考にしてください。
（追記2）
残念なプロジェクトにいた残念なPMなんですね、、、みたいなコメントを幾つか頂いたのですが、そもそもこれは私の話じゃなくて、良くない例を元にした空想物語ですので。。。
P.S. どうやっても二日酔いを防ぐプロジェクト管理ができません。なんでですか。
いいなと思ったら応援しよう！
