新社会人に意識してほしい！上司・リーダー・先輩が喜ぶ進捗報告の3つのポイント

喜早です。もう働きだして干支一回り以上経つのかと思うと、時の流れはあっちゅーまですね。

日本では学校を卒業し4月から新社会人になる方が相当数いますね。もう現場に配属されて業務に勤しんでいる方もいれば、まだ研修中という方もいるでしょう。当社でも毎年新卒採用を行っており、今年は約30人の将来有望な新メンバーを迎え入れています。目下、8月の現場配属に向けてムキムキになるためにみっちり研修に励んでおります。

さて、今回の投稿では、毎年新社会人のメンバーを見ている中で、多くの方が同じ苦労しているなと感じていることについて書こうかと思います。それは、上司・リーダー・先輩への「進捗報告」です。一方で、報告側が苦労している理由の一つに、報告を受ける側が何を求めているかをちゃんと説明していないというのもあるだろうなと思います。なので今回はその辺を中心に書いていこうと思います。

報告を受ける側は何を求めているか

私は業務ではマネージャというロールにあり、複数のプロジェクトを管理する立ち位置にいます。正直言って現場で仕事している方が好きなので、本当ならば、一個一個のプロジェクトにどっぷり入ってメンバーと一緒にプロジェクトを推進していきたいのですが、それをしていたら体が何個あっても足りません。

とまぁ余談はさておき、実際問題として自分自身がプロジェクトに深く関与することができない今の立ち位置で何を一番気にするかというと「プロジェクトになにか問題を抱えていることはないか、困っていることはないか」ということです。もし、問題を抱えていてプロジェクトの進捗が芳しくない場合には、それを立て直すための手立てを打たなければなりません。そして、プロジェクトの状況を知るには、各メンバーからの報告がほぼ唯一の手立てとなります。ここの情報を、自分が欲しい内容で提供してもらえるかということが、プロジェクト状況を正しく把握できるかの鍵になります。では、報告を受ける側はどんな情報が欲しいのか。ざっくりいうと「スケジュール」「ファクト」「見立て」の3つです。

スケジュール

「スケジュール」に含まれるものとしては、工程やフェーズ、マイルストン、特殊なイベント、リリース日といった日程や期間といった情報です。システム開発であれば、例えば、この日までに開発工程を終えてこの日から結合テストに入る、であるとか、この日にユーザーにプロトタイプをお披露目をするイベントがある、といったような内容です。スケジュールはプロジェクトにおける地図です。これがないと進んでいる方向が正しいのかどうかわからないので、タスクやテーマを持ったら粒度はどうあれ必ず計画する必要があります。

よく聞く話として、どれくらいかかるか見当がつかないのでスケジュール（タスクのエンド）が決められません、というものがあります。そういった場合でも、まずはドタ勘でいいので、調査観点や進む方向を決め、一旦の区切りの日付を打ち、まずはそこまでやってみる、という進め方のほうが効率よく進みます。ある期間での成果を踏まえて次に進むべき道を決めていけるからです。ゴールまで不透明なものの終わりを決める精神的辛さは十分にわかるのですが、でも逆に一旦でも終わりが決まらないとその後のアクションの手立てが建てられず、ズルズルと長引いてしまうことのほうが多いです。

ファクト

「ファクト」は、そのスケジュールに合わせて進めている作業の進捗を表す「揺るぎない事実」です。例えば、開発しなければいけない機能が10個合ったとして、それが今どこまで開発が完了しているのか、という情報や、次の工程に入るまでに準備しなければならないものが5個あって、うち3個まで終わっている、というような情報です。動画などをダウンロードする際に出る、XX%まで完了、というようなインジケーターと同じことをイメージしてもらえればと思います。ここは出来得る限り定量的な報告が望ましいです。例えば、画面開発であれば、全50画面中今25画面まで開発しました、というような報告だと状況が把握しやすくなります。

見立て

「見立て」はスケジュールとファクトに基づいた報告者自身の見解です。それ以外にもファクトだけでは見通せない現場の状況を踏まえた情報もここで加えます。実は、この「見立て」が状況の報告で一番難しいところでもあります。例えば、次のようなスケジュールとファクトの状況だったとします。

開発期間が残り5日
開発期間終了後の翌日から結合テスト工程に入る
残り5機能開発。これまでのペースでは1日あたりなんとか1機能開発できている。

このファクトを見たとき、報告を受ける側はきっと次の点を心配します。

開発期間終了までみっちり開発するとなると、翌日からの結合テスト工程の準備はできるのだろうか。
過去の開発ペースは1日1機能だとして、このあとに残っている機能も同じペースで進めることができるのだろうか。

報告をする側がこのあたりの「見立て」を持った報告ができることがベストですが、もちろんプロジェクト経験が少ない、または忙しくて気が回っていなかったりすると、この辺を意識した報告ができないこともあります。このあたりが「見立て」の難しいところです。

「見立て」が甘くても「ファクト」と「スケジュール」があればケアができる。

もし報告者がそのあたりを見据えた「見立て」を伝えられなかったとしても、「ファクト」と「スケジュール」を正しく伝えることができれば、報告を受ける側がそれらの情報から、前述のような心配点を伝えてくれるはずです。概してプロジェクト担当メンバーは目の前の仕事に忙殺されがちでなかなか周りを見る余裕がないことも多いです。リーダーやマネージャの仕事の一つは、客観的な立場からそのあたりの見落としをフォローすることです。なので、報告者は「見立て」とともに「ファクト」と「スケジュール」をしっかり報告してもらえると非常に助かります。

「スケジュール通りに終わります！大丈夫です！」と見立てだけの報告では、ほんとに大丈夫なのかの根拠がないため、言葉通り受け入れていいものか判断しかねてしまいます。また、例えばスケジュールに対して遅延が発生しているような場合「少々遅れていますが大丈夫です」という見立てを報告したとします。でも、どの程度までが「少々」かどうかは報告者と報告を受ける側で異なります。そこで「ファクト」が必要になります。報告者が「少々」と思っていた遅れの「ファクト」が、報告を受ける側から見たら「少々」ではない場合もあります。また、遅延を始めとするリスクは早くケアできるほど、リカバリのためにかかる金銭的コストやヘルプで投入する人数が小さく済みます。リスクを早期発見をするためにも「ファクト」と「スケジュール」を正しく共有することは大事なのです。

報告は「正直」に

最後にこれらの進捗報告を行う前提として意識してほしいことを。報告は「正直」に行うことです。プロジェクトは生き物です。当初立てたスケジュール通りや目論見どおりに行くことは殆どありません。トラブルや状況の変化が発生することは日常茶飯事です。最初からそれらにうまく対処できる人はなかなかいません。私も過去に沢山色んな人に助けられました。

とはいえ、タスクやプロジェクトには、必ず依頼主がいるはずです。その人々に迷惑をかけるわけにはいきません。最終的にはしっかりと終わらせる必要があります。そういった不確実なことが起きても助け合って対処するためにチームがあります。1人では対処が難しいことでもチームで当たれば大概はなんとかなるものです。それらに正しい対処をするには正しい状況把握が必要になります。そのためには報告は「正直」なものである必要があります。