コラム

TOP >  コラム >  コラム詳細

あるトラブル案件のテスト推進の顛末 第6回:今回の取り組みから見えてきた問題と対策

■はじめに

これまであるトラブル案件に対して行った取組内容とその取り組みの結果を振り返ってきた。

最終回となる今回は、取り組みを行った結果として分かってきた、取り組むべき課題とその対策についてみていく。


■アプローチ

まず最初に、私たちが取り組むべき課題と対策を検討した際にとったアプローチについて説明する。

私たちは、以下の流れで取り組むべき課題の検討を行った。

 1.トラブル案件化した要因の洗い出し
 2.要因の整理・分類
 3.要因の選別
 4.対策の検討

これからプロセスの流れに沿って、順に説明していく。


■1.トラブル案件化した要因の洗い出し

まず最初の作業として、今回の案件がどうしてトラブル案件化してしまったのか、その要因の洗い出しを行った。

今回は、我々テスト専任化チームにプロジェクトマネージャ、プロジェクトリーダー等プロジェクト主要メンバ数名というメンバ構成で実施した。

その結果、以下のような事柄が挙がった。

・弊社責任範囲外の画面デザインとそれに伴う仕様がなかなか決まらず、スケジュー
 ルに遅延が発生した(特に画面HTMLの納品の遅れが、実装開始の遅れと多くの
 手戻り工数を発生させた)

・各テストレベルにおいて確認すべきことが、そのテストレベルで確認されていなかっ
 た

・遅延が発生した際の対応が、結果だけでみると適切でなかった

・ITリテラシーの高くないお客様の言葉に甘えてしまった

・実装とテストのインプットとなる設計書の記述に曖昧さが残っていた

・実装とテストを行う上で必要な設計書が揃っていなかった

・設計書にテストの期待値となるべき項目が抜けているものがあった

・設計書を流用する形でテスト仕様書が作成されており、観点と期待値が定義できて
 いなかった

・プロジェクトの実情を把握する為の情報が開示されず、プロジェクトリスクの発覚が
 最終工程まで遅れてしまった

・テスト工程のプロセスが定義されていなかった

・仕様を押さえている人材が少く、ボトルネックになってしまった

.経験の浅い開発者が多かった


■2.要因の整理

次に洗い出した要因の分類・整理を行った。

要因を分類するにあたっては、改善策を検討するにあたって誰が(お客様と連携、マネジメント層、プロジェクトメンバレベル)中心になれば良いのかを分かりやすくする為に、大きく”お客様”、”マネジメント(管理/体制)”、”開発(設計/実装/テスト)”に分類・整理を行った。


・お客様

 -弊社責任範囲外の画面デザインとそれに伴う仕様がなかなか決まらず、スケ
  ジュールに遅延が発生した(特に画面HTMLの納品の遅れが、実装開始の遅れ
  と多くの手戻り工数を発生させた)

・マネジメント(管理/体制)

 -遅延が発生した際の対応が、結果だけでみると適切でなかった

 -ITリテラシーの高くないお客様の言葉に甘えてしまった

 -プロジェクトの実情を把握する為の情報が開示されず、プロジェクトリスクの発覚
  が最終工程まで遅れてしまった

 -仕様を押さえている人材が少く、ボトルネックになってしまった

 -経験の浅い開発者が多かった

・開発(設計/実装/テスト)

 -実装とテストのインプットとなる設計書の記述に曖昧さが残っていた

 -実装とテストを行う上で必要な設計書が揃っていなかった

 -設計書にテストの期待値となるべき項目が抜けているものがあった

 -設計書を流用する形でテスト仕様書が作成されており、観点と期待値が定義でき
  ていなかった

 -各テストレベルで確認すべきことがされていなかった

 -テスト工程のプロセスが定義されていなかった

1 2

>

>>


著者プロフィール


飯田秀樹/福良智明
株式会社オープンストリーム(http://www.opst.co.jp/)において、テスト推進チームとしてプロジェクトに従事。品質向上とプロジェクト事故撲滅のため何ができるか日々奮闘中


連載一覧



1 2

>

>>