テストマネジメント虎の巻（イントロダクション）

これは2010年11月にHPのマーケティングサイトであるBTOClub（当時）のブログへ投稿したものを転載しています。

ーーー

皆さんこんにちは。このたび、BTOClubでテストマネジメントに関して連載をすることになりました。今回から何回かに分けて、テストマネジメントに関して、その意義から具体的に行う際に直面する課題や、その対応例について書いていきたいと思います。どうぞよろしくお願いします。

ソフトウェア開発が直面している課題

まず今回は、最初ということもあるので、私たちがソフトウェア開発において直面している課題に関して簡単におさらいしておきたいと思います。

近年、ソフトウェア開発は、短納期かつ低コストのプレッシャーをうけ、開発の困難度合いが増しています。また、次から次へと出てくる新しい技術への適用や、ユーザニーズの変化に対する対応などもソフトウェア開発を困難にする大きな要因になっています。

実際、日経コンピュータの2008年度の調査では、ソフトウェア開発は31.1%しか成功していないという調査結果が出ています。

日経コンピュータの調査では、QCD、つまりシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうかを基に成功かどうかを判断しているのですが、３つのうち特に弱いのは、「品質」面であるという結果になっています。品質に対する何かしらの対処がソフトウェア開発における課題であるということです。これは日経コンピュータの2004年の調査から変わっておりません。

品質に関する何かしらの対処ということでいえば、ぱっと思いつくのはテスト、レビューです。テストやレビューを行うことで品質の善し悪しを確認することができます。また、テストやレビューの結果を数値化し、グラフで表すことで過去との比較をしたり、現状把握をしたりする定量管理を思い浮かべる方もいらっしゃるでしょう。

テストに工数がかかりすぎる？

また、品質の善し悪しを確認する方法のひとつであるテストに関して言えば、ソフトウェア開発の全45%をテストが占めるといわれています。※図1

図1　開発プロジェクトにおけるテストの比率（「基本から学ぶソフトウェアテスト」日経BP社　より）

この数字をどう思うでしょうか？

これは読者の皆さんがどのようなソフトウェア開発に携わっているかによって受ける感覚はちがうのではないでしょうか？ビジネスに直結するシステムや人の生命に直結するシステムでは、市場で問題が起きることは即大問題になります。そうならないようにするためにテストを山ほどやるので、45%を少ないと思うでしょう。

一方、ちょっとくらい問題が出てもそれが大きな問題にならないシステムであれば、テストはほどほどにして、実際に運用を開始してから問題が出たら対処するという方法を取ろう、という話になることも多く、「45%もテストするなんてありえない。」と思うでしょう。

テストをマネジメントしないと両極端になってしまう

テストは、出来たものが想定通りに出来ているかを確認する仕事であり、テスト自体が何かを生み出しているわけではありません。そのため、一見余計な作業に見えます。そのため、計画的というより必要に応じて適時確認しておけばよいのではないかと思ってしまい、重要視しないケースも多々見られます。

ただ、前述したようにソフトウェア開発は多くの要因から困難になっています。単純なものでしたら適時確認で済むものも、複雑で規模が大きいものになってくると状況は一転しテスト量が膨大になってきます。対策としては2つのパターンがよく見られます。

まず一つ目が、よりコストをかけて対処する方法です。市場で問題が出ると大問題になるプロジェクトであれば、かけられるだけ時間をかけ、人も大量に投入し、2交替制などの方法も使い、より多くテストをやろうと努力します。ただ、たくさんの人数でテストをしようとすると、役割分担が必要になったり、全員のテスト結果をまとめて整理し、全体としてどうなのかを判断しなければならなくなります。また、人数を増やせば全部できそうなテスト量であれば良いのですが、それでも到底全部をテストするのは困難な量になってきたとしたらどうするでしょうか。時間内までとことんやり、もう無理だというところで終わりにしていませんか。

別のパターンは、初期投資にコストをかけられない開発や、受託案件の場合です。かけられるお金は限られたものになってしまうため、本来テストすべき量と出来る範囲にあまりに差が出すぎてしまい、それこそ、時間が余ったらテストをするだけになってしまいます。（ガントチャートを開始時期から埋めていき、余った時間がテストという具合です）新規のEコマースのWebサイトに対して、システムテストを1人で1週間程度しかテストできないというケースもよく見かけます。

上記のように、行き当たりばったりで、手のつけられるところから適時テストするという方法を取ると、開発の予算だけでテスト量を決めるため、とことんやるか、ほとんどやらないかの両極端になってしまいます。

こうならないようにするには、どうすればよいでしょうか。きっと優先度を付けて、何処までテストをするかを決めることになるでしょう。ただ、何をどの程度テストをするかは、どの程度テストすれば十分なのかを上司やプロジェクトマネジャー、メンバー間で合意していないとわからなくなってしまうのです。また、決めたことが適切だったかを常に計測し、状況把握をして間違っていれば見直すこともしなければなりません。

マネジメントとは、「共通の目標・価値観を持つ人たちが、適切な組織をつくり、訓練と研鑚によって、共同で成果を上げられるようにすること。（P.ドラッカー）」だといわれています。テストにもそのようなマネジメントが必要なのです。なぜなら、テストは、開発の失敗要因である「品質」を確保するための手段あり、かつ開発で最もコストがかかっている活動だからです。

これからの内容

今回は、初回ということで、テストマネジメントの必要性について書きました。今後は具体的な場面場面に応じた話題にしていきたいと思います。内容としては、計画編、モニタリングとコントロール編として以下のことを予定しています。

■テストマネジメントの全体像

■計画編

• テストをまかせられたら

• 見積もり

• 人員確保

• プロジェクト全体との関係作り

■モニタリングとコントロール編

• レビュー

• テスト実施のスケジューリング

• 進捗把握

• 仕様変更に対処

次回は、「テストマネジメントの全体像」について書く予定です。