ITパスポート 2017年 秋期 問30

ソフトウェアライフサイクルのプロセスで利害関係者の合意が必要なもの【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題文で求められているキーワードを探す：ここは「機能に関して利害関係者の合意が必要」。
2. 各工程の役割を短く思い出す：
   • 企画：やるかどうか、何を目指すかの方針決定
   • 要件定義：具体的な機能や条件を決め、関係者が合意する段階
   • 開発：決まった要件を元に作る
   • 保守・運用：稼働後の運用・修正
3. 「機能の合意」が直接行われるのはどれかを選ぶ：要件定義 → イ.
4. 他の選択肢が間違いである理由を簡単に排除する（次の節参照）。

選択肢別の誤答解説

• ア: 企画
  企画は「何を目的にするか」「ビジネスとして成り立つか」を決める段階です。大まかな方向性や投資判断をする場で、具体的なシステムの細かな機能を詳細に合意する段階ではありません。
• イ: 要件定義
  正しい選択肢です。機能（例：ログインする、売上を集計する、レポートを出す）を明確にし、関係者の合意を得る工程です。ここで作る文書は「要件定義書」と呼ばれ、後工程の基準になります。
• ウ: 開発
  開発は決まった要件を実際にプログラムとして作る工程です。機能の合意は原則として先に済ませておきます。開発中に仕様の確認はありますが、「合意を得る主要な場」は要件定義です。
• エ: 保守・運用
  稼働後の監視や問題対応、機能追加などを行う段階です。既存の機能を最初に合意する場所ではありません。変更や追加があれば再び要件定義的な合意が必要になりますが、それは「保守の中の変更手続き」であり、設問が問う「機能に関して合意が必要なプロセス」とは異なります。

よくある誤解

1. 「企画で機能を全部決める」と考える
   → 企画は方向性（やるべきこと・やらないこと）を決める段階です。具体的な機能の細部や仕様は要件定義で決めます。
2. 「開発中に合意すればよい」と思う
   → 開発中の仕様変更は手戻りや追加コストを生みます。要件定義で合意を得ておくことが効率的です。
3. 「保守・運用で合意すれば良い」と混同する
   → 保守は既存システムの運用や問題対応が中心。初期の合意は要件定義で行います（変更があれば別途合意が必要）。

補足コラム

• 機能要件（functional requirements）と非機能要件（non-functional requirements）
  要件定義では「何をするか（機能要件）」と「どれくらいの性能・信頼性・セキュリティが必要か（非機能要件）」の両方を決めます。例：機能要件＝「ユーザーが商品を検索できる」、非機能要件＝「検索結果は2秒以内に返す」。
• 要件定義書は合意の証拠になります。署名や承認の日付が入ることが多いです。
• 開発手法による違い：ウォーターフォール型（順番に進める）では要件定義で固定することが多いです。一方、アジャイル（agile：短いサイクルで仕様を進化させる手法）では合意が段階的・繰り返しになります。試験問題では一般的な工程の役割を問うことが多いので「要件定義＝合意を得る工程」を基本として理解しておきましょう。

FAQ