4-1 システム開発技術
システム開発技術
システム開発は、業務上の目的と要求を明確にし、設計、実装、テスト、移行、運用・保守へつなげる活動です。ITパスポートでは、工程名だけでなく、「誰が何を確認する工程か」「どのテストで何を検証するか」を判断する問題が出題されます。
この節の目標は、要件定義から運用・保守までの成果物と責任を整理し、テスト工程、レビュー、移行、安全な開発を具体的なケースから選べるようになることです。
1. 企画・要件定義・設計を区別する
| 工程 | 主な問い | 成果物の例 |
|---|---|---|
| システム企画 | なぜシステム化するのか、投資する価値があるか | システム化構想、計画、投資評価 |
| 要件定義 | 利用者・業務が何を必要としているか | 業務要件、機能要件、非機能要件 |
| 外部設計 | 利用者や外部システムからどう見えるか | 画面、帳票、入力・出力、外部インタフェース |
| 内部設計 | システム内部をどう構成・処理するか | モジュール、データ構造、処理方式、内部インタフェース |
| プログラミング | 設計を動作するソフトウェアへ変える | ソースコード、設定、単体テストコード |
要件定義では「利用者が必要とすること」を明確にし、特定の実装方法を早く決めすぎないようにします。外部設計は画面や帳票など利用者に近い部分、内部設計はプログラム内部の構造に近い部分です。
2. 要件を検証可能な形にする
曖昧な要件は、設計・テスト・受入れで解釈の違いを生みます。
- 曖昧：「画面をすぐ表示する」
- 改善：「通常時、商品検索結果の95％を3秒以内に表示する」
- 曖昧：「安全なシステムにする」
- 改善：「管理者機能は多要素認証を必須とし、全操作を1年間記録する」
要件確認の観点
- 必要性：目的や業務課題と関係するか。
- 明確性：複数の意味に解釈されないか。
- 一貫性：他の要件と矛盾していないか。
- 実現可能性：技術、費用、納期で実現できるか。
- 検証可能性：テストやレビューで合否を判断できるか。
- 追跡可能性：要件から設計、テスト、変更履歴をたどれるか。
3. 完全ケース：予約システムの要件からテストまで
クリニックがWeb予約システムを導入します。主要な要件は次のとおりです。
- 患者は空き時間を検索し、予約・取消しができる。
- 同じ時間枠を二人へ重複予約してはいけない。
- 予約完了後に確認メールを送る。
- 月曜日の午前8時には同時に500人がアクセスする。
- 患者は自分の予約だけを閲覧できる。
この要件から、次の設計・テストへつなげます。
| 要件 | 設計の例 | テストの例 |
|---|---|---|
| 予約・取消し | 予約画面、取消し画面、状態管理 | 正常予約、取消し、入力不足を確認する |
| 重複禁止 | 排他制御、トランザクション | 同じ枠へ同時予約し、一件だけ成立するか確認する |
| メール送信 | メールサービス連携、再送設計 | 成功、失敗、再送、宛先誤りを確認する |
| 同時500人 | 性能・容量設計 | 負荷テストで応答時間とエラー率を測る |
| 本人の予約だけ閲覧 | 認証・認可設計 | 別利用者の予約番号を指定しても閲覧できないことを確認する |
機能だけでなく、性能、セキュリティ、障害時の動作という非機能要件もテストへ対応させます。
4. テスト工程を対象と責任で区別する
| テスト | 主な対象 | 確認する内容 |
|---|---|---|
| 単体テスト | 個々のプログラム・モジュール | 内部処理、境界値、例外処理 |
| 結合テスト | 複数モジュールやシステム間連携 | データ受渡し、インタフェース、処理順序 |
| システムテスト | システム全体 | 機能・性能・セキュリティなど要件全体 |
| 運用テスト | 実運用の手順と体制 | 監視、バックアップ、障害連絡、日次処理 |
| 受入テスト | 利用者・発注者の受入条件 | 業務で利用可能か、契約要件を満たすか |
V字モデルでは、要件定義に受入テスト、外部設計にシステムテスト、内部設計に結合テスト、詳細なプログラム設計に単体テストを対応させて考えます。
5. テストケースを作る基本技法
同値分割
同じ結果になると考えられる入力範囲をグループ化し、代表値を選びます。年齢が18歳以上なら申込み可能な場合、「17歳以下」と「18歳以上」に分けます。
境界値分析
条件の境界付近で誤りが起こりやすいため、17歳、18歳、19歳のように確認します。
ブラックボックステストとホワイトボックステスト
- ブラックボックステスト：内部構造を意識せず、入力と出力を確認する。
- ホワイトボックステスト：分岐や経路など内部構造を確認する。
正常値だけでなく、空欄、最大値、形式違い、同時操作、通信失敗なども確認します。
6. レビューで早期に誤りを見つける
レビューは、文書や設計、コードなどを人が確認して誤りを早期に発見する活動です。
| レビュー | 特徴 |
|---|---|
| ウォークスルー | 作成者が説明し、参加者から意見を得る |
| インスペクション | 役割と手順を定め、欠陥検出を重視して行う |
| コードレビュー | ソースコードの正確性、可読性、安全性などを確認する |
テストは実行結果から欠陥を見つけ、レビューは実行前の成果物からも欠陥を見つけられます。後工程で発見するほど、関連文書やコードの修正範囲が広がりやすくなります。
7. 移行・リリース・運用引継ぎ
本番移行では、プログラムを配置するだけでなく、データ、利用者、業務、運用体制を切り替えます。
移行計画の確認項目
- 移行対象のデータと品質を確認する。
- データ変換・移行手順と照合方法を決める。
- 切替日時、停止時間、担当者を決める。
- 旧・新システムの並行運用が必要か判断する。
- 失敗時の切戻し条件と手順を決める。
- 利用者教育、マニュアル、問い合わせ窓口を準備する。
- 移行後に件数、金額、権限、処理結果を確認する。
ケース：顧客データを移行する
旧システムの顧客件数が10,000件なら、新システムでも件数だけでなく、重複、文字化け、住所、契約状態、アクセス権を照合します。「移行処理がエラーなく終了した」だけでは完全性を確認したことになりません。
8. 運用・保守と変更
- 是正保守：発見された不具合を修正する。
- 適応保守：OS、法令、外部サービスなど環境変化へ対応する。
- 完全化保守：性能や使いやすさなどを改善する。
- 予防保守：将来の障害を防ぐために構造や部品を改善する。
変更時は、目的、影響範囲、テスト、承認、リリース、切戻し、文書更新を管理します。緊急修正であっても、事後承認や記録を含む統制が必要です。
9. 安全な開発を工程へ組み込む
セキュリティを完成後だけに追加するのではなく、各工程へ組み込みます。
| 工程 | セキュリティ活動の例 |
|---|---|
| 要件定義 | 情報分類、認証、権限、ログ、法令、復旧要件を決める |
| 設計 | 脅威分析、最小権限、安全な構成、秘密情報管理を行う |
| 実装 | 安全なAPI、プレースホルダ、出力処理、コードレビューを使う |
| テスト | 認証・認可、入力、セッション、脆弱性を確認する |
| リリース | 構成、証明書、秘密情報、不要機能を確認する |
| 運用 | 更新、ログ監視、脆弱性情報、インシデント対応を管理する |
WAFなどの防御装置は補助対策であり、安全な設計・実装の代わりにはなりません。
10. よくある誤りと理由
- 企画と要件定義を同じと考える：企画は投資目的と全体計画、要件定義は業務・利用者が必要とする内容を明確にします。
- 外部設計をプログラム内部の設計と考える：外部設計は画面、帳票、外部インタフェースなど利用者に見える部分です。
- 受入テストを開発者だけで行う：利用者・発注者が業務と受入条件を確認します。
- 正常値だけでテストする：境界値、異常値、同時操作、障害時も必要です。
- 移行成功を処理終了だけで判断する：件数、内容、権限、業務結果を照合します。
- セキュリティは最後の診断だけでよい：要件・設計段階から組み込みます。
11. セルフチェック
- 企画、要件定義、外部設計、内部設計を区別できるか。
- 要件を具体的かつ検証可能に表現したか。
- 単体、結合、システム、運用、受入テストの対象を確認したか。
- 境界値、異常系、性能、セキュリティを含めたか。
- 移行の照合、切戻し、教育、運用引継ぎを確認したか。
理解を確認したら、第4章の練習問題と第4章の知識カードで工程とテストを対応させてください。開発方法と変更管理はソフトウェア開発管理技術、プロジェクト全体の計画はプロジェクトマネジメントで確認できます。
公式範囲との対応
本節は、IPA「ITパスポート試験シラバス Ver.6.5」のシステム開発技術、ソフトウェア開発技術に対応し、要件定義、設計、プログラミング、レビュー、各種テスト、移行、運用・保守、安全なWeb開発を扱います。