システム開発では、最初から画面やプログラムの詳細を決めません。目的・対象・効果・リスクを計画し、利用者と業務の要求を分析して要件を明確にします。
SGでは、システム化計画、要求分析、要件定義、機能要件と非機能要件の違いを中心に判断します。読み終えると、各工程で何を決めるのかと、機能・非機能・セキュリティ要件の境界を見分けられるようになります。
先に結論：SGではどこまで学ぶか
| 論点 | 押さえる範囲 | 深追いしない範囲 |
|---|---|---|
| システム化構想・計画 | 方向性と具体化の違い | 詳細な立案手法 |
| 要求分析 | ニーズ・現状・課題・要求の整理 | 分析技法の詳細 |
| 要件定義 | 業務・機能・非機能・セキュリティ・データ要件 | 詳細な文書様式 |
| 機能・非機能要件 | 「何ができるか」と「どの程度の品質か」 | 非機能要求グレード |
| モデリング記法 | FEのシステム戦略分野へ橋渡し | DFD・E-R図・UMLの詳細 |
1．構想で方向を決め、計画で具体化する
| 段階 | 主に明らかにすること |
|---|---|
| システム化構想 | 対象業務、システム化の目的・方針 |
| システム化計画 | 範囲、体制、スケジュール、概算費用、期待効果、導入リスク |
SGシラバスVer.4.1では「システム化計画」は明示されていますが、「システム化構想」という名称は用語例に明示されていません。本記事では、計画との違いを理解するための補助概念として、方向性と具体化の違いだけを押さえます。
システム化計画は、投資判断と後続工程の土台です。関数名、CPUの型番、画面の細かな配置などは、後の設計・調達で具体化します。
導入リスクも計画へ反映する
システム化計画では、導入リスクの発生頻度、影響、範囲、想定損害と対応方針も整理します。分類の詳細は「リスク対応の4分類」の記事で扱います。
2．要求分析は利用者の要望を並べるだけではない
要求分析では、次の流れで要求を整理します。
- ユーザーニーズを調査する
- 現在の業務・データ・制約を分析する
- 解決すべき課題を定義する
- 要求項目を洗い出し、重複・矛盾・優先順位を分析する
- 要求仕様書として整理する
利用者の要望をそのまま機能一覧にせず、背景の課題と必要な処理を確認します。画面配置、製品選定、受入れ判定は後の工程です。
3．要件定義で実現内容と品質を明確にする
| 要件 | 主な内容 |
|---|---|
| 業務要件 | 業務の目的、対象、ルール、役割、業務処理手順 |
| 機能要件 | システムが実行すべき処理 |
| 非機能要件 | 性能、可用性、操作性、拡張性などの品質・制約 |
| セキュリティ要件 | 認証、権限、暗号化、ログ、バックアップ、対応時間など |
| 情報・データ要件 | データ項目、品質、保存、管理主体、システム間連携など |
合意した要件は、RFP、設計、試験、受入れ条件の基礎です。曖昧なまま進めると、手戻りや追加費用につながります。
4．機能要件と非機能要件を見分ける
判断の基本は次のとおりです。
何ができるか＝機能要件
どの程度の品質・性能・制約か＝非機能要件
| 要件の例 | 区分 |
|---|---|
| 受注データを登録できる | 機能要件 |
| 請求書を発行できる | 機能要件 |
| 在庫を検索して一覧表示できる | 機能要件 |
| 通常時の応答時間を3秒以内にする | 非機能要件 |
| 月間稼働率を99.9％以上にする | 非機能要件 |
| 障害発生後4時間以内に復旧する | 非機能要件 |
非機能要件は、可能な範囲で測定可能な数値・条件にします。
5．セキュリティ要件は後付けにしない
セキュリティ要件を設計後や稼働直前に追加すると、構成・業務手順の変更が必要になり、費用と手戻りが増えます。
要件定義の段階から、認証、アクセス権、暗号化、ログ、バックアップ、復旧、対応時間などを検討します。
現行SGシラバスでは、セキュリティ要件は機能要件・非機能要件とは別に列挙されています。機能的な事項と品質・制約の事項があるため、全てを非機能要件と決め付けません。
6．どこで補うか
| 目的 | 補う範囲 |
|---|---|
| DFD・E-R図・UMLなどのモデリング記法を学ぶ | FEのシステム戦略分野 |
| リスク対応の分類を整理する | 「リスク対応の4分類」の記事 |
| RFI・RFP・提案評価・契約・受入れ条件を学ぶ | 「調達とベンダー選定」の記事 |
| 出題範囲全体を体系的に確認する | 市販参考書 |
本記事では、SGで必要な工程の境界と要件の区分に絞ります。
よくある取り違え
| 誤った説明 | 正しい整理 |
|---|---|
| システム化計画で画面の細かな配置まで確定する | 後の設計工程で具体化する |
| 利用者の要望をそのまま機能一覧にする | 現状・課題・必要性を分析する |
| 要求分析で完成システムを受入れ判定する | 受入れは開発の終盤 |
| 登録・検索・帳票出力は非機能要件 | システムの処理なので機能要件 |
| 応答時間・稼働率・復旧時間は機能要件 | 品質・性能なので非機能要件 |
| セキュリティ要件は稼働直前に追加する | 要件定義段階から組み込む |
まとめ
- システム化構想は目的・方針を定め、システム化計画は範囲・体制・費用・効果・導入リスクを具体化する
- 要求分析は、ニーズ、現状、課題を調査し、必要な要求を整理する
- 要件定義では、業務・機能・非機能・セキュリティ・情報／データ要件を明確にする
- 機能要件は「何ができるか」、非機能要件は「どの程度の品質・性能・制約か」
- セキュリティ要件は後付けせず、企画・要件定義の段階から組み込む
- SGでは工程の境界を押さえ、詳細なモデリング記法はFEへつなぐ
関連記事
- C11-T01：経営戦略と情報システム戦略
- C11-T03：調達とベンダー選定
- C4-T05：リスク対応の4分類
- C7-T02：委託契約とセキュリティ要求事項
本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。
参考資料
- IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
- IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年12月20日）
- IPA「非機能要求グレード2018」（2018年4月公開）
関連する問題
- 情報セキュリティマネジメント システム戦略・システム企画・企業活動 一問一答 第6問〜第10問
- 情報セキュリティマネジメント システム戦略・システム企画・企業活動 択一式（応用） 第1問〜第5問
- 情報セキュリティマネジメント システム戦略・システム企画・企業活動 択一式（応用） 第6問〜第10問
- 情報セキュリティマネジメント システム戦略・システム企画・企業活動 一問一答 第1問〜第5問
コメント