週報をなるべく手軽にシステム化してみる

ウチの会社にもご多分に漏れず「週報」と言うモノがある。
もちろん、上司としては直接関わっていないプロジェクトや、
離れた場所にいる部下の状況を把握するためには「報告書」のやり取りが必要だとは思う。
しかし、あまりにもウチの会社の報告書の実体はヒドすぎる。
と、言うわけで週報をシステム化したい。
ただし、なるべく工数とコストを掛けずに。

使用するシステムの選定

システム化すると言っても別にフルスクラッチで作ろうと言う訳ではない。
なるべくなら既存のフリーのシステムを利用したい。

以前、情報の種類によって管理に適したシステムは異なるって話をした。
Blog、Wiki、ITS/BTS（と呼ばれるチケット管理システム）それぞれの役割について
では、週報を管理するにはどんなシステムがいいんだろうか？

週報に記載される内容は（ウチの会社では）こんな感じか？

1. 日々起こった事実
2. 発生し、解決していない問題点、原因分析や対策
3. 直近の予定や今後の予測
4. 報告に対する上長のコメント

コメントを記載するためにはBlogかITS/BTS。
2の課題を管理する点がある時点でRedmineのようなチケット管理システムがいいと思う。
幸い、社内でRedmineの運用が始まったのでRedmineならすぐに使える。

システムの使用方法の検討

システムが決まったので、次にRedmineをどう使うかを考えてみよう。

Redmineで週報を運用する方法として、ぱっと思いつくのは以下の二つ。

1. 1回の報告書で1チケット
2. 「報告書」と言うチケットを1つ作り、毎週コメントの形で追記

報告書を書くだけならどちらでも問題はないが、
2の運用方法だと最新の報告内容がチケットの一番下になってしまい、
いちいち下にスクロールしなければ見られない。
1であれば毎週報告書をクローズするルールをきちんとすれば、
最新チケットだけ気にすればいい。
以上のことから1を採用。

運用ルールの検討

最後に週報を記載してからクローズするまでの運用の流れを考える。
現状の運用の流れからすると、登場人物はメンバー、課長、部長の3人。
状況を整理してRedmineのデフォルトのステータスと紐付けるとこんな感じか？

フローを図にするとこんな感じ。

部長が全ての報告書をクローズしなければならないのが若干面倒かもしれないが、
まぁ、ちゃんと全体に目を通していることをオープンにするためにも必要かな。
部長を含めない運用であれば、課長がステータスを「終了」にしてクローズすればいい。
こんな感じ。

プロジェクト内で発生した課題に関しては、
個別にチケットを作成して対応し、週報にその旨を記載する。
関連チケットとか設定してもいい。
そうすることで課題の解決漏れを防ぐ。

こんなトコかな。
後は実際に運用して問題点を洗い出してみるか。