サービス変更の計画

D社は，中堅の食品販売会社で，D社の営業部は，小売業者に対する受注業務を行っている。D社の情報システム部が運用する受注システムは，オンライン処理とバッチ処理で構成されており，受注サービスとして営業部に提供されている。

情報システム部には業務サービス課，開発課，基盤構築課の三つの課があり，受注サービスを含め複数のサービスを提供している。業務サービス課は，サービス運用における利用者管理，サービスデスク業務，アプリケーションシステムのジョブ運用などの作業を行う。開発課は，サービスの新規導入や変更に伴う業務設計，アプリケーションソフトウェアの設計と開発などの作業を行う。基盤構築課は，サーバ構築，アプリケーションシステムの導入，バッチ処理のジョブの設定などの作業を行う。

業務サービス課にはE君を含む数名のITサービスマネージャがおり，E君は受注サービスを担当している。業務サービス課では，運用費用の予算は，各サービスの作業ごとの1か月当たりの平均作業工数の見積りを基に作成している。運用費用の実績は，各サービスの作業ごとの1か月当たりの作業工数の実績を基に算出し，作業ごとに毎月の実績が予算内に収まるように管理している。運用費用の予算はD社の会計年度単位で計画され，今年度は，各サービスの作業ごとに前年度の1か月当たりの平均作業工数の実績に対して10％の工数増加を想定して見積もった予算が確保されている。

【D社の変更管理プロセス】

D社の変更管理プロセスでは，変更要求を審査して承認を行う。変更要求の内容がサービスに重大な影響を及ぼす可能性がある場合は，社内から専門能力のあるメンバーを集めて，サービス変更の計画から移行までの活動を行う。また，サービス変更の計画の活動では，①変更を実施して得られる成果を定めておき，移行の活動が完了してサービス運用が開始した後，この成果の達成を検証する。

【受注サービスの変更】

これまで営業部では，受注してから商品の出荷までに，受注先の小売業者の信用情報の確認を行っていた。このほど，売掛金の回収率を高めるという営業部の方針で，与信管理を強化することとなり，受注時点で与信限度額チェックを行うことにした。

そこで，営業部の体制増強が必要となり，取引実績のあるM社に営業事務作業の業務委託を行うことになった。

受注サービスの変更の活動は，情報システム部の業務サービス課，開発課及び基盤構築課が実施し，業務サービス課の課長がリーダーとなった。

システム面の実現手段として，ソフトウェアパッケージ販売会社であるN社から信用情報管理，与信限度額チェックなどの与信管理業務の機能をもつソフトウェアパッケージの導入提案を受けた。この提案によると，N社のソフトウェアパッケージをサブシステムとして受注システムに組み込み，与信管理データベースを構築することになる。また，受注システムのバッチ処理でN社の提供する情報サービスに接続し，信用情報を入手して与信管理データベースを毎日更新する。D社はこの提案を採用し，受注サービスを変更することにした。変更後の受注サービスは，今年度後半から運用を開始する予定である。

E君は，各課を取りまとめるサブリーダーとして参加し，受注サービス変更後のサービス運用における追加作業項目の洗い出しと必要な作業工数の算出を行う。

【追加作業項目の洗い出し】

E君は，今回の受注サービス変更後の，サービス運用における情報システム部の追加作業項目を検討した。その結果，E君は追加で次の作業項目が必要であることを確認した。

• 利用者管理の作業にサービス利用の権限を与える利用者としてM社の要員を追加する。また，サービスデスク業務の作業に利用者からの与信管理業務の機能についての問合せへの対応とFAQの作成・更新を追加する。
• 受注システムのバッチ処理に，"信用情報取得ジョブ"のジョブ運用を追加する。このジョブは，毎日の受注システムのオンライン処理終了後に自動的に起動され，起動後はバッチ処理のジョブフロー制御機能によってN社の提供する情報サービスに接続して，更新する信用情報を受信し，与信管理データベースを更新する。バッチ処理が実行されている間，業務サービス課の運用担当者が受注システムに対して行う作業はないが，N社の情報サービスへの接続，情報受信，及びデータベース更新のそれぞれの処理が完了した時点で，運用担当者は，処理が正常に完了したことを確認する。正常に完了していない場合には，開発課が作成したマニュアルに従い，再実行などの対応を行う。
• N社から，機能アップグレード用プログラムが適宜提供され，N社ソフトウェアパッケージの機能を追加することができる。営業部は，追加される機能の内容を確認し，利用すると決定した場合は業務変更のための業務設計と機能アップグレードの適用を情報システム部の開発課に依頼する。なお，機能アップグレードの適用は，テスト環境で検証した後，受注システムの稼働環境に展開する手順となる。
• また，N社からは機能アップグレード用プログラムのほかに，ソフトウェアの使用性向上や不具合対策用の修正プログラム（以下，パッチという）が，臨時に提供される。このパッチは業務に影響を与えることはなく，パッチの適用や結果確認の手順は定型化されている。

E君は，情報システム部の追加作業項目とその作業内容の一覧を，表1のとおり作成した。

E君は，表1をリーダーにレビューしてもらった。リーダーから，"表1の作業項目aには情報システム部が行う作業内容が漏れているので，追加するように"と指摘された。E君は，各チームで必要となる作業を再検討し，表1の作業項目aに②漏れていた作業内容を追加した。

【サービス運用に必要な作業工数の算出】

E君は，追加が必要な作業のうち，定常的に必要となる利用者管理，サービスデスク業務及びジョブ運用の作業工数を算出した。算出手順として，表2に示す受注サービスの変更前の作業工数の実績一覧を基に，変更後の作業工数を見積もった。なお，変更前の1か月当たりの平均作業工数の実績は，予算作成に用いた前年度の1か月当たりの平均作業工数の実績と同じであった。

E君は，関係者と検討を行い，追加で必要となる作業工数を算出する前提を次のとおりまとめた。

• 利用者管理及びサービスデスク業務の発生頻度は，今回予定しているM社の要員の利用者追加によって，それぞれ10％増加する。
• 与信管理業務の機能の追加によって問合せが増加するので，サービスデスク業務の発生頻度は，利用者追加によって増加した発生頻度から，更に5％増加する。
• 利用者管理及びサービスデスク業務について1回当たりの平均作業工数は変わらない。
• ジョブ運用について，信用情報取得ジョブは，現在のバッチ処理のジョブに追加されるので，その運用の発生頻度は，現在と変わらず月に20回である。ジョブ1回当たりのシステム処理及び運用担当者の確認作業の実施時間は表3のとおりである。

表2と，追加が必要となる作業工数算出の前提及び表3から，E君は，サービス変更後のサービス運用に必要な作業工数を算出した。作業工数の算出においては，ジョブ運用の1回当たりの平均作業工数は，表2の受注サービスの変更前の平均作業工数に表3の信用情報取得ジョブ1回当たりの実施時間から算出した作業工数の合計を加算した。なお，運用担当者は1日3交替のシフト勤務をしているので，作業時間の単位"分"を"日"に換算する場合は，情報システム部では480分を1日として計算する規定としている。算出結果を表4に示す。

E君は，サービス変更後の作業ごとの1か月当たりの平均作業工数を算出した結果，③ある作業には問題点があると考えた。その問題点についてリーダーと相談して対策方針を決め，対策を実施することになった。