プロジェクト管理ツールの目的はプロセスの透明化

開発抽象化レイヤ - The Joel on Software Translation Projectを読み直して、もう一度考えを書き直す。

【元ネタ】
開発抽象化レイヤ - The Joel on Software Translation Project

開発抽象化レイヤーを担う人: プログラマの思索

RedmineやTracによって、Excelからタスク管理やワークフローをIT化する。
昨今の高機能なBTSによって、ワークフローやプロセス管理を開発者は特に意識せずに開発できる。

TestLinkによって、Excelからテスト管理をIT化する。
管理者やテスト設計者は、膨大なテストケースの管理や複雑なテスト計画・集計作業から解放される。

SVN、Mercurial、Gitによって、ソースだけでなく、WordやExcelのドキュメントもバージョン管理する。更に、BTSと連携してソースやドキュメントをチケットに紐付ける。
開発者も設計者も、ソースやドキュメントの変更理由をチケットから類推できる。

これらのツールが目指すのは、プロセスを透明化することだ。
ジョエルの言う開発抽象化レイヤを狭義に捉えると、開発者がプロジェクト管理を意識しなくてもクリエイティブに開発できるようにすることだ。

作業者がツールを使いこなせば、ツールの機能に隠されたベストプラクティスによって、自然にプロセス管理されている。
プロセス管理でがんじがらめな開発になるのではなく、複雑な連携作業やワークフロー管理はツールに任せて、開発者はクリエイティブに開発できる。
管理者も、マネジメント情報を収集する作業から解放されて、経営者のようにツールから出力されたマネジメント情報を使って、高度な意思決定に注力できる。

ソフトウェア開発において、プロジェクト管理やテスト管理、品質管理の問題が急速に言われ始めたのは、プログラミングを中心とする下流工程でここ10年大幅な技術革新が行われたのに、プロジェクト管理の技術が旧態依然のままで、プログラミングの速度に追いついていないからだろう。

Excelでチマチマと手作業で管理する技術は、RailsやSeasarのようなWebプログラミングの速度にマッチしていない。
わずか10～20人月のプロジェクトでLOCが1万行を超え、テストケース数も1千を超える規模では、ツールでプロジェクト管理を補完しなければ、せっかくのプログラミング技術の生産性も落ちる。

ツールに必要な物は何か？
それは、常に最新の作業情報、成果物、そして仕様。

最新の作業情報を入力データとして、BTSによるチケット駆動開発がプロセスを透明化する。
最新の成果物を入力データとして、バージョン管理ツールが開発プロセスのインフラを提供し、BTSとソース管理が連携して、成果物と作業情報を連携してくれる。

最新の仕様を入力データとして、ツールが仕様と成果物が紐づく。
この部分のツールは、TestLinkの要件管理機能のように、まだ不十分。
でも、昨今のように短期間で開発するには、作業情報と成果物と仕様が密接に連携できるツールを必要としている。