平成29年春期試験午後問題 問9
問9 プロジェクトマネジメント
⇱問題PDF
システムの移行レビューに関する次の記述を読んで，設問1，2に答えよ。
システムの移行レビューに関する次の記述を読んで，設問1，2に答えよ。
広告
P社は，家電量販店を営む会社である。約20店舗での店頭販売に加え，インターネットや電話による通信販売を行っている。電話応対は，コールセンタに勤務する約50名のオペレータが，商品の注文受付，問合せ対応などの業務を行っている。
〔コールセンタの新CTIシステム開発プロジェクトの概要〕
現在P社で運用しているコールセンタのシステム(以下，現行システムという)は，コンピュータと電話を統合したCTIシステムであり，Q社が提供するソフトウェアパッケージ(以下，現行パッケージという)を導入している。現行システムは，顧客の属性情報や購買履歴などを管理するCRMシステムや商品在庫管理システムなどの関連システムと，オンライン処理又はバッチ処理でデータ連携している。
現行システムのハードウェアが年度末に保守期限を迎えるので，Q社が新たに開発したソフトウェアパッケージ(以下，新パッケージという)に更改することに決め，新CTIシステム(以下，新システムという)開発プロジェクトを立ち上げた。プロジェクトマネージャにはシステム部開発課のX課長が選任された。プロジェクトのスコープは，現行パッケージに施されていたP社独自のカスタマイズを新パッケージに取り込んで導入すること，及び既存の関連システムとデータ連携できるようにすることである。
今回，新たなP社独自のカスタマイズ要件はない。新パッケージでは，主要なデータベース(以下，DBという)の一つである顧客属性管理テーブルの一部のコードの値が細分化された。新システムでは，新パッケージのコードの値を使用するが，今回は関連システムとの接続仕様を変更せず，新パッケージのコードの値を現行パッケージのコードの値に変換してから関連システムに引き渡すことにした。新パッケージで細分化されたコードの値の例を，図1に示す。
〔移行判定会議の開催と報告〕
プロジェクトは順調に進み，システム適格性確認テスト(以下，システムテストという)，運用者による受入れテスト(以下，運用テストという)及び利用者による受入れテストが終了したので，新システムへの移行の可否を判定する会議(以下，移行判定会議という)を開催することになった。X課長は，前工程のソフトウェア適格性確認テストの終了判定会議への出席者に加え，プロジェクトオーナであるE常務，プロジェクト責任者であるシステム部のF部長，営業部のG部長，及び①コールセンタの責任者であるHセンタ長に出席を依頼するように，部下のW君に指示した。
移行判定会議では，各担当リーダーから次のとおり報告があった。
〔移行判定会議での指摘事項〕
各担当リーダーからの報告後，次の質疑応答があった。
また，X課長は，F部長からの指摘を受けて，新システムが安定稼働していることを確認した後に実施すべきであるeの計画を策定することにした。そこで，運用及び保守の組織だけでなく利用者も参加させて，この活動を開始した。
〔コールセンタの新CTIシステム開発プロジェクトの概要〕
現在P社で運用しているコールセンタのシステム(以下，現行システムという)は，コンピュータと電話を統合したCTIシステムであり，Q社が提供するソフトウェアパッケージ(以下，現行パッケージという)を導入している。現行システムは，顧客の属性情報や購買履歴などを管理するCRMシステムや商品在庫管理システムなどの関連システムと，オンライン処理又はバッチ処理でデータ連携している。
現行システムのハードウェアが年度末に保守期限を迎えるので，Q社が新たに開発したソフトウェアパッケージ(以下，新パッケージという)に更改することに決め，新CTIシステム(以下，新システムという)開発プロジェクトを立ち上げた。プロジェクトマネージャにはシステム部開発課のX課長が選任された。プロジェクトのスコープは，現行パッケージに施されていたP社独自のカスタマイズを新パッケージに取り込んで導入すること，及び既存の関連システムとデータ連携できるようにすることである。
今回，新たなP社独自のカスタマイズ要件はない。新パッケージでは，主要なデータベース(以下，DBという)の一つである顧客属性管理テーブルの一部のコードの値が細分化された。新システムでは，新パッケージのコードの値を使用するが，今回は関連システムとの接続仕様を変更せず，新パッケージのコードの値を現行パッケージのコードの値に変換してから関連システムに引き渡すことにした。新パッケージで細分化されたコードの値の例を，図1に示す。
プロジェクトは順調に進み，システム適格性確認テスト(以下，システムテストという)，運用者による受入れテスト(以下，運用テストという)及び利用者による受入れテストが終了したので，新システムへの移行の可否を判定する会議(以下，移行判定会議という)を開催することになった。X課長は，前工程のソフトウェア適格性確認テストの終了判定会議への出席者に加え，プロジェクトオーナであるE常務，プロジェクト責任者であるシステム部のF部長，営業部のG部長，及び①コールセンタの責任者であるHセンタ長に出席を依頼するように，部下のW君に指示した。
移行判定会議では，各担当リーダーから次のとおり報告があった。
- システムテストの実施結果及び評価(報告者：X課長)
- システムテストの実施と検証，及び検出したバグの対応を完了した。バグ検出件数，バグ検出密度ともP社の品質基準を満たした。バグの検出状況を分析した結果，異常はなかった。
- システムテストは，新システムが稼働を予定している環境を使用して実施した。性能テストでは，関連システムも時間帯を調整して稼働環境を使用する予定であったが，商品在庫管理システムだけは時間帯の調整ができなかった。商品在庫管理システムのテスト環境の構成を調べたところ，性能テストをテスト環境で実施しても問題ないと判断できたので，稼働環境と同一のソフトウェアとDBをコピーしてテストを行った。
- 業務機能のテストでは，業務要件に基づく業務フローの正当性を，関連システムを含めて検証した。さらに，新システムで現行機能が正しく動作することを保証するために，新パッケージにおけるコードの値の細分化を考慮した上で現行システムと新システムに同一データを投入し，主要なテーブルの処理結果を比較した。②顧客属性管理テーブルのコードの値を自動的に比較するために，比較検証ツールを作成して検証を行った。結果は良好であった。
- 性能要件やデータボリューム要件など，aを満たしていることを検証するテストでの実測結果は目標値を満たし，システム全体の処理性能やデータボリュームに関する問題はなかった。
- 新システムのメンテナンスマニュアルを整備し，保守チームに引き継いだ。
- 運用テストの評価(報告者：システム部運用課C課長)
- システム部運用課の担当者も参加してテストを行い，結果は良好であった。
- 新システムの運用スケジュール，手順書，障害発生時の連絡体制など，必要なドキュメントを全て作成し，システム運用担当者に説明済みである。
- 利用者による受入れテストの評価(報告者：X課長，コールセンタDリーダー)
- 顧客属性管理画面のレイアウトが見づらいなどの指摘が2件あった。業務運用への影響は軽微なので，稼働後にプログラムを改修することを条件にHセンタ長から了承を得た。これらは，申し送り事項として管理する(X課長)。
- 新システムを使用して業務運用を行った。新パッケージの新機能や関連システムとの連動処理など，全ての業務を問題なく実施することができた(Dリーダー)
- 利用者訓練の状況と評価(報告者：Dリーダー)
- コールセンタのオペレータの運用訓練を完了した。訓練のカリキュラムに従った業務運用を行い，参加者全員が一定の水準に達した
- 新システムの業務オペレーションマニュアルを整備した。
- 移行計画(報告者：X課長)
- 稼働開始前日の業務終了後，現行システムから新システムへ移行する。
- 稼働開始日の午前9時に，新システムのサービスを開始する。
- 移行作業に必要な時間は，十分に確保している。
- 新システムの稼働開始日に，現行システムの運用を停止する。
- bの達成度確認(報告者：F部長)
- 新システムの品質と性能，利用者の業務運用の習得度が，移行可能な基準に達しており，移行作業の準備が十分であることを確認した。
〔移行判定会議での指摘事項〕
各担当リーダーからの報告後，次の質疑応答があった。
- G部長：
- 新システムへの移行及び稼働開始時に，不測の事態が発生した場合のcとその発動条件を定めていますか。
- X課長：
- はい。F部長に承認していただいたものを，文書化して共有しています。
- F部長：
- 性能テストで，商品在庫管理システムはテスト環境を使用して実施しても問題ないと判断した理由を説明してください。
- X課長：
- 商品在庫管理システムのテスト環境の構成を調べ，dであることを確認できたからです。
- F部長：
- ③新システムの稼働後に行うシステム関連作業を整理してください。
- X課長：
- 承知しました。引継ぎが必要な場合は，打合せを設定します。
また，X課長は，F部長からの指摘を受けて，新システムが安定稼働していることを確認した後に実施すべきであるeの計画を策定することにした。そこで，運用及び保守の組織だけでなく利用者も参加させて，この活動を開始した。
広告
設問1
〔移行判定会議の開催と報告〕について，(1)～(3)に答えよ。
解答群
- オペレータが新システムで業務を行えると判断したことを報告するから
- コールセンタ業務への指摘事項に対するシステムの改修を指示するから
- 新システム稼働後の顧客満足の向上施策結果を報告するから
- 利用者による受入れテストの評価に基づいて，システム品質が妥当であると判断したことを報告するから
- 利用部門の責任者として，新システムへの業務要件を要求するから
a，b に関する解答群
- QMS
- WBS
- 機能要件
- ソフトウェア導入基準
- 導入可否判断基準
- 非機能要件
解答例・解答の要点
- ア ※順不同
エ ※順不同
- 新パッケージのコードの値を現行パッケージのコードの値に変換する (31文字)
- a：カ
b：オ
解説
CTI(Computer Telephony Integration)は、コンピュータと電話をつなぎ、電話番号をもとに顧客情報の表示や通話の録音などを行うシステム、CRM(Customer Relationship Management)は、日本語では「顧客関係管理」の意味です。- 移行判定会議は、新システムの品質が本番稼働できる水準に達したことなどを関係者間で確認し、移行可否を判断する場となります。
Hセンタ長は、新しいCTIシステムの利用部門であるコールセンタの責任者であることから、コールセンタでの業務を新システムで行うことに対して支障がないことの報告を受ける立場として、出席者に選定されたことを表す選択肢が回答となります。- 正しい。
- システムの改修をすべき事案が生じたときに指示するのは、プロジェクトマネージャであるX課長です。
- 移行判定会議は新システム稼働前に行うため、稼働後の施策については報告できません。
- 正しい。
- 業務要件の要求は要件定義のフェーズで行うことですので、移行判定会議で要求すべき事項ではありません。
- 比較検証ツールは、同一データから作成された現行システムと新システムの主要テーブルの同一性の確認に際し、顧客属性管理テーブルのコードの値を自動的に比較するためのツールです。
新システムでは、細分化された職業分類のコード値を使用しますが、「関連システムとの接続仕様を変更せず，現行パッケージのコード値に変換してから関連システムに引き渡す」という条件があるので、業務機能のテストでは、現行パッケージのコードの値を用いて業務フローを確認したことがわかります。
主要なテーブルの処理結果の比較は、新システムで現行機能が正しく動作することを保証することを目的として行われ、同じデータを投入したときに各テーブルの値が同一になるかを照合比較します。現行パッケージと同じテーブルが作成されれば、業務機能のテストの結果に基づき正しく動作することが保証されるというわけです。
新パッケージでは、職業分類のコード値が細分化されているため、主要テーブルの処理結果を自動的比較検証するツールには、新パッケージのコードの値（11・12）を現行パッケージのコードの値（10）にする変換する機能が必要です。
∴新パッケージのコードの値を現行パッケージのコードの値に変換する - 〔aについて〕
非機能要件とは、性能や信頼性、保守性、拡張性、セキュリティなどのように、システム自体に求められる業務要件や入出力など以外のもの全般を指します。性能要件やデータボリューム要件は、システムの動作や機能を定義したものではなく、機能面以外の部分を定義したものとなるため、非機能要件が該当します。
∴a＝カ：非機能要件
〔bについて〕
この会議の報告内容であり、本問の対象となっている達成度確認は、新システムの品質と性能に加え、利用者の習熟度も判断の基準となっていることから、新システムの導入に関する内容であることがわかります。
〔移行判定会議の開催と報告〕にて、「新システムへの移行の可否を判定する会議」という記載があるため、「導入可否判断基準」が該当します。
∴b＝オ：導入可否判断基準
広告
設問2
〔移行判定会議での指摘事項〕について，(1)～(4)に答えよ。
- 本文中のcに入れる適切な字句を答えよ。
- 本文中のdに入れる適切な字句を，25字以内で述べよ。
- 本文中の下線③について，ソフトウェアの保守作業担当者に引き継ぐべき事項を，30字以内で述べよ。
- 本文中のeに入れる適切な字句を，15字以内で答えよ。
解答例・解答の要点
- c：緊急時対応計画
- d：テスト環境の容量・能力が稼働環境と同等 (19文字)
- 利用者による受入れテストで指摘されたプログラム改修 (25文字)
- e：現行システムの廃棄 (9文字)
解説
- 〔cについて〕
不測の事態が発生した場合に発動するものであることから、コンティンジェンシープラン(Contingency Plan)とも呼ばれる「緊急事態対応計画」が当てはまります。
万が一の不測の事態が発生した際に、プロジェクトや事業が被る被害を最小限にとどめて、速やかに復旧できるようにしておくために、あらかじめ対応策を講じる計画を立てます。特に金融機関や政府など被害を被った際に甚大な被害が想定されるケースでは、必要性が高いとされています。
BCP(事業継続計画)やディザスタリカバリも同様に緊急時における対応策を定めるものですが、どちらも予期しない災害等からの復旧計画であるため不適切です。
∴c＝緊急時対応計画 - 〔dについて〕
商品在庫管理システムは唯一、稼働予定の環境での性能テストができず、テスト環境で性能テストを行ったシステムとなります。システムテストは可能な限り本番環境と同一の環境を行うべきですが、これができないときにはテスト環境で行うことになります。
性能テストとは、実際に稼働する状況に近い環境でシステムを動作させ、応答時間やリソースの消費量等のパフォーマンスを検証するテストなので、有効なテストとするためにはテスト環境の能力（処理能力やメモリ・記憶装置等の容量）が稼働予定の環境と同等であることが要件となります。
∴d＝テスト環境の容量・能力が稼働環境と同等 - 移行判定会議の、利用者による受け入れテストで挙がった2件の指摘については、稼働後にプログラムを改修することが条件となっており、これを「申し送り事項として管理する」と記載されています。
組織の規模や体制によっては、開発チームと同じメンバーで保守・運用を行う場合もありますが、ローンチの後からは保守・運用チームが主立ってメンテナンスをしていくことになります。プロジェクトマネージャであるX課長は、運用・保守を行う組織に、この事項を引き継ぐ必要があります。
∴利用者による受入れテストで指摘されたプログラム改修 - 〔eについて〕
本文中に「運用及び保守の組織だけでなく…」とあることから、eの計画は、本来運用・保守プロセスで行われるべきことであるとわかります。
また、本問のパッケージ導入のきっかけは、ハードウェアの保守期限到来が理由となっています。ハードウェアの保守期限が切れた場合、使用し続けることは故障やセキュリティ面でのリスクを抱える場合もあります。本問での現行システムのハードウェアについては、再利用する計画は含まれていないので、廃棄の手続きをとることになります。
よって、eには現行システムの廃棄が入ります。
廃棄計画は、計画の立案、スケジュールの検討、利用者部門への通達、実行の順に行われることが一般的です。本問ではハードウェアの種類は明記されていませんが、データを保持するハードウェアの場合は、破棄した後にデータの移行漏れが発覚したとしても再取得できなくなるため、廃棄を想定した移行計画を立てなければなりません。新システムが安定稼働していることを確認したあとに行われるのは、こうした理由からです。また、旧ハードウェアを廃棄しない場合は、新システムの予備系として再利用される場合もあります。
∴e＝現行システムの廃棄
広告
広告