稼働延期に伴うプロジェクト計画の変更に関する次の記述を読んで,設問1〜4に答えよ。
Q社は中堅の飲料メーカであり,卸や小売の顧客企業に酒類を販売している。一定規模以上の顧客企業からはEDIで注文を受けているが,小規模な顧客企業からはQ社の販売部門がファックスや電話で注文を受けていた。小規模な顧客企業は約150社存在し,販売部門の業務負荷が高かった。そこで業務効率向上を目的にWeb受注システムを開発することを経営会議で決定した。さらに顧客企業への受注金額に応じた支払代金の一部の定期的な払戻しや売掛金管理や入出金管理などの業務を手作業で実施しているので,これらの業務も併せてシステム化することにした。販売部門からシステム部に開発を依頼し,プロジェクト(以下,Q社プロジェクトという)を立ち上げた。
(1)開発対象のサブシステム
開発対象のサブシステムの概要と機能数を表1に示す。なお,各機能は全て同等の開発規模である。
サブシステム | 概要 | 機能数 |
商品 | 商品の検索や照会,商品マスタの更新や在庫管理などの機能 | 16 |
販売 | 注文内容や購入履歴の表示,決済や発送管理などの機能 | 15 |
リベート | 年2回(6月1日,12月1日)実施する,払戻し金額の計算と顧客企業への払戻しの通知の機能 | 8 |
経理 | 売掛金管理,入出金管理,他システムとの接続などの機能 | 8 |
合計 | 47 |
(2)開発体制
Q社のシステム部のR氏がプロジェクトマネージャ(PM)に任命され,開発要員8人が割り当てられた。稼働日は2020年3月末が目標であった。
Q社プロジェクトはソフトウェア要件定義(以下,要件定義という),ソフトウェア方式設計(以下,基本設計という),ソフトウェアコード作成及びテスト(以下,製造という)の工程が終了し,テスト密度やテスト検出不具合密度などの品質管理の指標値に問題がないことを確認した。しかし,ソフトウェア結合テスト(以下,結合テストという)のテスト項目の消化が終了した時点で,全てのサブシステムで目標とするテスト検出不具合密度を大幅に超過する障害が発生していた。R氏は,システム部の部長に状況を説明し,次週の経営会議に報告するよう指示を受けた。
経営会議では,品質に問題があって注文が正しく処理されないと顧客企業に迷惑が掛かるので,品質の確保を最優先にすること,社内の業務効率向上が目的であり稼働日には調整の余地があるので販売部門に確認すること,予算を超過するコストの追加が必要な場合は経営会議の承認を得ること,が指示された。この指示を受けてR氏は,一旦プロジェクトを中断してプロジェクト計画変更の検討を開始した。
R氏は,販売部門に稼働日についてヒアリングして,“業務の都合上,2020年6月30日に稼働させてほしい”との回答を得た。1週間後の経営会議で承認が得られて,翌日にプロジェクトを再開すれば,6月29日までのプロジェクトの作業可能な日数は100日であった。
R氏は上司のアドバイスを受けながら,結合テスト工程で発生した障害を複数の観点で分析し,表2〜4に整理した。テストケースの不備やテスト作業のミスを除くと,障害件数は合計240件であった。
サブシステム | 障害件数 |
商品 | 46 |
販売 | 110 |
リベート経理 | 34 |
合計 | 240 |
障害動作 | 障害件数 |
画面表示 | 40 |
異常終了 | 120 |
値不正 | 75 |
その他 | 5 |
合計 | 240 |
原因工程 | 障害件数 |
要件定義 | 0 |
基本設計 | 180 |
製造 | 40 |
結合テスト | 20 |
合計 | 240 |
なお,表3の画面表示の障害とは,画面に表示する項目の位置がずれる障害で,商品サブシステム及び販売サブシステムで発生している。また,表4の原因工程とは障害の原因が作り込まれた工程を意味する。
R氏は品質の状態をサブシステム別の観点の分析から見た結果,特に販売サブシステムの品質を強化することにした。さらに a 別の観点の分析から,成果物を確認したところ,機能をまたがる整合性の確認が不十分であったことが分かった。これによって,障害件数が目標とするテスト検出不具合密度を大幅に超過した根本原因を特定した。そこで,R氏はこれまでに発生した障害の状況を踏まえて是正処置を講じた上で, b 工程から作業を再実施する方針とした。
〔販売部門との調整〕
R氏は,プロジェクト計画の変更に向けて,工数と期間の再見積りをすることにした。その際,“再実施する工程”,“再実施する結合テスト工程の障害の解消”及び“ソフトウェア適格性確認テスト・受入れテスト”に分けて見積もることにして,表5にその前提条件をまとめた。また,Q社のシステムの開発の経験があり,現在の開発要員と同様の開発生産性を期待できる開発要員を社外から2名調達して,開発要員を合計10名とすることにした。なお,開発要員は全てのサブシステムの全ての工程に対応が可能なので,タスクの待ちはなくフル稼働し,PMの工数は見積りに含めないものとする。
見積分類 | 前提条件 |
再実施する工程 |
・ b 工程〜結合テスト工程の再実施に,販売サブシステムは1機能当たり20人日,他のサブシステムは1機能当たり10人日の工数を要する。 ・再実施する結合テスト工程の障害の解消の作業工数は上記の工数に含めない。 |
再実施する結合テスト工程の障害の解消 |
・ b 工程〜結合テスト工程を再実施することで,作業対象の障害件数は,目標とするテスト検出不具合密度に収まり120件になる。 ・障害の解消には,1件当たり2人日の作業工数を要する。 |
ソフトウェア適格性確認テスト・受入れテスト |
・プロジェクト計画変更前の見積りを採用し,両テスト合計で30日の期間を設ける。 |
“再実施する工程”と“再実施する結合テスト工程の障害の解消”それぞれの工数と期間を見積もり,“ソフトウェア適格性確認テスト・受入れテスト”の期間を加えた。
見積りの結果,全てのサブシステムを b 工程からやり直し,再実施する結合テスト工程の全ての障害を解消する場合,開発要員を増員した体制でも,稼働までの作業に必要な日数は c 日となり,期限に間に合わないことが分かった。R氏は,開発要員を更に増やして作業期間を短縮する方法と,各工程の一部を並行実行して作業期間を短縮する方法を検討したが,いずれも品質を確保する上でリスクがあるので,別の方法を検討する必要があると考えた。
そこで,R氏は販売部門とシステム稼働の開始を判断するための d を変更することにした。検討の結果,“画面表示の障害はシステム利用の際に支障のある問題点とはならないので6月30日の稼働後に対応する”,“稼働日を考慮し,①リベートサブシステムを6月30日に稼働するスコープから外す”ことを提案することにした。これによる見積りの前提条件の変更点を表6にまとめた。
見積分類 | 前提条件の変更点 |
再実施する工程 |
・リベートサブシステムをスコープから外す。この変更による他のサブシステムの作業への影響はない。 |
再実施する結合テスト工程の障害の解消 |
・表5で前提条件としたリベートサブシステムの障害を障害件数から除外する。 ・画面表示の障害を作業対象から除外する。 ・作業対象の障害件数は75件となる。 |
ソフトウェア適格性確認テスト・受入れテスト |
・リベートサブシステムをスコープから外すので,期間は4日短縮できて,26日間となる。 |
調整の結果,6月30日の稼働後に追加開発を行うことを条件に販売部門と d の変更の合意が取れた。作業が必要な日数は e 日となり,期限に間に合う計画になった。
販売部門からシステム部に,経理サブシステムで算出する金額の誤りは業務への影響が大きいので,全ての経理の処理のパターンにおいて現行業務で算出している金額と経理サブシステムで算出する金額に差異がないように,特に注意して検証するよう要請があった。R氏は,経理の処理に関する条件は多岐にわたるので,販売部門にデータの提供を依頼し,②結合テストで予定していたテストの他に別のテストを追加した。このテストを追加しても期限には間に合うことも確認した。
R氏は,これまでの検討結果を反映して,プロジェクト計画を変更し,予定していた経営会議で承認を得たので,プロジェクトを再開した。R氏は,プロジェクトを再開するに当たって,進捗管理に加えて,計画どおりの工数で完了できるかどうかを見極めるため,検証と監視を強化した。再実施する工程については,一部機能で先行作業を行って,見積りどおりの工数に収まることを検証した。さらに再実施する結合テスト工程の障害の解消については,表5及び表6の前提条件に基づいて,③再実施する結合テスト工程で二つの指標の実績値を監視することにした。
出典:令和2年度秋期 問9
設問1 本文中の a , b に入れる適切な字句を8字以内で答えよ。
解答・解説
解答例
a:原因工程 b:基本設計
解説
- 前文の「サブシステム別の観点の分析から見た結果,特に販売サブシステムの品質を強化することにした。さらに〜」という表現から、サブシステム別の観点以外、つまり障害動作別か原因工程別ということが変わります。
さらに、後文の「成果物を確認したところ」という表現から、原因工程別が適切です。 - 前文に「これまでに発生した障害の状況を踏まえて是正処置を講じた上で〜」とありますが、表4を見ると明らかに基本設計工程起因の障害件数が多いかつその前工程(要件定義)起因の障害は0のため、是正処理を講じ作業を再実施したのも、基本設計工程と考えられます。
設問2 〔販売部門との調整〕について,(1)〜(3)に答えよ。
(1)本文中の d に入れる適切な字句を解答群の中から選び,記号で答えよ。
- コミュニケーション計画
- 導入可否判断基準
- マスタスケジュール
- リスク管理表
解答・解説
解答例
イ
解説
「システム稼働の開始を判断する」との表現から、なんらかの条件が入ると推測されます。また、「稼働後に追加開発を行うことを条件に〜」との表現から、導入可否判断基準が適切です。
*間接的には“マスタスケジュール”でも意味は通りますが、より適切な選択肢があったため不正解としています。
(2)本文中の下線①について,R氏がリベートサブシステムを6月30日の稼働のスコープから外せると考えた理由を40字以内で述べよ。
解答・解説
解答例
稼働日からリベートサブシステムの機能を実施する日まで期間に余裕があるから
解説
表1のリベートサブシステムの概要に「年2回(6月1日,12月1日)実施する,払戻し金額の計算と顧客企業への払戻しの通知の機能」とあります。
つまり、6月30日リリースのシステムの場合、はじめて利用されるのは12月1日となるため、5ヶ月程度の猶予がある(リベートサブシステムの稼働を遅らせることができる)ことがわかります。
(3)本文中の c , e に入れる適切な数値を答えよ。ここで,〔経理の処理のパターンへの対応〕に記載のある追加テストは見積りに含めない。
解答・解説
解答例
c:116 e:95
解説
- 表1の機能数、表5の前提条件から
(販売サブシステムの再実施工数)+(他のサブシステムの再実施工数)+(障害対応の工数)
= 20[人日/機能] × 15[機能] + 10[人日/機能] × 32[機能] + 2[人日/件] × 120[件]
= 860[人日]
であり、これを10人で行うため、860 ÷ 10 = 86[日]を要します。
また、ソフトウェア適格性確認テストと受入テストに30日を要するため、稼働までに必要な日数は、86 + 30 = 116[日] となります。
- 8機能が除外、障害件数が75件になることを考慮し、cと同様に工数を計算すると
(販売サブシステムの再実施工数)+(他のサブシステムの再実施工数)+(障害対応の工数)
= 20[人日/機能] × 15[機能] + 10[人日/機能] × 24[機能] + 2[人日/件] × 75[件]
= 690[人日]
であり、これを10人で行うため、690 ÷ 10 = 69[日]を要します。
また、ソフトウェア適格性確認テストと受入テストに26日を要するため、稼働までに必要な日数は、69 + 26 = 95[日] となります。
設問3 本文中の下線②について,どのようなことを確認するテストを追加したのか。30字以内で述べよ。
解答・解説
解答例
現行業務と経理サブシステムで算出する金額の一致
解説
「全ての経理の処理のパターンにおいて現行業務で算出している金額と経理サブシステムで算出する金額に差異がないように,特に注意して検証するよう要請があった」とありますので、この要請通り、現行業務と経理サブシステムの結果が同じであることをチェックするテストを追加したと考えられます。
設問4 本文中の下線③について,何の実績値を監視することにしたのか。25字以内で述べよ。
解答・解説
解答例
障害の発生件数と1件当たりの解消の作業工数
解説
「再実施する結合テスト工程の障害の解消については,表5及び表6の前提条件に基づいて〜」とありますが、この前提条件とは、“障害の発生件数(120件)”と“1件当たりの解消の作業工数(2人日/件)”のことです。
この前提が崩れてしまうと、見積り自体が崩れてしまうため、監視強化の対象となります。
IPA公開情報
出題趣旨
プロジェクトは様々な要因によって,当初の計画どおりに進まないことがある。
本問では,品質に問題が発生した状況を題材に,適切なプロジェクト計画と導入可否判断基準の変更,ステ ークホルダと変更内容を調整する能力を問う。
採点講評
問9では,品質に問題が発生した状況を題材に,適切なプロジェクト計画と導入可否判断基準の変更,ステ ークホルダと変更内容の調整について出題した。全体として正答率は平均的であった。
設問2(3)は,正答率が平均的であったが,数値が若干異なる解答が散見された。本文から機能数や障害件数などの期間の算出に必要な要素の抽出に時間を要したと思われるが,計算自体は複雑ではないので,落ち着いて計算して正答を導いてほしい。また,期間の算出をする際に,何を必要な要素として抽出するかは重要な観点であるので,十分に理解を深めてほしい。
設問3は,正答率がやや低かった。新システムの算出金額が正しいことを現行と比較し検証するテストは,品質を高めるために重要である。こうしたテストは,金額に限らず,新システムの算出する数値が正しいことを検証する局面において実施することが多いので,是非知っておいてもらいたい。