IPA アジャイル開発(スクラム・XP・リーン) — 頻出論点と過去問

頻出論点

1. この分野は何か

計画をはじめに固めきらず、短い区切りごとに動くものを作って見せ、その反応を次の区切りに生かすアジャイル開発の考え方と、それを実際に回すための手法を扱います。スクラムの役割・イベント・作成物がそれぞれ何に責任を持つか、XP（エクストリームプログラミング）などの手法が何のための工夫かを、場面ごとに言い当てられるかが問われます。

2. 実際の出題のされ方

アジャイルとほかの開発モデルの違いは、具体的な開発事例を通じて特徴を見分ける形で確かめられます。ITパスポートでは、説明文の空欄に入る語句を選ぶ問題、場面に合う開発モデルや事例を選ぶ問題、アジャイル全体の説明と個別の手法の説明を見分ける問題が出ています。

スクラムの役割・イベント・作成物や、XPのプラクティス、振り返りおよび計画・管理の手法は、応用情報技術者の午前や高度試験の午前Iで具体的に問われます。スクラムに関しては、4つのイベントの実施順序を並べる問題、特定のイベントの目的を選ぶ問題、役割ごとの責務を問う問題が出ています。このほか、プロジェクト初期に関係者間で目的やスコープの共通認識を得る手法、振り返りに用いるKPTの3つの視点や具体例の分類、進捗を表すグラフの軸の組合せ、システム管理基準に照らした監査の着眼点を選ばせる出題があります。

スクラムの定義やKPT、XPのプラクティスは、情報処理安全確保支援士とデータベーススペシャリストの午前IIでも対象になります。

宣言や原則、評価の観点に照らした判断は、プロジェクトマネージャとシステムアーキテクトの午前IIで深く掘り下げられます。アジャイルソフトウェア開発宣言の価値の対比、開発の後半に機能追加の要求が出た場面での教訓、INVESTの観点を使う目的とそれに合うユーザーストーリー、スプリントの途中でチームだけで変えてよいもの、リーンソフトウェア開発の説明が問われています。

エンベデッドシステムスペシャリストとシステム監査技術者の午前IIでは、スプリントの決まりごとや、アジャイル開発を監査するときの着眼点を選ぶ問題が出ています。

3. 学習のポイント

スクラムの枠組みは、役割・作成物・イベントのつながりで押さえます。

• 3つの役割と作成物: プロダクトオーナーは、何を作れば価値が大きいかに責任を持ち、プロダクトバックログの中身と並び順を決めます。スクラムマスターは、チームと周りの人がスクラムを正しく理解して使えるよう手助けする役です。開発者は、スプリントで何をどう作るかを自分たちで決め、スプリントバックログを自分たちで見直しながら、完成した成果（インクリメント）を作ります。スプリントの長さは1か月以内で固定します。
• イベントの順序と目的: スプリントは、達成目標と作業計画を立てるスプリントプランニングから始まり、期間中は毎日短時間で進捗確認と計画調整を行うデイリースクラムを実施します。スプリントレビューでは、できた成果をステークホルダーに見せて、次に何を作るかを一緒に見直します。最後のスプリントレトロスペクティブでは、チームの進め方そのものを振り返って、次のスプリントでの改善を決めます。振り返りで使うKPTでは、継続する良かったこと（Keep）、抱えている問題（Problem）、次に取り組む具体的な改善策（Try）に整理します。

XPとその他の開発手法は、それぞれの焦点と具体的なプラクティスで整理します。

• XP（エクストリームプログラミング）: XPは、コミュニケーションやフィードバックなど5つの価値を土台にしています。具体的なプラクティスには、実装前にテストケースをコードとして書くテスト駆動開発（TDD）、ドライバ（入力役）とナビゲータ（確認・助言役）の2人が1台のPCを共有して1つのプログラムを作るペアプログラミング、変更を小さな単位で頻繁に結合してそのたびにテストする継続的インテグレーションがあります。さらに、リファクタリング、コードの共同所有、週40時間労働なども含まれます。
• リーンソフトウェア開発: 製造の現場で磨かれた考え方を開発に応用したもので、ムダをなくすことや品質を工程の中で作り込むことなどを原則にします。工程と所要時間を図にして、ボトルネックやムダを見つけるのに使うのがバリューストリームマップです。

計画・見積り・要求管理の手法と基本理念も対比して覚えます。

• 立ち上げ・見積り・進捗管理: インセプションデッキは、開発を始める前に決まった問いに関係者で答え合い、目的や範囲の認識をそろえる手法です。プランニングポーカーは、各自がカードで見積りを一斉に出し、ずれの理由を話し合ってそろえる見積りの進め方です。ベロシティは、一定の期間に受け入れられた成果の量で、次の計画を立てる目安になります。バーンダウンチャートは、縦軸に残りの作業量、横軸に時間をとり、残りがどう減っていくかを予定と比べるグラフです。
• INVESTの6つの観点: 質の高いユーザーストーリーかを評価する指標です。頭文字は、Independent（他のストーリーと依存関係がない）、Negotiable（詳細が固定されず議論・交渉の余地がある）、Valuable（顧客や利用者にとって価値がある）を表します。残りの3つは、Estimable（見積り可能）、Small（1回の反復で作り終えられる大きさ）、Testable（テスト可能）です。
• アジャイルソフトウェア開発宣言と原則: 価値観では、プロセスやツールより個人と対話、包括的なドキュメントより動くソフトウェア、契約交渉より顧客との協調、計画に従うことより変化への対応に、より価値を置きます。背後の原則では、後期であっても要求変更を歓迎すること、対面での会話を重視すること、動くソフトウェアを進捗の尺度とすること、一定のペースを継続的に維持することが掲げられています。

4. 間違えやすいところ

上流から下流へ各工程の完了承認を得ながら順番に進めたり、全作業の完了後にリリース計画を立てたりするウォーターフォール型の進め方を、アジャイルの特徴や監査の着眼点として混ぜた誤答肢がよく並びます。スプリントの1回目に要件定義、2回目に設計のように、工程ごとにスプリントを割り当てる記述も同じ誤りです。

開発の後半に出た機能追加の要求をどう扱うべきだったかを問う問題では、後から出た要求は受け入れずに断るべきだったとする誤答肢がありました。アジャイルの原則では、開発の後半であっても要求の変更を歓迎します。

スクラムのイベントの実施順序では、スプリントレビューより先にレトロスペクティブを置く誤答肢があります。

スプリントの途中で、スプリントゴールを開発チームだけの判断で変えられるとする誤答肢もありました。スプリントゴールは、そのスプリントの間は変えずに目指す目標です。

テスト駆動開発の特徴を選ぶ問題では、初めのテストでバグをできるだけ多く見つけることを特徴とする誤答肢がありました。テスト駆動開発は、バグの数を稼ぐことを目的とした手法ではありません。

ペアプログラミングの説明を選ぶ問題では、2人でメインとサブのプログラムを分担して作るとする誤答肢がありました。メインとサブを分けて受け持つのは、ふつうの分担開発です。

INVESTの観点に合うユーザーストーリーを選ぶ問題では、開発者にとって価値があるとする誤答肢がありました。Valuableの価値は、使う人や顧客にとっての価値です。