プログラマの思索

Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。
トラッカーについて考えたことをメモ。
ラフなメモ書き。

【1】Redmineのトラッカーはワークフローそのもの。
Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。
デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。
個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。

トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。
ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。
バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。
だから、それら作業はワークフローに複数人の担当者がやり取りするためのステータスが必要になり、その分複雑になる。

だが、トラッカーが難しいのはそれだけではないと考えている。
どれだけトラッカーを作ればいいのか、悩むからだ。
トラッカーの数を増やしすぎると、直感的に分からなくなるので、新人や途中参加の開発者に逐一説明しないといけなくなる。
レビューやリーダーの承認のようなステータスを全てのトラッカーに入れると、ワークフローが複雑になるため、逆に開発速度が落ちてしまう場合もあるだろう。

【2】トラッカーの基本的な作り方は二つあると思う。
一つは、同じワークフローは一つのトラッカーに揃えること。
もう一つは、プロジェクトで必要な帳票のレイアウトに合わせること。

前者については僕も失敗した経験がある。
Redmineを初めて運用した時、「新規開発」「仕様変更」「リファクタリング」「バグ」「管理」などのトラッカーに細分化していた。
作業の種類ごとにワークフローを作った方がやりやすいのではないか、と思ったからだ。
でも、バグなどの一部のトラッカーを除いて、殆どが同じワークフローになっていた。
実際は、「新規開発」を新規に発生した作業の意味で使っていたから、それ以外のトラッカーはあまり使われなくなった。
だからその後は、「タスク」というトラッカーで一つにまとめて運用するようにした。

この経験を通じて、ワークフローにもファウラーの言う「知識・操作パターン」が当てはまるのだと気付いた。
つまり、「タスク」のインスタンスには「新規開発」「仕様変更」「リファクタリング」「管理」などの作業があり、それらインスタンスを抽象化した型が「タスク」になるのだ、と。

「知識・操作パターン」は抽象的で分かりにくいOOAのパターンの一つだが、クラスとインスタンスの関係と考えれば、インスタンスがいくらあっても、その本質はクラスにあると思えばいい。
同じワークフローのトラッカーがたくさんできてしまった時は、操作レベルではなく一つ上の抽象化レイヤーである知識レベルでは何に当たるのか、を考えるとよいと思う。

【3】後者は、「課題」と「QA」の違いだ。
僕がいたチームではチケット起票に慣れているメンバーが多かったので、顧客確認が必要な質問は「課題」、設計者に確認が必要な質問は「QA」で分けていた。
「課題」も「QA」もワークフローは同じだが、「課題」にはExcelの課題一覧から抽出した属性をカスタムフィールドとして追加していたから、「QA」とはチケットの形式が異なっていた。
Redmineでは、プロジェクト単位でトラッカーをアサインできたり、プロジェクト単位でトラッカーのカスタムフィールドを追加したりOFFにすることができる。
だから、課題一覧のフォーマットから「課題」トラッカーをあらかじめ用意しておくが、各プロジェクトで必要なカスタムフィールドをチェックして、自分たちの課題一覧を作れるように運用した。

マネージャや顧客は課題一覧、障害一覧、作業一覧のような帳票のレイアウトにとてもこだわる。
彼らの要望をそのまま引き受けると、チケットのカスタムフィールドがかなり増えてしまい、逆にチケットの入力が億劫になってしまうこともある。
だから、必要最低限の属性をチケットのカスタムフィールドとして付与するように調整した方がいいだろう。

この経験を通じて、同じワークフローでも帳票(課題一覧、障害一覧など)に応じて、トラッカーを切り替えた方が運用しやすいと考えるようになった。
この考え方は、DOAにおける画面や帳票から項目を抽出してテーブルを正規化していく考え方に似ている。
課題一覧は「課題」トラッカー、障害一覧は「バグ(障害)」トラッカーのように、帳票単位にトラッカーを作った方がいいと思う。
帳票の導出項目は、基本属性から計算できるようにRedmineのプラグインやExcelマクロを上手く使って、チケットの属性から省くようにした方がいいと思う。

すると、実際のプロジェクトではどれだけの帳票が存在していて、どのように使われているのか、を分析する必要があるだろう。
その分析作業そのものが、ERP導入時の画面や帳票の精査であり、Fit Gap分析にもつながる。
ソフトウェア開発の分析作業そのものも、我々が受託開発しているWebシステムの要件定義に似ているのだ。

トラッカーについては研究の余地がまだまだたくさん残っているように思っている。