応用情報技術者 2019年 春期 午後 問09

解答の論理構成

1. 前提整理
   【問題文】表1より関係する作業と所要日数は
   ・作業 A1 ：「10」日
   ・作業 A2 ：「10」日
   ・作業 A3 ：「30」日
   ・作業 B1 ：「10」日
   ・作業 B2 ：「30」日
   ・作業 B3 ：「24」日
   作業間の制約は図1に示され、A2 ― A3 間と B1 ― B3 間の矢印上に空欄 a、b が置かれている。
2. 最早時刻 (ES、EF) の forward pass
   ① A 系列
   • A1 の ES＝1 → EF＝1＋10－1＝10
   • A2 は A1 完了翌日から着手できるので ES＝10＋1＝11、EF＝11＋10－1＝20
   • A3 は A2 完了翌日から着手できる。従って A3 の ES＝20＋1＝21
   → この「21」が A2 ― A3 間矢印に記載する値である。
   よって a＝21
   ② B 系列
   • B2：ES＝1、EF＝1＋30－1＝30
   • B1：ES＝1、EF＝1＋10－1＝10
   • B3 の ES は「B2 完了翌日」と「B1 完了翌日」の遅い方
   ⇒ max(30＋1, 10＋1) ＝31
   • B3 の EF＝31＋24－1＝54
   → この「54」が B1 ― B3 間矢印に記載する値である。
   よって b＝54
3. 結論
   ・a＝「21」
   ・b＝「54」

誤りやすいポイント

• 「翌日から着手」の 1 日加算を忘れ、ES や EF を 1 日ずつずらしてしまう。
• B3 の ES を「30＋1＝31」の計算だけで求め、B1 からの制約を無視する。
• A3 の ES と EF まで計算せずに a を A2 の EF（＝20）と勘違いする。

FAQ

解答の論理構成

• 指示①は、Q部長が「“フィット＆ギャップ分析が完了した時点で、必要に応じて作業一覧と作業工程図を修正する”」よう求めた場面です。
• 同じ段落で、会計システムの作業内容について「“P社の経理業務に適合させるために、R社のSaaSに対して小規模のカスタマイズを行う。”」と前提を置いています。
• フィット＆ギャップ分析では、SaaS標準機能と要求仕様を突き合わせて差分（ギャップ）を洗い出します。
• もし分析結果で「小規模」と見込んでいたカスタマイズ量が想定より大きい／小さいと判明すれば、必要日数・担当要員・後続作業の開始時期が変動し、工程図やWBS（作業一覧）の前提が崩れます。
• したがって「カスタマイズの規模が事前の想定とかい離した場合」にのみ修正が必要となり、模範解答と一致します。

誤りやすいポイント

• 「フィット＆ギャップ分析が終わったら必ず修正する」と早合点しやすい
• “要件変更があれば修正”と広く書き過ぎてしまう
• 人事給与システム側の変更理由を書いてしまい、質問対象（会計システム）を取り違える
• 「分析期間が遅延した場合」とスケジュールの遅れにフォーカスし過ぎる

FAQ

解答の論理構成

1. 問題文では、外部設計途中の要請に対して、S課長が「作業 ID の B3 から B5 までの連続する作業の経路が、c の一部を含むので、人事給与システムのソフトウェア設計からソフトウェア適格性確認テストまでの作業を対象として、クラッシング及びファストトラッキングの考え方を用いて、開発期間を短縮することにした。」と記載しています。
2. “クラッシング”も“ファストトラッキング”も、プロジェクト全体の工期短縮を目的としてクリティカルパス上の作業を重点的に圧縮・前倒しするテクニックです。
3. よって、B3→B5 がプロジェクトの最長経路（遅れると全体が遅延する経路）に乗っているからこそ、短縮対象に選ばれたと判断できます。
4. したがって c に入る語句は、プロジェクトマネジメントで「最長経路」を表す “クリティカルパス” となります。

誤りやすいポイント

• “重要な経路” という読み取りで「主要経路」など曖昧な語を入れる失点。
• “クラッシング”“ファストトラッキング”の使いどころを理解せず、単に人員追加や並列化ならどこでも良いと考えてしまう誤認。
• B3〜B5 だけを見て “部分的な最長経路” と捉え「サブクリティカルパス」と誤記するケース。

FAQ

解答の論理構成

1. 【問題文】には、案2の説明として
   “これによって、ソフトウェア設計の作業が全て完了する予定であった日16日前から並行してdの作業を開始することができ、開発期間が短縮できる。”
   とあります。
   ここで “dの作業” は、“ソフトウェア設計と並行して前倒しで着手できる後続作業” を指します。
2. 同じ段落の冒頭で
   “プログラム製造・単体テストの作業は、製造チームが担当する”
   と明記されており、この作業は表1の作業 ID “B4” に該当します。
3. 表1を確認すると
   “B4　プログラム製造・単体テスト”
   と列記されており、ソフトウェア設計（“B3”）の直後に位置するタスクです。
4. したがって、ソフトウェア設計（B3）の完了を待たずに前倒し着手する作業は “B4” であると論理的に決定できます。

誤りやすいポイント

• “並行して開始” と聞いて “B5” を選びがちですが、B5 は “ソフトウェア適格性確認テスト” であり、B4 完了後でなければ着手できません。
• “16日前” という数字に惑わされて、人事給与システム外のタスク（例：A 系列）を候補に挙げてしまうケースがあります。あくまで B3〜B5 の連続経路が対象です。
• “設計チーム” と “製造チーム” の役割が混ざり、B3 と B4 の順序を取り違えるミスも頻出します。

FAQ

解答の論理構成

1. もとのクリティカルパス
   • 「B3 24 日＋B4 36 日＋B5 20 日」＝合計 80 日
   • これが“人事給与システム”側の最長経路であることは【表1】と【問題文】の「ソフトウェア設計からソフトウェア適格性確認テストまでの作業を対象」との記述より明らかです。
2. 案1（クラッシング）の日数短縮
   ① 追加要員後の有効工数
   • 設計チームも製造チームも「22 人」体制。
   • 追加 10 人は生産性 80％なので
     有効人数＝12 人＋10 人×0.8＝20 人。
   ② 必要マンデイ数
   • B3 の 1 モジュール当たり工数
     4 人×24 日＝96 人日
   • B4 の 1 モジュール当たり工数
     4 人×36 日＝144 人日
   • 3 モジュール総工数
     B3：96×3＝288 人日、B4：144×3＝432 人日
   • B5 の総工数
     12 人×20 日＝240 人日
   ③ 新たなカレンダー日数
   • B3 日数＝288／20＝14.4 日
   • B4 日数＝432／20＝21.6 日
   • B5 日数＝240／20＝12 日
   • 合計＝14.4＋21.6＋12＝48 日
   ④ 短縮量
   • 80－48＝32 日 … これが [e]
3. 案2（ファストトラッキング）の日数短縮
   • 「ソフトウェア設計の作業が全て完了する予定であった日16日前から並行してdの作業を開始」とあるため、短縮量はそのまま 16 日（表中既記）。
4. 増加コスト算定
   (1) 案1
   • 追加要員コスト＝5 万円／人日×96 人日＝480 万円
     （96 人日は 10 人×14.4 日＋10 人×21.6 日で算出）
   • 事業運営上の削減効果＝5 万円×32 日＝160 万円
   • 増加コスト＝480－160＝320 万円（表中既記）
   (2) 案2
   • 他プロジェクト遅延によるコスト＝150 万円
   • 事業運営上の削減効果＝5 万円×16 日＝80 万円
   • 増加コスト＝150－80＝70 万円 … これが [f]

誤りやすいポイント

• “追加要員は 20 人同時に稼働”と早合点し、余分な人日でコストを膨らませてしまう。実際には B3→B4→B5 が直列なので、設計側 10 人・製造側 10 人の稼働期間を分けて数える。
• 「生産性 80％」を人数に掛けず日数に掛けてしまい、人日計算を二重に縮める。
• 案2の“16日前から並行して開始”＝16 日短縮と素直に読めず、B3 の残り 16 日＋B4 の全期間などと誤って合算する。

FAQ

解答の論理構成

1. 現行ルールの確認
   　【問題文】には「ソフトウェア設計とプログラム製造・単体テストについては、各作業項目とも全グループの作業が完了した時点で、S課長が成果物の品質を判定する」とあります。つまり3モジュールすべてが終わるまで品質判定を待つルールです。
2. 案2での作業方式の変更
   　案2では「両チームとも、人事、給与、共通のモジュールの順に作業を行う」と明記され、モジュールを順次処理するシーケンシャル方式に変わります。さらに「ソフトウェア設計の作業が全て完了する予定であった日16日前から並行してdの作業を開始することができ」と記述され、モジュール単位で次工程へ前倒しする“ファストトラッキング”が狙いであることがわかります。
3. 品質判定を前倒しする必要性
   　従来どおり“全部完了後に一括判定”では、1モジュールが終わっても次工程へ渡せません。モジュール単位で並行を開始するためには、該当モジュールの成果物が出来るたびに品質を確認し、直ちに次工程へ流す品質ゲートが必要になります。
4. したがって
   　品質判定のタイミングは「各モジュールの作業完了時」に変更するのが合理的であり、模範解答「各モジュールの各作業が完了したタイミングで品質判定を行う。」に至ります。

誤りやすいポイント

• “各作業項目”という語をそのまま写してしまい、モジュール単位であることを示せない。
• 「全グループ完了後」という従来ルールを残したままではファストトラッキングが機能しないことを見落とす。
• “ソフトウェア設計のみ”または“プログラム製造・単体テストのみ”を対象と誤解し、両工程に共通する判定ルールである点を落とす。

FAQ