応用情報技術者 2019年 秋期 午後 問09
複数拠点での開発プロジェクトに関する次の記述を読んで、設問1、2に答えよ。
SI企業のS社は、住宅設備機器の販売を行うN社から、N社で現在稼働中の販売管理システム(以下、現行システムという)の機能を拡張する開発案件を受注した。現行システムは、S社の第一事業部が数年前に開発したものである。
今回の機能拡張では、新たにモバイル端末を利用可能にするとともに、需要予測、及び仕入管理における自動発注機能を追加開発する。自動発注機能は、現行システムの発注処理の考え方に基づき開発する必要がある。
東京に拠点がある第一事業部には、現行システムを開発した部門と、モバイル端末で稼働するアプリケーションソフトウェア(以下、モバイルアプリという)の開発に多数の実績をもつ部門がある。一方、大阪に拠点がある第二事業部には、需要予測などに関する数理工学の技術をもつ部門がある。
この開発案件に対応するプロジェクト(以下、本プロジェクトという)には、S社の各部門が保有する技術を統合した開発体制が必要なので、事業部横断のプロジェクトチームを編成することが決定した。プロジェクトマネージャには、第一事業部のT主任が任命された。
なお、本プロジェクトは1月に開始し、9月のシステム稼働開始が求められている。
〔開発対象システムと開発体制案〕
本プロジェクトの開発対象システムを図1に示す。本プロジェクトでは、在庫管理と売上管理の改修はない。

T主任は、本プロジェクトの開発体制を、全てS社の社員で構成される二つの開発チームで編成する方針とした。モバイルアプリの開発、モバイルアプリ接続機能の開発及び自動発注機能を組み込むための仕入管理の機能拡張を、第一事業部の東京チームが担当する。また、需要予測と自動発注機能を、第二事業部の大阪チームが開発する。
T主任の方針を受けて、各事業部は、本プロジェクトに割当て可能な開発要員案を提示した。T主任は、提示された案でプロジェクトの遂行に支障がないかを検証するために、各要員の開発経験などを確認するためのヒアリングを行った。提示された開発要員案とT主任が行ったヒアリングの結果は、表1のとおりである。

〔プロジェクトマネジメントの方針〕
T主任は、開発要員案でプロジェクトの遂行に支障があれば、事業部間で必要な要員の異動を行う考えであった。
T主任は、ヒアリングの結果を踏まえて、①不足するスキルを補うため、本プロジェクトの開発要員案の範囲内で、最小限の要員異動をして適切な開発チームを編成することにした。その上で、両開発チームが作成する成果物に対する品質保証の活動を徹底することにした。そこで、T主任は、次のプロジェクトマネジメントの方針を策定した。
・両拠点からアクセス可能なファイルサーバを導入し、成果物を格納する。
・各開発作業の成果物のaが明確になるように、成果物のサンプルを提示し、記述の詳細度、レビュー実施要領などについて、プロジェクト全体で認識を合わせる。
・モバイルアプリ開発ではプロトタイピングで、ソフトウェア要件を早期に確定する。ソフトウェア方式設計で作成した設計書に要件が反映されていることを確認するために、ソフトウェア詳細設計では、ソフトウェア結合のテスト設計に利用するbを作成する。
・両開発チームでソフトウェア要件定義の作業の進め方が異なるので、N社とのやりとりでは、ソフトウェア開発とその取引の明確化を可能とするcの用語を用い、開発作業の解釈について誤解が生じないようにする。
T主任は、このプロジェクトマネジメントの方針を上司に説明した。その際、上司から、“複数拠点での開発であることを考慮し、拠点間でコミュニケーションエラーが発生するリスクへの対応を追加すること。”との指示を受けた。T主任は、上司の指示を受けて、次の開発方針及びプロジェクトマネジメントルールを作成して、本プロジェクトを開始した。
・②各機能モジュール間のインタフェースが疎結合となる設計とする。
・両開発チーム間の質問や回答は、文書や電子メールで行い、認識相違を避ける。
・③東京チーム内の取組を、プロジェクト全体に適用する。
・スケジュールとコストの進捗は、成果物の出来高を尺度とする 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)に答えよ。
(1)本文中の下線①について、どのように要員を異動させたか。40字以内で述べよ。
模範解答
現行システムの開発経験者を東京チームから大阪チームへ異動させた。
解説
解答の論理構成
- 大阪チームのスキル不足
- 表1には大阪チームの各開発対象について、いずれも「現行システムの開発に関わった要員はいない。」と明記されています。
- 東京チームには余剰の該当スキル
- 同じく表1で東京チーム(仕入管理担当)は「現行システムを開発したベテラン社員複数名」かつ「現行システムの開発経験者を、余裕をもたせて割り当てている。」とされています。
- 方針①の内容
- 本文中の下線①は「不足するスキルを補うため、本プロジェクトの開発要員案の範囲内で、最小限の要員異動をして適切な開発チームを編成することにした」と記載されています。
- 最小限で効果的な異動とは
- 不足しているスキルは「現行システムの知識」であり、余剰を抱える東京から不足している大阪へ移せば良い。
- 以上より、解答は「現行システムの開発経験者を東京チームから大阪チームへ異動させた」と導かれます。
誤りやすいポイント
- 「大阪に数理工学スキルがあるから異動不要」と勘違いし、現行システム経験の不足に気付かない。
- 「最小限の要員異動」を“人数を減らす”と誤読し、東京→大阪の方向を逆に書いてしまう。
- 表1のコメント「余裕をもたせて割り当てている」を見落とし、東京側にもギリギリだと思い込む。
FAQ
Q: そもそも現行システム経験者を大阪に移すと東京側は困らないのですか?
A: 表1に「余裕をもたせて割り当てている」とあるため、東京は必要人数を確保したうえで異動できます。
A: 表1に「余裕をもたせて割り当てている」とあるため、東京は必要人数を確保したうえで異動できます。
Q: スキル補完なら大阪から東京への異動も検討できませんか?
A: 不足しているのは大阪側の“現行システム経験”です。大阪の独自スキル(数理工学など)は東京で不足していないため、逆方向の異動は合理性がありません。
A: 不足しているのは大阪側の“現行システム経験”です。大阪の独自スキル(数理工学など)は東京で不足していないため、逆方向の異動は合理性がありません。
Q: 方針①で“最小限の要員異動”とあるのに異動が必要なのはなぜ?
A: “最小限”は「ゼロ異動」とは異なり、必要なスキルギャップを埋める最低限の動きを指します。本件では現行システム経験者を若干名動かすだけでギャップが解消できます。
A: “最小限”は「ゼロ異動」とは異なり、必要なスキルギャップを埋める最低限の動きを指します。本件では現行システム経験者を若干名動かすだけでギャップが解消できます。
関連キーワード: スキルマネジメント、要員配置、拠点間協働、既存システム知識、ベテラン活用
設問1:〔プロジェクトマネジメントの方針〕について、(1)〜(4)に答えよ。
(2)本文中のa〜cに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:BABOK
イ:WBS
ウ:アクティビティ
エ:アンケート
オ:共通フレーム
力:作成基準
キ:チェックリスト
ク:メトリックス
ケ:ワークパッケージ
模範解答
a:力
b:キ
c:オ
解説
解答の論理構成
-
【問題文】では成果物管理について「各開発作業の成果物のaが明確になるように、成果物のサンプルを提示し、記述の詳細度、レビュー実施要領などについて、プロジェクト全体で認識を合わせる。」と記載されています。
- ここで必要なのは、成果物を作る際の“物差し”や“書き方ルール”を定める文書です。
- 解答群の「力:作成基準」が該当し、成果物ごとにフォーマット・粒度・版管理方法を統一できます。
- よって a=「作成基準」と判断します。
-
モバイルアプリ開発に関し「ソフトウェア詳細設計では、ソフトウェア結合のテスト設計に利用するbを作成する。」とあります。
- 結合テスト設計に使う文書は、網羅性を確認するための一覧表が一般的です。
- 解答群の「キ:チェックリスト」が、テスト観点や項目を漏れなく列挙し確認できるため最適です。
- よって b=「チェックリスト」となります。
-
拠点ごとにやり方が異なる状況で「N社とのやりとりでは、ソフトウェア開発とその取引の明確化を可能とするcの用語を用い、開発作業の解釈について誤解が生じないようにする。」とあります。
- 発注側と受注側が共通の用語で“作業範囲”“成果物”“検収”を定義できる標準は、日本の「共通フレーム2013」などの“共通フレーム”です。
- 解答群の「オ:共通フレーム」がこれに該当します。
- よって c=「共通フレーム」です。
以上から模範解答どおり
a:力(作成基準)/b:キ(チェックリスト)/c:オ(共通フレーム)となります。
a:力(作成基準)/b:キ(チェックリスト)/c:オ(共通フレーム)となります。
誤りやすいポイント
- a を「イ:WBS」と誤答
- WBS は作業分解構造であり成果物の“書き方”ではなく“作業の一覧”を示すものです。文脈が合いません。
- b を「ク:メトリックス」と誤答
- メトリックスは測定指標であってテスト項目そのものを列挙する文書ではありません。
- c を「ア:BABOK」と誤答
- BABOK はビジネスアナリシスの知識体系ガイドであり、契約上の用語統一には直接使用しません。
FAQ
Q: 成果物の「作成基準」とは具体的に何を含めるべきですか?
A: 文書名称・目的・記述粒度・入力元と出力先・版管理方法・レビューポイントなどを定め、サンプルテンプレートも用意します。
A: 文書名称・目的・記述粒度・入力元と出力先・版管理方法・レビューポイントなどを定め、サンプルテンプレートも用意します。
Q: チェックリストとテストケースの違いは?
A: チェックリストは「確認すべき観点の漏れ防止」が主目的で、詳細な手順や期待結果は簡易記載です。テストケースは手順・入力・期待結果を具体的に記述し実行結果を記録します。
A: チェックリストは「確認すべき観点の漏れ防止」が主目的で、詳細な手順や期待結果は簡易記載です。テストケースは手順・入力・期待結果を具体的に記述し実行結果を記録します。
Q: 共通フレームを用いるメリットは?
A: 発注者と受注者が同一の語彙と工程定義を共有できるため、作業範囲・成果物・検収基準の食い違いを防止できます。
A: 発注者と受注者が同一の語彙と工程定義を共有できるため、作業範囲・成果物・検収基準の食い違いを防止できます。
関連キーワード: 成果物基準、チェックリスト、共通フレーム、品質保証、テスト設計
設問1:〔プロジェクトマネジメントの方針〕について、(1)〜(4)に答えよ。
(3)本文中の下線②について、上司からの指示への対応として、インタフェースを疎結合とする設計は、何を実現でき、どのような効果があるか。35字以内で述べよ。
模範解答
作業の独立性を高め、コミュニケーションエラーのリスクを軽減する。
解説
解答の論理構成
- 上司は、拠点間でのコミュニケーション不足を懸念し、
“複数拠点での開発であることを考慮し、拠点間でコミュニケーションエラーが発生するリスクへの対応を追加すること.”
と指示しました。 - これを受け、T主任は下線②として
“各機能モジュール間のインタフェースが疎結合となる設計とする”
という方針を設定しました。 - 疎結合インタフェースは、各モジュールが他モジュールの内部仕様に強く依存せず、インタフェースさえ合意すれば個別に開発・変更できます。
- したがって、東京チームと大阪チームが並行作業を行っても相互の仕様変更影響が小さく、コミュニケーション量を抑えられます。
- 以上より、「作業の独立性を高める」ことで「コミュニケーションエラーのリスクを軽減」できるという答えになります。
誤りやすいポイント
- 疎結合の効果を「性能向上」「再利用性向上」とだけ捉え、リスク軽減との結び付けを忘れる。
- “インタフェースを明確化”と“疎結合化”を混同し、独立性への効果を十分に説明しない。
- 「コミュニケーションエラー」を単に「コミュニケーションコスト」と書き換えてしまい、問題文の趣旨を外す。
FAQ
Q: 疎結合にすると本当にコミュニケーションは減るのですか?
A: 各モジュールが公表されたインタフェースだけに依存するため、内部実装の相談や変更通知回数が大幅に減り、必然的にコミュニケーション量も減少します。
A: 各モジュールが公表されたインタフェースだけに依存するため、内部実装の相談や変更通知回数が大幅に減り、必然的にコミュニケーション量も減少します。
Q: チーム間でインタフェース仕様が変わった場合はどう対処すべきですか?
A: 変更管理プロセスを通してレビューと合意を行い、影響範囲を最小限に抑えます。疎結合設計でもインタフェース自体の変更時は全モジュールに影響するため、厳格な版管理が不可欠です。
A: 変更管理プロセスを通してレビューと合意を行い、影響範囲を最小限に抑えます。疎結合設計でもインタフェース自体の変更時は全モジュールに影響するため、厳格な版管理が不可欠です。
Q: 疎結合とAPI公開の違いは?
A: API公開はインタフェースを外部に提供する手段であり、疎結合はモジュールが相互の内部に依存しない設計方針です。API公開は疎結合を実現する代表的な方法の一つです。
A: API公開はインタフェースを外部に提供する手段であり、疎結合はモジュールが相互の内部に依存しない設計方針です。API公開は疎結合を実現する代表的な方法の一つです。
関連キーワード: 疎結合、インタフェース設計、コミュニケーションエラー、リスク低減、モジュール独立
設問1:〔プロジェクトマネジメントの方針〕について、(1)〜(4)に答えよ。
(4)本文中の下線③について、プロジェクト全体に適用する東京チーム内の取組を、35字以内で述べよ。
模範解答
文書名称、格納方法、版管理の規則を定め、その実施を徹底する。
解説
解答の論理構成
- 【問題文】の下線③には“東京チーム内の取組を、プロジェクト全体に適用する”とあります。
- 東京チームの取組内容は【問題文 表1】のヒアリング結果で示されており、
“文書管理では、文書名称、格納方法、版管理の規則を定め、その実施を徹底している。”
と明記されています。 - この記述をそのまま引用すれば、下線③で求められる「東京チーム内の取組」を具体的に示せます。
- したがって解答は、
“文書名称、格納方法、版管理の規則を定め、その実施を徹底する。”
となります。
誤りやすいポイント
- “文書管理”だけを抜き出し、具体策(名称・格納方法・版管理)を示さない。
- “徹底”を「遵守」や「厳守」などと置き換えて原文を改変してしまう。
- 東京チームではなく大阪チームの取組を引用してしまう。
FAQ
Q: 「版管理」を「バージョン管理」と書き換えても良いですか?
A: 原文は“版管理”なので、解答も正確に引用する必要があります。
A: 原文は“版管理”なので、解答も正確に引用する必要があります。
Q: “規則を定める”だけでは不十分ですか?
A: 不十分です。“その実施を徹底する”まで含めて初めて東京チームの取組を完全に表せます。
A: 不十分です。“その実施を徹底する”まで含めて初めて東京チームの取組を完全に表せます。
Q: 原文を引用すると長くなり過ぎる場合は要約しても良いですか?
A: 指定された内容を正確に示すため、原文を省略せずに記載してください。
A: 指定された内容を正確に示すため、原文を省略せずに記載してください。
関連キーワード: 品質保証、文書管理、版管理、プロジェクト統制
設問2:〔プロジェクトの進捗状況〕について(1)〜(3)に答えよ。
(1)表3中のd、eに入れる適切な数値を答えよ。答えは小数第3位を四捨五入して、小数第2位まで求めよ。
模範解答
d:0.90
e:1.05
解説
解答の論理構成
-
SPI(スケジュール効率指数)は
で求めます。
【問題文】表3の「2月小計」によれば、東京チームの EV は「360」、表2の同月 PV は「400」です。
→ となり、d は 0.90 です。 -
CPI(コスト効率指数)は
で求めます。
【問題文】表3の「2月小計」によれば、大阪チームの EV は「210」、AC は「200」です。
→ となり、e は 1.05 です。 -
小数第3位を四捨五入して小数第2位まで、という指示は【問題文】表3脚注の
“注記 CPI及びSPIは、小数第3位を四捨五入して小数第2位までの値を指標値としている。”
に従っています。計算結果は既に小数第3位以下がないため、そのまま 0.90/1.05 となります。
誤りやすいポイント
- SPI を EV÷PV と覚えつつ、誤って PV÷EV を計算してしまう。
- PV を表3ではなく表2から拾うことを忘れ、同じ行の AC で割ってしまう。
- 表2には「小計」と「累計」があるため、2月小計を使うべきところで累計値「640」「330」を使ってしまう。
- 四捨五入指定を見落とし、3桁目まで記載して減点される。
FAQ
Q: “小計”と“累計”のどちらを使えばよいのですか?
A: 問われているのは「2月小計」の指標値なので、2月単月の EV・PV・AC を使用します。累計を使うのは「2月累計」など累計行の指標を計算する場合だけです。
A: 問われているのは「2月小計」の指標値なので、2月単月の EV・PV・AC を使用します。累計を使うのは「2月累計」など累計行の指標を計算する場合だけです。
Q: SPI が 1 未満だと必ず遅延と判断してよいですか?
A: 原則は遅延ですが、短期的なズレの可能性もあるため、原因を分析し trend を見ることが重要です。
A: 原則は遅延ですが、短期的なズレの可能性もあるため、原因を分析し trend を見ることが重要です。
Q: CPI と SPI のどちらを優先的に是正すべきでしょうか?
A: プロジェクトの制約によります。納期遵守が最優先なら SPI、予算内完了が最優先なら CPI を重視し、両指標を総合的に管理するのが望ましいです。
A: プロジェクトの制約によります。納期遵守が最優先なら SPI、予算内完了が最優先なら CPI を重視し、両指標を総合的に管理するのが望ましいです。
関連キーワード: EV, PV, SPI, CPI, EVM
設問2:〔プロジェクトの進捗状況〕について(1)〜(3)に答えよ。
(2)本文中のf、gに入れるスケジュールとコストの状況を、解答群の中から選び、記号で答えよ。
解答群
ア:スケジュールは計画どおり、コストは計画値未満
イ:スケジュールは計画どおり、コストは計画値を超過
ウ:スケジュールは計画より遅れ、コストは計画値未満
エ:スケジュールは計画より遅れ、コストは計画値を超過
オ:スケジュールは計画より進み、コストは計画値未満
カ:スケジュールは計画より進み、コストは計画値を超過
模範解答
f:エ
g:ア
解説
解答の論理構成
-
指標の定義を確認
【問題文】表3脚注には
“EV:出来高、AC:実コスト、CPI:コスト効率指数、SPI:スケジュール効率指数”
とあります。EVMではで評価します。
・CPI<1 … コスト超過
・CPI=1 … コスト計画どおり
・CPI>1 … コスト計画値未満
・SPI<1 … スケジュール遅れ
・SPI=1 … スケジュール計画どおり
・SPI>1 … スケジュール前倒し -
東京チームの状況
表3「2月小計」の東京行は
“EV 360”、“AC 400”、“CPI 0.90”、“SPI d”。
CPIが “0.90” と1未満なので “コストは計画値を超過”。
SPIも EV<PV(表2「2月小計」のPVは “400”)なので
→ “スケジュールは計画より遅れ”。
よって f は
“エ:スケジュールは計画より遅れ、コストは計画値を超過”。 -
大阪チームの状況
表3「2月小計」の大阪行は
“EV 210”、“AC 200”、“CPI e”、“SPI 1.00”。
PVは表2「2月小計」で “210” です。
SPI=1.00 ⇒ “スケジュールは計画どおり”。
CPI=210/200=1.05>1 ⇒ “コストは計画値未満”。
したがって g は
“ア:スケジュールは計画どおり、コストは計画値未満”。
誤りやすいポイント
- CPIとSPIの向きの取り違え
“1より大きければ良好” を両指標で混同しがちです。 - PVの読み違え
表2には “小計” と “累計” があるため、2月分評価では “小計210、400” を用います。 - 東京チームのAC=400に目を取られ「コスト未満」と早合点
CPIはEVとの比で評価するので “400” 自体ではなく “360/400” の結果を確認します。
FAQ
Q: SPIが“1.00”なのにCPIが1超の場合、どんな状態ですか?
A: 作業量は予定どおり消化している(SPI=1.00)が、実コストが予定より少なく済んでいるためコスト効率が良好(CPI>1)という状態です。
A: 作業量は予定どおり消化している(SPI=1.00)が、実コストが予定より少なく済んでいるためコスト効率が良好(CPI>1)という状態です。
Q: “コストは計画値未満”と“コスト超過”は何が違うのですか?
A: “計画値未満”は予定より安く済んでいる、“超過”は予定より高くついているという意味です。EVMではそれぞれCPI>1とCPI<1で判定します。
A: “計画値未満”は予定より安く済んでいる、“超過”は予定より高くついているという意味です。EVMではそれぞれCPI>1とCPI<1で判定します。
Q: 小計と累計、どちらで判断すべきですか?
A: 当該月時点の状況を問う設問なら「小計」を使います。期間全体の傾向を見る問いであれば「累計」を使うのが一般的です。
A: 当該月時点の状況を問う設問なら「小計」を使います。期間全体の傾向を見る問いであれば「累計」を使うのが一般的です。
関連キーワード: EVM, CPI, SPI, PV, コスト管理
設問2:〔プロジェクトの進捗状況〕について(1)〜(3)に答えよ。
(3)本文中の下線④について、プロジェクト開始4か月後の東京チームのEACは何万円になるか。ここで、EACは次の式で求めるものとする。
模範解答
4,200
解説
解答の論理構成
-
BAC(完成時総予算)の確認
表2の累計最終列によると、東京チームの当初 BAC は 「4,160」万円です。
さらに本文で「東京チームのBAC(完成時総予算)は250万円増加した。」
と明記されているので、増加後の BAC は -
CPI(コスト効率指数)の計算
本文中の下線④直前に「4月累計のEVは2,100万円、4月累計のACは2,000万円」
とあるので、 -
EAC(完成時総コスト見積り)の算出
指定の式に代入すると、 -
結論
プロジェクト開始4か月後の東京チームの EAC は 4,200万円です。
誤りやすいポイント
- BAC 増加分「250」を足し忘れ、4,160 ÷ 1.05 で計算してしまう。
- CPI を「2月累計 0.94」や「2月小計 0.90」で誤用する。
- CPI 計算時に EV と AC を逆にして 0.95 としてしまう。
- 小数点以下を途中で丸めてから計算し、EAC が 4,210 など端数になる。
FAQ
Q: CPI が 1 より大きいのに EAC が BAC より小さくなるのは正しいのですか?
A: はい。CPI>1 は「コスト効率が良い」ことを示すため、EAC(=BAC/CPI) は BAC より小さくなります。
A: はい。CPI>1 は「コスト効率が良い」ことを示すため、EAC(=BAC/CPI) は BAC より小さくなります。
Q: なぜ 4月累計の CPI を使うのですか?
A: 本文の下線④で「4月累計のCPIを使ってEACを計算」と指示されているためです。
A: 本文の下線④で「4月累計のCPIを使ってEACを計算」と指示されているためです。
関連キーワード: EVM, BAC, CPI, EAC, 進捗管理


