プログラマの思索

リンク先から下記の記事を見つけたので、考えたことをメモ。

【元ネタ】
こんにちは。 ソフトウェアの不具合管理をしているのですが、現在はエクセルファイルを複数社で メール添付で行っています。 この方法だと、 ・どれが最新かわからなくなる.. - 人力検索はてな

不具合管理(障害管理)はソフトウェア開発の中で最も重要で、そしてコントロールが難しいマネジメントだ。
ウォーターフォール型開発で設計、開発、単体テストと順調に進んでも、結合テストや受入テストに入ると、バグが多発してしまって品質がボロボロになってしまうケースは数多い。

ソフトウェア開発が製造業など他の産業の工程と異なる箇所は、結合テスト以降の障害管理だと思う。
各種のモジュールを初めて結合して、インターフェイスが違っていたり、仕様通り作っていても性能が出なかったりする症状が分かる。
いわゆるビッグバン結合で頻発する。

上記の質問を読むと、地理的に分散した複数の開発チームと障害管理をメールベースで行っているようだ。
この状況では、抜本的な対策を打たない限り、泥沼から抜け出すのは難しいだろう。
というのも、障害の履歴を管理できておらず、どのバージョンに障害修正をリリースしていくかというマネジメントができていないように思えるからだ。
更に、複数の会社の開発チームが地理的に分散しているようだから、コミュニケーションの距離も遠いから尚更だ。

上記の解決方法は三つあるだろうと思う。

一つ目は、障害管理ツール(BTS)を導入すること。
Excelで障害の状況を管理し、メールベースで障害履歴を残しているから、バグ発見やバグ修正、バグ検証の状況が混乱しているのが原因の一つ。
まずは、Bugzilla、Mantis、Trac、RedmineなどのBTSを導入し、全てのバグはBTSで一括管理すればいい。
そうすれば、バグの記載漏れがなくなるし、障害履歴がBTSで統一されるから、バグの最新情報をいつでも誰でも共有できる。

BTSにはバグ修正のステータス管理機能が必ずあるので、バグ修正をワークフロー管理することによって、PGとテスターがペアプロのように作業できる。これによって、バグ検証は必ず二人の目を通すことによって品質向上できるはず。

二つ目は、メインラインモデルによる構成管理と継続インテグレーションによるビルド管理をセットで導入すること。
上記の質問には書かれていないけれど、障害修正が難しい理由の一つは、本番環境のバグを開発環境でバグ修正したとしても、構成管理やビルド・リリース管理に不備があるために、デグレが多発することだ。
デグレが多発すると、他人が作った成果物そのものの信頼がなくなるために、チーム内の信頼関係が壊れてしまう危険な症状だ。

メインラインモデルによる構成管理を当てはめれば、本番環境と同じメインライン(trunk)とバグ修正・バグ検証を行うタスクブランチ(トピックブランチ)でソースを使い分ければいいだろう。
つまり、メインラインはいつもでリリースできるコードラインであり、本番環境と同値。
タスクブランチは開発者がバグ修正を試すブランチと使い分ければいい。
あるいは、一つのトピック(バグ)を修正して検証するだけのブランチ(トピックブランチ)を作ってもいい。
とにかく、バグ修正のお試しコードラインと本番環境と同値のコードラインは使い分けないと、たくさんの手を入れる分、品質はすぐに劣化してしまう。

そして、HudsonなどのCIツールを導入して、バグ修正したコードラインを常時ビルド＆リリースできるようにして、バグ修正とバグ検証のタイムラグを無くす。
バグ検証が完了したビルド番号のSCMリビジョンから、パッチを作り、trunkへパッチをマージすればいい。
MercurialやGitなどの分散バージョン管理を使えば、ブランチ管理やマージ作業はより楽になるだろう。

三つ目は、どのバージョンにどの障害修正を入れてリリースするか、リリース判定を下す課題管理会議を定期的に開催すること。
つまり、開発者・プロジェクトマネージャ・プロダクトオーナーなどのステークホルダーが集まって、どのバージョンをどのタイミングでリリースするか、そのバージョンにどんな障害修正を混ぜるか、今バグ修正はどんな状況なのか、どのバグを後回しにすべきか、などを決める。

例えば、アジャイル開発ならばスクラムオブスクラム、ITILならCAB(変更諮問会議)、PMBOKならCCB(変更管理会議)と言われる会議に相当する。
この会議こそが本来のマネジメントに相当する。

ユーザが業務でどのバグで困っているのか、リリース時期と要件の優先順位が出る。
そして、開発者の工数見積もり、多数のバグの依存関係から、どのバグを直していくか、作業の優先順位が出る。
ユーザと開発者のバランスから、バグ修正の優先順位が決まり、どのタイミングでリリースするか、バージョンを付ければいい。
つまり、リリースする機能のスコープ(範囲)を決めることで、納期と工数のバランスを崩さないようにする。

定期的にバグFixをリリースしていければ、リリース予定バージョンがイテレーションに相当するように自然に運用できるはず。
すなわち、課題管理会議はXPの計画ゲームを実践したり、Scrumのプロダクトバックログを決めたりする重要な会議なのだ。
だから、上記の状況ならば、定期的に自社と複数の会社が集まって課題管理会議で、バグ修正のリリース時期の確認、バグの棚卸しを行うべきだ。

障害管理が上手でない開発チームは、いくらBTSや構成管理ツール、ビルド管理ツールが揃っていても、リリース判定を下す会議(課題管理会議)でマネジメントの意思決定を行っていないために、泥沼にはまる。
マネジメントの弱い開発チームは、ソフトウェア開発に必ず失敗するように思う。

更に、地理的に分散しているならば、課題管理会議を開くには、Skypeやテレビ会議などのツールでサポートするしかないだろう。
つまり、リリース判定を下す会議を開催するハードルが高いという難点がある。

障害管理の泥沼から脱出するには、これら三つの解決方法が最低限必要だと思う。