管理ドキュメント

Trac プロジェクト管理

今回は、プロジェクト管理用ドキュメントとして1つのツールと5つのドキュメントを中心に運用しようと考えている。

  1. Trac
  2. 要件管理表
  3. 課題管理表
  4. 問題管理表
  5. 問い合わせ表
  6. EVMスケジュール


かなり無難な布陣。
顧客環境にはちゃんとこういった情報を管理するグループウェアがあるので、わざわざExcelで管理する必要もないような気もする。

今後のためにも、どういうものを作成して、どう運用すべきか、自分でちゃんと考えようと思う。

Trac

まず、Trac。すべての情報の源泉としたい。
メンバーには、これまで使ってきた付箋ソフトのような感覚で使ってもらうようお願いしていく方針。
チケットの「分類」では、「個人」「要件」「課題」「問題」などを選択してもらう。


言葉の定義はちょっと迷うところでもある。
例えば、「障害管理」というカテゴリを将来的に追加したとして、「問題」とどう違うのか？と絶対聞かれる。
直感的に運用できないのは良くない。



課題管理表にも言えることだけど、作業開始日と終了日はいつやるかわかんなくてもとりあえずわからなくても
「予定」として入れてもらう。これルール。
開始日を入れないタスクは経験上、いつまでたってもやんない。結果、慌ててやるはめになったりする。


要件や、課題はそれに関連するメールが飛び交う。
この内、重要なメールの(本文の)コピーを、チケットの「コメント」に記録する。
チケットみれば時系列で決定事項がわかる、という状態にしておきたい。
ただ、仕様が頻繁にかわるような案件については、最新状態をなんらか別の方法で管理する必要がある。
とはいえ、源泉はこのチケットなので気にせずどんどん登録する。
どんどん登録してもらって、「Tracに馴染んでもらい」、「Tracを使うことが当たり前の事実」となったらこっちのもん。
あとは、先日の日記のコメントでいただいたプラグインで分類別に吸い上げて適宜各種管理表に転記する。


などなど、
こういう思いつきのエントリーをまとめて内部展開用にガイドライン作らなきゃ。
Tracユーザーのブログも探さないと。


他の管理表についてはまた別のエントリーで。

2008/12/07

写真 日記

大学時代の友人と久々に会うことになった。
彼は公務員をやっていて、念願かなって地方の役所から本省勤務になったラッキーマン。
ところが、毎日午前2時くらいまで働き続ける羽目に。そんなんだから、似たような処に住んでいるのに会うのは何年振りか。

超過労働手当の上限が決まっているもんだから、時給換算すると鬱になるって言ってた。民間だったら完全な「ブラック」認定。



さて、そういうわけで昼に(男二人)集まって上野動物に行ってみた。
自分が両生爬虫類館に行きたかったからに他ならない。


なにげにオカピがいる。キリンの隣にオカピ。
ズーラシアでしか見れんのかと思い込んでた。


キリンとオカピは見つめ合っていた。
が、彼らの目の位置から考えると、あれは果たして
見つめ合っていると言えるのか。謎である。


ゾウガメを見てたら、目の前のカップルが
男「これ知ってる？昔話の浦島太郎で、浦島太郎を運んでくれる亀いるじゃん。そのモデルになった亀。」
女「えー、たしかにこれなら人乗れるよねー。」


柵に取り付けてある看板には「世界最大の陸ガメ」と書いてあった。


男は「女に知識をひけらかしたい」願望が非常に強い生き物なのである。
知ったかぶったっていいじゃないか。
彼女がカマトトだったとしてもいいじゃないか。


私も男なので、すごくよくわかる。語りたい。
宇宙ヤバい！と、熱心に語りたい。
理解できもしない宇宙論を語りたい。
なんなら、ゾウガメが竜宮城に行ってもかまわない。


で、上野動物園〜国立科学博物館。
国立科学博物館は「地球館」と「日本館」の2館に分かれている。
「地球館」の2階には「たんけん広場」という、平均年齢10歳くらいのやんちゃなフロアがある。
もう30歳まで腰までつかってる男子2人が子供たちに紛れて科学の不思議に触れてきてみた。
すげー面白い。みんなで童心に帰るべき。
子供たちを驚かせない程度に童心に帰るべき。

動滑車で片手で自分を持ち上げてみて感動した。勿論、理論は知ってるけど実体験してみると楽しくて笑っちゃう。
入館時間が遅かったので1館あたり1時間の予定でプランを作成したのに、「たんけん広場」だけで1時間使った。
楽しみにしていた宇宙コーナーは10分くらいしか見れなかった。

近々再訪予定。

タスク管理の方法

プロジェクト管理 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で管理するタスクの住み分けを明確にしておく必要があるだろう。