応用情報技術者 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（ソフトウェア設計）：1モジュールあたり $4$ 人で $24$ 日 → 1モジュールの工数は $4\times 24=96$ 人日。モジュールは3つあるので全体で $96\times 3=288$ 人日。
• B4（プログラム製造・単体テスト）：1モジュールあたり $4\times 36=144$ 人日、3モジュールで $144\times 3=432$ 人日。
• B5（ソフトウェア適格性確認テスト）：表1の担当は「設計チーム［12］」で所要日数 $20$ 日なので工数は $12\times 20=240$ 人日。
  したがって、B3～B5の合計工数は $288+432+240=960$ 人日（ただし工程ごとにチームが別）です。元のカレンダ日数合計は表1の所要日数を足して $24+36+20=80$ 日です。

1. 案1（追加要員を投入）の効果（短縮日数の算出）

• 前提より「設計チーム、製造チームとも22人の体制」で、追加10人の生産性は当初の $80\%$ とされている。したがって各チームの実効的な等価人数は $12+10\times 0.8=20$（等価人）となります（「追加する開発要員の生産性は、…当初計画の80%で見積もる。」）。
• 各工程の新しいカレンダ所要日数はその工程の総工数を等価人数で割って求めます。
  • B3': $288÷20=14.4$ 日
  • B4': $432÷20=21.6$ 日
  • B5': $240÷20=12$ 日
• 合計は $14.4+21.6+12=48.0$ 日。元の $80$ 日からの短縮は $80-48=32$ 日。よって e = $32$。

1. 案2（要員追加なし）の増加コスト算定（f）

• 問文に「既に計画されている他のプロジェクトの作業が遅延し、P社の事業運営において増加するコストを150万円と見積もる。」とあり、また「開発期間を短縮できた場合には、P社の事業運営において、1日当たり5万円のコストの削減が見込まれる。」とあります。
• 案2では短縮期間が問題文に明示のとおり $16$ 日（「ソフトウェア設計の作業が全て完了する予定であった日の16日前から並行して…開始する」）です。したがって節約額は $16\times 5=80$ 万円。
• よって増加コストの純額は $150-80=70$ 万円。よって f = $70$。

• e：32
• f：70

誤りやすいポイント

• 「1モジュール当たりの工数」を抜かす・3モジュール分への展開を忘れる（$96\times 3=288$ を忘れやすい）。
• 追加要員の生産性を単純に100% とする誤り。ここでは追加要員は「80%」なので等価人数は $12+10\times 0.8$ と計算する必要がある。
• 人日（工数）とカレンダー日数を混同する。工程の短縮は「工数÷実効人数」で求める（人日÷人数＝日）。
• B4の開始条件（B1とB3の両方）を見落として、誤ってB1のみで判断する。今回B1は早く終わるため影響しませんが、常に確認すること。
• コスト計算で単位（万円）を扱う際の掛け算の向きに注意する（1日あたり5万円 × 日数＝万円）。
• 端数（日数の小数）を扱う際、途中で四捨五入すると誤差が出る。計算は小数で正確に行い、最終的に設問が整数を要求する場合のみ整数で示す。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ