----------------------------------------------------------------------

　（テスト段階における品質管理について）

----------------------------------------------------------------------

----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１　プロジェクトの概要とテスト段階で確認した項目
----------------------------------------------------------------------
１．１　プロジェクトの概要
----
　ＯＡ機器販売会社のＡ社はホストコンピュータを使っ
て販売管理システムを運用していたが、システムの稼動
開始から１０年以上経過し陳腐化していることから、Ｂ
社のパッケージソフトウェアへの移行を画策していた。

　Ｂ社のパッケージソフトウェアはＣＲＭとＥＲＰの機
能を併せ持つ先進的なものであったが、Ａ社の業務とは
合わない部分がいくつかあり、Ａ社の業務に合わせるよ
うにパッケージソフトウェアをカストマイズしたり、パ
ッケージソフトウェアに不足している機能を追加機能と
して開発する必要があった。

　Ｃ社の社員である私は、Ａ社のパッケージソフトウェ
ア導入プロジェクトに顧客管理サブシステムのプロジェ
クトマネージャとして参画し、追加機能の開発に従事し
た。

----
１．２　テスト段階で確認した事項
----
　テスト段階において品質が確保されているかどうかを
判断するために確認したことは、テストの実施件数と不
良が発生した件数である。

　テストを実施した件数と不良が発生した件数をテスト
要員から毎日報告させ、テストが予定通りに進捗してい
るか、不良の累積グラフが収束傾向を示しているか、不
良発生率が当プロジェクトの基準を満たしているかなど
を調査し、品質が確保されているかどうかを確認するよ
うにした。

　当プロジェクトでのテスト段階はサブプロジェクト内
結合テスト工程、システム全体結合テスト工程、総合テ
スト工程の３段階に分かれており、工程毎に決められて
いる不良発生率の基準を満たすことで、品質の作り込み
を段階的に行うことを狙っていた。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２　不良原因の調査と対策
----------------------------------------------------------------------
２．１　不良原因の調査
----
　システム全体結合テスト工程に入って１週間後、テス
トを実施した件数が予定通りなのに不良が予定よりも多
く発生していることが分かった。
　システム全体結合テスト工程においての不良発生率は
１．５％が当プロジェクトの基準であったが、テスト要
員からの報告を基に計算すると不良発生率は２．５％で
あった。
　基準より１％不良発生率が高く、このままではシステ
ム全体結合テスト工程の中で品質を確保するのが困難で
あり、システム全体結合テスト工程のスケジュールが遅
延したり、コストが増加する可能性があるため、原因の
調査と対策を検討することにした。

　当プロジェクトではテストで不良が発生した場合は障
害データベースに不良内容を登録することが義務付けら
れていた。障害データベースは多角的な分析ができる機
能が提供されており、これを用いて不良内容を分析する
ことにした。
　不良内容からパレート図を作成して分析してみると、
顧客の請求先情報に関連する画面やバッチ処理で不良が
多いことが判明した。

　顧客の請求先情報とは請求書の送付先住所や締日など
顧客への代金の請求に関する情報である。
　顧客の請求先情報はＡ社の移行サブプロジェクトが現
行システムから新システムに移行していた。

　サブプロジェクト内結合テスト工程ではこのような不
良は発生しなかったことから、移行サブプロジェクトに
おいて顧客の請求先情報の移行仕様が変更になっている
のではないかと原因を推測した。

----
２．２　不良原因への対応
----
　不良が予定より多く発生している件について、調査結
果をＡ社のプロジェクト統括責任者のＦ氏と移行サブプ
ロジェクトのプロジェクトマネージャのＧ氏に説明した
ところ、Ｇ氏から次のような回答があった。

　顧客の請求先情報の移行仕様は、Ａ社の売掛サブプロ
ジェクトからの要請で、システム全体結合テストの前に
データベース項目の数項目について変更した。
　この移行仕様の変更に対して移行サブプロジェクトは
変更した項目が少量であり、売掛サブプロジェクト以外
では使っていない項目という認識であったため、移行仕
様の変更について連絡をしていないとのことであった。

　現在、発生している問題の影響調査や対応を行うため
には、仕様変更内容を正確に把握する必要があると考え
た私は、Ｇ氏に移行仕様の変更について内容の説明を求
め、他に仕様変更がないかどうかを他のサブプロジェク
トに問合せを行った。
　問合せの結果、移行サブプロジェクトの移行仕様の変
更以外には仕様変更がないことを確認し、対応策を検討
することにした。

　Ｇ氏からの説明を受け、私の担当する顧客管理サブプ
ロジェクトの影響を調査したところ、プログラムの修正
とテストのやり直しに２週間分の追加作業が必要である
ことが分かった。
　原因がＣ社にはないことから、Ｆ氏にスケジュールの
見直しと追加作業分の費用負担を要求した。
　Ｆ氏からの回答は、追加作業分の費用はＡ社が負担す
るので、スケジュールの遅延は最低限に抑えてほしいと
のことであった。
　私は残業の追加や休日出勤を行うことにより、システ
ム全体結合テストを１週間の遅れで完了させる対応策を
Ｆ氏に提示し、併せて総合テストの実行計画を変更して
システム全体結合テストの遅れを吸収することを提案し
た。

　Ｆ氏はこの対応策を了承したため、私は対応策を実行
に移すことにした。
　対応策を実施した結果、不良の発生率は当プロジェク
トの基準内で推移するようになり、対応策の計画どおり
１週間の遅れでシステム全体結合テストを完了すること
ができた。
　総合テストではシステム全体結合テストが遅れている
部分に関連する部分のテストを後回しにするなどして、
１週間の遅れを吸収して予定どおりに総合テストを完了
することができた。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３　実施した施策に対する評価と再発防止策
----------------------------------------------------------------------
３．１　実施した施策に対する評価
----
　システム全体結合テストでの不良の発生率が当プロジ
ェクトの基準をよりも高くなる問題はあったが、その後
の対応策で不良率を改善し、対応策による遅れも総合テ
ストで吸収できたことは評価している。

　システム全体結合テストの前に移行サブプロジェクト
が移行仕様を変更したことを他のサブプロジェクトに連
絡しなかったことは、当プロジェクト全体の反省事項で
あり、今後の改善が必要と考えている。

----
３．２　不良原因の再発防止策
----
　今回のプロジェクトでの不良原因は、プロジェクトで
の変更管理が不充分であったと考えている。
　移行サブプロジェクトは顧客の請求先情報の移行仕様
を変更することによる影響が売掛サブプロジェクトにし
かないと判断して他のサブプロジェクトには連絡しなか
ったが、実際は顧客管理サブプロジェクトにも影響があ
った。

　今後、同様の問題を発生させないためには、仕様変更
を行う場合は進捗会議などで変更内容を他のサブプロジ
ェクトに漏れなく連絡することが必要である。

　現在、私はＡ社の販売管理システムの二次開発に従事
しており、プロジェクト全体の再発防止策として下記を
実施し、大きな問題は発生していない。

（１）仕様変更を行う場合は仕様変更連絡書を作成して
　　　変更内容を他のサブプロジェクトに連絡する。
（２）プログラムを変更するときは変更理由をリポジト
　　　リに登録し、プログラムの変更履歴が追跡できる
　　　ようにする。