プログラマの思索

Redmine運用の基本を再確認するために、@g_maedaさんの資料をもう一度読み込んだ。
ラフなメモ書き。

スポーツでも勉強でも仕事でも守破離がある。
慣れてくると、破離の段階に入っていくけれど、成長が頭打ちになる時がある。
そんな時に、もう一度原点に立ち戻り、守の部分からやり直すことには意味がある。
凡ミスが多くなる時は、基本を忘れて、基本を徹底していない時が多いものだ。

それはRedmineの運用でも同じように思う。
チケット管理の運用に慣れてきても、ちょっと運用から離れていたりして勘が鈍ると、割と忘れている。

上記の資料で、守の部分の箇所は下記だと思う。

（引用開始）
表計算ソフトで一覧表を作りたくなるような仕事をうまく使える。

難易度・低
課題管理、QA管理、インシデント管理
随時発生する課題を都度登録してどんどん処理していく形態の業務は適用が簡単。

難易度・高
プロジェクト管理
将来のタスクの洗い出しや、すぐには処理できない大量の課題の扱いには習熟が必要。

チケットは管理表の明細1行分に相当。
付箋と捉えてもよい

トラッカーは単なる分類ではない。項目やステータスを制御するもの。

トラッカーの設計＝入力フォームの設計

1チケット＝1課題

題名だけでも内容が伝わるように

説明欄では終了条件を明確に

担当者は、そのチケットに書かれた課題・仕事を任された人ではない
担当者は、現時点でそのチケットを対処すべき人

チケットの担当者は次々に変える方が良い

Redmineで仕事を進める考え方
仕事は原則チケット化
みんなでチケットを終了させて仕事を終わらせる
（引用終了）

つい最近、自分がミスしたな、と思った部分は、担当者を責任者に固定化してしまったこと。
本来は、担当者はボールを持っている人であり、キャッチボールでやり取りすべき。
責任者をチケットに持たせたいならば、カスタムフィールドで別で保持すればいい。

PJ計画でWBSを策定することばかりやっていると、そういうアンチパターンにはまってしまいやすい。

また、Redmineを運用する時に、チーム全員が積極的に利用する雰囲気を醸し出すことも大事だ。
プロジェクトリーダーは自分自身の管理を楽にするために使いたがるが、利用者の観点でもメリットが感じられるように、配慮すべき点はたくさんある。
もちろん、各メンバーがコミットする責任を持つ意識は必要だが、チーム全体でアウトプットを出すからには、メンバー全員で残チケットに積極的に対応して終わらせる、という意識も必要だ。

そういうメンバーの貢献意欲を引き出すための工夫もRedmine運用では必要だ。
いわゆるチームビルディングやファシリテーションのようなスキルも必要になってくるだろう。