以前、私がよく書いていた日報です。
その日にやった事がリストアップされています。
| 日付 | 内容 |
|---|---|
| 12/26(金) |
|
| 12/25(木) |
|
| 12/24(水) |
|
以前は、この日報で上司にこんな事が伝わるだろうと思っていました。
- 私は毎日真面目に仕事をしている
- 12/26(金)などは特に多くの仕事をこなしており優秀だ
ところがこの日報は上司から０点を下されてしまいました..
何がまずかったのか？
上司が知りたかった情報は以下のものでした。
- プロジェクトが期日通りに終わるか/否か？
- プロジェクトが抱えているリスクはあるか/それは何か？
上司は私が真面目かどうかには興味がありませんでした。プロジェクトが予定通り進捗し、クオリティに問題なければそれで良いのです。
個々の実装内容にもそんなに興味がありません。複数プロジェクトを抱えている上司は忙しく、気になるものがあれば実際に動くものを見るなり、Git log を見るなり出来るでしょう。
上司が期待していた日報
上司が期待していた日報は以下のようなものでした。
| 日付 | 内容 |
|---|---|
| 12/26(金) | プロジェクトA 進捗 55/100 予定通り |
| 12/25(木) | プロジェクトA 進捗 52/100 予定通り |
| 12/24(水) | プロジェクトA 進捗 51/100 予定通り |
これなら 「1. プロジェクトが期日通りに終わるか/否か？」 が分かります。
これは少なくとも私が 「プロジェクトは期日通りに終わるだろう」 と考えている事が伝わります。
予定通りを判断する最初の見積もりは上司と握っておくべきです。ここが作業者個人の感覚ではいけません。報告を受けた側は本当に予定通りか？を確認する必要が出てきてしまいます。
最初の日報の問題点
最初の日報では順調に見えて、実はプロジェクトはこんな状況だったかもしれません。
最初の日報からはこれが伝わらないのです。
| 日付 | 内容 |
|---|---|
| 12/26(金) | プロジェクトA 進捗 25/100 間に合わない |
| 12/25(木) | プロジェクトA 進捗 22/100 遅れ気味 |
| 12/24(水) | プロジェクトA 進捗 21/100 遅れ気味 |
この日報を受けて上司はどうするか
予定通りなら何もしない、訳ではありません。(それはマネジメントではありません。)
あくまで部下が順調という報告をあげているだけです。本当にそうなのかには上司が責任を持ちます。
ただし、全ての進捗を確認する必要はありません。（上司は複数のプロジェクトを抱えているのでそれが難しい場合が多い）プロジェクトの優先度、難易度などを鑑みて、チェックすべき所を確認します。
遅れ気味になったら、もちろん即手を打ちます。何が問題になっているのを把握し、アドバイスしたり、人を入れるべきか、しばらく任せて様子を見て大丈夫かを判断します。
この即手を打てるというのが非常に大事なのです。〆切３日前に１日遅れていますと言われると、打てる手段はほとんどありません。〆切から余裕を持っての１日遅れであれば、作業者にも他のプロジェクトを迷惑をかけずに様々な手を打つことが出来ます。例え作業が遅れたとしてもそれを早めに報告してくれる部下には安心して仕事が任せられます。
プロジェクトが抱えているリスクの情報を足す
プロジェクトの進捗だけならプロジェクトの進捗表を見れば事足ります。
ここで日報にもう１つ 「2. プロジェクトが抱えているリスクはあるか/それは何か？」 の情報を足す事で日報の価値が上がります。
| 日付 | 内容 |
|---|---|
| 12/26(金) | プロジェクトA 進捗 55/100 予定通り 機能Bの実装に手間取っている予定より＋３日かかる恐れあり 機能Cを実装したがテストケースが予定より増えそう |
| 12/25(木) | プロジェクトA 進捗 52/100 予定通り 機能Cを実装したがテストケースが予定より増えそう モジュールDを受領 |
| 12/24(水) | プロジェクトA 進捗 51/100 予定通り 本日もらえるはずのモジュールDが貰えていない |
機能Bの実装に手間取っている予定より＋３日かかる恐れあり
機能Cを実装したがテストケースが予定より増えそう
本日もらえるはずのモジュールDが貰えていない
こういった情報は プロジェクトの進捗表からは見えてきません。 ほおっておくとある日突然進捗が遅れたり、進まなくなったりします。この報告があることで実際に遅れが出る前に手をうつ事が出来ます。
もちろんリスクが高いものは、日報を待たず即上司に報告すべきです
またリスク情報はそれが解消するまでは記載し続けたほうがよいです。
日報で報告するメリット
リスクが低く、直接報告する程ではないと考えるものあります。
- 遅れるかもしれないが、何とかなりそう
- 遅れるかもしれないが、数時間程度
日報であればこういった情報も記載しやすく、少なくとも１日以内に共有する事ができます。
- リスクが低いと見積もっていても、ベテランから見ると実はリスクが高い事があるかもしれない
- 低リスクでも数が増えていくと大きな負債につながる事もある。分かっていれば早い段階から時間をかけて対処する事ができる
- 日報が誰でも見られるものであれば、同僚などからもアドバイスが期待できる
まとめ、日報には未来の情報を書こう
最初の日報にあった情報
- 作業者の作業ログ (現在の情報)
改良された日報にある情報
- プロジェクトの成否 (未来予想)
作業ログを日報に書いてはいけないという事ではないのですが、情報の価値からいうとプロジェクトの成否の方が高いです。
作業ログというのは現在完了したという、現在の情報です。
対してプロジェクトの成否というのは、今後どうなるかという未来の情報です。
現在の情報というのは、調べれば分かるものですが、
未来の情報というのは、確かな事は誰にも分からず、ゆえに価値が高いのです。
経営者は未来の情報を必要としている
今回の日報は、プロジェクト成否という未来情報でしたが、もっと出世して経営者に日報を送る場合でも同様です。未来に関する情報の方が価値は高く、立場の高い人ほどその情報を欲しています。同時に正確な裏付け、信用が必須ですが、そういった情報を送れると喜ばれると思います。
- プロジェクトによる会社への売上貢献予想
- ツール採用による会社への利益貢献予想
- 人員採用や福利厚生導入による貢献予想