タスク管理の方法

プロジェクト管理 Trac

12月から新しいプロジェクトに配属になった。
リーダーという役割なのでチームのタスクや各タスクの進捗状況を適時把握していく必要がある。今回、私はプロジェクトのタスク管理ツールに「TracLightning」を導入した。

■参考リンク

  1. Trac Lightningで始めるチケット式開発「電撃」入門
  2. 第1回 Tracをオススメする，これだけの理由

前回のプロジェクトで、リーダーである私の他、協力会社メンバー3人のタスク管理を「Trac」で行い、その便利さを体感したからだ。
だが、この「Trac」の導入について上司であるプロジェクトリーダ(以下、PL)から「このツールで管理するな。」と言われてしまった。
導入の根拠とメリット、このツールでは対応できない範囲について、つまり課題を把握した上で導入したことを説明をしたがPLの意見を変えることはできなかった。

彼の言う意見を整理してみると以下のようになる。

中止させる根拠

  1. 顧客からプロジェクトの課題提出を要求されたときに対応できない。
    1. Excel形式でエクスポートする方法がない。(現在、顧客と情報共有する課題一覧表はExcel形式が一般的なため)
    2. Excel形式でないにしろ、顧客側LANから開発チームLANのTracの情報を直接参照できない。
    3. Excelで課題管理表を別に作成するとして、Tracで管理している情報と二重管理になるから管理工数が無駄。
  2. 過去自分がこのツールを運用しようとして失敗したからこのツールは「使えない」と思った。

導入に関する批判

  1. 運用ガイドラインは作っているのか？
    1. いつまでに作るのか？それをプロジェクトの費用で作る気か？(作るなら家で作れ)
  2. おまえが(このツールが)面白そうだ、と思って遊んでいるだけではないのか。


彼の結論はこうだ。

結論

プロジェクト管理をするためには3つのドキュメントがあればよい。

  1. 課題管理表
  2. 問い合わせ表
  3. EVMスケジュール(≒ガントチャート)


これまでの経験の中で、PLの性格が「自分の言う通りに部下が行動しないと気が済まない」気質であることがわかっている。なので、「わかりました。運用を中止します。」と言って(表向き)引き下がるのが賢明なのだが、終電間際だというのに30分近くも「Trac導入の是非」について口論してしまった。
そういうPL自身が管理するプロジェクトで、「情報共有されない、仕様変更の経緯が不明、他人の作業が見えない、タスクの実施が漏れる」など問題が頻発しているからだ。つまり、彼の言う3つのドキュメントだけでプロジェクトは回らない。それを訴えたかった。

しかし、正論を強弁したり、議論をすり替えたり、一向に議論ができない。
こういう上司とは本当に仕事がやりにくい…。

さて、Tracを導入するにあたってはOマネージャーの指摘するようにいくつか考えなければならないことがある。

  1. 運用ガイドラインの作成、教育
  2. 課題管理表とTracでのタスク二重管理問題

1については早急に対応する必要がある。前回Tracを使った時は少人数だったため口頭での運用説明のみで、それを資料化していなかった。特に、2に関係するが、顧客提示用の課題管理表とTracで管理するタスクの住み分けを明確にしておく必要があるだろう。