4月から新人エンジニアになる皆さん、おめでとうございます。
新人プログラマ応援タグをつけたポエムを書けばcontribution稼げると聞いたので投稿いたします。
開発現場ではその日の作業を日報形式で提出するところが多いです。
1ヶ月目から差がつく日報の書き方のコツについてご説明します。
日報を書く理由について
日報を書く理由については様々あります。
その日の作業を記録したり、かかった時間を計測したり、進捗を報告したり、疑問や問題点を共有したりなどです。
もちろんどれも正しいですが、それらの多くは日報を読んで得られる副次的な効果に過ぎません。
日報を書く理由はたった1つです。
それは**「PDCAを回すため」**ということです。
日報でPDCAを回すとはどういうことか説明していきます。
ダメな日報
まず、日報を書く上で最悪なパターンを説明します。
それは「就業前にその日の作業を振り返って書く」ということです。
（残念ながら全ての日報の80％以上はこの方法で書かれています）
人間の記憶力は全く当てになりません。
就業前の時間帯にその日の午前中にやった作業を思い出せる人はほとんどいないでしょう。
「今日は 作業Aをやった ＋作業Bをやった ＋ 作業Cもやった」という積み上げ（加点方式）の書き方をする場合、
「日報を書く（ためにその日の作業を思い出す）」という無駄な作業が発生してしまうのです。
往々にして彼らは日報を書くのに30分も（しかも毎日）かかるそうです。
素敵な日報
ダメな日報から脱却するにはどうしたらよいでしょうか。
答えは簡単で「今日は 作業Aをやる 作業Bをやる 作業Cもやる 作業Dもやる」という日報を前の日に用意しておき、
就業前にその日できなかった部分を削って「今日は 作業Aをやる 作業Bをやる 作業Dもやる」の部分を提出する逆算（減点方式）の書き方にすればよいのです。
この書き方のメリットは「早く書ける」「詰まった時に軌道修正しやすい」など様々です。
これができるようになるだけで義務で日報を書いている
日報奴隷な人たちとは一ヶ月で差がつきます。
日報のコツ
PDCAの話から少しそれてしまいました。
PDCAを回すには、日報に必ず（御社のフォーマットになかったとしても）
その日の良い点、悪い点を毎日書いてください。
良い点も悪い点もなかったら、その日一日進化も退化もしていない素晴らしい1日です！
直訳すると給料泥棒です。
悪い点はたくさん出てくると思います。どんどん書きましょう。
・時間がかかった
・○○ができなかった
・遅刻した
良い点も頑張って書きます。
・▲▲が上手くいった
・今月の目標達成できた
エンジニアの世界は毎日大成功するわけではないので、良い点が書けない日も出てきます。
そんな時は、以前の日報で書いた「悪い点」の改善に挑戦して結果を書いてみてください。
先ほどの悪い点を改善した場合
・以前は時間がかかったが、やり方を■■のように変えて短縮できた
・前回の手順を残したので○○が簡単にできるようになった
のようになります。
とにかく小さな改善を毎日続けるのがコツです。
結局のところ小さなPDCAを回すことでしか大きなPDCAは回せないのです。
まとめ
前日に、その日の日報を完成させておこう
良い点と悪い点を毎日必ず書き続けよう
良い点には悪い点を改善したことを書いて小さいPDCAをたくさん回そう