【ITパスポート】企画・要件定義、開発プロセスとソフトウェア開発手法（8-1～8-4）
まえがき
ITパスポートの勉強をしているので、復習として記事にまとめました。
理解しやすいようにまとめたため、教材と一部説明が異なります。
今回は、8章の「企画・要件定義」「開発プロセス」「テスト手法と運用・保守プロセス」「ソフトウェア開発手法」についてまとめます。
使用教材
令和８年 イメージ＆クレバー方式でよくわかる
かやのき先生のITパスポート教室
https://gihyo.jp/book/2025/978-4-297-15243-7
企画・要件定義
ソフトウェアライフサイクルプロセス（SLCP）
企画・要件定義・開発・運用・保守までの一連の流れのこと。
共通フレーム
用語や作業内容にずれが生じないよう定めた共通のガイドライン（共通フレーム）。
企画プロセス
システム化の初期段階で、全体の構想や計画を策定するプロセスのこと。
システムの必要性やターゲットを検討し、システム化計画としてスケジュール・コスト・ROI（費用対効果）などの基本方針を策定する。
システム化構想
経営戦略に基づいて、情報システム化の全体的な方向性や狙いを描く段階のこと。
システム化計画
システム化構想をもとに、開発のスケジュールや予算、体制などを具体的に策定する段階のこと。
要件定義プロセス
利用者のニーズに基づいて、システムに求められる機能と性能を明確にするプロセスのこと。
業務要件定義
業務内容や業務の流れを整理し、業務上必要な要件を明確にすること。
機能要件定義
業務要件をもとに、システムに実装すべき具体的な機能を明確にすること。
非機能要件定義
性能、信頼性、セキュリティなど、機能面以外でシステムに求められる要件を明確にすること。
調達
システム開発を担当するベンダを選定し、契約を結ぶ一連の流れのこと。
以下の書類が用いられる。
| 書類 | 内容 | 方向 |
|---|---|---|
| RFI（Request For Information） | システムの目的や業務概要を提示し、情報提供を依頼する文書 | 依頼元→ベンダ |
| RFP（Request For Proposal） | システムに求める方針・機能・調達条件などを提示し、提案書の提出を依頼する文書 | 依頼元→ベンダ |
| 提案書 | RFPをもとに開発手法を提案する文書 | ベンダ→依頼元 |
| 見積書 | システム全体にかかる費用を提示する文書 | ベンダ→依頼元 |
重みづけ評価
提案書からどのベンダに依頼するかを決定する際に用いられる評価手法のこと。
項目ごとに重視する重みを掛け合わせて評価する。
開発プロセス
開発プロセス
要件定義から構築まで、以下の順に進める。
| 順 | 工程 | 内容 |
|---|---|---|
| 1 | システム要件定義 | 利用者へのヒアリングをもとに、システム化の範囲や要求される機能・性能（応答時間や処理時間、信頼性の目標値など）を定義する |
| 2 | ソフトウェア要件定義 | 利用者へのヒアリングをもとに、ソフトウェアに求められる機能・性能・インタフェース（画面や帳票のレイアウトなど）を定義する |
| 3 | システム設計 | システム要件定義をもとに、ハードウェアやソフトウェアなど、システム全体の構成を設計する |
| 4 | ソフトウェア設計 | ソフトウェア要件定義をもとに、プログラムの構造やモジュールの構成を設計する |
| 5 | ソフトウェア構築 | 設計をもとに、プログラムを実際にコーディングする |
ソフトウェアの品質特性
ソフトウェアの良し悪しを評価する6つの観点のこと。
| 特性 | 内容 |
|---|---|
| 機能性 | 必要な機能を満たしているか |
| 使用性 | 使いやすいか |
| 信頼性 | 安定して稼働するか |
| 効率性 | 資源を無駄なく使えているか |
| 保守性 | 修正や変更がしやすいか |
| 移植性 | 他環境でも動作させやすいか |
テスト手法と運用・保守プロセス
テスト手法
ソフトウェアをモジュール単位から段階的に規模を広げて確認していく一連の流れのこと。
以下の順で実施する。
| 順 | テスト | 内容 | 実施主体 |
|---|---|---|---|
| 1 | 単体テスト | モジュール単位のテスト | ベンダ |
| 2 | 結合テスト | プログラム間のインタフェースを確認するテスト | ベンダ |
| 3 | システムテスト | システム全体の機能や性能を確認するテスト | ベンダ主体・利用者協力 |
| 4 | 運用テスト | 本番環境での運用を確認するテスト（マニュアルの妥当性や手順の実行可否） | 利用者主体・ベンダ協力 |
| 5 | 受入れテスト | 納品されたシステムを利用者が受け入れるかを確認するテスト | 利用者 |
ホワイトボックステストとブラックボックステスト
単体テストでは、主にホワイトボックステストが用いられる。
| 種類 | 内容 |
|---|---|
| ホワイトボックステスト | プログラム内部の構造や分岐・命令の実行状況まで考慮してテストする手法 |
| ブラックボックステスト | プログラムの内部構造を考慮せず、入力と出力だけに着目してテストする手法 |
ホワイトボックステストでは、以下の観点で網羅性を確認する。
- すべての分岐が実行されるか
- すべての分岐条件の組み合わせが実行されるか
- すべての命令が実行されるか
運用・保守プロセス
ソフトウェア保守とは、本番稼働中のソフトウェアに対するバグ修正や、新しい要件への対応のこと。
- 本番稼働中のソフトウェアの不具合修正
- 仕様変更に伴うソフトウェアの修正
- 法律改正に伴うソフトウェアの修正
ソフトウェア開発手法
ウォータフォールモデル
要件定義・設計・開発・テストの順に、後戻りしない前提で進める開発手法。
スケジュールが立てやすい一方、仕様変更のコストが大きい。大規模なシステムに向いており、最初から完成品を目指す。
アジャイル開発
短い開発サイクルを繰り返し、段階的に完成度を高めていく開発手法。
Agile（俊敏、素早い）の名の通り仕様変更のコストが低く、小規模なシステムやサブスクリプション契約のソフトウェアに向いている。
一方で進捗管理が難しく、方向性がぶれやすいという課題がある。
XP（エクストリームプログラミング）
アジャイル開発の手法の一つ。
以下のように実践されている。
| プラクティス | 内容 |
|---|---|
| イテレーション | 短いサイクルでプログラムを作ること |
| ペアプログラミング | 一人がコードを書き、もう一人がチェックすること |
| リファクタリング | 外部仕様を変えずに内部構造を改善すること |
| テストファースト | プログラムを書く前にテストケースを作成すること |
スクラム開発
開発チームが一丸となってコミュニケーションを取りながら進める開発手法。
| 用語 | 内容 |
|---|---|
| プロダクトオーナー | 責任者 機能の優先順位を決める |
| スプリント | 短いサイクルでプログラムを作ること |
| レトロスペクティブ | スプリント終わりのふりかえり |
| プロダクトバックログ | 優先順位順に並べた作業項目 |
| デイリースクラム | 毎日行う短い会議 |
その他の開発手法
プロトタイピングモデル
プロトタイプ（試作品）を作成し、利用者に確認しながら開発を進める手法。
利用者との解釈違いを早期に確認できるため、後戻りを少なくできる。
小規模なシステムに向く。
スパイラルモデル
システムをサブシステムに分割し、サブシステムごとにウォータフォールモデルで開発する手法のこと。
RAD（Rapid Application Development）
利用者を含む少人数でGUIなどの開発支援ツールを使ってプロトタイプを作り、評価と改良を繰り返す開発手法のこと。
DevOps
開発部門（Development）と運用部門（Operations）が協力し合いながらシステムの改善を進める考え方のこと。
リバースエンジニアリング
既存のプログラムを解析して仕様書を導き出すこと。通常の開発とは逆の手順をたどる。
ソフトウェアの見積もり
| 手法 | 内容 |
|---|---|
| ファンクションポイント法 | 仕様から機能数を洗い出し、複雑度ごとにポイントを付けて規模を見積もる方法のこと。利用者にも理解しやすい |
| 類推見積もり法 | 過去の類似実績値をもとに規模を見積もる手法のこと。正確さは劣る |
開発規模の見積もりには、開発工数（人月・人日）やステップ数（プログラムの行数）が用いられる。
人月 = 人数 × 月数
試験によく出るポイント
| 項目 | 覚えるポイント |
|---|---|
| RFP | ベンダに提案書の提出を依頼する文書 |
| 単体テスト～受入れテスト | この順に規模を広げて実施 |
| ホワイトボックステスト | 内部構造まで考慮するテスト |
| ブラックボックステスト | 入出力のみに着目するテスト |
| ウォータフォールモデル | 後戻りしない前提で進める、大規模向け |
| アジャイル開発 | 短いサイクルを繰り返す、小規模・仕様変更向け |
| XP | ペアプログラミング・テストファーストなど |
| スクラム開発 | スプリント・デイリースクラムで進める |
| DevOps | 開発と運用が協力する考え方 |
| ファンクションポイント法 | 機能数から規模を見積もる方法 |
あとがき
今回は、企画・要件定義、開発プロセス、テスト手法と運用・保守プロセス、ソフトウェア開発手法についてまとめました。
ウォータフォールモデルとアジャイル開発の違いや、XP・スクラムといったアジャイルの具体的な手法はよく出るポイントです。テスト工程の順番と実施主体もセットで覚えておきたいところです。
次回は、8章の続きの内容、「８－５ プロジェクトマネジメント」から進めていきます。