Trac使った、プロジェクト管理

　別にレビューじゃないけど、下記の本へのメモ２回目

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド

　こちらの本を買って、Tracを使っています。自分はこの本で紹介していた「Trac Lightning」を使い、直観的に使うことができるのでほとんど本は参考書程度に見るぐらいです。使い始めてまだ運用方法に迷いがありますが、なかなかいいツールです。そこで、実際にはどんなことに気をつけたらいいのか、もしかすると本に書いてあることだったりしますがTrac初心者の自分の経験をもとに考えてみました。もしかすると下記は今の自分に合わせて書き換えたりするかも知れません。ご了承ください。

　自分が感じたのは、よく言われるようなチケット駆動というよりも「チーム運用基盤としてのTrac」でした。アプリケーションの基盤がしっかりしていないとその上で構築する人たちが迷ったり品質が一定にならなかったりするように、プロジェクトを運用する上での基盤としてTracの必要性です。なので下で書くのはよく言う「チケット駆動のTracの使い方」ではありません。Tracを使う上でその周辺でやった方が良い事をまとめています。
　

　Tracは使ってみればいい道具ですが、いい道具って気がつくまでは「他人の歯ブラシ」みたいなもんです。生理的に受け付けられない。それまでの自分のやり方や、今までやってきたExcel方眼紙などの道具から見れば他人が使っているちょっと生理的に受け付けられないやり方です。それをどうやってチーム内に浸透させ、情報をそこに集めるか、（飛躍しますがチーム内の見える化ですね）

　あとは、チーム内で「いいよ！」ってなっても、チーム外に認識されないと「わからないからこの形式で報告しろ！」ってなって、管理の二重計上が始まる。そして地獄の一丁目に連れていかれます。（おめーらのTracとやらの情報とこの報告書の結果は0.25人日合ってねーじゃないか！ちょっと反省部屋に来い！みたいな・・・）奴らはわかっちゃくれない。課題を丸裸にするにはこんなにいい道具なのに・・・って「チーム外への見える化」が必要ですね。

　チーム内、チーム外をTracをインターフェース（境界）としてつなぐ方法が難しいのかなと感じました。すごくいいフレームワークでも生で使わせると評価が二分しますよね。そのフレームワークが肌に合う奴と合わない奴とで。あれと同じ。フレームワークを使うためのユーティリティ、基盤なんかを作って、仕事を平均化する作業に似ている。これ自体はフレームワークと関係なくてそれを使うための周辺の作業ですよね。そこが難しいけど面白い。

チーム内にすべきこと

• Tracのチケット運用（発行）に対する敷居を下げること。
  • とにかく疑問、質問、もやっと思ったこと、メモ程度のものでもいいからチケット化してみんなに共有する。実は同じことをほかの人も思っていたりして、他の人の作業の手助けになったりする。また、そう思ったということは後でプロジェクトに入った人は必ず同じ思考をたどる。

• 情報のバケツはいずれ整理される。
  • 整理されずに書かれたものも、何度も見たり、Wikiなら更新したり、チケット通しのリンクをつけて行ったりするうちに、少なくともチーム内では情報の整理が進みます。これはあそこを見ればいい。このときはここを起点にして情報を追っていけばいい。って感じに。

• 製造ではよく使うSVNもみんな知っているわけではないと思った方がよい。
  • もしかするとCVSは使ったことあるけど・・・とか、VSSとか言うのは使っていたねぇ・・・なんて人もいる。たま〜に居るけどSVNが世界標準って誰が決めたの？それはあなたの標準？ならみんなわかんないよね。と言うことで「SVNって何」「簡単なSVNの使い方」「コミット方法」なんかはドキュメントとして作ってTracのWikiに貼っておく。
  • 最悪なのは「Webで調べろ。」「このURLを読め。」調べるのが技術者として当然なのはわかりますが、仕事としてやっている以上、速度を求められます。その人が調べて使い方を覚えるということは、他のチームメンバも同じ。例えばたった５人のチームで各個人が２時間使い方に迷っていたら１人日以上（１０時間）の工数が無駄になります。実際には影でもっとかかっていると思った方がよい。その工数がもったいないです。だったら資料を作って１時間みっちりレビューしたほうが最終的に工数削減になりますし、士気向上につながります。

• Trac自体への疑問をわかりやすいところに載せる。
  • TracのWikiに関しても同じ。TracのWiki表記についてはデフォルトでリンクがあちこちにあって参考となりますが、正直言ってWiki自体開発現場にはまだまだまだまだ・・・新しいものです。新しいページを作る方法なんかもどうやったらいいか迷うはずなので、簡単な作り方の資料を作ってTracのWikiに貼っておくのが良いと思います。また、メンバから上がったTracへの質問は、サイトトップページにまとめて資料を載せるとかしたほうがよいです。それがTracをチーム基盤の要素としていきます。

• Tracで管理している情報で新しい情報が皆に届く仕組み
  • RSSもいいですけど、要はちょこちょこ見るようになる雰囲気が必要と感じました。下でも書きますが、１日１回のリアルのミーティングでTracのチケット一覧を使って状況を把握し合うてのもいいと思います。

• 極力共有フォルダを使用しない
  • Tracに保存されるドキュメントと、共有フォルダに保存されるドキュメントで保存先が２系統になるのでは困惑します。ただ、全てTracで済むかといわれると難しいものがあり、以下のものに関しては共有フォルダが必要かなと思います。
    • いろんなサイトからダウンロードしたインストーラ
      • これは単純に容量がでかいから。以前、CVSから開発環境自体をチェックアウトしてEclipseを立ち上げて出来てる！って方法を模索しましたが、ダウンロードに１時間以上になったりして結局は共有フォルダに入れたほうが良かったって結論になったことがあります。
    • 外向きの資料・納品物（但しSVNから最新版のコピーをしとく。ここは絶対に更新しない。）
      • これはチーム外の人を迷わせない資料です。とにかくいつ見ても最新版が見れるってこと。

チーム外にすべきこと

• チームの問題管理の運用ルールをプレゼンテーションする。「このURLで状況が見れます」でもいいでしょう。関係者にはWikiをPDF化してしつこく見てもらうのもいいでしょうし、みんな大好きなパワーポイントで３枚ぐらいの運用ルールについて簡単なプレゼンテーション資料を作って、それだけを外向きに配布するてのも手です。（資料はこれしかない→必然的にTracのURLを見るようになる→Tracに慣れてくる）

• • 「ドキュメントの最新版？SVNから最新を落として！」
    • はたして現状としてこの一言でわかる人、行動に移せる人ってのはどのぐらいいるのでしょうか？SVN自体知らない方もいます。SVNは知っているけど単に経験がなくてやり方にまごつく方もいます。先ほど「SVNが世界標準って誰が決めたの？」って書きましたが、チーム内ですらそう思った方が良いということはチーム外には、簡単なSVNでの最新版の落とし方の資料（キャプチャは必要）ぐらいは作る必要があります。それで操作してくれるなら喜ばしいじゃぁありませんか。
    • または、チーム外向けに、プロジェクト全体の共有フォルダなんかの中に最新版を１日１回のペースで更新するって手もあります。バッチ作ってサービス化してしまえば、勝手に１日１回最新版にしてくれますよね。

• • サイト左上の画像をプロジェクトのものに更新すること。
    • これだけで結構注目度アップです。なければチーム内で作ってもいいですし、チーム外の偉い人に「ちょっと忙しいからさ！頼みますよ。確か絵うまいですよね」って頼んだりするのも手です。たぶんペイントなんか使って、変な画像を作ってきますが、これでその人もTrac関係者です。

• • Q/Aはちゃんと書式を作る。
    • 当たり前ですが・・・WikiをPDF化するプラグインもあるそうなので、Wikiできちっとした書式にしてそれをQAにするとか、WordのQAフォーマットを作るとか、とにかく外向きにはフォーマットをきちんとする。情報がわかりゃいいだろ！って言うのは内向きにしか使えません。再度言いますが当たり前ですが・・・

• • チケットの運用について
    • Tracのキモはチケットの運用ですが、次の点が鬼門かなと思いました。
      • １．チケットを書く基準
        • 当初、「気がついたら書く」「メモ的にも書く」としていましたが、だんだんチケットを切るべきか、他のWikiに情報として残すべきかに頭を悩ませるようになりました。しかし、はじめにリーダがチケットを切る基準なんかをガッチリと作ってドキュメント化するのもいいですが、これだと基準に沿った問題しか上がらずに、情報がどこかで途切れます。自分は今でもこの方法でいいと思っています。
        • 当人通しでひそかに話し合った情報。これも後追いでTracでチケット化します。チケット化するかWikiに書くかはプロジェクト次第だと思いますが、チケットに残ったほうが情報を見るところが少なくなり良いなと感じました。これは決定した瞬間は当人通しでわかってよいのですが、あとからプロジェクトに入る場合などに情報が消えてしまうので、必要だと思います。
      • ２．チケットを終わらせる基準
        • 正直本人でいいと思います。確認者が・・・とか言うのはある程度大規模なチームになってからであって、あまり気にする必要がないと思います。または、１日１回チーム内でミーティングを開いて、その時にクローズにするか継続案件にするかを決定するとか。はたまたは、気づいた人とか。結構クローズするのを忘れている場合もあるので。
      • ３．チケットから派生した課題の取扱い
        • これは、例えばＡチケットをクローズ時に、課題として派生したＢ，Ｃチケットをどうするかではなく、終わるＡチケットの扱いをどうするかです。実際にはＡチケットはクローズにしてしまうか、Ｂ，Ｃ　チケットがクローズのときにＡチケットをクローズとするのかということです。ＷＢＳの各項目が作業終了後に再度手をつけない（後戻りしない）というのが鉄則であるので新しい項目を作って対応するとか、問題管理表にて管理するのに似ています。後戻りすると工数の把握が難しくなりますよね。
        • 正直どっちでもいいと思う。状況次第。メンバーと話して（最終的にはリーダーが決定して）合意を得た後に、TracのWikiにTrac運用方法として情報を残すといいと思います。
      • ４．リアルな状況確認
        • 僕はTracを運用する上で一番これが大事と思います。Tracで情報は集まります。でも意外と見ているようで見ていない（覚えていない）のと、状況により作業に没頭せざるを得ない人はTracなんてそもそも見ません。他人の問題なんて関係ないです。しかし往々にしてそういったものが実は未来のその人に関係あったりします。リアルでの打ち合わせを行って、お互いに情報を補完するのが大切なんではないかなと思います。

Tracの情報っていつ必要なの？

　Tracの情報が本領を発揮するのは、プロジェクト運用中もそうですが、プロジェクト運用後、人がいなくなった後もだと思います。プロジェクト運用中にチケットをクローズした瞬間は、「なぜそうしたか」が分かっていていいのですが、別のチケット経由で同じ問題にぶつかったときなどに「昔もこんなことあったような・・・」なんてデジャブを感じたり、プロジェクトが終了して納品したあと、改修が入る際によく思うのが「この部分はなぜこうしたか」といった「Why」がほしい！ということです。開発当時の事情が分からなければ改良と思ってやるものも時として改悪になったりします。

　TracはそのWhyのみならず、開発当時のいろいろな情報をリンクベースで見えることにより5W3Hとして残すことに意義がると思います。ExcelやWordではそこまでできませんし、TracならWebブラウザ１枚で済みます。そういったチケット以外のメリットが見えてくるといいのかなと思いました。