【ITパスポート練習問題 6.3対応】(3) アジャイル

【解説】

正解: 3 誰が、何を、なぜ

この問題は、アジャイル開発において要件を定義する手法の一つである「ユーザーストーリー」の基本的な構成要素を理解しているかを確認するものです。

正解は3の「誰が、何を、なぜ」です。ユーザーストーリーは、「＜ユーザー（誰が）＞として、＜機能（何を）＞がほしい。それは＜価値・理由（なぜ）＞だからだ」という形式で記述されます。これにより、技術的な仕様ではなく、ユーザーにとっての価値や利用シーンを明確にすることを目指します。

選択肢1の「目的、詳細、技術的仕様」や、選択肢2の「要件、設計、テストケース」は、従来の開発手法における仕様書や設計書の構成要素に近いものです。ユーザーストーリーは、対話のきっかけとなる簡潔な記述を重視するため、最初から詳細な技術仕様やテストケースを含めることはしません。

【解説】

正解: 2 ソフトウェアの設計図を提供する

この問題は、ユーザーストーリーが「何のために作成されるのか」という役割と、その限界（何ではないか）を正しく理解しているかを確認するものです。

ユーザーストーリーは、顧客やユーザーが実現したいこと（What）とその理由（Why）を簡潔に伝えるためのものであり、システムをどう作るかという「設計図（How）」を提供するものではありません。設計や実装の詳細は、開発チームがストーリーをもとに検討し、別の形で定義します。したがって、2が「適切でない目的」となります。

選択肢1の「ユーザーの視点から要件を明確化する」や、選択肢3の「開発チームに優先順位を示す」は、ユーザーストーリーの本来の目的です。これらにより、何を作るべきか、どれから着手すべきかをチームが共有しやすくなります。

【解説】

正解: 1 開発の方向性をユーザー視点から維持しやすい

この問題は、アジャイル開発でユーザーストーリーを採用することによるメリット（利点）を理解しているかを確認するものです。

正解は1です。ユーザーストーリーは「誰のために」「なぜその機能が必要か」を常に明示するため、開発チームが技術的な関心事だけでなく、ユーザーへの価値提供に集中し続けるのを助けます。これにより、開発の方向性がぶれるのを防ぐことができます。

選択肢2の「要件の迅速な変更が困難になる」は誤りです。むしろ、ユーザーストーリーは小さく独立しているため、入れ替えや変更が容易であり、変化に柔軟に対応できます。選択肢3の「詳細な技術仕様書を作成するための基礎資料になる」も、主目的ではありません。ユーザーストーリーは対話を促すためのものであり、文書作成のための単なる資料ではありません。

【解説】

正解: 2 ペアプログラミング

この問題は、アジャイル開発の手法の一つであるXP（エクストリームプログラミング）の具体的なプラクティス（実践項目）を知っているかを問うものです。

正解は2の「ペアプログラミング」です。これはXPの代表的なプラクティスの一つで、1台のコンピュータを2人のプログラマで共有し、1人がコードを書き（ドライバー）、もう1人がそれをレビュー・補佐する（ナビゲーター）手法です。これにより、コードの品質向上や知識の共有を図ります。

選択肢1の「ウォーターフォールモデル」は、XPとは対極にある従来型の開発手法です。選択肢3の「リリースの長期計画作成」は、変化への対応を重視するXPの考え方とは異なり、XPでは短いサイクルでの計画とリリース（スモールリリース）を推奨します。

【解説】

正解: 1 顧客のフィードバックを重視した反復開発

この問題は、XP（エクストリームプログラミング）がどのような開発スタイルをとるか、その全体的な特徴を理解しているかを確認するものです。

正解は1です。XPでは、短期間でソフトウェアを開発・リリースし、実際に動くものに対する顧客からのフィードバックを素早く得ることを重視します。この「反復（イテレーション）」を繰り返すことで、顧客の要望に合ったシステムを作り上げていきます。

選択肢2の「長期の計画に基づくリリース」は、変化の激しい環境に対応しにくい従来型の手法の特徴です。選択肢3の「仕様書に基づく厳密な設計プロセス」も、ドキュメントよりも対話や動くコードを重視するXPの特徴とは異なります。

【解説】

正解: 3 コスト削減

この問題は、XP（エクストリームプログラミング）が掲げる「5つの価値（コミュニケーション、シンプル、フィードバック、勇気、尊重）」を把握しているかを確認するものです。

XPでは、開発チームが重視すべき価値観を定義していますが、「コスト削減」はその中に含まれていません。もちろん結果としてコストが最適化されることはありますが、それはあくまで結果であり、XPが直接的に追求する行動指針や価値観（バリュー）ではありません。したがって、3が適切でないものとなります。

選択肢1の「コミュニケーション」は、チーム内や顧客との対話を重視するXPの核心的な価値です。選択肢2の「勇気」も、既存のコードを捨てて書き直す決断や、真実を伝える姿勢としてXPで重視されています。

【解説】

正解: 2 テスト作成→コーディング→リファクタリング

この問題は、テスト駆動開発（TDD）における作業の順序（サイクル）を正しく理解しているかを確認するものです。

TDDの基本サイクルは、「レッド（失敗するテストを書く）」→「グリーン（テストに通る最小限のコードを書く）」→「リファクタリング（コードを整理する）」の順で行われます。まずテストを作成し、それを満たすように実装を進めるのが特徴です。したがって、2が正解です。

選択肢1の「設計→コーディング→テスト」は、一般的なウォーターフォール型などの開発手順です。選択肢3の「コーディング→デバッグ→リリース」は、テストコードの作成が含まれておらず、TDDの手順ではありません。

【解説】

正解: 3 コードの品質と保守性の向上

この問題は、なぜテスト駆動開発（TDD）を行うのか、その主たる目的と効果を理解しているかを確認するものです。

TDDを行う最大の目的は、バグの少ない「動くきれいなコード」を作成することです。テストを先に書くことで要件が明確になり、リファクタリングによってコードの構造が整理されるため、品質と保守性（メンテナンスのしやすさ）が向上します。

選択肢1の「開発スピードの大幅な向上」は、長期的には手戻りが減って速くなりますが、初期段階ではテスト記述の工数がかかるため、直接の目的というよりは副次的な効果です。選択肢2の「新しい技術の採用促進」は、TDDの目的とは無関係です。

【解説】

正解: 2 コードの構造を改善して読みやすくするため

この問題は、テスト駆動開発（TDD）のサイクルの一部である「リファクタリング」の定義と目的を理解しているかを確認するものです。

リファクタリングとは、外部から見た「ソフトウェアの挙動」を変えずに、内部の「コードの構造」を整理することです。変数名の変更、冗長な処理の統合などを行い、人間にとって読みやすく、修正しやすい状態にすることを目的としています。

選択肢1の「コードの動作を変更するため」や選択肢3の「新しい機能を追加するため」に行う作業は、リファクタリングではなく「機能追加」や「仕様変更」にあたります。リファクタリング中は機能を変えてはいけません。

【解説】

正解: 1 コードのレビューや改善点の指摘を行う

この問題は、ペアプログラミングにおける役割分担（ドライバーとナビゲーター）について正しく理解しているかを確認するものです。

ペアプログラミングでは、キーボードを操作してコードを書く人を「ドライバー」、その横で全体を俯瞰し考える人を「ナビゲーター」と呼びます。ナビゲーターの役割は、ドライバーが書いているコードをリアルタイムでレビューし、設計の誤りや改善点を指摘したり、次にやるべきことを考えたりすることです。

選択肢2の「コードの入力を担当する」のはドライバーの役割です。選択肢3の「開発環境の設定を行う」は、役割分担とは関係のない個別のタスクです。

【解説】

正解: 3 開発コストの削減

この問題は、ペアプログラミングのメリットとデメリット（コスト面の影響）を冷静に理解しているかを確認するものです。

ペアプログラミングは、1つの作業に2人のエンジニアを割り当てるため、単純計算では人件費（工数）が倍になります。品質向上による手戻りの減少で長期的には元が取れることも多いですが、即座に「開発コストの削減」につながるわけではありません。したがって、これが適切でない利点となります。

選択肢1の「バグの早期発見」や、選択肢2の「知識の共有」は、ペアプログラミングによって得られる代表的なメリットです。

【解説】

正解: 2 ナビゲーターが頻繁に役割を交代する

この問題は、ペアプログラミングを効果的に行うための運用ルールやコツを理解しているかを確認するものです。

ペアプログラミングでは、長時間同じ役割を続けていると集中力が低下したり、片方だけが作業内容を把握している状態になりがちです。そのため、ドライバーとナビゲーターの役割を頻繁に交代することで、双方が主体的にコードに関わり、知識の共有と集中力の維持を図るのが適切な進め方です。

選択肢1の「ドライバーが全ての意思決定を行う」と、ナビゲーターの存在意義がなくなります。選択肢3の「ナビゲーターは指示を出さず黙って観察する」のも誤りで、対話こそがペアプログラミングの肝です。

【解説】

正解: 3 コードの内部構造を改善し保守性を高めること

この問題は、「リファクタリング」という用語の正確な定義を理解しているかを確認するものです。

リファクタリングの定義は「外部から見た振る舞いを保ちつつ、理解や修正が簡単になるようにソフトウェアの内部構造を改善すること」です。つまり、機能追加やバグ修正とは明確に区別される活動であり、将来の変更を容易にするための「整理整頓」が目的です。

選択肢1の「コードの動作を変更すること」や選択肢2の「新しい機能を追加すること」は、リファクタリングとは異なる作業です。これらをリファクタリングと混同すると、バグの原因特定が困難になるなどの問題が生じます。

【解説】

正解: 3 すべての開発が完了した後

この問題は、リファクタリングをいつ実施すべきかという「タイミング」についての理解を問うものです。

リファクタリングは、開発の過程で「こまめに」行うことが推奨されます。特に、機能追加の前（準備として）や、バグ修正の後（再発防止や整理として）に行うのが効果的です。全ての開発が終わった後にまとめて行おうとすると、修正箇所が膨大になり、テストも困難になるため適切ではありません。

選択肢1の「新しい機能を追加する前」や選択肢2の「コードにバグが見つかったとき」は、コードを整理するのに適したタイミングです。

【解説】

正解: 2 コードが簡潔になり読みやすくなる

この問題は、リファクタリングを行った結果、具体的にどのような成果が得られるかを理解しているかを確認するものです。

リファクタリングを行うと、複雑なロジックが整理され、重複コードが排除されます。その結果、コードが簡潔になり、誰が見ても理解しやすい（可読性が高い）状態になります。これにより、将来の変更や修正がスムーズに行えるようになります。

選択肢1の「プログラムの実行速度が常に向上する」とは限りません。読みやすさを優先した結果、速度が変わらない、あるいはわずかに低下することもあり得ます（最適化とは異なります）。選択肢3の「リリーススケジュールが短縮される」も、長期的には効果がありますが、リファクタリング作業自体には時間がかかるため、直ちに短縮されるわけではありません。

【解説】

正解: 1 過去のスプリントで起きた問題を追及する

この問題は、アジャイル開発における「ふりかえり（レトロスペクティブ）」の基本的な姿勢と目的を理解しているかを確認するものです。

ふりかえりの目的は、チームがより良く働くための改善点を見つけることです。「誰が悪かったか」という犯人探しや責任の追及（選択肢1）を行うと、メンバーが萎縮し、本音で話し合えなくなるため、ふりかえりの目的として最も不適切です。

選択肢2の「次のスプリントに向けて改善点を見つける」や、選択肢3の「チームの作業プロセスを評価する」は、ふりかえりで実施すべき正しい活動です。

【解説】

正解: 2 スプリントの終了時に行う

この問題は、スクラムなどのアジャイル開発におけるイベントのタイミングを理解しているかを確認するものです。

ふりかえりは、一つの開発サイクル（スプリント）の区切りとして、次のサイクルを始める前に行います。今回のスプリントでの働き方を振り返り、次回のスプリントで試す改善策を決めるため、実施タイミングは「スプリントの終了時」が一般的です。

選択肢1の「毎日行う」のは「デイリースクラム（朝会）」です。選択肢3の「1年に1回行う」のでは頻度が低すぎ、アジャイルの「短いサイクルでの改善」という特徴を活かせません。

【解説】

正解: 3 個人のミスや責任追及

この問題は、ふりかえりを効果的なものにするための「心理的安全性」や「議論の対象」に関する理解を問うものです。

ふりかえりでは、「事象（コト）」に焦点を当てて議論すべきであり、「人（ヒト）」を攻撃してはいけません。個人のミスを責め立てる場になると、問題が隠蔽されるようになり、チームの成長が止まってしまいます。したがって、3が話し合われるべきでない内容です。

選択肢1の「次のスプリントで試すべき改善策（Try）」や、選択肢2の「スプリントでうまくいったこと（Keep）」は、KPT法（Keep, Problem, Try）などで扱われる中心的なテーマです。

【解説】

正解: 1 統合の問題を早期に発見すること

この問題は、継続的インテグレーション（CI）を導入する意義を理解しているかを確認するものです。

複数人で開発していると、それぞれの作業成果を持ち寄って合体（統合）させる際に、コードの競合や不整合が起きやすくなります。CIは、これを毎日あるいは数時間おきに頻繁に行うことで、問題が小さいうちに発見・対処できるようにすることを主な目的としています。

選択肢2の「手動でのテストを省略すること」は誤りです。自動テストは強力ですが、探索的テストなどの手動テストが不要になるわけではありません。選択肢3の「すべてのバグを自動で修正すること」も誤りです。CIツールは問題を検知しますが、修正するのは人間です。

【解説】

正解: 3 コードの品質を継続的に確保できる

この問題は、継続的インテグレーション（CI）の中で「自動テスト」が果たす役割を理解しているかを確認するものです。

CIでは、コードが変更されるたびに自動テストが実行されます。これにより、「新しい変更が既存の機能を壊していないか」を常にチェックできるため、コードの品質を一定水準に保ち続けることができます。

選択肢1の「コードのバグをすべて修正できる」わけではありません。テストで見つからないバグもあります。選択肢2の「リリースの頻度を減らすことができる」は逆です。品質が安定するため、安心して頻繁にリリースできるようになるのがCIのメリットです。

【解説】

正解: 2 自動化されたテストのセットを頻繁に実行する

この問題は、継続的インテグレーション（CI）を成功させるための技術的な要件を理解しているかを確認するものです。

CIの核心は「頻繁な統合」と「自動検証」です。コードを統合しても、それが正しく動くかどうかが分からなければ意味がありません。したがって、ビルドやテストを自動化し、コード変更のたびにそれらを頻繁に実行することが不可欠な要素となります。

選択肢1の「コードの変更を手動で統合する」は、手間がかかり頻繁な実施が難しくなるため、CIの考え方に反します。選択肢3の「リリース作業を完全に自動化する」は、CIの先の「継続的デリバリー（CD）」の領域であり、CIの必須条件ではありません。

【解説】

正解: 2 一定の期間で開発する反復的なサイクルである

この問題は、スクラム開発における「スプリント」の基本的な定義と性質を理解しているかを確認するものです。

スプリントとは、あらかじめ決められた固定の期間（タイムボックス）のことです。スクラムでは、この期間内で設計・実装・テストを行い、動くソフトウェアを作成するサイクルを繰り返します。期間を固定することで、リズムを作り、進捗を測りやすくします。

選択肢1の「期限が決まっておらず、自由に延長できる」は誤りです。スプリント期間は厳守し、終わらなかった作業は次のスプリントに持ち越すなどの判断をします。選択肢3の「すべての機能をリリースする必要がある」も誤りです。スプリント終了時には「リリース可能な状態のもの」を作るのが目標ですが、実際に市場にリリースするかどうかはビジネス判断によります。

【解説】

正解: 1 チームの進捗状況を確認し、問題を早期に解決すること

この問題は、スクラムにおけるイベントの一つ「デイリースクラム」の目的を理解しているかを確認するものです。

デイリースクラムは、開発チームが毎日同じ時間に短時間（通常15分以内）で行うミーティングです。「スプリントゴールに向けて順調か」「何か障害（ブロック）になっていることはないか」を確認し合い、チーム内の同期をとることが目的です。

選択肢2の「長期的な計画を詳細に策定すること」や、選択肢3の「顧客からのフィードバックを収集すること」は、スプリントプランニングやスプリントレビューなど、他のイベントで行うべき内容です。

【解説】

正解: 2 プロダクトオーナー

この問題は、スクラムチーム内の役割（ロール）と、その責任範囲についての知識を問うものです。

「何を作るか（What）」を管理し、プロダクトの価値を最大化する責任を持つのがプロダクトオーナー（PO）です。したがって、実現したい機能のリストである「プロダクトバックログ」の管理や優先順位付けは、POが担当します。

選択肢1の「開発チーム」は、バックログの項目を「どう作るか（How）」に責任を持ちます。選択肢3の「スクラムマスター」は、スクラムのプロセスが円滑に回るように支援する役割です。

【解説】

正解: 3 スクラムのプロセスをサポートし、チームの障害を取り除く

この問題は、スクラムマスターという役割の具体的な活動内容を理解しているかを確認するものです。

スクラムマスターは「サーバントリーダー（奉仕型リーダー）」として機能します。チームに対して命令するのではなく、スクラムのルールが守られるようガイドしたり、外部からの割り込みや環境の問題といった「障害」を取り除き、開発チームが作業に集中できる環境を作ることが主な役割です。

選択肢1の「優先順位を決める」のはプロダクトオーナーの役割です。選択肢2の「ソフトウェアのテストを担当する」のは開発チームの役割です。

【解説】

正解: 2 開発チームのパフォーマンス評価

この問題は、プロダクトオーナー（PO）の役割の境界線を理解しているかを確認するものです。

POは「プロダクト（製品）」に対して責任を持ちますが、「人（チームメンバー）」の管理職ではありません。したがって、開発チームのメンバーに対する人事評価やパフォーマンス評価を行うことは、スクラムにおけるPOの役割定義には含まれません（組織によっては兼任する場合もありますが、スクラムの定義ではありません）。

選択肢1の「要件の決定とプロダクトバックログの管理」や、選択肢3の「ステークホルダーとのコミュニケーション」は、プロダクトの価値を高めるためにPOが担うべき重要な責任です。

【解説】

正解: 2 実装する機能の設計とコーディング

この問題は、スクラムにおける「開発者（開発チーム）」の役割を理解しているかを確認するものです。

スクラムにおける開発者は、スプリントバックログに選ばれたアイテムを、スプリント終了時までに「動作するインクリメント（製品）」にするための全ての作業を行います。これには設計、コーディング、テストなどが含まれます。

選択肢1の「プロジェクトの全体計画の策定」は、プロダクトオーナーが主導しつつチーム全体で考えるものです。選択肢3の「スプリントの終了後にリリース計画を立てる」も、主にプロダクトオーナーの管轄です。

【解説】

正解: 1 1〜4週間

この問題は、スプリントの適切な期間設定（タイムボックス）に関する知識を問うものです。

スクラムガイドでは、スプリントの期間は「1か月以内」とされており、一般的には1週間から4週間の間で固定して運用されます。これは、環境の変化に適応しつつ、十分な成果物を出すために適切な長さとされています。

選択肢2の「6〜12ヶ月」では期間が長すぎてフィードバックのループが回らず、アジャイルのメリットが得られません。選択肢3の「毎日行われる」では短すぎて、まとまった機能の開発が困難です。

【解説】

正解: 3 スプリントレビューとふりかえり

この問題は、スプリントの最後に行われるイベントの種類と目的を理解しているかを確認するものです。

スプリントの終わりには、作成した成果物をステークホルダーに見せてフィードバックをもらう「スプリントレビュー」と、チームの働き方やプロセスを改善するための「スプリントレトロスペクティブ（ふりかえり）」の2つのイベントが行われます。

選択肢1の「プロジェクトの全体計画の再策定」は特定のイベントではありません。選択肢2の「休憩期間を設ける」もスクラムのルールにはなく、通常はすぐに次のスプリントが始まります。

【解説】

正解: 2 現在のスプリントを完了させ、その後に変更を考慮する

この問題は、スプリント期間中の「変更管理」の原則を理解しているかを確認するものです。

スプリント期間中は、開発チームが集中して作業できるよう、原則として「ゴールを脅かすような仕様変更」は受け入れません。新しい要望が出た場合は、プロダクトバックログに追加しておき、次回のスプリント計画時に検討するのが基本ルールです。

選択肢1の「中断して新たに開始する」のは、スプリントゴールが意味をなさなくなった非常時のみです。選択肢3の「即座に修正する」と、計画が破綻し、チームの集中力が乱れるため避けるべきです。

【解説】

正解: 3 プロダクトオーナー

この問題は、プロダクトバックログの「所有権」が誰にあるかを再確認するものです。

プロダクトバックログの内容、順序（優先順位）、可視性に対して最終的な責任を持つのは、プロダクトオーナーただ一人です。他のメンバーが提案することはできますが、決定権はプロダクトオーナーにあります。

選択肢1のスクラムマスターや選択肢2の開発チーム全員は、バックログの整備に協力することはあっても、管理責任者ではありません。

【解説】

正解: 3 詳細な技術設計書

この問題は、プロダクトバックログに記載される項目の粒度や性質を理解しているかを確認するものです。

プロダクトバックログは「何が必要か（What）」をリスト化したものであり、機能追加、バグ修正、技術的改善などが含まれます。しかし、「どう作るか（How）」を記述した詳細な技術設計書そのものは、バックログアイテムとしては不適切です。設計は、スプリント内で開発チームが行う作業の一部です。

選択肢1の「機能要求」や、選択肢2の「技術的負債の対応策」は、プロダクトの価値や健全性に関わるため、バックログに含まれるべき項目です。

【解説】

正解: 2 常に必要に応じて随時更新される

この問題は、プロダクトバックログが固定的な文書ではなく、「生きたアーティファクト」であることを理解しているかを確認するものです。

プロダクトバックログは、一度作ったら終わりではありません。市場の変化、新しいアイデア、前のスプリントでの学びなどを反映して、いつでも項目の追加・削除・並べ替えが行われます。これを「リファインメント」と呼びます。

選択肢1の「スプリント終了時のみ」や選択肢3の「プロジェクトの初期段階のみ」といった限定的な更新では、変化に柔軟に対応するアジャイル開発の目的を果たせません。

【解説】

正解: 1 特定のスプリントで実施するタスク

この問題は、「スプリントバックログ」と「プロダクトバックログ」の違いを理解しているかを確認するものです。

スプリントバックログは、開発チームが「今回のスプリント」で達成するために選んだプロダクトバックログの項目と、それを実現するための具体的な作業計画（タスク）をまとめたものです。

選択肢2の「プロジェクト全体の要件一覧」はプロダクトバックログの説明です。選択肢3の「将来のリリース計画」もスプリントバックログの範囲外です。

【解説】

正解: 2 開発チーム

この問題は、スプリントバックログの管理責任が誰にあるかを理解しているかを確認するものです。

スプリント期間中、「どの作業を、誰が、どのように進めるか」を決めるのは、実際に作業を行う開発チーム自身です。外部からの指示ではなく、チームが自律的に計画・管理することがスクラムでは重視されます。

選択肢1のスクラムマスターや選択肢3のプロダクトオーナーは、スプリントの進行中はチームの自律性を尊重し、スプリントバックログの細かなタスク管理には介入しません。

【解説】

正解: 1 スプリント中に必要に応じて随時更新される

この問題は、スプリントバックログの運用方法について理解しているかを確認するものです。

開発作業を進めると、当初想定していなかった新しい作業が必要になったり、逆に不要になったりすることがあります。スプリントバックログは、チームの現在の状況を正確に反映させるため、スプリント期間中であれば開発チームの手によっていつでも更新されます。

選択肢2のように「スプリント計画ミーティングのみ」で固定してしまうと、現実の作業状況と計画が乖離してしまいます。選択肢3の「スプリント終了後」では、進捗管理の役に立ちません。