応用情報技術者 2020年 秋期 午後 問08
アジャイルソフトウェア開発手法の導入に関する次の記述を読んで、設問1~3に答えよ。
H社は、電車や飛行機などの移動手段と宿泊施設をセットにしたパッケージツアーをインターネットで販売している。このサービスを提供している現行システムに、移動途中や宿泊先近辺の商業施設と提携して、観光地の情報提供やクーポン配布を行うサービスを追加することになった。その開発手法として、アジャイルソフトウェア開発(以下、アジャイル開発という)手法の一つであるスクラムを採用する。
〔開発体制の検討〕
本開発を通してH社でアジャイル開発経験者を育成するために、プロジェクトメンバに求められる役割と割り当てるメンバ(M1~M7)について検討した。その開発体制を表1に示す。

〔開発プロセスの検討]
アジャイル開発経験者からアジャイル開発経験のないメンバに経験を伝えるために、プランニングポーカやペアプログラミングなどのプラクティスを幾つか導入することにした。検討した開発プロセスを表2に示す。

週に2日、社外から招へいするアジャイルコーチが効果的にプロジェクトに参画できるようにするため、招へいするタイミングをc及びdのファシリテータを依頼するタイミングに合わせてもらうことにした。
また、プロジェクトの進捗状況を可視化するためにバーンダウンチャートをホワイトボードに書き、eためにスプリントごとのベロシティを計測することにした。
〔レトロスペクティブの実施〕
初回のスプリントのレトロスペクティブにおいて、二つの問題点が取り上げられた。
一つ目は、②デイリースクラムに目安の倍以上の時間を掛けてしまう問題点である。状況を確認したところ、このミーティングはメンバの出社時間がバラバラなので夕方に実施していた。また、その日の問題を解消するために解決方法まで議論することにしていた。さらに、進捗状況を共有するために、タスクボードを作成し、その周囲に集まって立った状態で実施していた。
二つ目は、スプリント計画どおりにタスクを全て終わらせることができなかった問題点である。③スプリントバックログ管理上の課題を分析するために、バーンダウンチャートを用いてポイントと考えられる箇所について確認した。バーンダウンチャートを図1に、確認したポイントを図2に示す。

二つの問題点それぞれについて原因と解決策、課題を分析して、次回以降のスプリントで改善に取り組んだ結果、それらの問題点を解決できた。
設問1:
表1及び表2中のaに入れる適切な字句を答えよ。また、表中のbに入れる最も適切な字句を解答群の中から選び、記号で答えよ。
bに関する解答群
ア:具体的
イ:自律的
ウ:組織的
エ:段階的
模範解答
a:プロダクトオーナ
b:イ
解説
解答の論理構成
-
役割名 a の判定
- 表1では、a の説明として
「提携する商業施設との調整を行い、追加するサービスに必要な機能を定義し、その機能を順位付けする。」
と記載されています。 - スクラムの公式ガイドでは、ステークホルダ調整・機能要求の整理・優先順位付けは “Product Owner” の責務です。よって a は「プロダクトオーナ」となります。
- 表1では、a の説明として
-
空欄 b の判定
- スクラムマスタの説明に
「メンバ全員が b に協働できるように支援、マネジメントする。」
とあります。 - スクラムではチームが “Self-organizing”(自律的)に動ける環境を整えることがスクラムマスタの中心的役割です。
- 解答群を照合すると「イ:自律的」がこれに該当します。
- スクラムマスタの説明に
以上より、
a:プロダクトオーナ
b:イ
b:イ
誤りやすいポイント
- a を「プロジェクトマネージャ」と誤答
スクラムでは仕様決定・優先度付けを行うのは “Product Owner” であり、PM とは責務が異なります。 - b に「ア:具体的」や「ウ:組織的」を選択
スクラムマスタはタスク細分化や組織統制ではなく、チームの “自律性” を促す役割です。 - 「オーナ」の表記揺れ
問題文はカタカナ表記「プロダクトオーナ」を採用しているため、語尾の “ー” を付けると減点対象になることがあります。
FAQ
Q: スクラムマスタは開発進行を指示する立場ではないのですか?
A: 指示よりも障害除去やファシリテーションに注力します。チームが自律的に判断できるよう環境を整えることが使命です。
A: 指示よりも障害除去やファシリテーションに注力します。チームが自律的に判断できるよう環境を整えることが使命です。
Q: プロダクトオーナとクライアント担当者は同一人物でもよいですか?
A: 可能ですが、優先度付けやROI責任を負える立場であることが前提です。複数ステークホルダの調整が必要な場合は代理人ではなく決定権保持者が望ましいです。
A: 可能ですが、優先度付けやROI責任を負える立場であることが前提です。複数ステークホルダの調整が必要な場合は代理人ではなく決定権保持者が望ましいです。
Q: 「自律的」に協働できる状態を測る指標はありますか?
A: ベロシティの安定、デイリースクラムでの主体的な課題提起、インクリメントの品質維持などが間接的指標になります。
A: ベロシティの安定、デイリースクラムでの主体的な課題提起、インクリメントの品質維持などが間接的指標になります。
関連キーワード: スクラムマスタ、プロダクトオーナ、自律的チーム、優先度付け、ファシリテーション
設問2:〔開発プロセスの検討〕について、(1)、(2)に答えよ。
(1)表2中の下線①を行う際のメンバの割当て例として最も適切なものを解答群の中から選び、記号で答えよ。
解答群
ア:M4がドライバ、M5がナビゲータを担う。
イ:M4がドライバ、M6がナビゲータを担う。
ウ:M4がナビゲータ、M6がドライバを担う。
エ:M4とM5がドライバとナビゲータを交代で担う。
オ:M4とM6がドライバとナビゲータを交代で担う。
模範解答
オ
解説
解答の論理構成
-
ペアプログラミングの目的
- 知識と経験を相互に伝搬することでチーム全体の生産性と品質を高める手法です。
- 一般に「ドライバ(実装役)」と「ナビゲータ(レビュー・指示役)」を交代しながら作業し、双方が学び合える組合せが望ましいとされています。
-
メンバの保有スキルを整理
- 表1より
- 「M4, M5:アジャイル開発経験はないが、現行システムをウォータフォールで開発した経験はある。」
- 「M6, M7:アジャイル開発経験はあるが、現行システムを開発した経験はない。」
- ここから
- M4 は “現行システム” のドメイン知識がある。
- M6 は “アジャイル開発” の実践知識がある。
- 表1より
-
共有したい経験の方向性
- 【問題文】では「アジャイル開発経験者からアジャイル開発経験のないメンバに経験を伝える」ことが明示されています。
- 逆に、現行システムの仕様は M4 が熟知しており、これを M6 に伝える必要があります。
-
最適なペアの条件
- アジャイルのやり方を教える ⇒ M6(経験者)がナビゲータ/ドライバを交代する形で M4 に伝授。
- 現行システムの仕様を教える ⇒ M4(ドメイン知識保有者)がナビゲータ/ドライバを交代する形で M6 に伝授。
- よって「交代制」で双方の知識を行き来させるペアが最適となります。
-
解答群の照合
- 「オ:M4とM6がドライバとナビゲータを交代で担う。」
⇨ 両者の経験をバランス良く共有でき、問題文の狙いに合致します。 - その他の選択肢
- ア・イ・ウ:役割固定または経験の偏りが残り、知識伝搬の効果が限定的。
- エ:M4 と M5 では双方ともアジャイル未経験のため目的を達成しにくい。
- 「オ:M4とM6がドライバとナビゲータを交代で担う。」
以上より最も適切な割当ては「オ」です。
誤りやすいポイント
- 「同じ経験レベル同士を組ませれば安心」と考えて M4 と M5 を選んでしまう。
- ドライバ/ナビゲータを固定にすると学習機会が一方向になりがちな点を見落とす。
- 「アジャイル経験者=ドライバ」と早合点し、役割交代の効果を軽視する。
FAQ
Q: ペアプログラミングで役割を交代する頻度はどの程度が良いのですか?
A: スプリント中に複数回交代するのが一般的です。タイマーで 15〜30 分毎に切り替えるチームもありますが、タスクの区切りで交代しても構いません。重要なのは双方が同量のコーディングとレビュー経験を得ることです。
A: スプリント中に複数回交代するのが一般的です。タイマーで 15〜30 分毎に切り替えるチームもありますが、タスクの区切りで交代しても構いません。重要なのは双方が同量のコーディングとレビュー経験を得ることです。
Q: ナビゲータが指示だけしていても学習効果はありますか?
A: はい。ナビゲータは設計意図の説明やリスク検知を行うため、ドメイン知識や高レベル設計を深められます。交代制にすることでドライバ経験も得られ、学習が相互補完されます。
A: はい。ナビゲータは設計意図の説明やリスク検知を行うため、ドメイン知識や高レベル設計を深められます。交代制にすることでドライバ経験も得られ、学習が相互補完されます。
Q: ドメイン知識がないメンバがドライバになるとコーディングが遅れませんか?
A: 最初は遅れる場合がありますが、ナビゲータがレビューしながら補助するため品質低下を抑えられます。短期的な遅れより、長期的なチーム総合力向上を重視するのがペアプログラミングの狙いです。
A: 最初は遅れる場合がありますが、ナビゲータがレビューしながら補助するため品質低下を抑えられます。短期的な遅れより、長期的なチーム総合力向上を重視するのがペアプログラミングの狙いです。
関連キーワード: ペアプログラミング、ドライバ、ナビゲータ、知識共有、スキル伝搬
設問2:〔開発プロセスの検討〕について、(1)、(2)に答えよ。
(2)本文中のc、dには、表2中の小分類のいずれかが入る。(1)〜(7)から選び、その番号で答えよ。また、本文中のeに入れる適切な字句を解答群の中から選び、記号で答えよ(cとdは順不同)。
eに関する解答群
ア:開発チームが現在1スプリントで開発できるタスク量を測定する
イ:開発チームがこれまでのスプリントで完了させたストーリポイントを測定する
ウ:各プロジェクトメンバのアジャイルスキル習得度合いを測定する
エ:各プロジェクトメンバの生産性を測定する
模範解答
c:(4)
d:(7)
e:ア
解説
解答の論理構成
-
アジャイルコーチを呼ぶ目的の把握
本文には「週に2日、社外から招へいするアジャイルコーチが効果的にプロジェクトに参画できるようにするため、招へいするタイミングをc及びdのファシリテータを依頼するタイミングに合わせてもらうことにした。」
とあります。アジャイルコーチがもっとも効果を発揮するのは “計画を固める場” と “改善を議論する場” です。 -
表2の小分類を照合
表2より関係しそうな小分類は次の 2 つです。- 「(4)スプリント計画(イテレーション計画)」
- 「(7)レトロスペクティブ(ふりかえり)」
どちらもファシリテーションが不可欠なイベントであり、アジャイルコーチの支援効果が高いと判断できます。したがって - c = (4)
- d = (7)
-
ベロシティ計測の目的
本文には「バーンダウンチャートをホワイトボードに書き、eためにスプリントごとのベロシティを計測することにした。」
とあります。ベロシティはチームが 1 スプリントでどれだけの作業を“完了”できるかを示す指標です。解答群を見比べると- 「ア:開発チームが現在1スプリントで開発できるタスク量を測定する」
がベロシティの定義そのものです。よって - e = ア
- 「ア:開発チームが現在1スプリントで開発できるタスク量を測定する」
-
以上より
c:(4)
d:(7)
e:ア
誤りやすいポイント
- (5)「スプリント」や (6)「スプリントレビュー」を選んでしまう
スプリント中にコーチを貼り付けるより、計画立案とふりかえりへの参加がスクラムのセオリーです。 - velocity の誤解
「イ:開発チームがこれまでのスプリントで完了させたストーリポイントを測定する」は累積的な結果に聞こえますが、ベロシティは“各スプリント単位”で測る流量的指標です。 - ベロシティを個人評価に使う誤解
選択肢「エ」を選ぶと“生産性評価”の誤用に陥ります。
FAQ
Q: ベロシティは人数が増えると比例して上がるのでしょうか?
A: 一定期間でのチーム総量なので原理的には上がりますが、コミュニケーションコストも増えるため必ずしも比例しません。
A: 一定期間でのチーム総量なので原理的には上がりますが、コミュニケーションコストも増えるため必ずしも比例しません。
Q: レトロスペクティブに外部コーチを入れるメリットは?
A: 利害関係が薄い第三者が場を中立に保ち、根本原因の深掘りや建設的な議論を促せるためです。
A: 利害関係が薄い第三者が場を中立に保ち、根本原因の深掘りや建設的な議論を促せるためです。
Q: スプリント計画でのファシリテーションのポイントは?
A: 全員の見積り観点を引き出し、合意済みの「Definition of Done」を満たすタスクだけをスプリントバックログに入れることです。
A: 全員の見積り観点を引き出し、合意済みの「Definition of Done」を満たすタスクだけをスプリントバックログに入れることです。
関連キーワード: スプリント計画、レトロスペクティブ、ベロシティ、バーンダウンチャート、ファシリテーション
設問3:〔レトロスペクティブの実施〕について、(1)、(2)に答えよ。
(1)本文中の下線②の問題点の原因と解決策を、それぞれ25字以内で述べよ。
模範解答
原因:問題の解決方法まで議論してしまった点
解決策:問題解決のための会議体を別途設ける。
解説
解答の論理構成
- 問題点の確認
- 本文に「下線②」の説明として
「デイリースクラムに目安の倍以上の時間を掛けてしまう問題点」
とある。スクラムガイドではデイリースクラムは短時間のタイムボックスで実施し、課題の詳細議論は行わないことが原則です。
- 本文に「下線②」の説明として
- 原因の特定
- 原文には
「その日の問題を解消するために解決方法まで議論することにしていた。」
とあり、タイムボックスを超過した直接原因が明示されています。
- 原文には
- 解決策の導出
- スクラムガイドは、課題の深掘りはデイリースクラム後に必要メンバだけで行うことを推奨します。したがって
「問題解決用の別会議体を設ける」
ことでデイリースクラム本来の目的(情報共有)と時間厳守を両立できます。
- スクラムガイドは、課題の深掘りはデイリースクラム後に必要メンバだけで行うことを推奨します。したがって
- 以上より模範解答は
- 原因:問題の解決方法まで議論してしまった点
- 解決策:問題解決のための会議体を別途設ける。
誤りやすいポイント
- 「夕方に実施していた」ことを主因と誤解する。時間帯は長時間化の根本原因ではありません。
- タスクボードを囲んだ「立ち話」形式だから良いと考え、議論の深さを軽視する。立っていても長時間ならタイムボックス違反です。
- デイリースクラムで即時解決まで行うべきと勘違いし、別会議体を設ける発想に至らない。
FAQ
Q: デイリースクラムで課題解決の議論をしてはいけないのですか?
A: 原則は情報共有と次の24時間の調整に限定します。解決の詳細は会議後に必要メンバで行うことで効率化します。
A: 原則は情報共有と次の24時間の調整に限定します。解決の詳細は会議後に必要メンバで行うことで効率化します。
Q: 別会議体はどのように設定すれば良いですか?
A: デイリースクラム直後に15〜30分の「問題解決ミーティング」を設け、課題当事者と関係者のみ参加させると効果的です。
A: デイリースクラム直後に15〜30分の「問題解決ミーティング」を設け、課題当事者と関係者のみ参加させると効果的です。
Q: 夕方開催でも構いませんか?
A: 夕方開催自体は問題ではありませんが、全員の都合で開始が遅れがちなら朝会に変更するなど、タイムボックスが守れる時間帯を再検討しましょう。
A: 夕方開催自体は問題ではありませんが、全員の都合で開始が遅れがちなら朝会に変更するなど、タイムボックスが守れる時間帯を再検討しましょう。
関連キーワード: スクラム、デイリースクラム、タイムボックス、タスクボード、ファシリテーション
設問3:〔レトロスペクティブの実施〕について、(1)、(2)に答えよ。
(2)本文中の下線③にある、スプリント内におけるスプリントバックログ管理上の課題について、35字以内で述べよ。
模範解答
スプリント期間中に外部からの変更要求を受け入れてしまった点
解説
解答の論理構成
- スクラムでは、スプリント開始後にスプリントバックログを変更しないのが原則です。
- 【問題文】図2に「8日経過時点で、提携する商業施設からの要望でスプリントバックログにタスクが追加された。」とあります。
- 同じく図2に「16日経過時点で、考慮していないテストシナリオのタスクが見つかったので、そのタスクが追加された。」とも書かれており、バーンダウンチャートの実線も増加しています。
- これらはスプリント期間中に外部要因や追加作業を受け入れたことを示しており、スプリントバックログ管理の課題は「途中変更を許容してしまった点」だと導けます。
- したがって模範解答は「スプリント期間中に外部からの変更要求を受け入れてしまった点」となります。
誤りやすいポイント
- 「バーンダウンチャートの増加=進捗遅延」と早合点し、“見積もり精度”の問題と誤解する。実際は途中でタスクを追加しているため増加しています。
- 変更を加えたのが「提携する商業施設」なので、「利害関係者との調整不足」と焦点をずらしてしまう。ポイントは“スプリント中に変更を入れた”行為自体です。
- スクラムではプロダクトバックログの更新は常時可能ですが、スプリントバックログは固定であるという区別を混同しやすいです。
FAQ
Q: バーンダウンチャートで実績線が上がるのは必ず NG なのでしょうか?
A: 原則はスプリントバックログが固定なので上昇は発生しません。上がった場合は途中追加や作業の戻しが起きており、原因を分析して次回に活かす必要があります。
A: 原則はスプリントバックログが固定なので上昇は発生しません。上がった場合は途中追加や作業の戻しが起きており、原因を分析して次回に活かす必要があります。
Q: もし緊急度が高い変更要求だった場合でも受け入れてはいけませんか?
A: スプリントを中止して計画し直す、または次のスプリントに回すなど、スクラムのルールに従って対処します。“バックログの途中変更”という抜け道は原則取りません。
A: スプリントを中止して計画し直す、または次のスプリントに回すなど、スクラムのルールに従って対処します。“バックログの途中変更”という抜け道は原則取りません。
Q: スプリントバックログとプロダクトバックログの違いは?
A: プロダクトバックログは全体の要求一覧で常に変化します。一方、スプリントバックログはスプリント目標を達成するためにその期間内で「確定」した作業項目です。
A: プロダクトバックログは全体の要求一覧で常に変化します。一方、スプリントバックログはスプリント目標を達成するためにその期間内で「確定」した作業項目です。
関連キーワード: スプリントバックログ、バーンダウンチャート、変更要求、スクラム、ベロシティ


