プログラマの思索

最近思うのは、ソフトウェア開発のプロジェクト管理とは、ソフトウェア構成管理と表裏一体ではないか、ということ。

プロジェクトリーダーの仕事を見てみよう。
彼らの実際の仕事は、ガントチャートを作って、日々の進捗をガントチャートに反映するのに半日以上かける。
結合テスト以降は、業務シナリオ単位でテストケースを作成し、仕様変更や仕様漏れに対しテストケースを何度も保守する。
そして、テストで出てきたバグに対し、優先順位と期限を決めて、修正担当者・テスト担当者・検証担当者をアサインして回す。

それらのプロセス管理のために、進捗状況やバグ情報、バグが発生した要件を手作業で情報収集している。

プロジェクトリーダーの仕事は本来マネジメント業務なのに、マネジメントの判断材料をそろえる作業に1日の90％以上をかけていないだろうか？

日本人はプロセス改善が大好きだ。
製造業の影響を受ける組み込み系の人達は、プロセス改善、品質管理、テスト手法が大好き。
なのに、ソフトウェアの品質が悪い。

テストプロセスでは、たくさんのテスト担当者を投入してマンパワーでバグ潰ししようとする。
人手が多いから、マネージャはテストプロセスを管理するのが大変。
テストプロセスが最もIT化されていない。

理由は、構成管理ツールの概念やノウハウが少ないからだと思う。
つまり、バージョン管理、統合ビルドを自動化するとか、BTSでバグ管理、Testlinkでテスト管理というIT化の発想がない。

プロジェクト管理とソフトウェア構成管理が別々になっている。
プロジェクト管理は、結局はリソース管理。
つまり、誰が何をするか、いつまでに何をやるか、がプロジェクト管理だと思う。

ソフトウェア構成管理は、バージョン管理(SVN)、統合ビルド(Maven＋Continuum)、BTS(Redmine)の3つが必須だと思う。

プロジェクト管理とソフトウェア構成管理を一元管理できないから、マネージャは雑用がすごく多い。

ソフトウェア構成管理をIT化できれば、プロジェクト管理の引継ぎがすごく楽になる。
会社としては、優秀なプロジェクトリーダーほど、1次開発で頑張ってもらい、運用保守や2次開発は若手のリーダーに任せたいもの。

その時に、SVNやBTSなどの開発インフラが揃っていれば、使い方さえ覚えてもらえれば、誰でもやれる。
プロジェクト管理のノウハウが共通化されるから、若手も使い方に慣れるだけで、管理業務に自然に強くなる。

プロジェクト管理は属人性が強い。
誰でも管理できると管理者は不要になる。
だから故意に自分がいないと回らないようにするマネージャもいるらしい。
プロジェクトリーダー個人の能力に大きく依存するプロジェクトは、会社にとっても危険だ。

オープンソースのBTSを使う利点は、色んな会社、色んな開発者が使った要望を実現しているので、ソフトウェア開発のデファクトスタンダードになっているからだ。
最初は使い方に慣れないけれど、慣れた方がソフトウェア開発のベストプラクティスをマスターできる。

Testlinkは、テストプロセスに特化したWebのテスト管理ツール。
Testlinkを使うと、テストケースを一度DBに放り込めば、テストの進捗をリアルタイムに管理できる。
また、DBにあるから、テストケースを保守しやすいし、2次開発でテストケースの再利用が楽になる。

更に、Testlinkは要件管理機能もあるので、バグが出たテストケースから影響を受ける要件を洗い出し、それに対して対策を取る、というやり方もできる。

特に、2次開発以降、1次開発で苦労したテストにかかわる機能を仕様変更で修正する場合、あらかじめ関連する機能とテストケースを洗い出しておいて、回帰テストで何度もテストし直すこともできる。
これらはリスクを未然に防ぐというやり方。

プロジェクトリーダーの本来の仕事はリスク管理、リソース管理であるべき。
Redmineでリソース管理、Testlinkでテスト管理を実施して、開発リスクの対策を早期に実行できるインフラを作る。

プロジェクト管理は誰でも実行できるインフラであるべきで、その実装がソフトウェア構成管理ではなかろうか？