Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。
デブサミ2011では、[デブサミ]速報：2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。「チケット管理システム大決戦」というセッションは、デブサミ史上最大の観客数となったと聞いています。
なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか？
開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、「作業を適切なサイズに分割する」「優先順位をつける」「人をアサインする」という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
TracやRedmineのようなツールは、タスクをチケットという単位で簡単に管理できます。それぞれのチケットはメンバーによってトラッキングされ、様々なビューによって表示されます。ツールを導入するだけで、ある程度、プロセスが整理され、ユーザはツールによってナビゲートされます。
プロセスを柔軟に標準化するツールに、現場が期待しているのではないでしょうか？
私は、5年前にTracを使って以来、ずっと仕事でチケット管理システムを使っています。中でも、TracとRedmineの導入や運用ではいろいろ学ぶことがあったので、過去の経験などをふりかえりとしてここにまとめていきたいと思います。
SIerからの受託作業でTracを導入する
2006年末。当時、私はいわゆるSIerの2次受けをやっていました。そこは、アジャイルなどとは無縁で、使われない機能、固まらない仕様といった、バカみたいなあたりまえがあたりまえに振りかかる状況です。その当時のコンテキストは、以下のようなものでした。
- 研究開発に近いWebアプリケーション開発
- 画面数は100以上
- 大量の決まらない要件があるのにスケジュールの変更は認められなかった
- 一次受けのSIerの作業場で作業
- 一次受けとは比較的フラットに相談ができる関係
- メンバーは10名ぐらい。ほとんどが3次受けのメンバーで会社もバラバラ。スキルも高くなかった
簡単にまとめるとカオスですw。膨大な要件。時間はない。規模はでかい。人はしょぼい。ありあわせのように集められたメンバーでこの状況を戦うには、どれだけ効率的に働ける状況を作るかではないかと考え、カオスでありながらTracの導入を試してみたのです。
スプリント0
当時は、スプリント0とは思っていませんでしたが、以下の方法でレポートライン、開発プロセスを整備しました。
- 朝礼で今日やることを報告（毎日）
- ドキュメント作成よりホワイトボードで議論
- リーダーがアサインするチケット単位で作業、開発者はログを必ずつける
- 共通的な機能は自分が担当
MTGをやっている時間がもったいないので朝礼で共有を行います。はじめは「いろいろやります」といった共有をする人もいますが、わからないことに質問をするだけで、報告の精度は高くなっていきます。ドキュメントは、必要とされるものだけ一部の人間で作りました。開発者はコードを書くことに集中すべきです。
チケット単位の作業とログはとても重要です。単位に関してはとても難しいですが、当時は画面と工程で分割しました。
- 登録画面の開発
- 登録画面のテスト
- 表示画面の開発
- 表示画面のテスト・・・
最後に、共通的な部分は、自分やコアなメンバーが先回りして作りました。そうやらざるを得ない状況だったのですが、画面の大量生産をする現場の場合は、このやりかたがもっとも効率的だったと思います。開発者は、部品を用意することで、組み立て作業に集中できます。上のように画面と工程でチケットを分けたのも、この方法だと、どの画面もある程度同じぐらいの作業量（Agileでいうストーリーポイント）にだったからです。
その他、当時はSubversion、Trac、Wikiの整備を行いました。
プロジェクト開始
朝礼も起動に乗り、各自が自己的に作業を消化する形が徐々にできてきました。開発者が開発に集中している間に、要件などを詰める形となり、どんどんスプリントが回ります。当時、イテレーションなどの取り組みを入れていれば、もっと面白い形になっていた気がします。
本当に面白いぐらいチームは動きました。
問題の傾向とその対策
このやりかたがハマって、私はとても楽ができました。ですが、やはり細かい問題は発生するものです。
閉じられないチケット
作業内容が不明確な場合に発生する現象ではないでしょうか？この問題は、Redmineを使ってタスクを管理している今の現場でも発生しています。
作業内容が不明確な場合、チケットを切る側と、チケットをアサインされる側でゴールがずれてしまう可能性があります（Agileでいう終了の定義）。「本当はこうやってほしかった」とか「ここはもうちょっとこうできるだろう」とか、読み取れる人間もいればできない人間もいる。
この状況で、「ずっとできない」のが一番恐ろしい状態です。よって、会話が必要になってきます。私の場合、会話をもちかける側として、「何が問題だったか？」「どうすれば改善できるか」を議論し、お互いの認識をチケットの最後に記載し、新しいチケットを切るようにしています。ここで問題から逃げる人もいますが、この会話は逃げている限り終わりません。残念ですが、そういった場合にどうするのがベストか？は、今の私の課題の一つです。
更新されないチケット
Excelでタスク管理を行うこともできます。しかし、Excelの致命的な問題は、タスクの作業ログを記載しにくいところだと思います。作業ログを書けば書くほど、セルは大きくなっていきやがてスクロールができなくなるほどになります。
TracやRedmineはトラッキングに優れたツールです。
作業のはじめにやることをまとめ、終わったときにそのログを記載する。「うまくいった」でもよく、「思った以上に時間がかかった」でもいいので、作業のタイムライン上で発生したことを記載する。SIerの仕事をしている場合は、人の入れ替えは頻繁にあります。手離れのいい仕事ができるようになるのもエンジニアの仕事です。
私は、コードを共有することと同時に、作業を共有することもとても重要だと考えています。そのための朝礼であり、そのためのトラッキングであること。チケット管理システムを使うときには、これらの状況を説明し理解してもらうことが重要だと思います。
もし、この考え方に賛成できない場合はどうなるか？答えは簡単です。定期的にMTGで進捗確認をし、日・週・月といった単位で作業報告をする。タスクを箇条書きにしたうすっぺらい文章をたくさん書くことになります。きっと、それでもコミュニケーションロスが発生するでしょう。それでもやります？
顧客との協調
適当にしていましたw。
言い訳をすると、顧客側がMicrosoft Projectを使ったざっくりとしたロードマップを使っていて、より詳細な報告となってしまうTracは使い物になりませんでした。本当は、ストーリーなどの単位で見せていく形が良かったのかもしれませんが、当時はExportしたデータをProjectに流し込んだり、Tracの画面をフィルタリングしてレポート表示することで対応しました。
Viewをカスタマイズ出来るということはプロジェクト管理ツールにとっては重要な機能だと思います。Tracはその重要な機能が実装されていたため、改造することなく利用することが出来ました。
ただ、受託開発ということもあり、顧客、一次受けとの共有まではできませんでした。
Tracでよかったこと
当時、Redmineがあったのかもしれませんが、Tracのレポート機能が強力だったので本当に助かりました。優先順位ごとにチケットの色を変えたり、担当者別にまとめたり、開発者向けにいろいろ工夫できるTracはすごいなぁと思っていました。
また、WindowsPC一台で環境を作ることができるのもすばらしいことです。当時は、客先でサーバを借りるのは大変で、PC一台の調達は簡単にできたので、自分のPCや専用PC上で、Trac＋Subversion環境をよく作りました。プロジェクト終了後にTrac Lightingが記事で紹介されていて、環境面のハードルがさらに下がりましたね。すばらしい。
まとめ
人数を集めて一気に進めるプロジェクトだったのですが、その状況だとTracは最高の働きをしました。ちょっとの規律と、チケット管理システムがあれば、自然に開発プロセスが整っていき、開発効率は格段にあがります。
また、当時一緒に働いていた友人がいうは、自社でもTracを導入したそうです。友人が言うには、導入を上司にいってみたものの理解されず、一部で使っていたものが話題となり、最終的に全社的に使われるようになったそうです。チケット管理システムにはそういう力があります。
ただ、今回は危機的な状況でしたが、降りてくる作業をこなすだけの仕事なので退屈に感じることもあります。Trac導入は成功したのですが、開発者のモチベーションアップにすることはできませんでした。
しかし、それぞれのコンテキストにあわせ、適切なツールを用意し、リリーストレインに開発者を乗せる。そのツールとして、チケット管理システムはあなたの役に立つはずです。
*
次は、Shibuya.trac 勉強会10回で話せなかった今の会社でのRedmine導入についてもまとめたいと思います。
旅と子育てとアジャイルコーチのブログ「世界」 