2019年 春期 応用情報技術者試験 問9

システム更改プロジェクトのスケジュールの作成

P社は、家電製品の製造・販売を行う中堅企業である。これまでオンプレミスで運用してきた会計システムと人事給与システムが、更改時期を迎えた。P社では、開発コストと運用費用の削減、及び事業継続性の確保を図るために、両システムともクラウドサービスを利用して更改することになった。そこで、情報システム部のQ部長は、クラウドサービスを提供する発注先候補に対して、提案依頼書を発行し、具体的な提案を求めた。

数社から提出された提案書を評価した結果、会計システムはR社が製造業向けに提供しているSaaSを、人事給与システムはR社の提供しているPaaSを、それぞれ利用することにした。R社のクラウドサービスでは、セキュリティが強化された新しいOS（以下、新OSという）と新しいミドルウェア（以下、新MWという）を採用している。

Q部長は、両システムを更改するプロジェクトのプロジェクトマネージャにS課長を指名し、120日以内にシステム更改を完了させることをプロジェクト目標の一つとして、作業内容を整理して、スケジュールを作成するよう指示した。

[システム更改の作業内容の整理]

更改する両システムを利用する部署からの要求は、次のとおりである。

• 会計システムを主に利用する経営企画部と経理部は、各種の財務データを取得、集計、分析するSaaSの機能について、P社向けに一部の改修を要求している。両部は、"この改修を加えれば、十分に業務に適合可能である"と判断している。
• 人事給与システムを主に利用する総務人事部は、"P社特有の人事制度及び職位に基づく給与体系への対応と、プログラムを改修することなく、人事評価区分及び給与区分の追加・削除ができること"を要求している。

これらの要求は、情報システム部の支援の下、要件定義書としてまとめられた。S課長はまず、要件定義書に基づき、システム更改の作業内容を次のとおり整理した。

(1) 会計システムの更改

• P社の経理業務に適合させるために、R社のSaaSに対して小規模のカスタマイズを行う。

(2) 人事給与システムの更改

• 総務人事部の要求に対応するために、現行の人事給与システムのソフトウェアを改修して、R社のPaaSに配置し、実行できるようにする。
• ソフトウェアの改修は、R社のPaaSを利用し、P社の情報システム部の開発要員だけで、全ての作業を行う。
• ソフトウェアは、人事、給与及び共通の三つのモジュールで構成され、全てのモジュールのプログラムを改修する必要がある。各モジュールとも改修の規模及び改修の難易度は同等である。

[システム更改スケジュールの作成]

次に、S課長は、システム更改スケジュールを明確にするために、プロジェクトで実施すべき作業項目と成果物（文書）を洗い出して、表1の作業一覧を作成した。

人事給与システムの外部設計からプログラム製造・単体テストまでの各作業項目では、設計チーム及び製造チームは、三つのモジュールに対応して、両チームとも4人ずつの三つのグループに分ける。三つのグループとも、生産性は同じである。三つのグループは、同時に作業を開始し、それぞれ並行して作業を行う。作業が完了した後は、既に計画されている他のプロジェクトの作業を行う。

また、ソフトウェア設計とプログラム製造・単体テストについては、各作業項目とも全グループの作業が完了した時点で、S課長が成果物の品質を判定する。良好と判定されると、各チームは次の作業に着手するルールにする。

続いて、S課長は、表1の作業一覧に基づいて、図1の作業工程図を作成した。

S課長が、表1の作業一覧と図1の作業工程図について、Q部長に説明したところ、会計システムの更改においては、①フィット&ギャップ分析が完了した時点で、必要に応じて作業一覧と作業工程図を修正するよう、指示があった。

[システム更改スケジュールの見直し]

会計システムのフィット&ギャップ分析が完了した時点で、作業一覧と作業工程図の見直しは、不要であると判断された。

一方、人事給与システムの外部設計の途中で、総務人事部から、"人事評価区分及び給与区分の見直し時期を早めるので、開発期間を短縮してほしい"という要請があった。そこで、S課長は、作業IDのB3からB5までの連続する作業の経路が、cの一部となるので、人事給与システムのソフトウェア設計からソフトウェア適格性確認テストまでの作業を対象として、クラッシング及びファストトラッキングの考え方を用いて、開発期間を短縮することにした。開発期間を短縮できた場合には、P社の事業運営において、1日当たり5万円のコストの削減が見込まれる。

開発期間の短縮案として、開発要員を追加して作業計画を見直す案（以下、案1という）と開発要員を追加しないで作業計画を見直す案（以下、案2という）を評価して、採用する案を決定することにした。

S課長は、案1と案2の評価に当たっては、次の前提を置いた。

(1) 案1

• 新OSと新MWの環境でのシステム開発経験がある開発要員を設計チーム、製造チームにそれぞれ10人ずつ追加し、設計チーム、製造チームとも22人の体制で、ソフトウェア設計からソフトウェア適格性確認テストまでの作業を行う。
• 追加する開発要員の生産性は、業務要件を理解するのに必要な時間を考慮して、当初計画の80%で見積もる。
• 開発要員を追加した場合の三つのグループの生産性は同じである。
• 開発要員の追加によって増加するコストは、当初の開発要員と同じく、工数1人日当たり5万円とする。

(2) 案2

• 開発要員を追加しないで、設計チーム、製造チームとも12人の体制のまま、ソフトウェア設計からソフトウェア適格性確認テストまでの作業を行う。
• 人事給与システムの設計チーム、製造チームの開発要員は、既に計画されている他のプロジェクトの作業に優先して、人事給与システムの作業に参加するよう調整する。
• 既に計画されている他のプロジェクトの作業が遅延し、P社の事業運営において増加するコストを150万円と見積もる。
• 当初の予定どおり、人事給与システムのソフトウェア設計の作業は設計チームが担当し、プログラム製造・単体テストの作業は、製造チームが担当する。両チームとも、それぞれ一つのグループで作業を行う。当初の計画では、三つのモジュールについて、同時に作業を開始し、それぞれ並行して作業することにしていたが、この方式をやめて、両チームとも、人事、給与、共通のモジュールの順に作業を行う。一つのグループで行っても作業効率は、当初と変わらない。これによって、ソフトウェア設計の作業が全て完了する予定であった日の16日前から並行してdの作業を開始することができ、開発期間が短縮できる。

S課長は、これらの前提に基づき、案1と案2の評価を表2のように整理した。

S課長は、この評価を基に、総務人事部と話し合った結果、増加コストを考慮して、案2を採用することにした。そこで、S課長は、開発期間の短縮を確実に実現するために、設計変更が発生した場合には、プロジェクト内で直ちに情報を共有するルールを設定するとともに、ソフトウェア設計及びプログラム製造・単体テストの各作業項目において、②成果物の品質判定のタイミングを見直すことにした。