解説

• 図1の作業工程図はプレシデンスダイアグラムと呼ばれるものです。
  
  プレシデンスダイアグラム法は、個々の作業を四角で囲み、作業同士を矢印で結ぶことで作業順序や依存関係を表現する図法です。作業同士の関係を表すという意味ではアローダイアグラムと同じですが、アローダイアグラムでは作業を矢印で、結合点を丸のノードで示すので、記述方法が根本的に異なります。またアローダイアグラムでは、ある作業の終了が別の作業の開始条件となる「終了－開始」(FS：Finish to Start)の依存関係しか表現できませんが、プレシデンスダイアグラムではこの他に、「開始-開始」(SS：Start to Start)、「開始-終了」(SF：Start to Finish)、「終了-終了」(FF：Finish to Finish)の関係を記述できることが特徴です。
  
  プレシデンスダイアグラム法では、凡例に貼るように個々の作業を表す四角の四隅に数字を記述することがあります。これはそれぞれ次の意味をもちます。
  
  プレシデンスダイアグラムを作図する場合は、まずは各作業を四角で囲み、依存関係に注意しながら最早開始日と最早完了日を書き入れます。
  
  全体の最短完了日数が14日とわかるので、そこから逆算して最遅終了日、最遅開始日を書き入れます。(クリティカルパス上の作業は、最早開始日＝最遅開始日、最早終了日＝最遅終了日になります)
  
  〔aについて〕
  作業A3の最早開始日が入ります。最早開始日とは、その名の通り最も早くその作業を開始できる日です。
  表1「作業一覧」を見ると、作業A3は作業A2が完了すれば開始でき、作業A2は作業A1が完了すれば開始できるとわかります。作業A1及び作業A2ともに所要日数は10日なので、作業A3の最早開始日は、プロジェクトの開始日である1日目に所要日数「10日＋10日＝20日」を足した21日目となります。
  
  ∴a＝21日
  
  〔bについて〕
  作業B1の最遅終了日が入ります。最遅終了日とは、プロジェクト全体がスケジュール通りに完了するために、その作業を少なくとも完了していなくてはならない日です。
  最終結合点で最早終了日＝最遅終了日となっている120日がプロジェクト全体の所要日数です。この120日から作業C・作業B5・作業B4の所要日数を引いたものが答えになります。表1「作業一覧」を見ると、作業Cの所要日数は10日、作業B5は20日、作業B4は36日なので、
  
  　120日－10日－20日－36日＝54日
  
  作業B1が少なくとも54日目までに終了していれば、後続作業の所要日数66日を足しても120日でプロジェクトは完了するということです。
  
  ※作業B4の最遅終了日が90日と記載されているので、単純に「90日－36日＝54日」でも良いと思います。
  
  ∴b＝54日
  
  なお、本問のプレシデンスダイアグラムに数値を入れると次のようになります。
  
• フィット＆ギャップ分析は、企業の業務プロセス、システム化要求などのニーズと、ソフトウェアパッケージの機能性がどれだけ適合し、どれだけかい離しているかを分析する手法です。
  
  会計システムを利用する経営企画部と経理部は、更改に当たり「SaaSの機能について，P社向けに一部の改修を要求」しているので、フィット＆ギャップ分析により、現行の会計システムとSaaSで提供される機能を比較して、カスタマイズが必要な部分を洗い出しその開発規模を見積もることになります。
  表1「作業一覧」では、会計システムのカスタマイズが10日と見込まれていますが、フィット＆ギャップ分析の結果によってはカスタマイズの規模が大きくなり、追加作業や所要日数の増加が生じる可能性があります。この場合、作業一覧や作業工程図を変更しなければなりません。これが本設問の肝要な部分です。
  
  ∴カスタマイズの規模が事前の想定とかい離した場合

解説

• 〔cについて〕
  B3からB5までの作業を短縮するためにクラッシング及びファストトラッキングの適用を検討しています。クラッシングとファストトラッキングは、どちらもプロジェクトの期間を短縮する方法です。

  クラッシング

  クリティカルパス上の作業に追加資源を投入することでプロジェクト全体のスケジュールを短縮させる方法。メンバの増員や時間外業務の拡大などが該当する。

  ファストトラッキング

  開始当初の計画では直列に並んでいた作業を同時並行的に行ったり、作業の前後を入れ替えたりすることで期間短縮を図る方法。

  プロジェクト全体の期間を短縮するにはクリティカルパス上の作業を短縮しなければなりません。よって、cにはクリティカルパスが入ります。
  
  プレシデンスダイアグラムにおけるクリティカルパスは、最早開始日＝最遅開始日、かつ、最早終了日＝最遅終了日となる作業の繋がりです。実際に完成したプレシデンスダイアグラムを見ると、B3からB5はどれもクリティカルパス上の作業となっています。
  
  ∴c＝クリティカルパス
  
  
• 〔dについて〕
  案2では、3つのモジュールを順次開発します。従前の計画では全モジュールを並行して作業するので、どのモジュールのソフトウェア設計も24日目の完了でしたが、順次開発になれば、人事モジュールのソフトウェア設計は8日後、給与モジュールは16日後、共通モジュールは24日後に完了することになります。
  
  この変更により8日目に完了した人事モジュールについては、9日目から"プログラム設計・単体テスト"の工程に移ることができます。本来はソフトウェア設計の作業がすべて完了する予定であった日の翌日25日目から開始する予定でしたから、本来の16日前から"プログラム設計・単体テスト"の作業を開始できます。"プログラム設計・単体テスト"の作業IDはB4ですから、dにはB4が入ります。
  
  ∴d＝B4
  
  
• 〔eについて〕
  案1では、設計チーム・製造チームにそれぞれ10人ずつ追加します。これにより、"ソフトウェア設計"から"ソフトウェア適格性確認テスト"までの作業の所要日数が短縮されます。
  
  現状の要員数は"ソフトウェア設計"・"プログラム製造・単体テスト"及び"ソフトウェア適格性確認テスト"ともに12人であり、追加された要員10人の生産性は当初計画の80％ですので、どの工程でも要員追加後の実質的な生産性は、
  
  　12人＋(10人×80％)＝20人日
  
  となります。これは現状の12人日の5／3倍に相当しますから、要員追加後の所要日数は当初予定の所要日数の3／5倍となります。"ソフトウェア設計"・"プログラム製造・単体テスト"及び"ソフトウェア適格性確認テスト"の所要日数の合計は「24日＋36日＋20日＝80日」ですから、その3／5倍は48日です。つまり、短縮できる日数は「80日－48日＝32日」となります。
  
  【別解】
  計算量は多くなりますが、各工程の工数を算出して20人日で割ることで要員追加後の所要日数を求めることも可能です。
  • ソフトウェア設計 … 12人×24日＝288人日
  • プログラム製造・単体テスト … 12人×36日＝432人日
  • ソフトウェア適格性確認テスト … 12人×20日＝240人日
  • 合計 … 288＋432＋240＝960人日
  各工程ともに20人日の生産性で作業を進めるので、所要日数は「960人日÷20人日＝48日」、短縮可能な日数は「80日－48日＝32日」となります。
  
  ∴e＝32
  
  〔fについて〕
  案2では、P社の事業運営において増加するコストが150万円と見積もられています。しかし、開発期間を短縮できた場合には1日当たり5万円のコスト削減が見込まれていますから、案2の短縮日数分のコスト削減金額を差し引いた金額が実質的な増加コストとなります。
  
  　150万円－(5万円×16日)＝70万円
  
  ∴f＝70
  
  
• 現状では3つのモジュールの開発を並行して行っていたので、各工程の完了したタイミングで3つのモジュールをまとめて品質判定していたことになります。しかし、案2を採用すると各モジュールが順次開発になり、全てのモジュールの作業完了を待つことなく次の工程に移っていきます。現状の品質判定タイミングのままだと、品質判定が行われる前に次工程に取り掛かることになるため品質不良による手戻りが生じる可能性が考えられます。これを回避するためには、各モジュールの各作業が完了したタイミングで、その都度品質判定を実施する必要があります。
  各モジュールの各作業が完了したタイミングとは、「人事モジュールのソフトウェア設計が完了した」とか「給与モジュールのプログラム開発・単体テストが完了した」などの時点です。
  
  ∴各モジュールの各作業が完了したタイミングで品質判定を行う