2022年 春期 応用情報技術者試験 問9

販売システムの再構築プロジェクトにおける調達とリスク

D社は、若者向け衣料品の製造・インターネット販売業を営む企業である。売上の拡大を目的に、販売システムを再構築することになった。再構築では、営業部門が販売促進の観点で要望した、購買傾向を分析した商品の絞込み機能、及びお薦め商品の紹介機能を追加する。あわせて、販売システムとデータ接続している現行の在庫管理システム、生産管理システムなどのシステム群（以下、業務系システムという）を新しいデータ接続仕様に従って改修する。また、スマートフォン向けの画面デザインや操作性を向上させる。これらを実現するために、販売システムの再構築及び業務系システムの改修を行うプロジェクト（以下、再構築プロジェクトという）を立ち上げた。

再構築プロジェクトのプロジェクトマネージャにはシステム部のE課長が任命された。D社の要員はE課長と開発担当のF君の2名である。業務系システムの改修は、このシステムの保守を担当しているY社に依頼する。販売システムの再構築の要員は、Y社以外の外部委託先から調達する。

[販売システムの要件定義]

販売システムの要件定義を3月に開始した。実現する機能を整理するため、営業部門にヒアリングした上で要求事項を確定する。この作業を実施するために、E課長から外部委託先の選定を指示されたF君は、衣料品販売業のシステム開発実績はないが他業種での販売システムの開発実績が豊富であるZ社から派遣契約で要員を調達することにした。派遣労働者の指揮命令者に任命されたF君は、次の条件をZ社に提示したとE課長に報告した。

(a) 作業場所はD社内であること

(b) F君が派遣労働者への作業指示を直接行うこと

(c) 派遣労働者に衣料品販売業務に関するD社の社内研修をD社の費用負担で受講してもらうこと

(d) F君が事前に候補者と面接して評価し、派遣労働者を選定すること

これに対してE課長から、①これらの条件のうち労働者派遣法に抵触する条件があると指摘されたので、これを是正した上でZ社に依頼し、要員を調達した。

E課長は、要件定義作業を始めてから、営業部門が新機能を盛り込んだ業務フローのイメージを十分につかめていないことに気がついた。営業部門に紙ベースの画面デザインだけを用いて説明していることが原因であった。そこで、②システムが提供する機能と利用者との関係を利用者の視点でシステムの動作や利用例を使って表現した、UMLで記述する際に使用される図法で作成した図を使って説明し、営業部門と合意して要件定義作業は3月末に終了した。

[開発スケジュールの作成]

要件定義作業を終えたF君は、次の項目を考慮して図1に示す再構築プロジェクトの開発スケジュールを作成した。

・外部設計で、画面レイアウト、画面遷移と操作方法、ユーザインタフェースなどを定義した画面設計書を作成する。また、販売システムと業務系システムとのデータ接続仕様を決定する。

・外部設計完了後、ソフトウェア設計～ソフトウェア統合テスト（以下、ソフトウェア製造という）を、販売システム、業務系システムでそれぞれ実施する。

・販売システム及び業務系システムのソフトウェア製造完了後、両システムを統合して要件を満たしていることを検証するシステム統合テスト、更にシステム全体が要件どおりに実現されていることを検証するシステム検証テストを実施する。

・システム検証テストと営業部門によるユーザ受入れテスト（UAT：User Acceptance Test）の結果を総合的に評価して、稼働可否を判断する。稼働が承認された場合、営業部門が要求している8月下旬に新しい販売システムを稼働してサービスを開始する。

[外部委託先との開発委託契約]

販売システムの再構築作業は、要件定義作業で派遣労働者を調達したZ社に開発委託することにした。F君は、③Z社との開発委託契約を、次のとおり作業ごとに締結しようと考え、E課長から承認された。

・外部設計は、作業量に応じて報酬を支払う履行割合型の準委任契約を結ぶ。

・ソフトウェア製造は、請負契約を結ぶ。Z社に図1のソフトウェア製造の詳細なスケジュールを作成してもらい、週次の進捗確認会議で進捗状況を報告してもらう。

・ソフトウェア製造作業を終了したZ社からの納品物（設計書、プログラム、テスト報告書など）に対して、D社は6月最終週にaし、その後、支払手続に入る。

・ソフトウェア製造でZ社が開発した販売システムのソフトウェアをD社が他のプロジェクトで再利用できるように、開発委託契約の条文中に"ソフトウェアのbはD社に帰属する"という条項を加える。

・システム統合テスト及びシステム検証テストは、履行割合型の準委任契約を結ぶ。

一方、業務系システムの改修作業は、Z社と同様の開発委託契約にすることをY社と合意しており、現在の業務系システムの保守に支障を来さないことも確認済みである。

[開発リスクの特定と対応策]

E課長は、F君が作成した開発スケジュールをチェックして、販売システムの再構築に関するリスクを三つ特定し、それらを回避又は軽減する対応策を検討した。

一つ目に、外部設計で作成した画面設計書を提示された営業部門が、画面操作のイメージをつかむのにかなりの時間を要し、後続のソフトウェア製造の期間になってから仕様変更要求が相次いで、外部設計に手戻りが発生するリスクを挙げた。この対応策として、外部設計でプロトタイピング手法を活用して開発することにした。D社が調査したところ、Z社にはプロトタイピング手法による開発実績が多数あり、Z社の開発標準は今回の販売システムの開発でも適用できることが分かった。プロトタイピング手法による開発は、営業部門が理解しやすく、意見の吸収に有効である。しかし、営業部門の意見に際限なく耳を傾けると外部設計の完了が遅れるという新たなリスクが生じる。E課長はF君に、追加・変更の要求事項のc、提出件数の上限、及び対応工数の上限を定め、提出された追加・変更の要求事項の優先度を考慮した上でスコープを決定するルールを事前に営業部門と合意しておくように指示した。

二つ目に、Z社の製造したプログラムの品質が悪いというリスクを挙げた。外部設計書に正しく記載されているにもかかわらず、Z社での業界慣習の理解不足でプログラムが適切に製造されず、後続の工程で多数の品質不良が発覚すると、不良の改修が8月下旬のサービス開始に間に合わなくなる。これに対し、E課長はF君に、Z社に対して業界慣習に関する教育を行うように指示した。さらに、④ソフトウェア製造は請負契約であるが、D社として実行可能な品質管理のタスクを追加し、このタスクを実施することを契約条項に記載するように指示した。

三つ目に、スマートフォン向けの特定のWebブラウザ（以下、ブラウザという）では正しく表示されるが、他のブラウザでは文字ずれなどの問題が生じるリスクを挙げた。E課長は、利用が想定される全てのブラウザで動作確認することで問題発生のリスクを軽減することにした。しかし、利用が想定されるブラウザは5種類以上あるが、開発スケジュール内では最大2種類のブラウザの動作確認しかできないことが分かった。現状のスマートフォン向けのブラウザの国内利用シェアを調べると、上位2種類のブラウザで約95%を占めることが分かった。E課長は、営業部門と8月下旬のサービス開始前に⑤ある情報を公表することを前提に、上位2種類のブラウザに絞って動作確認することで合意した。