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

Ａ社生産管理システムのダウンサイジングにおけるパイロット開発

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


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1.情報システムの概要とパイロット開発の目的
----------------------------------------------------------------------
1.1.情報システムの概要とダウンサイジング計画
----
　Ａ社は電子部品を製造するメーカであり、メインフ
レーム上に生産管理システムを稼動させていた。システ
ムは構築されてから２０年が経過しており、老朽化・保
守コストの肥大から、ＰＣサーバへのダウンサイジング
が計画された。尚、ダウンサイジングの方式としては、
コスト・工期を再優先したことから、既存のビジネスロ
ジック・プログラムを活かしたままＰＣサーバへの移行
する方式（以下、リホストと略す）が採用された。

　私はＮ社のアプリケーションエンジニアとして詳細設
計より、当プロジェクトに参画した。

----
1.2.本開発に当たって想定した課題
----
　ダウンサイジングにあたっては、Ａ社の経営・工場操
業を担う基幹業務システムである・ＦＡとも連動してい
るなどの理由から、安定稼動させることは勿論、レスポ
ンスを保証することも重要な要件であった。

　私はリスク分析を行い、本開発に当たって想定される
大きな課題として、以下を洗い出した。

a.プログラムの誤作動
　リホストを前提としているが、実行環境の差異により、
既存のプログラムが期待通りの動作をしない。

b.安定性の保証
　基本的に月に１度の計画停止を除き、２４時間３６５
日の稼動を求められているが、メインフレーム並みの安
定性を保証することができない。

c.レスポンスの保証
　ハードウェア・ソフトウェアの差異により、既存シス
テムと同等のレスポンス保証を行うことができない。


----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.パイロット開発の内容
----------------------------------------------------------------------
2.1.開発対象の絞込み
----
　前述の全てのリスクに対してパイロット開発を行い、
リスクを低減することは、コスト・スケジュールの観点
から現実的では無い。私はパイロット開発で取り組むべ
き対象を絞り込む必要があると考え、リスクの再評価に
取り組んだ。

a.プログラムの誤動作
　前述の通り、同一のプログラムであっても、実行環境
の差異により、プログラムの動作結果が異なる可能性が
ある。これは特にコンパイラ・コード体系の差異により
発生するが、事前に洗い出しが可能であり、パイロット
開発は不要であると判断した。

b.安定性の保証
　安定性ついては、ハードウェアの２重化とクラスタリ
ングソフトウェアで対応することを計画していた。基本
的に実績のある構成であり、ＰＣサーバであるが故にリ
スクとされる、耐障害性については対策が可能であると
判断した。

c.レスポンスの保証
　レスポンス保証については、ハードウェアの差異もさ
ることながら、ソフトウェア・アプリケーションに依存
する部分も大きい。例えば、以下が挙げられる。

- メインフレームのデータベースとしては階層型を使用
しており、ＤＢＭＳの制約や処理効率の観点から正規化
もされていない。

- しかし、プロジェクトでは、将来的なメンテナビリ
ティを考慮した結果、正規化に取り組むことを要件とさ
れていた。

- この要件に対して私は、ミドルソフトウェアの開発に
より、正規化されたデータベースと従来データベースと
のレイアウト変換を行い、既存プログラムへ提供するこ
とを検討していた。　つまり、ミドルソフトウェアの性
能がレスポンスを左右する大きな要因となる。

　以上より、レスポンス保証というリスクに対して、特
にミドルソフトウェアの部分に限定してパイロット開発
に取り組むことを決定した。

----
2.2.パイロット開発の目的
----
　パイロット開発の目的は以下の通りである。

a.行き過ぎた正規化は性能劣化に繋がる可能性があるた
め、正規化を行うレベルを見極める。

b.プログラムはリホストを前提としているので従来の
データベースレイアウトが必要になり、これはミドルソ
フトウェアにより提供される。しかし、正規化された
データベースから従来レイアウトを提供するためには、
多くの結合処理が必要となり、レスポンスを保証するこ
とは容易では無い。もしも、従来レイアトとレスポンス
を同時に保証することが難しい場合、必要項目を絞った
新レイアウトを提供することになり、これは既存プログ
ラムの修正を伴うため、必要な修正規模を見極める。

c.両者のバランスを図り、正規化によるシステムの将来
性と、リホストを選択した低コスト開発を両立できる閾
値を見極める。

----------------------------------------------------------------------
3.パイロット開発の工夫
----------------------------------------------------------------------
a.対象となる処理の切り出し
　パイロット開発対象はミドルソフトウェアの性能検証
である。しかし、パイロット開発の性格からも、ミドル
ソフトウェアの最終形である全テーブルを対象にした汎
用品を作成する訳にはいかない。そこで私は、既存の
テーブルを、レコード長・項目数等で層別分析を行い、
９テーブルを対象に開発を行うこととした。

b.目標値の設定
　従来のメインフレームのオンライン処理では３秒以内
のレスポンスを保証していた。これはレスポンスタイム
であり、実際の内部処理、特にＩ／Ｏ処理の所要時間を
測定する必要があった。オンライン処理は基本的に１件
単位の処理であり、Ｉ／Ｏ処理が２秒であろうと、
１．５秒であろうとレスポンスに大差はない。しかし、
この僅かな差でさえ、ミドルソフトウェアの評価には欠
かせないことから、私は既存メインフレームのオプショ
ンである、更新前後ジャーナルよりＩ／Ｏ処理の所要時
間を分析し、目標値を設定することとした。しかし、更
新前後ジャーナルの取得はレスポンスを低下させる懸念
があることから通常は使用されておらず、容量の関係か
らも長期間の採取はできない。従って私は、適当なバラ
ツキを求めるために、ある一日全て・平日・休日・日中・
夜間等幾つかの絞り込みを行った上でジャーナルを採取
し、ばらつきを調べ、目標値を２秒と定めた。

c.開発環境の整備
　開発環境として用意されていたデータベースサーバは、
本番機より２割程度性能が劣っていたが、パイロット開
発時点では本番時に使用する予定のデータベースサーバ
が利用できない。ベンダに短期借用の協力を要請する方
法もあったが、プロジェクトマネージャと相談した結果、
性能評価結果が厳しい方向に偏るリスクを持っているだ
けで、保証という観点では大きなリスクにはならないと
判断し開発環境をそのまま使用した。


----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
4.パイロット開発の評価
　パイロット開発の結果、３０テーブルを超える結合処
理を伴う正規化は避けるべきであるとの結論を得た。こ
れを超える可能性がある場合には、正規化の条件を緩め
る、もしくはプログラムを修正し、必要な部分だけを
Ｉ／Ｏできる新レイアウトに対応させることとなる。本
開発に際しては、事前にこれらの標準を用意できたこと
で、混乱を避けることができた。これは、パイロット開
発の取組が奏効していると評価する。

　但し、パイロット開発で定めた標準は開発環境での性
能評価結果をベースとしており、本番機によるシステム
テスト時の結果から評価すると、やや厳し目に設定して
しまったと言わざるを得ない。性能評価を目的としたパ
イロット開発では極力本番と同等の環境を再現するべき
であり、今後はプロジェクトマネージャに働きかけてい
きたいと考えている。