令和3年度 秋期 応用情報技術者試験 午後 問題 問9 インターネット販売システム開発へのスクラムの導入とプロセス確立

表2の「プロダクトオーナ」の役割を問う問題です。
スクラムにおいて、プロダクトオーナはプロダクトの価値を最大化することに責任を持ち、プロダクトバックログの管理（アイテムの追加、優先順位付け、見直しなど）を行います。本文中でもR氏は「リリース1でリリースする計画のプロダクトバックログアイテムを見直すことになる」と判断しており、この役割を担っています。

各選択肢の解説

• ア: スプリントバックログの作成は、スプリントプランニングにおいて開発チームが行う役割です。
• イ: ガントチャートによるスケジュール管理は、従来のウォーターフォール開発におけるプロジェクトマネージャの役割であり、スクラムのプロダクトオーナの役割ではありません。
• ウ: スクラムの導入指導、トレーニング、コーチングを行うのはスクラムマスタ（S氏）の役割です。
• エ: 正解です。プロダクトバックログアイテムを作成・管理するのはプロダクトオーナの役割です。

本文中の「まずは全メンバでWebストアの開発チームを編成し」という体制の狙いについて、人材育成の観点から記述する問題です。
根拠となるのは〔本プロジェクトの方針〕(2)の記述です。
そこには「試行開発の段階を設けて，スクラム開発の理解を深め，スクラムの開発要員を育成し，プロセスを確立しながら本プロジェクトを遂行する」「試行開発を経て，本格的なスクラム開発の人材を確保し，顧客からの要求に迅速に対応できるようにする」とあります。
Webストアの開発は〔本プロジェクトのスコープ〕(3)において「試行開発」と位置付けられています。したがって、この試行開発を通じて要員を育成し、その後の本格的な開発に向けた人材を確保することが狙いです。

高得点のポイント

• 「スクラムの開発要員を育成する」という試行段階での直接的な目的が含まれていること
• 「本格的なスクラム開発の人材を確保する」という将来に向けた目的が含まれていること

「リリースのサイクルを3か月に1回とした」という方針の狙いを、顧客の特性を踏まえて記述する問題です。
根拠となるのは〔本プロジェクトの計画〕(1)の目的です。
顧客の特性として「インターネット販売システムへの要求が満たされないと顧客は簡単に競合相手に移ってしまう」ことが挙げられています。
これに対するP社の方針は「顧客からの要求に対して，競合相手と比べてより迅速に対応できるようにする」ことです。競合相手のリリースサイクルが「1年に1〜2回程度」であるのに対し、P社は「3か月に1回」と短く設定することで、競合よりも素早く顧客の要求をシステムに反映し、顧客の流出を防ぐ狙いがあります。

高得点のポイント

• 顧客の要求に対応するという目的が明示されていること
• 「競合相手より迅速に」対応するという、サイクルを短くした理由となる比較構造が含まれていること

本文中の $b$ に入る、プロジェクトの進捗状況を管理するためのグラフの名称を問う問題です。
「横軸に時間，縦軸にストーリポイントを割り当て，残りのストーリポイントを折れ線グラフで示す」という説明は、アジャイル開発（スクラム）でスプリントやリリースの進捗・残作業量を視覚化するために用いられるバーンダウンチャート（Burndown Chart）の定義そのものです。

各選択肢の解説

• ア: アーンドバリューは、プロジェクトの計画と実績をコストとスケジュールの観点から定量的に評価する進捗管理手法です。
• イ: アローダイアグラムは、作業の順序関係を矢印で結んで表現し、クリティカルパスを特定する図法です。
• ウ: インクリメンタルは、システムを少しずつ構築して機能を追加していく開発手法（インクリメンタル開発）のことです。
• エ: スパイラルは、設計・実装・テストのサイクルを繰り返し、徐々にシステムの完成度を高めていく開発モデルです。
• オ: 正解です。残作業量を示す折れ線グラフはバーンダウンチャートです。
• カ: プロトタイピングは、開発の初期段階で試作品（プロトタイプ）を作成し、ユーザの要件を確認する手法です。
• キ: マイルストーンは、プロジェクトにおける重要な節目やイベントを指します。
• ク: リファクタリングは、外部から見たプログラムの振る舞いを変えずに内部構造を改善することです。

本文中の $c$ に入る、プログラムの内部構造を整理する手法の名称を問う問題です。
「プログラムの外部から見た動作を変えずにソースコードの内部構造を整理する」手法は、リファクタリング（Refactoring）と呼ばれます。機能拡張や仕様変更が繰り返されるアジャイル開発において、ソースコードの可読性や保守性（今後の拡張性・柔軟性）を保つために重要なプラクティスです。

各選択肢の解説

• ア〜キ: 設問2(2)の解説と同様、進捗管理手法や別の開発モデルなどを指しており、ソースコードの内部構造を整理する手法ではありません。
• ク: 正解です。動作を変えずに内部構造を改善するのはリファクタリングです。

S-04途中での、プロダクトバックログアイテム追加に伴うR氏（プロダクトオーナ）とT氏（ユーザチーム代表）の認識のズレを踏まえ、今後誰とどのようなプロセスを確立すべきかを記述する問題です。
T氏は「アジャイル開発なので，要件の柔軟な追加や変更ができると思っていた」と述べ、「計画したプロダクトバックログアイテムも全てリリース1に入れられるのではないか」とも考えていました。これに対し、開発チームの生産性（ベロシティ）は一定であるため、R氏は「リリース1でリリースするプロダクトバックログアイテムの見直しは不可避だ」と説明しました。
この対立（ステークホルダ間の認識不一致）を防ぐため、要件の出し手であるT氏との間で、アイテムの追加・変更が発生した際の対応方法（優先順位の見直しやスコープの調整など）についてあらかじめ合意し、ルール化しておくプロセスが必要です。

高得点のポイント

• 対象者が「T氏」（またはユーザチーム代表）であると明確に示されていること
• 確立すべきプロセスが「プロダクトバックログアイテム追加・変更時の対応方法（ルール化や調整手順）」に関することであると示されていること

リリース2で対応予定となる残りのストーリポイント $d$ を計算する問題です。

1. ベロシティの算出
   S-05以降で用いるベロシティは、S-01～S-04の平均値です。
   表3より、各スプリントの完了ptは以下の通りです。

• S-01: $10$ pt
• S-02: $8$ pt
• S-03: $9$ pt
• S-04: $9$ pt
  合計 $10 + 8 + 9 + 9 = 36$ pt となり、4スプリントの平均ベロシティは $36 \div 4 = 9$ pt/スプリント です。

2. 当初の総ストーリポイントの確認
   表1より、優先順位ごとの合計ストーリポイントを算出します。

• 優先順位A: $(9 \times 2) + (7 \times 3) + (2 \times 5) = 18 + 21 + 10 = 49$ pt
• 優先順位B: $(1 \times 5) = 5$ pt
• 優先順位C: $(4 \times 2) + (4 \times 3) + (5 \times 5) = 8 + 12 + 25 = 45$ pt
  全体の当初合計は $49 + 5 + 45 = 99$ pt です。

3. リリース1の消化と追加要件
   T氏の依頼で優先順位A・サイズ大（$5$ pt）が1個追加されたため、優先順位Aの合計は $49 + 5 = 54$ pt となりました。
   表3より、S-04までに完了した優先順位Aのアイテムは合計 $36$ pt です。
   したがって、優先順位Aの残りは $54 - 36 = 18$ pt となります。
   S-05とS-06（2スプリント）の想定ベロシティ合計は $9 \times 2 = 18$ pt であり、リリース1で優先順位Aのアイテムは全て完了できます。

4. リリース2で対応予定のポイント
   リリース2では「残りの全てのプロダクトバックログアイテム」を完了させます。
   これは優先順位B（$5$ pt）と優先順位C（$45$ pt）の全てを指すため、対応予定のストーリポイント $d$ は $5 + 45 = 50$ pt となります。
   （※リリース2はS-07～S-12の6スプリントであり、想定対応可能ptは $9 \times 6 = 54$ pt なので、$50$ ptであれば「ベロシティ上の問題はない」という記述とも矛盾しません）