応用情報技術者 2013年 春期 午後 問10

解答の論理構成

• 問題文の引用
  「またWBSでは各タスクのa関係が分かりにくいので、フローダイアグラムも作成した。」
• WBSは成果物分割構造であり、タスク同士の前後関係や依存関係は表しにくいという弱点があります。
• そこでプロジェクトマネジメントでは、タスクの順序を示すためにネットワーク図やフローダイアグラムを併用します。タスク同士の「どれが先で、どれが後か」を示す関係は一般に「先行後続関係」と呼ばれます。
• フローダイアグラムを作成した目的が「タスク間の順序を可視化すること」であるため、a には「先行後続」を当てはめるのが適切です。
• 以上より解答は「先行後続」となります。

誤りやすいポイント

• 「依存」「関連」などの抽象的な語を入れてしまう
  → WBSが苦手とするのは依存の内容そのものではなく、タスクの順序（先・後）の視認性です。
• 「前後関係」と記述する
  → 正しい意味ではあるものの、5字以内の条件と用語の一般性から「先行後続」がより適切です。
• フローダイアグラム＝フローチャートと連想し、プログラムの制御構造だと誤解する
  → ここではプロジェクトタスクの流れを示す図であり、作業順序を把握する補助資料です。

FAQ

解答の論理構成

1. 指標の確認
   • 【問題文】「表1　開始後4週間の本プロジェクト全体のEVM表」における“4月26日”の値は
     • 「PV（Planned Value）」＝14,000
     • 「EV（Earned Value）」＝10,400
       と明示されています。
2. スケジュール差異 (SV) の算出
   • EVM では $SV=EV-PV$ が基本式です。
   • したがって
     SV = 10,400 − 14,000 = −3,600 (単位：千円)
3. 判定ロジック
   • $SV<0$ の場合、作業が計画より遅れていると判断します。
   • 上式は −3,600 で負値ですから「遅れ」と結論づけます。
4. 大きさの扱い
   • 設問は「大きさが何千円であったか答えよ」とあり、負符号ではなく金額の絶対値を求めています。
   • よって大きさは 3,600千円 となります。

• スケジュール：遅れ
• 大きさ：3,600千円

誤りやすいポイント

• PV と EV の読み違え：列・行を取り違え、4月26日以外の値で計算してしまう。
• SPI と混同：SPI = EV / PV をそのまま差異と勘違いし、0.74 を金額と答えてしまう。
• 符号処理：−3,600 をそのまま「−3,600千円」と書き、要求された“遅れ／進み”の文言を落とすミス。

FAQ

解答の論理構成

1. コストの評価指標
   プロジェクトのコスト状況は、EVM の指標 CV (Cost Variance) で確認します。
   $CV=EV-AC$
   「EV（Earned Value）：実際に出来上がった作業量に相当する計画コスト」から「AC（Actual Cost）：実際に支出したコスト」を引き、正負で判断します。
2. 4月26日の数値を確認
   【問題文】表1の「4月26日」の行を引用します。
   ・EV：10,400
   ・AC：12,000
3. CV を計算
   $CV=10,400-12,000=-1,600$
   値が負なのでコストは「超過」です。絶対値が 1,600千円 だけ予定より多く使っています。
4. 設問への対応
   問われているのは「コストは、超過／削減／予定どおりのいずれか」と「大きさ」。
   よって
   コスト：超過
   大きさ：1,600千円

誤りやすいポイント

• PV と EV を取り違えて CV を計算し、誤って「14,000−12,000＝+2,000」として削減と判断してしまう。
• 金額の単位を見落として「1.6千円」や「1,600円」などと書いてしまう。
• CV が負の場合の表現を「赤字」「コストオーバー」など独自用語で記述し、採点基準とズレる。

FAQ

解答の論理構成

1. 社内ルールの確認
   【問題文】に「SPI又はCPIが0.90を下回ったとき、プロジェクトに何か問題が生じていると判断して、原因の調査及び対策の検討に着手する」とあります。したがって最初に $0.90$ を下回った日を探せば良いです。
2. 指標値の計算方法
   Schedule Performance Index (SPI) は $SPI=\frac{EV}{PV}$、Cost Performance Index (CPI) は $CPI=\frac{EV}{AC}$ です。計算に用いる数値は【問題文】表1のとおりです。
3. 週次の計算結果
   • 4月5日　$SPI=\frac{3,350}{3,500}=0.96$、$CPI=\frac{3,350}{3,000}=1.12$
   • 4月12日　$SPI=\frac{6,200}{7,000}=0.886\dots$、$CPI=\frac{6,200}{6,000}=1.03$
   • 4月19日　$SPI=\frac{8,550}{10,500}=0.81$、$CPI=\frac{8,550}{9,000}=0.95$
   • 4月26日　$SPI=\frac{10,400}{14,000}=0.74$、$CPI=\frac{10,400}{12,000}=0.87$
4. 閾値との比較
   最初に $0.90$ を下回ったのは「4月12日」の $SPI$ で $0.886\dots$ です。小数第3位を四捨五入し小数第2位まで求めると $0.89$ になります。
5. よって
   • 日付：4月12日
   • 指標：○SPI
   • 値：0.89

誤りやすいポイント

• CPI ではなく SPI が先に閾値を割る点の取り違え
• 0.886… を切り捨てて 0.88 としてしまう計算ミス
• 閾値「下回った」を「以下」と誤読し 0.90 ちょうどを含めてしまう誤判断
• 表1の値を読み間違え PV⇔EV を取り違えた計算

FAQ

解答の論理構成

1. 各チームの現状を【問題文】から整理
   • 「業務ロジックチーム…スケジュールは遅れている」
   • 「データベースチーム…スケジュールは進んでいる。生産性は当初の想定よりも高い」
   • 「ユーザインタフェースチーム…予定どおりに配置している要員が待ち状態となっており、スケジュールは遅れている」
2. EVM の典型的なグラフの形を確認
   • スケジュール遅延＋要員待機：PV＝AC ＞ EV
   • スケジュール遅延＋要員不足：PV ＞ EV＝AC
   • スケジュール前倒し＋高生産性：EV ＞ AC、かつ SPI ≥ 1
3. 図1の三つのグラフの特徴を読み取る
   • b：PV と AC が重なり、EV が大きく離れている → 要員は計画通り消費しているが成果が出ていない
   • c：EV と AC が重なり、両方とも PV より小さい → 人が足りずコストと成果が等しいまま遅延
   • d：EV が AC を上回っておりコスト効率が高い → 高スキルで前倒し気味に進行
4. 上記をチーム状況に対応させる
   • 要員待機＝ユーザインタフェース → b
   • 要員不足＝業務ロジック → c
   • 高生産性＝データベース → d
5. よって
   • b：ウ
   • c：ア
   • d：イ

誤りやすいポイント

• 「スケジュール遅れ＝EV が小さい」とだけ考え、AC の動きを無視すると UI と業務ロジックを取り違えやすいです。
• EV と AC のどちらが重なるかまで見ないと、高生産性（EV＞AC）と単なる遅延（EV＝AC）の区別がつきません。
• CPI／SPI の算出式（SPI＝EV÷PV、CPI＝EV÷AC）を頭に入れておかないと、グラフから状態を言語化できません。

FAQ

解答の論理構成

• 問題文には次の記述があります。
  「業務ロジックチーム： … スケジュールは遅れている。生産性はe。」
• 生産性を判断する代表的なEVM指標はCPI（Cost Performance Index）です。
  CPIは $CPI=\frac{EV}{AC}$ で計算します。
• 図1を見ると、業務ロジックチームの EV と AC が同じ値で推移している ため $EV=AC$ となります。
  よって $CPI=1.0$ となり、計画通りの生産性であることを示します。
• 以上より、e には「当初の想定どおりである」が入ります。
  理由は「EVとACが等しいから」です。

誤りやすいポイント

• スケジュール遅延＝生産性低下と短絡的に判断してしまう
  → コスト効率（CPI）とスケジュール効率（SPI）は別物。
• EV と AC の差ではなく、PV と EV の差を見て生産性を評価してしまう
  → PV は予定コストであって、実コストとは直接関係しない。
• CPI を計算せずグラフの見た目だけで高・低を決めてしまう
  → 必ず数式で裏付けることが重要。

FAQ

解答の論理構成

1. 問題の背景確認
   本文には「ユーザインタフェースチーム：　設計を終え、利用者にレビューを依頼しているが…見た目や操作性の十分な理解が進まず、いまだに利用者の合意が得られていない。」とあります。したがって、利用者が完成イメージを掴めず承認が遅れていることが主要因です。
2. 求められている対策の把握
   さらに本文では「レビューで十分な理解を得るために、fを骨組に作成し、設計書と合わせて説明するよう、R氏はユーザインタフェースチームに指示した。」と示されています。
3. “骨組”というキーワードの意味合い
   “骨組”は機能を限定していても画面遷移や操作感を体験できるモノを指すのが一般的で、静的な「モックアップ」より動的・試作的なものを示唆します。
4. UI／UX領域で利用者理解を深める標準的手法
   要件確認や合意形成を円滑にする代表的手法は「プロトタイプ」です。プロトタイピングにより利用者は実際に触って操作性を体験し、フィードバックを即座に反映できます。
5. 結論
   以上より、f に入る語は「プロトタイプ」が最も妥当です。

誤りやすいポイント

• 「モックアップ」と混同する
  モックアップは静的模型を指す場合が多く、“骨組”という表現や操作性確認の目的には「プロトタイプ」の方が適切です。
• “ユーザインタフェースの資料追加”と勘違いし資料名を答えてしまう
  例：ワイヤーフレーム、画面遷移図など。設問は具体物（試作ソフト）を求めています。
• EVMの数値ばかりに注目し、文章中の原因・対策の記述を読み飛ばす
  ブランク f はEVM計算とは無関係であり、ヒアリング結果と対策部分を精読する必要があります。

FAQ

解答の論理構成

1. 【問題文】では、遅延を挽回するために “必要な要員の確保” を決定したとあります。
   引用：「R氏は、業務ロジックチームの遅れを挽回し、予定完了日までに設計を完了させるために、必要な要員の確保を最優先で行うことにした。」
2. ただし同じ文中に “①新規メンバの投入が既存メンバの生産性に影響を及ぼすこと” を考慮したとも記載されています。
   引用：「その際、①新規メンバの投入が既存メンバの生産性に影響を及ぼすことを考慮し、既存メンバの効率を維持するための配慮も併せて行った。」
3. プロジェクト現場では、新しく加わったメンバを戦力化するまで、既存メンバが教育・フォローに時間を割くため、結果として既存メンバ自身の作業時間（工数）が減ります。
4. よって、下線①が示す具体的な内容は「教育という追加作業が既存メンバの工数を奪う」点であり、模範解答「既存メンバの工数が新規メンバの教育に割り振られる」と一致します。

誤りやすいポイント

• 「新規メンバ投入＝即戦力増」と短絡し、教育負荷を無視してしまう。
• 影響対象を“スケジュール”や“コスト”のみに限定し、既存メンバ自身の生産性低下を明示できない。
• 「コミュニケーションが増える」「調整が必要」とだけ書き、教育という具体行動を示さない。

FAQ