□------------------------------------------------------------------□
□　Ｃ社生産管理システムにおけるシステムテスト工程の進め方
□------------------------------------------------------------------□


---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
1.プロジェクトの概要
----
1.1.Ｃ社生産管理システムの再構築
----
　Ｃ社はシリコンウェハーを製造するメーカであり、大
容量化への対応と、更なる品質向上を目的に、新工場の
建設を中心とする大規模な設備投資を行った。これによ
り製造工程は大幅な変更となり、生産管理システムも抜
本的な見直しが必要となった。私はシステムインテグレ
ータであるＥ社に勤務しており、Ｃ社生産管理システム
の再構築に際し、プロジェクトマネージャとして携わる
事となった。尚、プロジェクトの規模は以下の通りであ
る。
・開発工数：１２０人月
・開発後期：１４ヶ月
・プログラム本数：１６０本
・プログラムステップ数：１６０ＫＬＳ
----
1.2.直面した課題
----
　一般的な素材産業における生産管理システムと同様に、
Ｃ社生産管理システムの機能も、受注・品質設計（以下、
設計）・計画・作業指示・操業・品質検定・出荷等のサ
ブシステムから構成されている。一方で、システムのテ
スト工程は、プログラム単体テスト・サブシステム内の
連動テスト・総合テスト・ユーザによる運用テストの順
にすすめられる。
　当プロジェクトでは、連動テスト工程において、設計
サブシステムの品質が他サブシステムに比べ著しく悪い
事が発覚した。他サブシステムのバグ発生件数が、
１〜２個／ＫＬＳであるのに対し、設計においいては、
５個／ＫＬＳを超えるという状況であった。
　プロジェクトマネージャである私の役割は、短期間で
システムの品質を向上させ、プロジェクトを計画通り
カットオーバーさせる事にあった。
---------------------------------------------------------------------
 （設問イ）
---------------------------------------------------------------------
2.課題に対する施策と評価
----
2.1．原因の分析と品質向上に必要な工数見積り
----
　私は、設計サブシステムの品質を下げている原因を分
析するために、担当のＳＥと共に、プログラム仕様書・
ソースコード・テスト計画書等の見直しを行った。その
結果、テストケースの設定が甘く、イレギュラーケース
でのテストが大幅に不足している事が判った。
　更に、設計サブシステムではプログラムを８０本以上
抱えており、テストケースの見直しと単体テストを実施
して、品質を向上させるためには５人月の工数と、２ヶ
月の期間が必要である事が判った。
----
2.2.適切な要員の確保
----
　前述の品質対策を確実にかつ短期間で実施するために、
私は以下の方策を実施した。
　a.プログラム開発工程が完了した時点でプロジェクト
　　を離れていたプログラマを呼び戻す。
　b.他サブシステム担当ＳＥを一部、設計サブシステム
　　へシフトする。
　これは、Ｃ社計算機環境と生産管理システムの内容に
精通している要員を確保することを目的としたものであ
る。特に、他サブシステムからのシフトについては、一
部のメンバーから反対があったが、設計サブシステムの
作り出すデータは、作業条件・品質検定条件の設定など、
以降のサブシステムの根本となるものであり、総合テス
トを円滑にすすめるためには何としても設計サブシステ
ムを安定させる必要がある事を説明し、理解を得た。
　これにより、設計サブシステムの品質対策は１ヶ月で
実施できる見通しとなったが、プロジェクトを予定通り
カットオーバーさせるためには、更に１ヶ月を短縮しな
ければならない状況であった。また、他サブシステムか
ら要員をシフトする事により、一部で連動テストが中断
するため、その対応も必要であった。
----
2.3.連動テスト工程の絞り込み
----
　連動テストを実施するためには、想定しているテスト
ケースに準じたテストデータが必要になる。一方でＣ社
生産管理の主要ＤＢ数は１０であり、データ項目数は、
２０００を超えている。データの設定を必要な部分のみ
に限定した場合でも、項目間の整合を取ったテストデー
タを準備する事は容易で無い。
　今回私は、テスト工程で１ヶ月を短縮するために、連
動テストのテストケースを大幅に絞り込む事を行った。
具体的には、ノーマルケースによる基本機能についての
み動作確認を行い、イレギュラーケースのテストは総合
テストで実施することとした。
　これは、テストデータの準備を、ツールや人手によら
ずサブシステムを順に機能させることによりデータを生
成する事を狙ったものである。
　これにより、連動・総合テスト工程において１ヶ月を
短縮する事が可能となり、プロジェクトは予定通りの
カットオーバーを迎える事ができた。
---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
4.今後改善したいと考えている点
----
4.1．上流工程での品質の造り込み
----
　今回プロマネであった私は、開発工程においては日々
の進捗のみを管理し、品質についてはＳＥ・プログラマ
任せとしていた。しかしながら、今回の反省から、プロ
グラムの品質は開発工程で造り込むものであり、品質管
理のスタートは、開発工程にある事を深く認識した。
　今後は開発工程の段階から、ｕ管理図・ｐ管理図等に
よる品質の管理、およびバグ抽出の累積グラフによる品
質の予測等を実施していきたいと考えている。
----
4.2.工程を超えたクリティカルパスの導出
----
　今回のＣ社生産管理システムでは、品質設計の作り出
すデータが、他機能に与える影響は大きく、先行して開
発を完了させ品質を安定させておく必要があったと判断
している。一方で、ウォーターフォールモデルによる、
開発工程管理では、設計・製作・テストの縦割りでの管
理を行い、確実に前工程を完了させた後に後工程に進む
事となっている。
　私は、このウォーターフォールモデルに加え、サブシ
ステム機能の依存関係を洗い出し、設計・開発・テスト
を超えたクリティカルパスを導出すべきであると考える。
これにより、例えば今回のプロジェクトで、テストデー
タ生成・検証ツールの準備を省略したように、省ける作
業が見えてくる。
　もっとも、一部機能を先行させる場合には、その他機
能からの影響により、手戻りが発生する可能性もある為、
プロジェクトの規模・仕様の確実性等を見極めながら進
めていく必要がある事は言うまでも無い。