解説

プロダクトオーナ

チームに最も価値の高いソフトウェアを開発してもらうために、プロダクトに必要な機能を定義し、プロダクトバックログの追加・削除・順位付けを行う。開発への投資に対する効果を最大にすることに責任をもつ。

開発チーム

実際に開発を行うチームのことで、開発者たちを指す。ビジネスアナリスト、プログラマー、テスター、アーキテクト、デザイナーなどの機能横断的な様々な技能を持った人がプロダクトを中心に集まり、自律的に行動する。開発チームはバックログに入っている項目を完了状態にし、プロダクトの価値を高めていくことに責任を持つ。

スクラムマスター

スクラムチーム全体が自律的に協働できるように、場作りをするファシリテーター的な役割を担う。ときにはコーチとなってメンバーの相談に乗ったり、開発チームが抱えている問題を取り除いたりする。スクラム全体をうまく回すことに責任を持つ。

解説

• ペアプログラミングは、2人1組で1つのプログラムの実装を行い、1人が実際のコードをコンピュータに打ち込み、もう1人はそれをチェックしながら補佐するという役割を随時交代しながら作業を進めていく手法です。プログラムをコンピュータに打ち込む人を「ドライバ」、それを補佐する人を「ナビゲータ」といいます。ペアプログラミングを行うことで、小さな問題の解決に要する時間が短くなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、などの様々なメリットがあるとされています。
  
  まず選択肢のうち「ア」～「ウ」は、ドライバおよびナビゲータが一方に固定されているためペアプログラミングの規範に反します。
  
  次に表1を見ると、メンバーM4・M5は、現行システムの開発経験がありますがアジャイル開発の経験がありません。一方、メンバーM6・M7は、現行システムの経験開発はありませんがアジャイル開発の経験があります。本開発は、現行システムに対する追加開発をアジャイル開発手法で行うものであるため、開発に当たり両方の知識・経験が求められます。これを踏まえると、スムーズに開発を進めるためには両グループから1名ずつを組み合わせたペアにするのが適切と言えます。この点から「イ」と「エ」は不適切なペアです。
  
  したがって、ドライバとナビゲータが交代制である、かつ、(M4・M5)の組と(M6・M7)の組から1人ずつを選出してペアにしている「オ」が適切であると判断できます。
  
  ∴M4とM6がドライバとナビゲータを交代で担う。
  
  
• アジャイル開発のプラクティスには従来型のやり方と矛盾するものがあり、アジャイル型開発の採用初期は、行っていることが正しい方向に向かっているのか、そうでないのかを、チームメンバー自身では判断しづらいという問題があります。このような場合には、アジャイル型開発の経験者を探して、コーチとして招き、チームに対してのアジャイルの導入や改善を手伝ってもらうのが解決策となります。この人物が「アジャイルコーチ」です。
  
  スクラムマスタのスキルが高いときには、スクラムマスタがアジャイルコーチの役割を兼ねる場合もありますが、本問では、スクラムマスタであるメンバーM2にスクラムマスタの経験がないため、外部のアジャイルコーチを招へいしているという背景が読み取れます。
  
  〔c、dについて〕
  アジャイルコーチに参画したもらった場合には、チームのリズムを作り、改善を促すために、日次ミーティング、スプリント計画ミーティング、レトロスペクティブ（ふりかえり）のファシリテータを最初に依頼するとよいとされています。本問では、アジャイルコーチの招へいは週2回で日次ミーティングごとに招聘するのは無理なので、(4)スプリント計画と(7)レトロスペクティブ（ふりかえり）のファシリテータを依頼することになります。
  
  また、問題後半でデイリースクラムの進め方について課題が指摘されていることからも、(5)スプリントはアジャイルコーチなしで実施されていることが読み取れます。
  
  ∴c、d＝(4)、(7)　※順不同
  
  〔eについて〕
  ベロシティ（velocity）は、開発チームが1回のスプリント（またはイテレーション、以下同じ）で完了させたユーザーストーリーのストーリーポイントの合計値です。ざっくり言えば、1スプリントにおける開発量のことです。
  
  アジャイル開発では、スプリント終了時に、チームが完了した全ユーザーストーリーのストーリーポイント数を計測し、その実績を元にチームのスプリントあたりの開発可能な作業量を算出します（ベロシティ計測）。その後、リリースに必要なユーザーストーリーの見積りを合計し、それをベロシティで割ることによってリリース日を見積もります。
  
  ベロシティを計測する目的は、開発チームが1スプリントで完了できる開発量を把握するためです。
  
  ∴e＝ア：開発チームが現在1スプリントで開発できるタスク量を測定する

解説

• デイリースクラム（日次ミーティング）は、毎日決まった時間と場所で、開発チームが全員が顔を合わせて行う短時間のミーティングです。「昨日やったこと」「今日やること」「障害になっていること」の順で1人ずつ話すことで、日々の必要な情報がチーム内で共有されることを目的とします。
  
  デイリースクラムは15分程度の短い時間で済ませるのが肝要ですが、H社では「その日の問題を解消するために解決方法まで議論することにしていた」ので、これが時間が掛かっていた原因とわかります。問題の解決方法まで議論する時間を含めるとミーティングが長時間に及ぶため、デイリースクラム自体は情報の共有に留め、問題解決は「別途会議体を設ける」ことが望まれます。
  
  なお、H社で夕方にデイリースクラムを実施していますが、必ずしも朝の時間帯にこだわることはなく、関係者が集まりやすい時間帯に開催すればOKなので、この点は問題ありません。
  
  ∴原因＝問題の解決方法まで議論してしまった点
  　解決策＝問題解決のための会議体を別途設ける
  
  
• 下線③では、スプリント計画どおりに全てを終わらせることができなかった問題点について、スプリントバックログ管理上の課題を分析しています。
  
  スプリントバックログは、プロダクトバックログから抜き出された、今回のスプリントで追加する機能のリストです。スプリント中のスプリントバックログは開発チームが管理し、スプリントバックログへのタスクの追加や削除、見積りとその更新は開発チームの責任でしなければなりません。
  
  図2には「8日経過時点で，提携する商業施設からの要望でスプリントバックログにタスクが追加された」とありますが、これはプロダクトに関する要求全体を管理するプロダクトバックログに追加されるべき事項であり、スプリント中のスプリントバックログに追加するのは誤りです。
  
  本来はプロダクトオーナであるメンバーM1が、関係先との調整を行うとともに必要な機能を順位付けすべきなのですが、M1はアジャイル開発に対する知識・経験がないので、このような誤った運用をしていまい、また開発チームもアジャイル開発に慣れていないので要求をそのまま受け入れてしまったという事情が読み取れます。
  
  ∴スプリント期間中に外部からの変更要求を受け入れてしまった点