Trac運用の反省点、というより、それ以前の問題に対する反省

昨年、サブシステムの性能改善チームのリーダーとして2人の後輩社員と共に、とある大規模プロジェクトに参画した。
メンバー間の情報の連携、タスク指示には「Trac」を導入したのだけど、全然運用できなかったので反省点をまとめてみる。

Trac運用の反省点

１．運用する余裕がない。

　そもそもの問題点として、無茶苦茶な納期で上からの作業指示が来るものだから管理工数が捻出できない。チケット発行して、更新して、進捗管理して、とやるより、目の前にある作業をこなすことに忙殺されてしまった。　

よって、Tracは全然悪くない。Tracどうこうの問題ではない。
「納期が厳しいなら、リーダーの責任で調整すればいいじゃない。」
正しい。それは、確かに正しい。しかしながら、そのような傍から見ればもっともな申し立てが通じない環境は実際に存在する。経験上、大規模プロジェクトにその傾向は顕著に見られる。いくつにも階層化された指示系統を逆流することは想像以上に困難で、どこかで弾き返されてしまう。顧客に提示したマスタスケジュールは絶対であり、プライムの面子としてこれを遅らせることは余程の事情がない限りは出来ない。このようにして、末端には無数の屍が築かれていく。

　さて、そうした環境の中、リーダーとして出来ることは

成果物は必要最低限になるよう交渉する
上位のリーダーに要員を増やしてもらうなどの相談を行う

ぐらいしかなかった。もっとうまいやり方がないか、常に模索していく必要があるね。メンバーを守るのはリーダーの責任でもあるし。

２．Tracの効果を伝えられない。

　納期に余裕があり、きちんと管理工数が工面できていたと仮定して、思うように運用できていたかを考えてみる。

　おそらくは、こちらが期待する運用にはならなかったと想像する。それはプロジェクト参画当初の、Trac導入直後の様子から伺える。Trac導入のメリットとして、作業がチケット駆動となりWBSと対応させて作業の指示漏れが防止できることや、作業の進捗状態や履歴が把握しやすいなどが挙げられる。やや乱暴な言い方をすると、これは管理者視点でのメリットであり、実際に頻繁に更新するであろうメンバーにとっては面倒な作業が増えただけで、メリットをあまり感じられない。メリットが感じられないのだから動機付けが弱い。動機付けが弱いから、Tracの存在感が薄くなる。そして、段々更新しなくなる。

　メンバーに「ちゃんと更新しろ」と指示する事はいたって簡単なのだけど、根本的解決にはならない。たぶん、続かない。それどころか、「Trac嫌い」になる可能性の方が高い。

「Tracを使うと便利だ！」と体感してもらう、あるいは、理解してもらわなければ意味がない。プロジェクト管理を経験したことのある位のメンバーならば導入メリットを感じるところだろうが、若いメンバーに対してどのようにメリットを伝えていくべきかは考えていく必要があると思った。今後の課題。