応用情報技術者 2021年 秋期 午後 問09

解答の論理構成

1. 【問題文】では表2のプロダクトオーナー行の「役割の説明」がaと欠落している。
   引用：「表2 本プロジェクトの体制」‐「プロダクトオーナー」‐「役割の説明」欄にa。
2. スクラム公式ガイドラインでプロダクトオーナーの主業務は「プロダクトバックログを作成し、順序付け、価値を最大化する」ことです。
   これを踏まえ、表2の「役割の説明」にはプロダクトバックログに関する記述が入るのが自然です。
3. 解答群を確認します。
   ア：S-04におけるスプリントバックログを作成する。
   イ：ガントチャートで本プロジェクトのスケジュールを管理する。
   ウ：情報システム部門へのスクラムの導入を指導、トレーニング及びコーチングする。
   エ：本プロジェクトのプロダクトバックログアイテムを作成・管理する。
4. アはスプリントバックログの作成であり、スクラムでは開発チームの仕事です。
   イはウォーターフォール的手法で、プロダクトオーナーの職務ではありません。
   ウはスクラムマスタの役割に近い内容です。
   エのみがプロダクトオーナー本来の責務であり、表2の空欄を適切に補完できます。
5. よって a に入る最も適切な選択肢は「エ：本プロジェクトのプロダクトバックログアイテムを作成・管理する」です。

誤りやすいポイント

• スクラムマスタとプロダクトオーナーの職務を混同し、ウを選んでしまう。
• スプリントバックログとプロダクトバックログを取り違え、アを選ぶミス。
• 表2の他行（スクラムマスタ欄）に既に「スクラムの実施方法を計画・助言する」とあるため、ウが空欄と誤認するケース。

FAQ

解答の論理構成

1. 体制の事実確認
   • 【問題文】では、下線①として「開発チームは、まずは全メンバで Webストアの開発チームを編成し、Webストアの開発の完了後に、モバイルアプリの開発チームとSNSの開発チームを編成することとする」と記されています。
2. 方針における人材育成の要求
   • 【問題文】の「本プロジェクトの方針」には、 「『P社にはスクラムの経験者が少ない。そこで試行開発の段階を設けて、スクラム開発の理解を深め、スクラムの開発要員を育成し、プロセスを確立しながら本プロジェクトを遂行する』」
     「『試行開発を経て、本格的なスクラム開発の人材を確保し、顧客からの要求に迅速に対応できるようにする』」
     と明示されています。
3. 2つの記述を結び付けて整理
   • まず全員を同一チームに集約すれば、経験者「3名」が未経験者「5名」をリードしながら実務でスクラムを学習可能。
   • Webストアを“試行開発”と位置付けることで、スクラム運用ノウハウを全メンバに共有し、次フェーズ（モバイルアプリ・SNS）でチームを分割しても自律的に回せる状態を目指しています。
4. よって、狙いは「スクラム要員の実践的育成と将来チームの人材確保」であり、模範解答「スクラムの開発要員を育成し、本格的なスクラム開発の人材を確保する」と合致します。

誤りやすいポイント

• 「3つのサブシステムを順に開発＝単なる工数平準化」と捉え、人材育成との関連を見落とす。
• 方針に書かれた「顧客からの要求に迅速に対応」を主目的と誤解し、育成の観点を回答から外してしまう。
• 経験者「3名」の存在を軽視し、全メンバ体制のメリットを挙げられない。

FAQ

解答の論理構成

• まず本文には、競合の更新頻度について「競合相手の Webストアは、1 年に 1～2 回程度のリリース」とあります。
• これに対して P 社は「②リリースのサイクルを 3 か月に 1 回とした」と明記し、競合より短い間隔でリリースできる体制を採用しました。
• さらにプロジェクト目的として「顧客からの要求に対して、競合相手と比べてより迅速に対応できるようにする」と宣言しています。
• 顧客はオンラインで簡単に他社へ乗り換える特徴があるため、短いリリース間隔は要求への素早い反映＝顧客離脱防止につながります。
• したがって下線②の狙いは「顧客からの要求に競合相手より迅速に対応すること」となります。

誤りやすいポイント

• 「アジャイル＝生産性が高いから短期リリース」と早合点し、競合比較や顧客離脱リスクを無視する。
• 「3か月」だけに着目し、頻度を上げる理由を技術的制約（CI/CD など）と勘違いする。
• 「顧客の特性」が“個人消費者”である事実に気付かず、BtoB など他の文脈で解釈してしまう。

FAQ

解答の論理構成

1. 問題文の該当箇所を確認
   • 「横軸に時間、縦軸にストーリポイントを割り当て、残りのストーリポイントを折れ線グラフで示すbを用いる」
   • 「プログラムの外部から見た動作を変えずにソースコードの内部構造を整理するcを実施する」
2. キーワードから想起できる図表・技法を整理
   • 残作業量を時間軸で折れ線表示するアジャイルの代表的ツールは「バーンダウンチャート」。
   • 外部仕様を変えずに内部構造を改善するプラクティスは「リファクタリング」。
3. 解答群との照合
   • 解答群「オ：バーンダウンチャート」が b に対応。
   • 解答群「ク：リファクタリング」が c に対応。
4. よって
   • b = オ
   • c = ク

誤りやすいポイント

• 「アーンドバリュー」と混同
  EVM はコスト・進捗を金額ベースで管理する指標で、残ストーリポイントの折れ線とは目的も見た目も異なります。
• 「インクリメンタル」「スパイラル」など開発モデルとの取り違え
  どちらもプロセス全体の枠組みを指す語であり、コード内部構造の改善を表す用語ではありません。
• バーンダウン vs バーンアップ
  残量を減らすグラフがバーンダウン、完了量を積み上げるのがバーンアップ。問題文は「残りのストーリポイント」と明記しているため前者です。

FAQ

解答の論理構成

1. 追加依頼が発生した背景
   • 会話の中で、ユーザチーム代表である「T氏」が「重要な新規要件を優先順位Aとして追加することがビジネス上必須となった。」と要求しました。
   • これに対しプロダクトオーナーである「R氏」が「リリース1でリリースするプロダクトバックログアイテムの見直しは不可避」と回答しています。
   • 要件追加に伴い優先順位やリリース計画を調整する必要があるため、変更時の手順を定めておかなければ再度同様の混乱が生じます。
2. 下線③の指示内容
   • 問題文は「③R氏とT氏との今回のプロダクトバックログアイテムの追加依頼の会話を踏まえて、関係者間でのプロセスの確立について検討することにした。」と述べています。
   • 「関係者間」とは、直接やり取りを行う「R氏」と「T氏」を中心に据えるのが自然です。
3. 確立すべきプロセスの内容
   • 追加・変更依頼が発生した際に
     ① 影響を受ける既存アイテムの棚卸し
     ② 優先順位の再評価
     ③ リリースへの組み込み可否判断
     ④ スプリントプランニングへの反映
     といった一連のフローを事前合意しておけば、作業生産性を誤解されることなく円滑に調整できます。
   • したがって解答は「T氏とプロダクトバックログアイテム変更に伴う対応方法を決めておく」となります。

誤りやすいポイント

• 「スクラムマスタのS氏と決める」と誤答する例
  スクラムマスタはあくまで促進役であり、変更内容のビジネス的優先度を決める当事者ではありません。
• 「開発チームと決める」とする例
  開発チームは実装担当で、プロダクトバックログの内容・優先順位を決める権限を持ちません。
• 変更プロセス＝承認フローとだけ考え、優先順位再評価やリリース影響分析を明示しないケース。

FAQ

解答の論理構成

1. 初期の総ストーリポイントを把握する
   • 表1の最下行より、Webストア全体のストーリポイント合計は 「99」pt。
2. リリース1に含めるポイントを整理する
   • リリース方針より「優先順位A…リリース1」。
   • Aに属するユーザストーリのポイントは次のとおり（すべて表1から計算）。
     • 小: 「9」 件 × 2pt = 18pt
     • 中: 「7」 件 × 3pt = 21pt
     • 大: 「2」 件 × 5pt = 10pt
     • 合計 18 + 21 + 10 = 49pt
3. 既に完了しているポイントを差し引く
   • 表3の合計欄より、S-01〜S-04で終了したポイントは 「36」pt。
   • A残ポイント = 49 − 36 = 13pt
4. 追加要件を考慮する
   • 会話文より「サイズ大のプロダクトバックログアイテム1個を新規追加」「優先順位 A」。
   • 大サイズのポイントは注3より 5pt。
   • リリース1の新しい合計 = 49 + 5 = 54pt
   • A残ポイントは 13 + 5 = 18pt（S-05, S-06で消化予定）。
5. リリース2のポイントを算出する
   • 全体ポイントも 99 + 5 = 104pt へ増加。
   • リリース2に回るポイント = 104 − 54 = 50pt
6. ベロシティ条件の確認
   • 表3より各スプリントのベロシティは 10, 8, 9, 9 → 平均 9pt。
   • リリース2 50pt ÷ 9 ≒ 6スプリントで収まるため「ベロシティ上の問題はない」。
   • よって d に入る値は 50。

誤りやすいポイント

• 新規追加の 5pt を全体 99pt に“足し忘れる”ため、残ポイントを 45pt と計算してしまう。
• 「優先順位B は場合によってリリース2でも可」の文を、A項目だけでなくB全部をリリース1に含めると誤読する。
• 表3の 36pt を「リリース1全体」ではなく「S-04単体」と取り違え、重複して減算する。
• ベロシティ確認を怠り、計算した残ポイントがチーム能力と合致しているかの検証を省いてしまう。

FAQ