【PM経験者が語る】進捗報告のコツ
こんにちは、FUUです。
PM(プロジェクトマネージャー)になって、進捗報告の機会がかなり増えました。
正直、最初は結構苦戦しました。
恥もかいたし、会議に参加したくない日も度々ありました。
しかし、流石にこのままじゃにいけないと思い、ちょっと本気で進捗報告の方法を見直しました。
すると、報告相手ごとに報告の方法を分けることが解決のヒントになりました。
まだ、改善の途中ですが、現段階で進捗報告のコツを報告します！
意外と難しい進捗報告の３パターン
要件定義などに参加したりすると、調査や実装の報告相手が増えたりしませんか？
すると、一気に進捗報告が難しくなりますよね。
そこで、私が特に報告する機会が多い
PM・開発同士の報告
運営者・利用者への報告
全体会議での報告
の３パターンのシーンで報告を行うコツをお伝えします。
よろしければ参考にされて下さい。
PM・開発同士の報告
PM・開発者同士の進捗報告は結構密に取った方がいいと思います。
進捗だけでなく、不明点や疑問点などは、普段の会話や打ち合わせなどで確認しておきましょう。
しかし、進捗報告になって初めて疑問点をぶつけるのはNGだと思います。
ほとんどの場合は、会議内で解決できずに、ただ会議を長引かせるだけなので。
フルリモートなど、相談したい上司と面談する時間が取れない時は、バックログやスラックでテキストベースで相談する方法がおすすめです。
注意点として、ログを残すこと。
口頭での技術的アドバイスや設計方針って、意外と活かし方が難しいです。
先輩Aさんのアドバイスを元に設計して、社内でレビューを貰ったら先輩Bさんから全く別のアドバイスを貰うことは良くある話。
それが原因で、設計が進まなくなったことも何度かあります。
そこで、「先輩Aさんとこんな方針で設計することにしました。」
みたいなコメントをログに残すことで、設計に至るまでの経緯が共有できて、設計の作り直しなどが減ります。
運営者・利用者への報告
運営者・利用者への報告の場合は、「イメージ」と「スケジュールの認識」を重視しています。
現在、開発以外の方と進捗の会話をする時には、ほとんどの場合工数確認をします。
ただ工数を回答して納得していただけたら良いのですが、たまに「なんでそんなに掛かるんですか？」とやんわり聞かれることがあります。
その原因のほとんどは「イメージできていない」ことです。
例えば、申し込みフォームの１項目を変更するとして、項目によってはデータ型を変えなくてはいけません。
その時に、「DBのカラムの定義を変えなくちゃいけません」と言っても、ほぼ大変さが伝わりません。
一方、今回変更した1項目が登録されるカラムを調べて、他にカラムを参照・登録・更新している操作を調べて、「この操作にまで影響があるんですよ！」と伝えると、ある程度分かっていただけます。
このように、操作する時のイメージまで必死に伝えることで認識のミスマッチは減ったと思います。
さらに、気をつけるべきは「スケジュールの認識」です。
たまに、さらっとスケジュールを聞かれますが、開発側の認識としては
開発側=「実装が終わる日」
運用側=「運用をスタートする日」
と認識が違う場面が多々ありました。
運用をスタートするまでには、実装だけでなく、テストやレビュー、さらに実装前の仕様確認の時間も必要です。
しかし、運用側と話すときに「開発工数=スケジュール」で話しちゃうと
開発側=「予定通り」
運用側=「遅れてんじゃん」
という事態が起きてしまいます。
そのすれ違いが起きたまま報告を続けると、かなりお互いしんどいです。。。
報告を行う前に、この、「イメージ」と「スケジュールの認識」を共有しておくと、報告も結構楽に進みます。
全体会議での報告
全体会議で、社長をはじめとして他の部署が集まるメンバーの前で報告を行う場合は、「とにかく結論」がいいと思います。
特に、開発の内容って開発外の人にとっては「内容を詳しく共有されてもなぁ」と思うことがほとんど。
「結局これってできるの？できないの？」や「この開発は進んでるの?進んでないの?」と言う結論に対してスパッと答えることを意識した方が、お互いストレスなく会議を進めれました。
あとは、「運営者・利用者への報告」とほとんど一緒です。
報告が長引かない方法
進捗報告って短い時と長くなる時がいませんか？
相当ヒマな会社ではない限り、進捗報告は誰もが手短に済ませたいもの。
でも、長くなるのはなぜでしょう。
今回はその理由も含め
報告前の根回し
進捗が悪いところは正直に言う
1報告1タスクを意識
この３つのコツをお伝えします。
報告前の根回し
報告前に資料や設計書の作成など下準備が必要な場合がありますが、
私が一番大切にしている下準備が「根回し」です。
開発者同士の会議や全体会議などで、大きなプロジェクトの進捗報告や新しい何かを導入したい時、
まず、影響力がある人に相談します。
すると、いざ会議が始まって本題に入ると、プロジェクト説明の補足や手助けをしていただけたことが何度かありました。
進捗が悪いところは正直に言う
経験上、進捗が悪い場合、会議では"なぜ進捗が悪いのか"原因を追求する時間よりも
「進捗が悪い事実を認識してくれ！」と言う認識合わせの時間が長くなる傾向にあります。
そのため、進捗が悪い時には、まず進捗が悪いと正直に伝えましょう。
さらに、会議前にその事実を認識しておくと、報告では対策や巻き返し案も報告できるようになります。
まずは進捗の悪さを認める。話はそれから。
1報告1タスクを意識
これわ自分自身への戒めでもあるのですが、1報告1タスクを意識するようにしましょう。
会議の場では、その場で最終的な結論が出ない場合が多いです。
その時に、結局誰が何をするんだっけ?で終わることがあります。
この場合、次も同じ内容の会議になってしまいます。
これって、会議した意味がないから、一言で言うと失敗なんですよねぇ。
開発の時には確認するだけの内容が多かったのですが、PMになってからは1会議で何とか案件を前に進めないといけません。
となると、誰に振るのか、何をするのかをはっきりとしないと会議は失敗に終わります。
難しいけど、勇気を持って会議を成功させましょう。
進捗報告のための進捗報告にしない
なんだかんだ言ってきましたが、私にとって進捗会議の目的は
「進捗を共有して、協力を仰ぐ」ことだと思っています。
そのために、毎日開発メンバーや開発外の方にも必死に今の状況を伝えています。
しかし、時に進捗報告を行うことが目的となってしまい、報告のための準備に時間を割きすぎたり、進捗報告だけ行い次のアクションを見出せなかったりします。
この「進捗報告のための進捗報告」の会議は時間のコスパがかなり悪いと思っています。
「進捗報告」って私は今でも苦手です。
だからこそ、目的をかなり大事にしています。
進捗報告の目的を忘れずに、意味のある進捗会議を行いたいですね。