チケット駆動開発が進むべき道part2～プロジェクト管理サーバーは開発チームの資産

プロジェクト管理の歴史が書かれた記事から、チケット駆動開発に至っている現在を連想した。
又、「プロジェクト・マネジメントは組織としての能力である」という記事から、チケット駆動開発が進むべき道について考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ECナビ　エンジニアブログ : ECナビにおける案件管理の歴史 ～Excel/MS ProjectからRedmineまで～

プロジェクトマネジメント　ワンポイント講義～プロジェクト・マネジメントは組織としての能力である

ECナビ　エンジニアブログ : ECナビにおける案件管理の歴史 ～Excel/MS ProjectからRedmineまで～を読むと、Excel・MS Project→自作ツール→Trac・Redmineに至る流れの背景がよく分かる。

10年前まではオープンソースのプロジェクト管理ツールは存在せず、紙やExcelで障害報告してタスク管理してワークフロー管理していたのだ。
だが、今のように短期間にアウトプットを出さなくてはならない状況が多いと、もはやそのような作業をのんびりすることはできなくなっている。

特に、運用ルールの徹底が難しい。
何故なら、新規加入のメンバーや新人が運用ルールに慣れるために、大量のドキュメントを読まざるを得ないが、実際に実行してみると、プロセスを飛ばしていたり、ドキュメントに書かれていない運用ルールがあったりするからだ。
プロジェクトリーダーの仕事の一つは、運用ルールを作ることにあるが、チームに馴染まない運用ルールを提案して、メンバーに強制しても逆に混乱するだけだ。

チケット駆動開発の利点はいくつかある。
一つ目は、RedmineやTrac、Subversion、Hudson、Gitのようなツールに慣れれば、自然にソフトウェア開発のベストプラクティスが身に付くこと。

作業を開始する時はToDo代わりにチケットを自分で登録して、作業履歴を自ら残す習慣が身に付けば、自分自身で作業を振り返るきっかけになるし、メンバーと情報共有できる場にもなる。
コミットログにチケットNoを書く習慣を身に付ければ、コミットする目的を必ず自覚するようになるし、不用意なコミットもなくなる。
また、コミットログに残されたチケットNoから、過去の修正理由を探すことも楽になる。
あるいは、GitやMercurialのバージョン管理でブランチを状況によって使い分ける手法を身に付ければ、機能追加していくコードラインと品質重視のコードラインを別々に維持しやすくなるし、突然の仕様変更があったとしても、緊急リリースに対応出来るインフラもある。

特に、オープンソースのツールは世界中のたくさんの開発者が試してきて、良いと思われた機能を実装しているのだから、その機能に慣れた方がプログラミングの良い習慣が身に付く。

二つ目は、開発者や管理者の作業を透過的にサポートするインフラがあること。
ソフトウェア開発はバージョンアップが激しいため、元々変化しやすい。
そんなソフトウェア開発のプロセスで重要なのは、多種多様なバージョンアップ作業を変更管理プロセスで制御すること。
しかし、大量のドキュメントや申請・承認が厳格すぎる運用ルールは、開発の機動力を落とし、メンバーを無気力にさせる。
チケット駆動開発なら、チケットの種類をワークフローに紐づけることによって、メンバーにワークフローを意識させずに、一つの成果物を複数人でチェックすることが自然にできる。
また、チケットに予定・実績工数・ステータスなどを入力する運用ルールを徹底できれば、開発者は進捗報告を気にせずに作業に専念できるし、管理者はRedmineやTracのような優れたチケット集計機能によって、リアルタイムに進捗や品質をモニタリングできる。

以上の二つは、プロジェクトマネジメント　ワンポイント講義～プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうち、「プロジェクト遂行手順・ＷＢＳ体系などの標準」に相当するだろう。

三つ目は、チケット駆動開発を運用するインフラが開発チームの資産になること。
チケット駆動開発を運用するインフラとしては、タスク管理(Redmine・Trac)、構成管理(SVN・Git)、ビルド管理(Hudson)、テスト管理(TestLink)、メトリクス出力(StatSVN)などがあげられる。
それらのツールからなるインフラは、開発チームのプロジェクト管理をサポートするプロジェクト管理サーバーそのものになる。
つまり、プロジェクト管理サーバーはPMBOKの言うPMIS(プロジェクトマネジメント・ソフトウェア)そのものになるはずだ。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

プロジェクト管理サーバーとは: プログラマの思索

そのプロジェクト管理サーバーがあれば、日々の開発チームの活動のログが貯められる。
そのログはサーバー上で一括管理できるので、進捗や品質をいろんな観点で分析することによって、プロジェクトの現状を報告したり、プロジェクトの将来を予測することが可能になる。
いわゆるソフトウェア・リポジトリ・マイニングと同じ。
つまり、プロジェクト管理サーバーに溜まった過去の実績データは、開発チームの資産そのものだ。
過去の実績データがあるからこそ、開発や運用ノウハウが貯められるし、Web上にあるからこそ、メンバーは簡単に全文検索して探すこともできる。
更に、メンバー全員でKPTによるふりかえりを行えば、より有効な知見を見出すことができるだろう。

プロジェクト管理サーバーのメトリクスは教科書みたいだ: プログラマの思索

ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

これは、プロジェクトマネジメント　ワンポイント講義～プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうちの「過去の実績データ」、あるいは「プロセス資産」に相当するだろう。

プロジェクト管理サーバーがプロセス資産であるという意味は重要だと思う。
ツールを使いこなすほど、作業の効率は増すし、運用ノウハウがたまり、更に開発チームに見合った運用ルールが生まれる。
プロセス改善で得られたノウハウは、まさに開発チームの資産だからだ。

チケット駆動開発によって、ソフトウェア開発のプロジェクト管理のハードルが下がって、もっとクリエイティブに開発できる。
そんな環境が誰でも容易に手に入る時代になったのだな、と思う。