応用情報技術者過去問題 令和元年秋期 午後問9
⇄問題文と設問を画面2分割で開く⇱問題PDF問9 プロジェクトマネジメント
複数拠点での開発プロジェクトに関する次の記述を読んで,設問1,2に答えよ。
SI企業のS社は,住宅設備機器の販売を行うN社から,N社で現在稼働中の販売管理システム(以下,現行システムという)の機能を拡張する開発案件を受注した。現行システムは,S社の第一事業部が数年前に開発したものである。
今回の機能拡張では,新たにモバイル端末を利用可能にするとともに,需要予測,及び仕入管理における自動発注機能を追加開発する。自動発注機能は,現行システムの発注処理の考え方に基づき開発する必要がある。
東京に拠点がある第一事業部には,現行システムを開発した部門と,モバイル端末で稼働するアプリケーションソフトウェア(以下,モバイルアプリという)の開発に多数の実績をもつ部門がある。一方,大阪に拠点がある第二事業部には,需要予測などに関する数理工学の技術をもつ部門がある。
この開発案件に対応するプロジェクト(以下,本プロジェクトという)には,S社の各部門が保有する技術を統合した開発体制が必要なので,事業部横断のプロジェクトチームを編成することが決定した。プロジェクトマネージャには,第一事業部のT主任が任命された。
なお,本プロジェクトは1月に開始し,9月のシステム稼働開始が求められている。
〔開発対象システムと開発体制案〕
本プロジェクトの開発対象システムを図1に示す。本プロジェクトでは,在庫管理と売上管理の改修はない。 T主任は,本プロジェクトの開発体制を,全てS社の社員で構成される二つの開発チームで編成する方針とした。モバイルアプリの開発,モバイルアプリ接続機能の開発及び自動発注機能を組み込むための仕入管理の機能拡張を,第一事業部の東京チームが担当する。また,需要予測と自動発注機能を,第二事業部の大阪チームが開発する。
T主任の方針を受けて,各事業部は,本プロジェクトに割当て可能な開発要員案を提示した。T主任は,提示された案でプロジェクトの遂行に支障がないかを検証するために,各要員の開発経験などを確認するためのヒアリングを行った。提示された開発要員案とT主任が行ったヒアリングの結果は,表1のとおりである。〔プロジェクトマネジメントの方針〕
T主任は,開発要員案でプロジェクトの遂行に支障があれば,事業部間で必要な要員の異動を行う考えであった。
T主任は,ヒアリングの結果を踏まえて,①不足するスキルを補うため,本プロジェクトの開発要員案の範囲内で,最小限の要員異動をして適切な開発チームを編成することにした。その上で,両開発チームが作成する成果物に対する品質保証の活動を徹底することにした。そこで,T主任は,次のプロジェクトマネジメントの方針を策定した。
〔プロジェクトの進捗状況〕
両チームの開発作業のスケジュールは図2のとおりである。 また,開発チーム別・月別のPV(計画価値)は表2のとおりであり,1月及び2月のEVM指標値は表3のとおりである。 表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(完成時総コスト見積り)を計算して,コストは予算を超過せずにプロジェクトを完了できると判断した。
SI企業のS社は,住宅設備機器の販売を行うN社から,N社で現在稼働中の販売管理システム(以下,現行システムという)の機能を拡張する開発案件を受注した。現行システムは,S社の第一事業部が数年前に開発したものである。
今回の機能拡張では,新たにモバイル端末を利用可能にするとともに,需要予測,及び仕入管理における自動発注機能を追加開発する。自動発注機能は,現行システムの発注処理の考え方に基づき開発する必要がある。
東京に拠点がある第一事業部には,現行システムを開発した部門と,モバイル端末で稼働するアプリケーションソフトウェア(以下,モバイルアプリという)の開発に多数の実績をもつ部門がある。一方,大阪に拠点がある第二事業部には,需要予測などに関する数理工学の技術をもつ部門がある。
この開発案件に対応するプロジェクト(以下,本プロジェクトという)には,S社の各部門が保有する技術を統合した開発体制が必要なので,事業部横断のプロジェクトチームを編成することが決定した。プロジェクトマネージャには,第一事業部のT主任が任命された。
なお,本プロジェクトは1月に開始し,9月のシステム稼働開始が求められている。
〔開発対象システムと開発体制案〕
本プロジェクトの開発対象システムを図1に示す。本プロジェクトでは,在庫管理と売上管理の改修はない。 T主任は,本プロジェクトの開発体制を,全てS社の社員で構成される二つの開発チームで編成する方針とした。モバイルアプリの開発,モバイルアプリ接続機能の開発及び自動発注機能を組み込むための仕入管理の機能拡張を,第一事業部の東京チームが担当する。また,需要予測と自動発注機能を,第二事業部の大阪チームが開発する。
T主任の方針を受けて,各事業部は,本プロジェクトに割当て可能な開発要員案を提示した。T主任は,提示された案でプロジェクトの遂行に支障がないかを検証するために,各要員の開発経験などを確認するためのヒアリングを行った。提示された開発要員案とT主任が行ったヒアリングの結果は,表1のとおりである。〔プロジェクトマネジメントの方針〕
T主任は,開発要員案でプロジェクトの遂行に支障があれば,事業部間で必要な要員の異動を行う考えであった。
T主任は,ヒアリングの結果を踏まえて,①不足するスキルを補うため,本プロジェクトの開発要員案の範囲内で,最小限の要員異動をして適切な開発チームを編成することにした。その上で,両開発チームが作成する成果物に対する品質保証の活動を徹底することにした。そこで,T主任は,次のプロジェクトマネジメントの方針を策定した。
- 両拠点からアクセス可能なファイルサーバを導入し,成果物を格納する。
- 各開発作業の成果物のaが明確になるように,成果物のサンプルを提示し,記述の詳細度,レビュー実施要領などについて,プロジェクト全体で認識を合わせる。
- モバイルアプリ開発ではプロトタイピングで,ソフトウェア要件を早期に確定する。ソフトウェア方式設計で作成した設計書に要件が反映されていることを確認するために,ソフトウェア詳細設計では,ソフトウェア結合のテスト設計に利用するbを作成する。
- 両開発チームでソフトウェア要件定義の作業の進め方が異なるので,N社とのやりとりでは,ソフトウェア開発とその取引の明確化を可能とするcの用語を用い,開発作業の解釈について誤解が生じないようにする。
- ②各機能モジュール間のインタフェースが疎結合となる設計とする。
- 両開発チーム間の質問や回答は,文書や電子メールで行い,認識相違を避ける。
- ③東京チーム内の取組を,プロジェクト全体に適用する。
- スケジュールとコストの進捗は,成果物の出来高を尺度とするEVM(Earned Value Management)で管理する。
〔プロジェクトの進捗状況〕
両チームの開発作業のスケジュールは図2のとおりである。 また,開発チーム別・月別のPV(計画価値)は表2のとおりであり,1月及び2月のEVM指標値は表3のとおりである。 表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(完成時総コスト見積り)を計算して,コストは予算を超過せずにプロジェクトを完了できると判断した。
設問1
〔プロジェクトマネジメントの方針〕について,(1)~(4)に答えよ。
a,b,c に関する解答群
- BABOK
- WBS
- アクティビティ
- アンケート
- 共通フレーム
- 作成基準
- チェックリスト
- メトリックス
- ワークパッケージ
解答入力欄
- a:
- b:
- c:
解答例・解答の要点
- 現行システムの開発経験者を東京チームから大阪チームへ異動させた (31文字)
- a:カ
- b:キ
- c:オ
- 作業の独立性を高め,コミュニケーションエラーのリスクを軽減する (31文字)
- 文書名称,格納方法,版管理の規則を定め,その実施を徹底する (29文字)
解説
- 要員異動はヒアリングの結果を踏まえ、不足するスキルを補うために行われます。ヒアリングの結果で各要員の開発経験を確認すると、現行システムの開発者が東京チームにしかいないことがわかります。
大阪チームが開発する需要予測は現行システムとのインタフェースがあり、同じく大阪チームが開発する自動発注機能は現行システムの仕入管理内に追加される機能です。現行システムを理解している人がいない状況で開発を進めることはプロジェクト遂行上のリスクとなるため、可能であれば現行システムの仕様を理解している人材をチームに含めることが望まれます。
幸いにも、東京チームでは現行システム経験者を、余裕を持たせて割り当てているので、この余剰人員を大阪チームに異動する方策が適切となります。
なお、表1の開発要員案列を見ると、どの開発対象においても開発対象に関するスキルを有する者が選抜されていますので、それらのスキル不足を補うための要員異動は必要ないと考えられます。
∴現行システムの開発経験者を東京チームから大阪チームへ異動させた - 〔aについて〕
サンプル、記述の詳細度、レビュー実施要領などは、成果物を作成する上での品質ガイドラインとなります。地理的に離れた場所だと適切な品質管理が難しいですが、品質ガイドラインを提示しておくことによって成果物の「作成基準」が明確となり、適切な品質で作成されることを期待できます。
∴a=カ:作成基準
〔bについて〕
ソフトウェア詳細設計では、ソフトウェア結合のためにテスト要件及びスケジュールを定義します。
本文中で「ソフトウェア方式設計で作成した設計書の要件が反映されていることを確認するために…bを作成する」とあるので、システム方式設計書に適合していることを確実にするために用いるものを選択することになります。
選択肢の語句中だと「チェックリスト」が適切です。
∴b=キ:チェックリスト
〔cについて〕
共通フレームは、ソフトウェア産業界において取得者と供給者の「共通の物差し」となることを目的として作成された規格です。取得者と供給者双方及びシステム開発に関わる全ての人が、システムライフサイクルの各フェーズにおける作業項目を共通に参照できるよう詳細に記述したり、ソフトウェア取引を明確化したりするための基準が記述されています。
共通フレームは、取得者と供給者で用語が統一されていないことや、役割分担が不明確な点、曖昧な見積り等が招くトラブルを防止する一助となります。取得者であるN社とのやりとりで誤解が生じないように用いるものなので、cには「共通フレーム」が入ります。
∴c=オ:共通フレーム
正解以外の語句についても簡単に確認しておきます。- BABOK(Business Analysis Body of Knowledge)
- 経営ニーズやステークホルダの課題を調査・整理、および検証して取りまとめる"ビジネス分析"のベストプラクティスを体系化した書籍の略称
- WBS(Work Breakdown Structure)
- プロジェクト目標を達成し、必要な成果物を過不足なく作成するために、プロジェクトチームが実行すべき作業を、成果物を主体に階層的に要素分解したもの
- アクティビティ
- ワークパッケージを完了するために必要な個々の作業
- メトリックス
- プロジェクトを管理するために必要な測定指標
- ワークパッケージ
- WBSの最下層の要素成果物
- 疎結合とは、機能間の依存関係が少なく、結びつきが弱い関係をいいます。各機能の独立性が高いともいえます。
T主任が疎結合となる設計を開発方針としたのは、疎結合でない場合、すなわち密結合だった場合に生じる問題を考えてみるとわかります。2つの機能で互いに依存している部分が大きいと、整合性を保つために各機能の担当者間で綿密なコミュニケーションをとらなければなりません。また、片方の変更がもう一方に影響を与えるので保守性も非常に悪くなります。
本プロジェクトは拠点間にまたがった大規模なプロジェクトなので、密接な連絡が取りにくく、思い込みや解釈の違いなどによる誤りが発生しやすい状況にあります。疎結合にしたことには、コミュニケーションの回数をできるだけ減らし、コミュニケーションエラーの発生リスクを低減する狙いがあります。
∴作業の独立性を高め,コミュニケーションエラーのリスクを軽減する - 本文中において「東京チーム内の取組」は表1に記載されている次の2つしかありません。
- 記録がメモ書きだけで残され,開発文書の更新から漏れることがあった。
- 文書名称、格納方法、版管理の規則を定め、その実施を徹底している。
∴文書名称,格納方法,版管理の規則を定め,その実施を徹底する
設問2
〔プロジェクトの進捗状況〕について,(1)~(3)に答えよ。
- 表3中のd,eに入れる適切な数値を答えよ。答えは小数第3位を四捨五入して,小数第2位まで求めよ。
- 本文中のf,gに入れるスケジュールとコストの状況を,解答群の中から選び,記号で答えよ。
- 本文中の下線④について,プロジェクト開始4か月後の東京チームのEACは何万円になるか。ここで,EACは次の式で求めるものとする。
EAC=BACCPI
f,g に関する解答群
- スケジュールは計画どおり,コストは計画値未満
- スケジュールは計画どおり,コストは計画値を超過
- スケジュールは計画より遅れ,コストは計画値未満
- スケジュールは計画より遅れ,コストは計画値を超過
- スケジュールは計画よリ進み,コストは計画値未満
- スケジュールは計画よリ進み,コストは計画値を超過
解答入力欄
- d:
- e:
- f:
- g:
- 万円
解答例・解答の要点
- d:0.90
- e:1.05
- f:エ
- g:ア
- 4,200
解説
EVM(Earned Value Management)は、プロジェクトにおける作業を金銭の価値に置き換えて定量的に実績管理をする進捗管理手法です。
EVMではPV,EV,ACの3つの指標を用いてプロジェクトの進捗を管理します。
これだけだとわかりづらいので単純化した例を示します。例えば、下表のように期間10カ月、予算100万円のプロジェクトがあったとします。この条件で5カ月目が終了したときに、仮に進捗度が全体の45%、実コスト(AC)が50万円だったとすると、EV及びPVは次の金額になります。
EVMではPV,EV,ACの3つの指標を用いてプロジェクトの進捗を管理します。
- PV(Planned Value)
- プロジェクト開始当初、現時点までに計画されていた作業に対する予算
- EV(Earned Value)
- 現時点までに完了した作業に割り当てられていた予算
- AC(Actual Cost)
- 現時点までに完了した作業に対して実際に投入した総コスト
これだけだとわかりづらいので単純化した例を示します。例えば、下表のように期間10カ月、予算100万円のプロジェクトがあったとします。この条件で5カ月目が終了したときに、仮に進捗度が全体の45%、実コスト(AC)が50万円だったとすると、EV及びPVは次の金額になります。
- EV=100万円×45%=45万円
- PV=50万円
- 〔dについて〕
SPI(スケジュール効率指数)は、PVに対するEVの比率を示します。
SPI=EV/PV
SPIが1を超える場合は計画よりもスケジュールが早まっていることを示し、SPIが1未満の場合はスケジュール遅延であることを示します。SPI=1はスケジュール通りということです。
東京チームの2月単月の各値については、表3の2月小計よりEV=360万円、表2の2月小計よりPV=400万円とわかるので、
SPI=360÷400=0.90
∴d=0.90
〔eについて〕
CPI(コスト効率指数)は、ACに対するEVの比率を示します。
CPI=EV/AC
CPIが1を超える場合は計画よりも少ないコストで進捗していることを示し、CPIが1未満の場合はコスト超過であることを示します。CPI=1は予算通りということです。
大阪チームの2月単月の各値については、表3の2月小計よりEV=210万円、AC=200万円とわかるので、
CPI=210÷200=1.05
∴e=1.05 - SPIとCPIの値を見て判断します。
〔fについて〕
東京チームは、2月累計のSPIが「600÷640=0.9375」、CPIが0.94でどちらも1未満です。よって、スケジュール遅れ、コスト超過の状態にあると判断できます。
∴f=エ:スケジュールは計画より遅れ,コストは計画値を超過
※SPIについては「EV<PV」で1未満となることがわかれば具体的な値まで計算する必要はありません。
〔gについて〕
大阪チームは、2月累計のSPIが1.00、CPIが「330÷320=1.03125」です。よって、スケジュールは予定通り、コストは計画値よりも少ない状態にあると判断できます。
∴g=スケジュールは計画どおり,コストは計画値未満
※CPIについては「EV>AC」で1を超えることがわかれば具体的な値まで計算する必要はありません。 - EAC(完成時総コスト見積り)は、全作業完了までに予測される総コストで、発生済み実コストと残作業見積りの合計として表されます。この設問のように現時点までのコスト効率がプロジェクト終了まで続くと仮定するならば、
EAC=BACCPI
で単純に求められます。BAC(完成時総予算)は、全作業を実施するために確定された予算の合計です。- CPI
- 前述の通り「EV÷AC」で求めます。本文中に、東京チームの4月累計のEVは2,100万円、4月累計のACは2,000万円とあるので、4月累計のCPIは「2,100÷2,000=1.05」とわかります。
- BAC
- プロジェクト開始当初、東京チームのBACは8月累計PVと同じ4,160万円でしたが、N社からの変更要求により250万円増加し、4月末時点では「4,160+250=4,410万円」になっています。
4,410÷1.05=4,200万円
EACがBAC以下となっているのでコスト超過を起こすことなくプロジェクトを完了できると見通せます。
∴4,200