プログラマの思索

最近、Redmineエバンジェリストみたいに見られて、あちこちでRedmineを導入する役割を担う時が多い。
その時に、気付いたことについてメモ。

【1】開発チームが初めてRedmineを運用する場合、必要なトラッカーを最初に洗い出す。
その理由は、開発チームが必要とするワークフローは何か、を見つけ出したいからだ。
ワークフローの種類がその開発チームが持つべき開発プロセスの種類に相当する。

ワークフローは「タスク」の1種類だけではない。
「障害」管理もあるし、「課題」管理もある。
普通は、タスク・障害・課題の3種類は、ステータスもステータスの遷移もカスタムフィールドも違う。

【2】ステータスが違えば、ワークフローは別に増やした方がいい。
僕は、開発チームのプロジェクトリーダーやメンバーにヒヤリングした後、ワークフローのアクティビティ図や状態遷移図を書いて、このイメージで合っているか、を全員に確認する手法を取る。

すると、ワークフローで何らかのプロセスの漏れが判明する時がある。

例えば、仕様に従ってコーディングした後、タスクを終了にする時の判断基準は何か？を問う。
すると、メンバーがリーダーへ単なる報告をするだけで、自分でチケットをCloseするチームがいる。

話を聞くと、リーダーは複数の案件を抱えており、メンバーの作業や彼らが抱えている課題をチェックしていない。
だから、勝手に自分の都合で「終わった」と判断するらしい。
普通は、そういうチームは単体テストもろくにせず、そのまま納品して、結合テストで全く動かないという事例がとても多い。
つまり、リーダーによる作業の受け入れ検証が全くできていないのだ。

同様に、オフショアに設計書を送ってプログラムを納品してもらうが、その受入検証を社内で行わずにそのままスルーしてしまうことが判明したこともある。
ワークフローを書いてみると、オフショアの作業を納品した後の受入検証ないしリーダーの承認というプロセスがなかったのだ。

上記の例は、いわゆる「Doneの基準」がその開発チームではあいまいであり、リーダーとメンバーの間で合意が取れていなかった事実があったことが、ワークフロー設定で判明したわけだ。
そんなザルのようなワークフローならば、品質も悪く、納期に間に合わない案件が多くなるだろう。

おそらく他チームや他の会社でも、Redmineのワークフロー設定をする時に、開発プロセスの欠点が見える化されるのではないか、と考えている。
なあなあでやっているチームほど、ワークフローに穴が多い。

【3】カスタムフィールドも、各チーム、各案件によって微妙に違ってくるので、トラッカーを別に増やす時が多い。
同じ「タスク」であっても、設計やテスト、レビューではステータスの遷移は同じでも、カスタムフィールドが異なる時がある。
その理由は、普通は、成果物一覧(設計書)、テスト結果報告書、レビュー報告書などの帳票が別途必要であるために、それら帳票の項目をチケットに追加して記録したいために発生する。

普通は、プロジェクトリーダーにヒヤリングすると、そのような帳票は顧客や上司に提出するために必要であると聞くけれど、メンバーは実はそんな帳票の存在を知らなかったりする。
プロジェクトに必要な帳票が明確にされて、チーム全員で共有できるようになると、なぜこんなトラッカーが必要になるのか、という理由をメンバーも理解してくれるようになる。

つまり、プロジェクトリーダーが報告用に作る帳票を見える化したことで、今まで隠されていた開発プロセスが明確になったわけだ。

【4】かと言って、ワークフローをガチガチにすると、運用が面倒になる。
僕の経験で、ステータスを10個以上に増やして、10個以上のステータスを遷移して初めて終了できるようなワークフローを見かけた時がある。
すると、そのワークフローでは確かに厳格に管理できるが、チケットの滞留時間が長くなるために、チケットの棚卸しの管理工数がかなり大きくなる。

特に、ITILを導入した運用保守では、インシデント管理・問題管理・変更管理などの各チームや各プロセスへエスカレーションする仕組みになってしまうため、どうしてもステータスが増えやすく、ワークフローも複雑になりやすい。

リーン開発が教える所によれば、チケットの滞留時間はサイクルタイムに相当し、サイクルタイムが長いほど、顧客に価値ある製品をリリースできる納期がどんどん長引くことを意味している。
つまり、残チケットが多すぎるバックログになっていると、顧客の要望が即座に反映されない糞詰まりのような開発プロセスになっているのだ。
だから、バックログに残すチケットはできるだけ少なくする方が、顧客の新規要望を素早く反映できるようになる。

リーン開発で出てくる「WIP(Work In Progress)」という概念によって、バックログに入れるチケットの総数にWIPという最大値で制限をかけて、バックログが大きくなり過ぎないようにする。

【5】Redmineのワークフロー管理は最終的には、システム監査における証憑になるだろう。
つまり、プロジェクト内で発生するすべての作業は、しかるべき変更管理に基づいて、申請・承認のフローがあり、プロセスが改ざんを起こすことはない、という保証にもなるはずだ。

チケット駆動開発の良い点は、ワークフローはチケット管理システムの一機能に隠れているため、メンバーやリーダーもチケットを流すだけでよく、あまり考えなくてもいいことだ。
ツールがワークフローを保証してくれているので、流れてくるチケットを粛々とこなしていくだけでいい。

ワークフロー管理とその設定には、開発プロセスの問題点を全員の目にさらしてしてしまう特徴があるのがすごく面白い。
他にも考えてみたい。