開発プロセスの型をツールで構築する #tidd

@daipresentsさんがRedmineを1000人のユーザで運用している事例をアップしていたのでメモ。
僕もこの規模まで運用したことはないので、とても参考になります。

【元ネタ】
受託開発でTracを導入してよかったことや失敗したこと | 世界 - daipresents!!

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - daipresents!!

Twitter / @kamatamadai: 導入から2年で1000人以上にRedmineを使わせる楽天の実例。各種プラグインが参考になる / Redmineが1000人のエンジニアに使われるまでのこと | 世界 - daipresents!! http://htn.to/yWM5HK

資料にもあるように、楽天で、9万個のチケット、900個のプロジェクト、1300人のユーザでRedmineを運用されている。
この記事で面白いのは、「開発プロセスの型をツールで構築する」ということ。

CMMIでもPMBOKでも開発プロセスやプロジェクトマネジメントの標準化が重視されている。
その理由は、開発チームごとの能力のばらつきを抑えて、平均の能力を上げることにあると思う。
しかし、プロセスの標準化の作業は実際はとても面倒だ。

標準化された手続きをこなすための膨大なマニュアルと大量の中間的ドキュメントが要求される。
更に、皆が決められた手続きを守るために、稟議書のような承認フローが必要とされる。
もっと身軽に開発したいのに、標準化を頑張るほど、開発の速度が遅くなっていく。

CMMIを推進する立場の品質管理部門やプロジェクトマネージャと開発チームを支援するPMOは、その標準化作業の先頭に立つけれども、普通は開発チームと利害が対立しがちだ。
開発チームにお仕着せのプロセスを押し付けるから、開発チームはそれを実際は嫌がる。
トップダウンで頑張るほど、現場は疲労していく。

Redmineのようなツールによるプロセス改善は、それとは逆でボトムアップによるプロセスの標準化を進める。
プロジェクト管理やソフトウェア開発の作業に必要なツールが用意されていれば、メンバーもチームもそのツールに合わせて作業すればいい。
鈴木雄介さんのスライド「Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場・ツール・環境篇」」にある主張「コトそのものではなく、コトの外側を標準化する」がそれを意味していると思う。
実際の作業(コト、トランザクション)ではなく、コトの外側(開発環境、プロジェクト管理に必要な環境)をツールで標準化することで、開発チームの手順をどのチームも同じようにする。
それによって、要員の流動化も可能だし、メンバーのスキルも底上げできる。

僕自身もチケット駆動開発を運用してみて、プロジェクト内部の作業が全てチケットにあがっていれば、そのチケットを引継するだけでいい。
新人はRedmineでのタスク管理やSubversionによるバージョン管理、障害管理のプロセスに慣れれば、ツールにはソフトウェア開発のベストプラクティスが実装されているので、自然にソフトウェア開発をチームで作業するスキルを身に付けてくれる。

又、@daipresentsさんの事例で面白いのは、アジャイル開発の概念をRedmineのプラグインでどんどん実現して実際の運用がスムーズだったこと。
特に、アジャイル開発は進捗管理のビューが優れていると言う指摘は面白い。
確かに、タスクボードは単なるガントチャートやチケット一覧よりも分かりやすいし、バーンダウンチャートはプロジェクトの現状を的確に指摘してくれる。
そして、アジャイルな開発をもっと実践するために、チケットをタスクカードからストーリーカードへ、ガントチャートからタスクボードへ昇華していったという言葉が意味深い。

タイムボックス的な開発を行うには、ある程度の粒度が揃った要件の束が必要だし、イテレーション単位の進捗を測るには精度の高い見積りが重要になる。
だから、タスク管理や要件管理の作業の精度が要求されてくるのだろう。
つまり、プロジェクト管理の質がどんどん上がっていったことを意味しているのだろう。

@daipresentsさんの事例では、史上最高のチーム、タスクボード、バージョンバーンダウンチャート、パーキングロットなどのプラグインが紹介されていて、非常に参考になる。
個人的には、Redmineのチケット集計機能はまだまだ不足していると思うので、もっと強化されていいと考えている。
もっとたくさんの種類のビューを用意して、現場リーダーは状況に応じてビューを使い分けてもいいはずだ。
進捗管理でもガントチャートだけではなく、バーンダウンチャートやカンバンもあるといいし、品質管理やリスク管理、要員管理でも色んなビューがあると便利なはず。

プロジェクト管理の各種の状況に応じて必要なビューは何があるのか、という問いを今一度精査し直す必要があるように思う。