問題原因は時間とともに変化する | トレンドの把握の仕方にも工夫が必要
itpjstudy
別の回で、状況把握や着地予測のために、トレンドを把握することの重要性を説明しました。
今回は、状況は刻々と変わっていくため、トレンドを追い続けていくことが大切さだということについて、お話したいと思います。
基本的に、ほぼ全ての活動について、トレンドを追い続けることを推奨しますが、今回は、システムテストにおける不具合原因を取り上げたいと思います。
時間の経過とともに、問題原因は変わってくる
以下は、システムテストが始まって2週間経った時点の不具合原因の分析表です。まずは、この表をオーソドックスに見て行きたいと思います。
第1-2週の問題原因分析
テストですから、システム品質に関わる問題を洗い出したいところです。そこで、黄色でハイライトしているような「基本設計」「詳細設計・開発」「設定・コンフィグレーション」に関する不具合が出てきて欲しいです。
ただ、この時点では、まだテストを始めたばかりということもあり、ベージュでハイライトしている「テストデータ」「権限」「オペレーションミス」といったテスト初期に出がちな問題が多く出ているようです。
テストを始めたばかりだから、まあ、この手の問題が出てくるのは想定通り。
次は、第3-4週の状況を見てみましょう。
第3-4週の問題原因分析
どうやら「データ」「権限」「オペレーションミス」といった初期の問題は少なくなってきて、「基本設計」「詳細設計・開発」「設計・コンフィグレーション」といった、本来洗い出したかった問題を見つけられ始めたようです。
よしよし。3週目以降は、本来洗い出したかったシステム実装の問題が出てきているぞ。
ここまでは、分かりやすくるため、第1-2週、第3-4週という風に表を分けて説明してきました。
実際には、適切なレポートの出し方が出来ていないため、関係者が状況を誤認するケースが少なからずあります。
累計だけで見ていると、見誤る危険がある
下記は、第4週目終了断面で、第1週から第4週までの累計を表示しています。
累計で説明することの必要性もあるので、これ自体は悪くはありません。ただ、ここに誤解を招く危険が潜んでいるのです。
詳細設計・開発の問題も、そこそこ出てきているけど、やっぱりデータの問題が大きいんだなぁ。
データの問題に解消に力を入れないといけないな。
皆さんはすぐに分かったかと思いますが、この認識は誤りです。
確かに、第1-2週は、データの問題が多く検知されました。ただ、第3-4週では問題件数は減少しており、山場を脱しています。
このように累計だけで見ていると、状況認識を見誤る危険があります。そのため、ここでもトレンドを把握できるようなレポートが必要になるのです。
グラフを使わずに、トレンドを正しく見る方法
上記は折れ線グラフではありませんが、トレンドが分かるように、時系列の情報を入れています。加えて、大きな数字をハイライトしています。
この表を見てみると、以下のように状況が変わってきているのが分かります。
| 第1週 - 第2週 | データや権限など、テスト初期にありがちな問題が出ている |
| 第3週 - 第4週 | 初期の問題が解消して、システム実装の問題が多数を占めるようになった |
| 第5週 - 第6週 | システム実装の問題は引き続きでているが、徐々に基本設計に関わるような難しい問題も出てきた |
| 第7週 - 第8週 | 仕様変更につながるような要件の問題や、周辺システムとの連携テストで出てくる問題など、問題の難易度が上がってきた |
今回は、オーソドックスにシステムテストが進捗している例で記載しましたが、トレンドが想定通りでない場合は、何か良くないことが起きているということですから、状況を深掘りしていくことになります。
状況は刻々と変わっていきますので、常にトレンドを把握しておくことは非常に重要です。
トレンドを見るには、折れ線グラフが一番分かりやすいです。しかし、今回の問題原因のように、要素が多い場合は、折れ線グラフだと、逆に見にくくなってしまうことがあります。
ただ、今回見て頂いたように、表でも、工夫次第でトレンドを分かりやすく見れるようになります。
ちなみに、今回取り上げた問題原因の分析は、色々と奥が深く、システム品質を上げる際や、ユーザ企業とITパートナとの費用交渉の際にも利用されます。また別の機会に取り上げたいと考えています。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
