くっ…

なぜ米国にいるときに売られていないのだ…

Buy.com
ASUS EeePC 900

課題管理考察

転職先である今の会社に入って、関わり方が異なっても相変わらず開発現場を渡り歩いているわけだが、特に目にしなくなったもののひとつにバグ管理システムが挙げられる。

BugzillaやMantis、TracやJIRAに代表されるオープンソース系プロダクトでは沢山目にしているBug/Issue Trackerも、いざ企業の開発現場に入ると、途端にExcelによる課題とその進捗管理表(票)になってしまって、毎回のように課題管理表はどういう書式で書くのか、という議論(もしくはこれで良いかという確認)になる。なんでそんなに皆Excelが好きなのか良く解らないが、そのような話になる。

勿論このようなことは前職でも頻繁に起きていたため、機会があるごとに管理システムを使いましょう！と推薦してきたわけだが、どうにも受け入れてもらえないことが多く、特別なケースを除いて浸透しなかった、というよりも使われていなかったように記憶している。

それでもまぁ、毎週の進捗会議で課題が見直されることでプロジェクトは回っていた。結局のところ、どういう形であっても課題管理がプロジェクトマネジメントの上で重要な項目として抜けていなければ問題なし、ということなのかもしれない。で、皆がそれを経験するために課題管理とはそういうものだと思ってしまう、と。

では課題やバグ管理用のツールを積極的に活用したらいったいどうなるのか？どうなっていたのか？
どうなるのか、というのは楽になるのか(ならないのか)、と言い換えても良いだろう。

チームが分割され、システムの足回りから業務アプリケーションまで次々に噴出する課題を管理するのは至難の業だ。この場合「管理する」というところがミソで、管理することは解決することとは少し違うように思うのである。

重要なのは、課題を解決するのはチーム構成員であり、それを管理するのはマネージャの役目であるということである。

マネージャは多数のチームが挙げてくる多数の課題管理表の全てに目を通し、技術的もしくは人的および時間的リソース、政治的課題を判別し、技術的な可能不可能とプライオリティと、商売としてのやりくりを考えた上で、すべての課題に対して効果的に対処するための指示を的確に出せているかどうか。または、的確な指示が出せていなくともそういった視点で管理が出来ているかどうか。(無論、課題管理のみがプロジェクトマネジメントでは無いわけで、彼もしくは彼女の仕事の一部に過ぎないことを忘れてはいけない)

プロジェクト自体は、課題の解決が随時行われることで進んでいくだろう。だが、管理が*うまく*出来ているかそうでないかは、プロジェクトの進捗とは別次元で捉えられてしまってはいないだろうか。

Excelでの管理は確かに手軽で便利なものである。だがこれが2枚、3枚と増えていったらどうなるのか。マネージャは本当に、自分の持つ時間のわずか一部を使って全ての課題を管理しきれるだろうか。毎回の印刷で無駄な時間と紙を浪費し、プリンタのジャムに付き合わされるのは一体どこの誰だろうか。毎週送られてくるメール添付ファイルに辟易するのはメールサーバだけだろうか。

大規模プロジェクトでチームが分割され、チームリーダという更なる中間管理職が設定されたとしても、マネージャの課題管理の責任は変わらない。「重大なものだけ自分に報告してくれ」というのはナンセンスである。課題は課題であり、すべての課題が進捗を左右するからだ。全ての課題に目を通す必要は無くなるかもしれないが、それは見えなくなっただけの話に過ぎない。

勿論、これらの問題がIssue/Bug Trackerで全て解決できるとは到底思わない。インストールや設定、カテゴリ作成、ユーザ追加削除などの使い方を覚えたり、ワーカーに報告のやり方をトレーニングしたりガイドを作成したり、果てはDBのバックアップを取らねばならなくなったりと、わずらわしいことこの上ない。だがこのツールの特徴とExcelの特徴を知った上で比較し、体系づけた上で、適材適所な課題管理の手法を確立するのもひとつの手ではないだろうか。