【知識】システム開発技術｜情報処理問題1000本ノック

【知識】顧客の「本当の欲しい」を引き出す！「要求獲得」の全貌｜情報処理問題1000本ノック（解説編）

システム開発の最上流工程であり、プロジェクトの成否を握る最重要局面「要求獲得（要求エライシテーション）」。単に言われたことをメモするのではない、本質的な知識を整理しましょう。

1. 要求獲得で「絶対に聞き出すべき」4つの本質

ステークホルダー（利害関係者）に対してヒアリングを行う際は、表面的な機能の要望（「画面にボタンが欲しい」など）ではなく、以下の根本的な問いをぶつけ、合意形成を行う必要があります。

・システムの目的は？（Why：なぜこのシステムを作るのか）

・何を達成したいの？（Goal：最終的なゴール、経営目標は何か）

・どんなビジネスニーズに対応するの？（Need：市場や業務のどんな課題を解決したいのか）

・システムがビジネスで、どう使われていくの？（Operation：現場でどのような業務フローになるのか）

2. 要求獲得が「極めて難しい」3つの理由

要求獲得は、システム開発の中で最も人間臭く、トラブルが起きやすい工程です。それには以下の3つの大きな原因が存在します。

1. スコープの問題
システム化の「境界線（どこまでやるか）」の設定が甘いと、「あれもやりたい、これもやりたい」とスコープが無限に広がっていき、予算と納期が崩壊します。

2. 要求や問題自体の問題
・利用者が、問題自体を正しく認識していない（何に困っているか、何が欲しいのかを自分たちで言語化できない）。
・立場（経営層、現場のリーダー、一般社員など）によって、問題のとらえ方が全く異なる。

3. 時間による変化の問題
ビジネス環境の変化、法改正、あるいは開発が進んで画面が見えてくることによって、要求は時間とともに必ず変化・追加される性質を持っています。

3. 要求獲得プロセスの「7つの実践ステップ」

要求を獲得し、仕様として確立するまでには、以下の一連のエンジニアリング作業を順番に進めていきます。

ステップ	作業内容
ステップ 1	ビジネスや技術の面から実現可能性を検討（フィージビリティスタディ）
ステップ 2	要求の定義および組織での役割の特定（誰がどの要求を出しているかの明確化）
ステップ 3	技術環境（アーキテクチャ等）の定義（システムを動かす土台の策定）
ステップ 4	ドメインの制約定義（業界ルールや法規制などの縛りの定義）
ステップ 5	要求獲得の技法の定義（インタビュー、ミーティング、観察など手法の決定）
ステップ 6	要求獲得、プロトタイプでの確認（試作品を見せて認識ズレを早期に解消する）
ステップ 7	ユースケースシナリオの定義（実際の利用シーンに沿った具体的な動きの落とし込み）

1. 理解のコツ: 顧客は「ドリル（機能）」が欲しいのではなく「穴（ビジネスの成果）」が欲しいのだ、という格言があります。要求獲得の難しさを突破するには、ステップ6にあるプロトタイプ（試作品）を素早く見せ、「欲しかったのはこれじゃない」を先に言わせることが最大の防御になります。
2. 試験対策の視点: 応用情報以上の高度試験（システムアーキテクトなど）では、「利用者は要件を正しく認識していない」という前提をもとに、それを解決するための「プロトタイプ」「ユースケース記述」「JAD（共同アプリケーション開発）」などの技法と絡めて、午後問題の記述や論文のテーマとして非常によく狙われます。

4. まとめ

「ステークホルダーの潜在的なニーズを引き出し、実現可能性や制約を考慮しながら、具体的な利用シナリオに落とし込んでいく一連のプロセス」。それが要求獲得です。ここでの妥協や認識ズレは、後々の工程（設計・テスト）で何十倍もの手戻りコストとなって跳ね返ってくるため、7つのステップを堅実に回していく管理能力が求められます。

【知識】プロジェクトの成功を導く！「開発手法」の全容｜情報処理問題1000本ノック

開発手法は、時代やプロジェクトの性質に合わせて進化してきました。大きく分けて「伝統的な手法」「アジャイル系」「品質・設計重視型」の視点で整理しましょう。

開発手法	一言説明（特徴・目的）
ウォーターフォール	要件定義から順に、上流から下流へ滝のように戻ることなく進める最も標準的な手法。
Vモデル開発	開発工程（左側）とテスト工程（右側）を対応させ、検証（検収）作業を明確にしたモデル。
スパイラル開発	設計と試作（プロトタイプ）を繰り返し、徐々にリスクを排除しながら螺旋状に規模を拡大する。
反復開発	システムを小さな単位に分割し、短期間のサイクル（イテレーション）を繰り返して完成させる手法の総称。
アジャイル開発	柔軟な計画と短期間の反復を重視し、顧客との対話を通じて動くソフトウェアを迅速に提供する手法。
XP (エクストリーム・プログラミング)	ペアプログラミングやテスト駆動開発など、技術的実践を通じて変化への対応力を高める。
クリスタル開発	プロジェクトの規模や重要度（色）に応じて、手法の厳密さを柔軟に使い分ける手法。
DSDM	時間の制約（タイムボックス）を優先し、ビジネス価値を迅速に届けるための英国発祥のアジャイル手法。
リーン	トヨタ生産方式を源流とし、徹底的に「ムダ」を省いて価値提供の効率を最大化する考え方。
構造化開発	機能を段階的に詳細化（トップダウン）し、プログラムを単純な構造の組み合わせで構築する手法。
オブジェクト指向開発	データと手続きを「オブジェクト」としてまとめ、再利用性や保守性を高める設計手法。
データ中心設計 (DOA)	機能よりも先に、変化しにくい「データの構造」に着目してシステムを設計する手法。
パターンベース開発	過去の成功例である「デザインパターン」などを再利用して、効率的に設計・開発を行う。
クリーンルーム開発	数学的検証に基づき、バグの混入を未然に防いで「無欠陥」のソフトウェアを目指す高品質重視の手法。
RAD (Rapid Application Development)	CASEツールやプロトタイプを用い、少人数で短期間にシステムを完成させることを目指す。
RUP (Rational Unified Process)	オブジェクト指向を基盤とし、ユースケース駆動・リスク中心で進める反復型の開発フレームワーク。
JAD (Joint Application Development)	ユーザーと開発者が一堂に会して集中討議を行い、合意形成を加速させる要件定義の手法。
PSP / TSP	個人のスキル向上（PSP）とチームのプロセス管理（TSP）を通じて、予測通りの納期と品質を達成する。

※これらの手法は独立しているわけではなく、たとえば「アジャイルという大きな枠組みの中にXPやリーンがある」といった関係性や、「オブジェクト指向という設計思想をウォーターフォールで使う」といった組み合わせが実際の現場ではよく見られます。

【知識】リズムと透明性でつくる！「スクラム」の重要用語｜情報処理問題1000本ノック

スクラムは、変化の激しい現代の開発において、短期間で成果を積み上げ、改善を繰り返すための強力なフレームワークです。各用語の意味を正確に理解し、開発の流れを攻略しましょう。

■ スクラムを構成する主要な要素

開発の単位、管理リスト、そして情報共有のためのイベントを整理します。

スプリント (Sprint)

アジャイル開発における反復（イテレーション）の単位です。通常「1〜4週間」の固定期間で実施され、その期間内で設計・開発・テストを行い、動くソフトウェア（インクリメント）を完成させます。

バックログ (Backlog)

顧客にとってビジネス価値がある開発機能の一覧です。主に以下の2段階で管理されます。

プロダクトバックログ：製品全体の「やりたいこと（フィーチャー/ストーリー）」を優先順位付けしたリスト。
スプリントバックログ：そのスプリント内で完了させるために、プロダクトバックログから抜き出し、具体的なタスクに分解した作業一覧。

タイムボックス (Timebox)

スプリントの期間を厳守する考え方です。スプリント期間中に対応するバックログの内容は、原則として変更されません。 これにより、チームは目の前の作業に集中し、確実に成果物を出し切ることができます。

デイリースクラム（スクラムミーティング）

毎日決まった時間に短時間（15分程度）で行う進捗確認です。以下の3点を中心に共有します。

昨日（前回）は何をしたか？
今日（次回まで）は何をするか？
現在、直面している障害や困りごとはあるか？

試験対策の重要ポイント：3つの役割

スクラムには重要な3つのロールがあります。
★ プロダクトオーナー：製品価値の最大化とバックログの優先順位決定に責任を持つ。
★ スクラムマスター：スクラムの理解を助け、チーム内の障害を取り除く支援者。
★ 開発者（開発チーム）：実際に作業を行い、スプリント終了時にインクリメントを生み出す人々。

※プロダクトバックログは「夢や希望が詰まった大きなリスト」、スプリントバックログは「今週、確実に終わらせる戦術リスト」というイメージで使い分けを理解しましょう。