Redmine を教えるということ

あれこれ「手練手管」を使い？、ようやく中堅社員向けの社内教育で Redmine を教えることになりました。受講者は「PJ管理の方法と、その実践的なツールの説明」を期待しているが、自分は「Redmineの布教」にしか興味がない... ってことはないです。ちゃんと昨今の PJ マネージメントの問題から紐解き、PM が楽できるのは PJ 管理ツールという論理で説明しています。
使い方とかの知識教育はあまり意味がない（各自やってくれ！）ので、以下の様な観点で話をしようと思ってます。

１．PJ 内の情報共有ステーション
とりあえず、PJ関係者は全員、知ってる情報は全て文字にして公開する。何か探す時には、redmine を見る。何かする時には、チケットを切る。No チケット、No ワーク。逆に言えば、redmine にない情報は、非公式であり、裏情報。メンバは知らなくても、文句は言われない。PM の考えや意思（メンバには不明な世界）よりも、チケットのステータスが全て。文句があったら、close チケットを理由を書いて差し戻せ...　導入する以上、これは守りましょう。それで、最新情報が確実にredmineにあるし、無ければ他を探す必要がない（無いこと決定）となります。基本的な共通ルールを持つことで、最低限の秩序が発生します。

２．ストック情報とフロー情報
過去の何らかのタスク情報は、ストック情報として１つのチケットに誰がいつ書いたか分かるように格納されます。もちろん記載粒度によりますが、何年前の PJ のタスクでも、ある程度は追跡出来ます。当時 PJ に関わっていた人だけでなく、全くの部外者でもチケット番号を伝えれば大体の情報が得られます。説明不要です。なんて楽なのでしょう。
今まさに生きているタスクの情報は、フロー情報になります。途中経過の情報であり、かつ「なぜ今、その状態なのか？」の情報が追跡出来ます。あるいは、次に誰が何をすべきで、なぜ止まっているのかも、おおよそ判断可能です。それ故、メンバに不調があっても、PJ の他メンバに比較的簡単に引き継げます。

３．タスク毎の小さな計画と、予実管理
良く、個人のTODO管理の話で「全てのやることを紙に書け」と言われます（自分はこれが苦手で、そこで止まったりしますが...）。PJ では、やるべきタスクを決めて、そのチケットを全部切ることが管理の始まりです。チケットを切る時には、必ず期日と「何がどうなったら close なのか？」を決めます。それらは細かく言えば WBS の１要素であり、担当者が責任を持ってチケットをクローズしますし、進捗会議はチケットの読み合わせをすれば、タスクの漏れはありません。もちろん予実は常に変化し、遅れることもあると思いますが、それを定期的な進捗会議でチケット単位でフォローできます。予実がズレた場合も、主にそれをフォローする／今後遅れないように考えるのは、PM ではなくまずはチケットのオーナーです。曖昧に PM が引き受けず、各自の自主性を求める事が出来ます。

４．変更管理
PJ の想定とは別に、お客様からの指示でタスクの優先度が差し替えられる事があります。スクラム開発の様にスプリント毎にキッチリバックログを管理していれば良いですが、通常の PJ は WBS での全体感で対応となります。もう少し粒度が細かく、オーナーもはっきりしているチケット単位で管理すれば、もし誰かにタスクを積みすぎても、本人から「これ、間に合わん」と自動的にアラームが上がります。チケット調整後の影響範囲も、メンバが自分で考えることになり、PM の気付かないクリティカルパスが見つかることもあります。最新の変更情報を、チケット調整の結果として、全員に伝わるのがポイントです。

５．excel／ファイル共有 との比較
自由度が高すぎて、何の制限もないexcelやファイル共有で、上記のルールを作って守ることは、非常に難しいと思います。何が最新だかわからない共有フォルダー、最後に誰が直したかすら怪しい excel シート。複数人でファイルを上書きして先祖戻りをしたり、更新の理由が解らなかったりと、暗黒時代とも言えるでしょう。
redmine は PJ 管理ツールとしては割と自由度が高く、利用者の工夫の余地のあるツールですが、当然チケット駆動開発としての「骨格」は存在しており、それが利用者の「当たり前動作」にも繋がって行きます。もちろん、チケット単位での排他動作も出来ています。