応用情報技術者 2020年 秋期 午後 問09

　 　Q社は中堅の飲料メーカーであり、卸や小売の顧客企業に酒類を販売している。一定規模以上の顧客企業からはEDIで注文を受けているが、小規模な顧客企業からはQ社の販売部門がファックスや電話で注文を受けていた。小規模な顧客企業は約150社存在し、販売部門の業務負荷が高かった。そこで業務効率向上を目的にWeb受注システムを開発することを経営会議で決定した。さらに顧客企業への受注金額に応じた支払代金の一部の定期的な払戻しや売掛金管理や入出金管理などの業務を手作業で実施しているので、これらの業務も併せてシステム化することにした。販売部門からシステム部に開発を依頼し、プロジェクト（以下、Q社プロジェクトという）を立ち上げた。

〔Q社プロジェクトの概要〕 　(1) 開発対象のサブシステム 　　開発対象のサブシステムの概要と機能数を表1に示す。なお、各機能は全て同等の開発規模である。

　(2) 開発体制 　　Q社のシステム部のR氏がプロジェクトマネージャ（PM）に任命され、開発要員8人が割り当てられた。稼働日は2020年3月末が目標であった 　 〔プロジェクト計画の変更〕 　Q社プロジェクトはソフトウェア要件定義（以下、要件定義という）、ソフトウェア方式設計（以下、基本設計という）、ソフトウェアコード作成及びテスト（以下、製造という）の工程が終了し、テスト密度やテスト検出不具合密度などの品質管理の指標値に問題がないことを確認した。しかし、ソフトウェア結合テスト（以下、結合テストという）のテスト項目の消化が終了した時点で、全てのサブシステムで目標とするテスト検出不具合密度を大幅に超過する障害が発生していた。R氏は、システム部の部長に状況を説明し、次週の経営会議に報告するよう指示を受けた。 　経営会議では、品質に問題があって注文が正しく処理されないと顧客企業に迷惑が掛かるので、品質の確保を最優先にすること、社内の業務効率向上が目的であり稼働日には調整の余地があるので販売部門に確認すること、予算を超過するコストの追加が必要な場合は経営会議の承認を得ること、が指示された。この指示を受けてR氏は、一旦プロジェクトを中断してプロジェクト計画変更の検討を開始した。 　R氏は、販売部門に稼働日についてヒアリングして、“業務の都合上、2020年6月30日に稼働させてほしい”との回答を得た。1週間後の経営会議で承認が得られて、翌日にプロジェクトを再開すれば、6月29日までのプロジェクトの作業可能な日数は100日であった。 　 〔結合テスト工程の障害の原因分析〕 　R氏は上司のアドバイスを受けながら、結合テスト工程で発生した障害を複数の観点で分析し、表2～4に整理した。テストケースの不備やテスト作業のミスを除くと、障害件数は合計240件であった。

　なお、表3の画面表示の障害とは、画面に表示する項目の位置がずれる障害で、商品サブシステム及び販売サブシステムで発生している。また、表4の原因工程とは障害の原因が作り込まれた工程を意味する。 　R氏は品質の状態をサブシステム別の観点の分析から見た結果、特に販売サブシステムの品質を強化することにした。さらにa別の観点の分析から、成果物を確認したところ、機能をまたがる整合性の確認が不十分であったことが分かった。これによって、障害件数が目標とするテスト検出不具合密度を大幅に超過した根本原因を特定した。そこで、R氏はこれまでに発生した障害の状況を踏まえて是正処置を講じた上で、b工程から作業を再実施する方針とした。 　 〔販売部門との調整〕 　R氏は、プロジェクト計画の変更に向けて、工数と期間の再見積りをすることにした。その際、“再実施する工程”、“再実施する結合テスト工程の障害の解消”及び“ソフトウェア適格性確認テスト・受入れテスト”に分けて見積もることにして、表5にその前提条件をまとめた。また、Q社のシステムの開発の経験があり、現在の開発要員と同様の開発生産性を期待できる開発要員を社外から2名調達して、開発要員を合計10名とすることにした。なお、開発要員は全てのサブシステムの全ての工程に対応が可能なので、タスクの待ちはなくフル稼働し、PMの工数は見積りに含めないものとする。

　“再実施する工程”と“再実施する結合テスト工程の障害の解消”それぞれの工数と期間を見積もり、“ソフトウェア適格性確認テスト・受入れテスト”の期間を加えた。 　見積りの結果、全てのサブシステムを　b工程からやり直し、再実施する結合テスト工程の全ての障害を解消する場合、開発要員を増員した体制でも、稼働までの作業に必要な日数はc日となり、期限に間に合わないことが分かった。 　R氏は、開発要員を更に増やして作業期間を短縮する方法と、各工程の一部を並行実行して作業期間を短縮する方法を検討したが、いずれも品質を確保する上でリスクがあるので、別の方法を検討する必要があると考えた。 　そこで、R氏は販売部門とシステム稼働の開始を判断するためのdを変更することにした。検討の結果、“画面表示の障害はシステム利用の際に支障のある問題点とはならないので6月30日の稼働後に対応する”、“稼働日を考慮し、①リベートサブシステムを6月30日に稼働するスコープから外す”ことを提案することにした。これによる見積りの前提条件の変更点を表6にまとめた。 　

　調整の結果、6月30日の稼働後に追加開発を行うことを条件に販売部門とdの変更の合意が取れた。作業が必要な日数はe日となり、期限に間に合う計画になった。

〔経理の処理のパターンへの対応〕 　販売部門からシステム部に、経理サブシステムで算出する金額の誤りは業務への影響が大きいので、全ての経理の処理のパターンにおいて現行業務で算出している金額と経理サブシステムで算出する金額に差異がないように、特に注意して検証するよう要請があった。R氏は、経理の処理に関する条件は多にわたるので、販売部門にデータの提供を依頼し、②結合テストで予定していたテストの他に別のテストを追加した。このテストを追加しても期限には間に合うことも確認した。 　 〔プロジェクトの監視） 　R氏は、これまでの検討結果を反映して、プロジェクト計画を変更し、予定していた経営会議で承認を得たので、プロジェクトを再開した。R氏は、プロジェクトを再開するにたって、進捗管理に加えて、計画どおりの工数で完了できるかどうかを見極めるため、検証と監視を強化した。実施する工程については、一部機能で先行作業を行って、見積りどおりの工数に収まることを検証した。さらに再実施する結合テスト工程の障害の解消については、表5及び表6の前提条件に基づいて、③再実施する結合テスト工程で二つの指標の実績値を監視することにした。