真面目過ぎる人に情報のハブをさせることで起きるリスクよりチケットシステムに情報のハブをさせよう


混乱しているっていう状況は、誰が何をやっているかわからないということです。


誰が何をやっているかわからないから、仕事を出す方も仕事を受け取る人の負荷なんて知る手立てがないから次第に構わず投げるようになるんですね。で、出来る人や真面目過ぎる人がその人の責任感から何でも受けてしまうことになって、結果的にその人がハブになって余計に情報が集積されてしまう。一度集積し始めると、情報を持っている人に更に集積することになるから始末が悪い。そしてその人に依存してしまうことになるんだね。で、真面目すぎた人の張りつめた線が何かの拍子にプツンと切れてしまう。


そうした構造では情報は真面目過ぎた人に属人化されていることが多いからタスクや課題の一覧があったとしてもそれは過去形であることが多いもので。過去形と書いたのはある時期まではそれこそ生真面目にメンテナンスしていたけれどある時期を境にそれもできないよう状態になってしまうんですね。そしてそのプロジェクトは誰も全容を知ることが出来なくなってしまう。


やっぱり、仕事を出す方も受ける方もどんな仕事をして欲しいのか、仕事を受ける方もどんな仕事をしているのかを同じリポジトリに向かって仕事を出す方も受ける人も一人ひとりがそれぞれ違う情報を持っているのだからそれをリポジトリで共有することで人が情報のリポジトリになることを防ぐことが出来るようになるんです。


多くのプロジェクトは相変わらずメールだけでの情報のやり取りやexcelだけのWBSや課題一覧でやることが多いでしょうけれど、一人ひとりの情報を共有を実現するには向かないのは明白なんですね。メールじゃ、ぱっと広げて一覧で見ることは叶わないし、excelじゃあ誰かがたった1行情報を共有したくて入れたくてもファイルが管理単位になっているから更新したいタイミングが重なると競合状態が起きてしまい派生を生み、結局どのファイルが最新のマスターかわからなくなってしまうんですね。

混乱しているからこそ、情報は共有できるリポジトリにまとめたい。
混乱しているからこそ、情報のオーナが好きなときに最小単位で情報を更新したい。


なら、tracredmineのチケットシステムを使って、一人ひとりが持っている情報をリポジトリに更新し続ける方が幸せ。実際、そうした状況のプロジェクトメンバに、チケットシステムを見せると「いいなー。それ欲しい。」っていうもの。


人を情報のリポジトリにして壊すなんて馬鹿げていることだし、人に情報のハブをさせることはその人がリスクになってしまうことになるのだからそれをさせないということも大事なんだね。情報のハブは人ではなく、機械にさせればいいのだから。


 〔改訂〕Trac入門 ~ソフトウェア開発・プロジェクト管理活用ガイド (Software Design plus)

 Redmineによるタスクマネジメント実践技法