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

（システムの運用におけるユーザ部門の役割分担について）

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


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１システム構築の背景
----------------------------------------------------------------------
１．１当社の問題点
----
　当社は従業員数３００名のシステム運用会社である。
　当社は親会社であるＡ社が開発したシステムの運用構
築及び２４時間運用を主業務としている。

　私の所属している部署では主にホストコンピュータの
バッチ処理のスケジュール管理と成果物客先への納品を
行っている。

　近年、バッチ処理に使用する直接アクセス記憶装置（
以下ＤＡＳＤ）の容量不足を原因とする障害が多発して
いた。障害による対応の為のコスト増、障害による成果
物の納品遅延による顧客への信用低下が部署内で問題と
なっていた。

----
１．２システム構築の目標と私の役割
----
　当部署が運用しているシステムで使用する全てのシス
テムリソースは親会社であるＡ社が用意している。これ
まではＤＡＳＤの容量不足が発生した都度、ＤＡＳＤの
追加をＡ社に依頼していた。

　このような運用方法では容量不足を起因とする障害が
未然に防げないため、新しい運用方法とそのシステムを
作成する必要があった。当部署は容量不足を起因とする
障害の５０％削減を目標に短期のプロジェクトチームを
結成することとなった。私はプロジェクトチームのサブ
リーダーとしてシステムの構築及び親会社との運用方法
に関する調整を行った。


----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２システムと運用の構築　
----------------------------------------------------------------------
２．１ＤＡＳＤの種類
----
　ＤＡＳＤは使用目的により以下の３つに区分けされてい
る。
a.パブリック
　プログラムの処理（ソート等）で使用される。プログラ
ム実行後はデータは消去される。

b.ストレージ
　長期間保存する必要のないデータを保存する為に使用さ
れる。その為、半日に一回全てのデータを消去する。

c.プライベート
　長期間保存する必要あるデータを保存する為に使用され
る。その為、任意の消去プログラムを実行しない限りデー
タは消去されない。また、この区分に関しては従来Ａ社が
管理していたが容量不足の障害が多発している。

----
２．２Ａ社との取り決めの変更
----
　容量不足が発生してからＡ社にＤＡＳＤの増強依頼をす
るという運用ではなく、あらかじめ予想される必要容量を
月次報告書でＡ社に提出し事前にＤＡＳＤを準備してもら
う運用に変更する必要があった。

　そこで、私はＡ社のシステムリソースを管理する部署の
課長にアポイントメントをとり、当社の運用改善案を話し
た。Ａ社の課長も近年多発する容量不足に関する障害を問
題視しており協力を約束してくれた。そして以下の点につ
いて注意して月次報告書を作成して欲しいと依頼された。

・ＤＡＳＤを用意する為に半年程度かかるため、余裕容量
　を１年程度で見積もって欲しい。
・区分プライベートに関しては今後は当社で管理をして欲
　しい。

　以上の点に留意し私たちはシステムの開発を進めることと
なった。

----
２．３システムの開発
----
　ＤＡＳＤの容量を実績を収集するシステムの導入案として
２案が考えられた。外部ベンダーのアプリケーションの導入
する案と既存の基幹データを加工するプログラムを部内で内
製する２案があった。外部ベンダーに見積もり求めるとを機
能的には大変優れていたが約２０００万円との回答だった。

　部内で内製する場合、機能的には限定されるが月次報告書
を作成する為には十分なシステムを構築でき３００万円で作
成することができると見積もりがでた。費用対効果を考え内
製することに私たちは決定した。

----
２．４処理追加時の受入条件の変更
----
　区分けされたＤＡＳＤはそれぞれ特性が異なる為違った
対応をとる必要があった。「a.パブリック」と「b.ストレ
ージ」に関しては急激にその使用率が圧迫されることがな
い為、月次報告書をＡ社に提出し必要容量を事前に追加し
てもらう事で問題は解決するが「c.プライベート」に関し
ては新しい処理を増加するタイミングで事前に準備する事
とした。方法としてはＡ社から新規処理の運用を受け入れ
る際、保存先のＤＡＳＤの容量を記入してもらい対象の
ＤＡＳＤに十分な容量があるかシステムでチェックし足り
なければＤＡＳＤの追加を依頼することとした。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３システムの評価と対応策
----------------------------------------------------------------------
　内製したシステムで作成した月次報告書はＡ社の課長の
要求定義を押さえておりＡ社にも好評だった。事前にＡ社
の要求定義を確認しておいた事が良かったと自分では評価
している。

　目標としていた容量不足を起因とする障害の５０％削減
も結果は７０％の削減と目標以上の数値を上げることがで
きた。また副次的なものとしてＡ社の開発担当者は直接シ
ステムリソースを管理していなかった為、リソースに関す
る意識が低く処理に無駄な容量を使用しているケースが多
々あったが月次報告書を提出するようなってからは、そう
いったケースが目に見えて減った。

　今後の改善点としてはシステムを構築してから得たデー
タを基に予測値の精度の向上を目指したい。

以上