ソフトウェア開発やシステム開発で作成されるプログラムは、ほとんどの場合人によって開発される。 そのため、プログラム内にはバグと呼ばれるプログラム上の間違い、不具合が必ずあり、バグのない

プログラムを作成することはほとんど不可能と考えられている。(バグとは)

開発者はプログラム作成において、バグを取り除く作業に多くの時間が費やされることになるが、 そのデバッグ工程で大活躍しているツールとバグ管理方法について紹介したいと思う。

ソフトウェア企業で障害管理表、バグ管理表といえば MS Excel や MS Word で管理している企業は多いと思う。 実際に過去自分が関わったプロジェクトでは Excel が多く利用されていた。

弊社でのバグ管理方法は、Trac といわれるバグトラッキングシステム(Bug Tracking System/BTS) を利用して管理している。 ほとんどすべてのプロジェクトでバグトラッキングシステムを利用しているが運用するためには最低限のルールが必要になる。ルールを守って、だれでも簡単に運用できるようにしなければ、チーム内でうまく利用されない。

これから導入を検討されている方の参考になればと思う。

基本の考え方

• プロジェクトスタートと同時に開発用の BTS を準備
• プロジェクト内で発生するバグ・課題は必ず BTS に登録すること
• 「BTS に登録されないバグや課題は対応しない」など、徹底させるためのルールをはじめに説明

運用方法

1. すぐやる / 都度やる

バグや課題は見つけたときにすぐ登録、「あとで」は忘れるもと。導入後でデータ登録 が一番めんどうだが、メリットを考えるとちょっとの努力を惜しまずにやる。

1. 各プロジェクトの管理責任者を決める

BTSの導入後、チケットの乱発、処理されないチケット、担当のいないチケットがいつ までも残ることがあるので、管理責任者を用意する方がうまくいく。

1. バグ・課題のクローズはチケット作成 バグ・課題(チケット)をクローズする権限は、発行者、各プロジェクトの管理責任者、品質保証のメンバー

チケット運用イメージ(ワークフロー)

開発サポートツールをうまく導入するために、できるだけシンプルなルールだけを決めて運用してきたつもり。 開発者ならだれでも使えるだろう Excel や Word ほど学習コストは下げられないが、一度利用しはじめたら そのメリットから開発には必須のツールになる。

まだ導入していないソフトウェア開発者の人は、ぜひ導入を検討してもらえれば幸いである。

ソフトウェア開発管理で一番大切なことは「コスト、品質、納期」ということはよく言われることですが、これまでのソフトウェア開発プロジェクトでは3つのうち何かが欠けてしまい失敗(デスマーチ)という状況が少なからずあった。（本当ならビジネスとしてやっている以上、あってはならないことですが･･･）

プロジェクト失敗の原因は様々あると思いますし、多くの人たちがより良い方法を考えていますが「これだ！」と言われる方法はなく、プロジェクトの規模・内容によって試行錯誤されていると思う。特定の業務では正しいと言われる方法はあるかもしれないが。

その失敗理由について「プロジェクトリーダ/マネジャの力不足」と終わらせてしまっては何も生まれない。

これまで携わってきたプロジェクトの中で特に難しいことの1つに工数見積があります。

破たんした見積もりはプロジェクト失敗への近道 － ＠IT自分戦略研究所

最近自身も経験したことで概算見積がある。 見積手法と言われる方法は様々あるが、これらの方法は顧客の要件が確定している場合、または確定後のフェーズで利用される手法と理解している。 しかし、実際の開発現場では担当者から引き合いレベルで「予算化するために概算見積がほしい」という依頼がよくある。これに対応する場合「FP法などは利用できないなぁ。」と。顧客にとってもこれから導入しようと考えているソフトウェアにいくらかかるのか? 費用対効果は? を判断するために早く概算見積が必要名のは理解しているつもり。

どのようにやっているのかと思って、あるソフトウェア開発企業でプロジェクトリーダの方に聞いたところ、

• 現状で分かっている要件から機能毎の工数を積み上げていく
• それに2～3倍を掛けて提示する(笑)

この「工数を数倍」というところが重要で実際にプロジェクトが完了した時点で「トントンになるか」「すこしマイナス」という場合がけっこうあるという話を聞いた。 この数字に根拠があるわけではないと思うが、甘い見積では確実に穴があり、痛い目をみる。見積精度を高める努力はしているがやっぱり難しい。

[Think IT] 第1回：工数見積もりの見える化 (3/3)

エンタープライズ系ソフトウエア開発における見積もり手法 … 「類似プロジェクトからの類推」 「プロジェクトリーダや担当者の経験」、 そして「積み上げ」が三強で全体の90%以上を占める。

• 見積の間違いはチーム全体を不幸にする、顧客にとっても。
• 正確な見積はできない。限りなく正しいと言える見積はあるはず
• 開発者と顧客が喜ぶことが出来る結果を目指す

開発側ばかりに負担をかけることも問題、顧客側に負担をかけることも問題、開発側と顧客側が満足できるソフトウェア開発とプロジェクト管理の両立を目指したいですね。

[見積手法]

ソフトウェア測定法 – Wikipedia

[Think IT] 第1回：工数見積もりの見える化