プログラマの思索

Redmineはプロジェクトを横断して使うべきか否かという議論をTogetterにまとめた。
過去の僕の経験を踏まえながら、Redmineの運用スコープはどこまでなのか、を振り返ってみる。
ラフなメモ書き。

【元ネタ】
Redmineはプロジェクトを横断して使うべきか否か - Togetterまとめ

【1】当初は、メンバー3人で、短期間の受託開発案件をこなしていた。
その時、Redmineを導入して、Redmineの機能を一つずつ試しながら、アジャイル開発の実現方法を習得していった。
少人数のメンバーで1個のチームだけだから、イテレーションごとにRedmineの運用ルールを軌道修正して、アジャイル開発のプラクティスを1個ずつ試していけた。

一番の発見は「イテレーション・リリースバージョン・マイルストーン一致の原則」と「プロジェクトとブランチ一致の原則」だった。
「イテレーション・リリースバージョン・マイルストーン一致の原則」を実装したプラクティスが「小規模リリース」であり、「プロジェクトとブランチ一致の原則」から「プロジェクトのライフサイクル」「ブランチのライフサイクル」という概念の意味を体で体験できた。

TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索

でも、試行錯誤は結構あった。
僕が良かれと思ったトラッカーではステータスが足りなくて、実は、テスターが作業中であるステータスを作る必要があるとか、似たようなトラッカーをたくさん乱発して逆に混乱した時もあった。
前者は「足りないステータス」、後者は「乱発されたトラッカー」というアンチパターン。

とはいえ、1チームだけのRedmineは運用しやすかった。
アジャイル開発を自由に試すには都合が良かった。
運用ルール変更の影響範囲は、1チームだけだったから。

【2】Redmineの運用を大規模化したい、という意図はずっとあった。

Redmineの大規模化の壁: プログラマの思索

Redmineの複数プロジェクト機能を使えば、複数チームや複数案件のプロジェクト管理は可能だから。
でも単純に、大規模受託案件をそのままRedmineに適用するのは、しっくりこないだろう、というのは感じていた。

以前、Mantisを使った経験があり、Mantisには親子プロジェクトの機能があったから、工程単位にMantisプロジェクトを作って運用していた。
しかし、その運用は「工程単位のプロジェクト」というアンチパターンにはまっており、本番リリース前は良くても、その後の運用保守では、しっくりこなかった。

他にも、Redmineのチケット管理にWF型開発をそのまま適用して、Redmineバージョンを工程に割り当てる「工程単位のバージョン」のアンチパターンにはまった事例もみてきた。

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

WF型開発の工程をそのままRedmineに適用すると、チケット管理の効果が得られない、という経験があったから、僕なりに色々工夫した。
例えば、大規模案件では、各チームのタスク管理プロジェクトとは別に、CCB(変更管理委員会)が使う課題管理プロジェクトをもうけて、週1回は各チームリーダーが出席して棚卸する場を作ってみた。

あるいは、Rootとなる第1階層に事業部プロジェクトを作り、第2階層以下に各チームまたは各案件を配置し、親プロジェクトから複数プロジェクトを横断して進捗管理できるようにしてみた。

個人的には、約100人で約50案件のプロジェクトでうまく回せたから、たぶん、それ以上の規模でも運用可能だろうと思う。

【3】SIでは、大規模受託開発案件だけでなく、小規模な保守案件を1個のチームが担当してやり繰りする場合もある。

こういうチームでは、バージョンやロードマップを全く使わない「空っぽのロードマップ」アンチパターンをよく見かける。
彼らは、イテレーションまたはマイルストーンという区切りを実感しない場合が多いみたいだ。

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

だから、僕は、毎月の作業報告のタイミングでRedmineバージョンを設定するように運用した。
保守案件だから、月末にアクセスログやSLAの報告が必ずあるから、それらの目標に向けた作業を登録するとか、当月中にやるべきタスクを登録するように、メンバーに声掛けした。

その結果、イテレーションごとにVelocityを自然に集計できるようになり、毎月の作業予定量を把握しやすくなったから、イテレーションの意味が分かるようになったみたい。

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

また、小規模な保守案件をRedmineプロジェクトに割り当てるのは良いが、Redmineプロジェクトを階層化しない「サイロ型プロジェクト」アンチパターンもよく見かける。
だから、複数の保守案件をまたがった進捗管理がやりにくく、担当者の作業負荷や開発予定表を把握しにくいみたいだ。

だから、全ての保守案件のRedmineプロジェクトは、チームの親プロジェクトの配下に階層化させるようにした。
そして、Redmineプロジェクトに入れるほどではない中規模ないし小規模なタスクは、親子チケットでWBS化する方法や、Redmineバージョンにリリース対象機能を割り当てるパーキングロットチャートの方法を採用した。

個人的には、小規模な保守案件を抱えるインフラチームやソフトウェア保守チームこそ、Redmineによるチケット駆動開発は有効だと思っている。

【4】とはいえ、Redmineの運用が最初からうまくいったわけではない。
部署や会社を変わるたびにRedmineを入れて、チケット管理の運用ルールをWikiに書いて、運用を普及させようとしたが、どのRedmineでも、トラッカーやカスタムフィールドは全く違う。

Redmineのトラッカーやカスタムフィールドを一度作って運用した後、削除するのは非常に危険だ。
なぜなら、チケットの履歴が表示されなくなる可能性があるからだ。
だから、トラッカーやカスタムフィールドは野放図に増えてしまいがちだ。

特に、Redmine運用に慣れていない部署の場合、試行錯誤の段階で、あのトラッカーやカスタムフィールドは間違っていたね、と気づく時もあるが、その時はもう遅い。

でも、僕はそれでいいと思っている。
チケット管理の運用で試行錯誤するのは当たり前だし、試さなければ分からないことが多いから。

もし、Redmineを綺麗にしたかったら、新しいRedmineのインスタンスを作って、データ移行して作り直せばいい。
また、プログラマ上がりのプロジェクトリーダーが多く、マネジメントに詳しくなければ、チケット管理でたくさん実験してみたらいい。

Redmineによるチケット管理でプロジェクト管理を実験してみたら、アジャイル開発のプラクティス、PMBOKの9つのプロセスエリアの概念、ITILに書かれている運用保守プロセスの概念が自然に分かってくるはずだ。
Redmineで運用するのが目的ではなく、Redmineによるチケット駆動開発を通じて、それぞれのプロジェクトリーダーがマネジメントスキルを身につければいいのだから。