応用情報技術者試験 過去問 2019年（令和元年） 秋期 午後 問9
複数拠点での開発プロジェクト
SI企業のS社は，住宅設備機器の販売を行うN社から，N社で現在稼働中の販売管理システム（以下，現行システムという）の機能を拡張する開発条件を受注した。
現行システムは，S社の第一事業部が数年前に開発したものである。
今回の機能拡張では，新たにモバイル端末を利用可能にするとともに，需要予測，及び仕入管理における自動発注機能を追加開発する。自動発注機能は，現行システムの発注処理の考え方に基づき開発する必要がある。
東京に拠点がある第一事業部には，現行システムを開発した部門と，モバイル端末で稼働するアプリケーションソフトウェア（以下，モバイルアプリという）の開発に多数の実績をもつ部門がある。一方，大阪に拠点がある第二事業部には，需要予測などに関する数理工学の技術をもつ部門がある。
この開発条件に対応するプロジェクト（以下，本プロジェクトという）には，S社の各部門が保有する技術を統合した開発体制が必要なので，事業部横断のプロジェクトチームを編成することが決定した。プロジェクトマネージャには，第一事業部のT主任が任命された。
なお，本プロジェクトは1月に開始し，9月のシステム稼働開始が求められている。
開発対象システムと開発体制案
本プロジェクトの開発対象システムを図1に示す。本プロジェクトでは，在庫管理と売上管理の改修はない。
T主任は，本プロジェクトの開発体制を，全てS社の社員で構成される二つの開発チームで編成する方針とした。モバイルアプリの開発，モバイルアプリ接続機能の開発及び自動発注機能を組み込むための仕入管理の機能拡張を，第一事業部の東京チームが担当する。また，需要予測と自動発注機能を，第二事業部の大阪チームが開発する。
T主任の方針を受けて，各事業部は，本プロジェクトに割当て可能な開発要員案を提示した。T主任は，提示された案でプロジェクトの遂行に支障がないかを検証するために，各要員の開発経験などを確認するためのヒアリングを行った。提示された開発要員案とT主任が行ったヒアリングの結果は，表1のとおりである。
| 開発チーム | 開発対象 | 開発要員案 | ヒアリングの結果 |
|---|---|---|---|
| 東京 | モバイルアプリ（新規開発） | モバイルアプリの開発経験がある人社 2～5年ほどの若手社員複数名 | ・現行システムの開発に関わった要員はいない。 ・過去の開発案件では，顧客との仕様や設計内容の検討結果が担当者のメモ書きだけで残され，開発文書の更新からもれることがあった。 |
| モバイルアプリ接続機能（新規開発） 仕入管理（既存機能拡張） |
現行システムを開発したベテラン社員複数名 | ・現行システムの開発経験者を，余裕をもたせて割り当てている。 ・文書管理では，文書名称，格納方法，版管理の規則を定め，その実施を徹底している。 |
|
| 大阪 | 需要予測（新規開発） | 数理工学のスキルをもつ中堅社員複数名 | ・現行システムの開発に関わった要員はいない。 ・本プロジェクトの開始前に顧客の需要データを分析している。 |
| 自動発注機能（新規開発） | 自動発注機能の開発経験者であるベテラン社員複数名 | ・現行システムの開発に関わった要員はいない。 ・流通業務のノウハウの蓄積がある。 |
プロジェクトマネジメントの方針
T主任は，開発要員案でプロジェクトの遂行に支障があれば，事業部間で必要な要員の異動を行う考えであった。
T主任は，ヒアリングの結果を踏まえて，①不足するスキルを補うため，本プロジェクトの開発要員案の範囲内で，最小限の要員異動をして適切な開発チームを編成することにした。その上で，両開発チームが作成する成果物に対する品質保証の活動を徹底することにした。そこで，T主任は，次のプロジェクトマネジメントの方針を策定した。
- 両拠点からアクセス可能なファイルサーバを導入し，成果物を格納する。
- 各開発作業の成果物のaが明確になるように，成果物のサンプルを提示し，記述の詳細度，レビュー実施要領などについて，プロジェクト全体で認識を合わせる。
- モバイルアプリ開発ではプロトタイピングで，ソフトウェア要件を早期に確定する。ソフトウェア方式設計で作成した設計書に要件が反映されていることを確認するために，ソフトウェア詳細設計では，ソフトウェア結合のテスト設計に利用するbを作成する。
- 両開発チームでソフトウェア要件定義の作業の進め方が異なるので，N社とのやりとりでは，ソフトウェア開発とその取引の明確化を可能とするcの用語を用い，開発作業の解釈について誤解が生じないようにする。
T主任は，このプロジェクトマネジメントの方針を上司に説明した。その際，上司から，"複数拠点での開発であることを考慮し，拠点間でコミュニケーションエラーが発生するリスクへの対応を追加すること。"との指示を受けた。T主任は，上司の指示を受けて，次の開発方針及びプロジェクトマネジメントルールを作成して，本プロジェクトを開始した。
- ②各機能モジュール間のインタフェースが疎結合となる設計とする。
- 両開発チーム間の質問や回答は，文書や電子メールで行い，認識相違を避ける。
- ③東京チーム内の取組を，プロジェクト全体に適用する。
- スケジュールとコストの進捗は，成果物の出来高を尺度とするEVM（Earned Value Management）で管理する。
プロジェクトの進捗状況
両チームの開発作業のスケジュールは図2のとおりである。
また，開発チーム別・月別のPV（計画価値）は表2のとおりであり，1月及び2月のEVM指標値は表3のとおりである。
| 開発チーム | 集計の分類1) | 月 | |||||||
|---|---|---|---|---|---|---|---|---|---|
| 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | ||
| 東京 | 小計 | 240 | 400 | 400 | 700 | 700 | 700 | 580 | 440 |
| 累計 | 240 | 640 | 1,040 | 1,740 | 2,440 | 3,140 | 3,720 | 4,160 | |
| 大阪 | 小計 | 120 | 210 | 300 | 420 | 420 | 420 | 440 | 300 |
| 累計 | 120 | 330 | 630 | 1,050 | 1,470 | 1,890 | 2,330 | 2,630 | |
| 開発チーム | 集計の分類 | EVM指標値 | |||
|---|---|---|---|---|---|
| EV1)（万円） | AC1)（万円） | CPI1) | SPI1) | ||
| 東京 | 1月小計 | 240 | 240 | 1.00 | 1.00 |
| 2月小計 | 360 | 400 | 0.90 | d | |
| 2月累計 | 600 | 640 | 0.94 | （省略） | |
| 大阪 | 1月小計 | 120 | 120 | 1.00 | 1.00 |
| 2月小計 | 210 | 200 | e | 1.00 | |
| 2月累計 | 330 | 320 | （省略） | 1.00 | |
注1) EV：出来高，AC：実コスト，CPI：コスト効率指数，SPI：スケジュール効率指数
表3のEVM指標値によると，プロジェクトを開始して2か月が経過した時点で，東京チームはfであり，大阪チームはgである。東京チームのモバイルアプリ開発で，2月にN社から業務要件追加の変更要求があり，追加のソフトウェア要件定義の作業が必要になった。T主任は，N社と合意して，モバイルアプリの開発要員を追加し，コストの増加をPVに反映させた。この変更の結果，東京チームのBAC（完成時総予算）は250万円増加した。
T主任は，4月末時点で，東京チームの4月累計のEVは2,100万円，4月累計のACは2,000万円となったことを確認した。また大阪チームの4月累計のEVとACは計画どおりであることも確認した。T主任は，④4月累計のCPIを使ってEAC（完成時総コスト見積り）を計算して，コストは予算を超過せずにプロジェクトを完了できると判断した。