Architect's Log

I'm a Cloud Architect. I'm highly motivated to reduce toils with driving DevOps.

私が日報を書く8つの理由

私は特に指示がなくても、毎日日報を書いてプロジェクトメンバーにメールで送信しています。

それはプロジェクトメンバーのためでもプロジェクトリーダーのためでもありません。自分のためになるからです。

理由を書く前に、日報のテンプレートを晒しておきます。

テンプレート

お疲れ様です。○○です。
本日の作業を報告します。

<連絡事項>
・・・

<問題点>
・・・

<本日の作業>
【プロジェクト名】
■タスク名
 →完了。 

【プロジェクト名】
■タスク名
 →仕掛かり中。

<明日の作業予定>
【プロジェクト名】
■タスク名

<明後日以降の作業予定>
【プロジェクト名】
■タスク名

<本日の作業時間>
8.0h

日報を書く理由

タスクの棚卸し

日報を書くことにより、必然的に残タスクを把握することになります。

問題報告の判断のプロセス自体をなくす

若い頃は、問題が発生すると冷静な判断ができず、報告が遅れ叱責されることが度々ありました。これを防ぐには、報告をすべきかどうかの判断のプロセス自体をなくしてしまえばいいのです。

日報を書くことにより、その日に発生した問題点は漏れなく報告されることになります。

他のメンバーが問題解決してくれる

問題点を書いておくと、頼んでもいないのに他のメンバーが問題を解決してくれることがあります。

「退社します」宣言の代わり

「もう退社します。仕事をふらないでください。」言ってもかまわないと思います。その日の分のタスクを消化できていれば。

でも実際にこんなことを行ったら角が立つので、なかなか言えませんよね。

そこで日報です。日報を送ることによりプロジェクトメンバーにその日の仕事の終了を宣言することができます。

日々の作業ログ

「あの作業をやってもらったのっていつだったけ?」この質問に確実に回答できる人は少ない思います。

でも私はできます。日報が日々の作業ログになっているので、メールを検索するだけです。

モチベーションのUp

「納期のプレッシャー」や「顧客からの圧力」はモチベーションの源泉にはなります。ただそれが大き過ぎると精神が消耗し、次第に生産性が落ちていきます。私はこれを「負のプレッシャー」と呼んでいます。

日報を書くと決めていると集中力が高まるのを感じます。「完了タスク:1」よりも「完了タスク:2」あるいは「完了タスク:3」で報告したいと思うのが人間の性です。これは健全な「正のプレッシャー」と呼んでいいでしょう。

複数プロジェクトに参画している場合、トータルの負荷を認識してもらう

複数プロジェクトに参画している場合、プロジェクトAのマネージャーはプロジェクトBでの負荷を知らず、一方でプロジェクトBのマネージャーはプロジェクトAでの負荷を知らない、ということが得てして起こります。そのためトータルの負荷が作業者のキャパシティを超えてしまうことがあります。
日報を両マネージャに送っておけば、そのような状況は起こりにくくなるでしょう。

ふりかえり(2011/10/28追記)

日報を書くということは「ふりかえり」を毎日行う必要があります。言い換えれば「日々の作業は全て日報という成果物に集約される」とも表現できます。

でも一番の理由は、

404 Blog Not Found:酒場の若者達(ナゴヤ)

ホワイトカラーの世界では、仕事は報告があってはじめて完了したものとみなされる。少なくとも「まともな」職場ならそう教える。

ってこと。