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

Ｂ社生産管理システム再構築における本番稼動時の問題

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


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1.プロジェクト概要と本番稼動を妨げる要因
----------------------------------------------------------------------
1.1.B社生産管理システムの再構築
----
　Ｂ社はシリコンウェハを製造するメーカである。Ｂ社
では操業開始当時より、システム化には積極的に取り組
んでおり、生産管理システムはホスト計算機上に構築さ
れていた。

　一方でシリコンウェハを取り巻く業界は変化が激しく、
常に新品種・大容量化への対応を行わなければならない。
この度、Ｂ社ではこれまでにない新品種の量産化の目処
が立ち、かつ生産管理・品質管理の手法も従来とは異な
る事から、従来の品種を含め生産管理システムを抜本的
に見直す事となった。

　システムインテグレータであるＮ社に勤務する私は、
Ｂ社生産管理システム再構築にあたり、ＰＭとして任命
された。

----
1.2.本番稼動を妨げる要因
----
　前述の通り、システムは全面的な再構築であり、その
規模は、ＣＯＢＯＬ６００ＫＬＳで約４００人月である。
Ｎ社にとっては、かなり大規模なプロジェクトであった
が、Ｂ社が市場に新製品を投入するタイミングの都合上、
開発期間は１年間に限られた。

　私は、週に一度定期的なミーティングを開催し、進捗・
品質管理を行う事とした。プロジェクトは設計・開発と、
順調に進んでいたが、本番稼動を目前にした、運用テス
トにおいて以下の重大な問題が発生した。

「注文仕様を、現場で作業可能な製造仕様に展開するサ
　ブシステムにおいて、誤った情報が展開される場合が
　ある。」

　上記は、品質設計と呼ばれるサブシステムであり、生
産管理の最も基本となる部分であり、この不具合がシス
テム全体に及ぼす影響は大きい。私は、この問題に対し
て稼動時期を延ばす事無く対処するために、Ｂ社との調
整を開始した。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.本番稼動を妨げる要因に対する対応
----------------------------------------------------------------------
2.1.原因の切り分けと影響範囲の調査
----
　前述の通り、品質設計は生産管理の最も基本的な部分
であり、このサブシステムを除いた分割立ち上げは不可
能である。私は、この問題を解決するために、まず以下
の視点での調査を指示した。

　a.問題は特定品種で発生するのか、全ての品種で発生
　　するのか。
　b.問題は特定工程の製造仕様で発生するのか、全ての
　　工程で発生するのか。
　c.問題は、ユーザの仕様ミスにあるのか、システムの
　　ミスにあるのか。

　この調査の視点は、システム全体に及ぼす影響を確認
するためのものである。

　調査の結果、全約１００品種中の３品種であり、かつ
特定工程のみで発生する事が判った。一方で原因の切り
分けについては、ユーザの仕様ミスである事も判った。
また、ユーザが提示した仕様を、ユーザ自身により再度
詳細にトレースすると、３品種・特定工程において誤っ
た製造仕様となるという結果が得られ、システムの調査
結果と整合をとる事ができた。

　尚、この仕様ミスについてSEからは、プログラムの修
正・単体テストの為には、１ヶ月が必要であるとの報告
がなされた。ユーザは、完全な仕様ミスであり、修正に
必要なコストの負担は認めるものの、本番稼動時期の延
期だけは避けて欲しいとの要請であった。

----
2.2.特定品種のハンド対応の提案
----
　前述のような状況に対し、私は問題の３品種について、
ハンド対応する事を提案した。具体的には、特定３品種
については品質設計の結果に誤りがある事は判っている
ので、実際に操業に着手する前に、ユーザにより内容を
修正させるというものである。勿論、誤って操業が開始
されないように、修正・承認機能を一時的に強化する前
提である。

　ユーザは私の提案を受け入れ、プロジェクトは運用テ
ストを継続し、本番稼動を迎える事となった。

----
2.3.仕様ミスへの対応
----
　特定の３品種についてのプログラム修正は、本番稼動
後としたが、ユーザには変則的な運用を強いている訳で
あり、極力早期に対応しなければならない。

　一方で、本番稼動を迎えたシステムに対しても暫くは、
細かいバグ対応や修正も日常的に発生している状況であ
った。この様な状況下で、特定品種に対応するための纏
まった規模での修正を開始すると、プログラムのデグレ
ードが発生する事は明らかであった。

　そこで私は、本番稼動中・開発テスト中等のプログラ
ムの状態管理とライブラリ運用の整理をＳＥに支持した。
この結果のコントロールをプロジェクトではバージョン
コントロールと呼び、全てのＳＥ／ＰＧがこのコントロ
ールに従った運用を行う事により、デグレードを発生さ
せる事無く、特定３品種への対応を完了する事が出来た。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
3.評価と課題
----------------------------------------------------------------------
3.1.問題への対応結果と評価
----
　前述の通り、本番稼動時期を延期する事無く、プロジ
ェクトの問題を解決する事が出来た。これは、適切な調
査の指示、ユーザとの調整による結果であると判断する。

----
3.2.今後同様の問題を発生させないために
----
　一般的なプロジェクトがそうであるように、今回のプ
ロジェクトでも、ユーザの参画を、設計工程と、運用テ
スト工程としていた。しかしながら、今回の問題はユー
ザの視点があれば、単体テスト工程で抽出する事が可能
であったと判断する。

　これに対応する方法としては、我々システムインテグ
レータがユーザ業務を熟知し、単体テスト工程の精度を
上げる事が考えられる。しかしながら、益々短工期での
開発が求められる今日では現実的では無い。

　私は、ユーザ自身も単体テストに参画し、その結果を
確認する事が、同種の問題を再発させないための手段と
して最も有効であると考える。尚、これを実現するため
には、プロジェクトの基本計画で、システム側・ユーザ
側の役割分担・参画のタイミング等を確認・徹底してお
く必要があり、これはまさしくＰＭの役割であると考え
る。