①システム工学完全版_上流工程

商用レベル・標準準拠 ｜ SYSTEMS ENGINEERING COMPLETE EDITION システム工学 完全版 上流工程編 ステークホルダー分析から妥当性確認まで。ISO/IEC/IEEE 29148・INCOSE準拠で押さえる6ステップ 要求工学 EARS記法 機能/非機能要件 面白きこともなき世を面白く ── うさうさ研修工房 アーキテクチャ設計 トレーサビリティ 検証と妥当性確認 2026

上流工程 6ステップ完全マップ ISO/IEC/IEEE 29148:2018・INCOSE SE Handbook（第5版, 2023）に基づく、商用開発の標準プロセス 01 02 03 ステークホルダー分析 要求記述（ EARS記法） 機能要件／非機能要件 誰のニーズか特定し、抜け漏れを防ぐ 曖昧語を排除し、検証可能な文にする 「何をするか」と「どう動くべきか」を分離 04 05 06 システムアーキテクチャ設計 トレーサビリティ管理 検証と妥当性確認 全体を要素に分解し、責務を割り当てる 要求→設計→実装→テストの連鎖を可視化 「正しく作ったか」と「正しい物を作ったか」 うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 2

ステークホルダー分析とニーズ抽出 STEP 1 誰のための、何のためのシステムかを最初に固定する なぜ大事か Why • • ステークホルダー漏れ＝要求漏れに直結 上流の手戻りは下流の 10〜100倍高コスト 発注者 運用・保守 何をするか What • • 利用者・発注者・運用者・規制側を洗い出す ISO 29148の「利害関係者要求」定義に対応 エンドユーザー 対象 システム 規制・監査 どうやるか How • • ステークホルダーマップを作成し役割を明記 各者に「成功の定義」を一言でヒアリング 出典: ISO/IEC/IEEE 29148:2018 §9「Stakeholder Requirements」／INCOSE SE Handbook 第5版(2023) うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 3

要求記述： EARS記法で曖昧語を排除 STEP 2 Easy Approach to Requirements Syntax ── 定型文で「読み手依存」をなくす なぜ大事か Why • • 「なるべく」「適切に」は人により解釈が割れる 自然文の要求は検証不能＝完成判定ができない 何をするか What • • 条件・状態・応答を定型パターンに当てはめる ISO 29148の well-formed requirement に準拠 どうやるか How • • まず「システムは ○○すること」の基本形で書く トリガーがあれば「〜のとき」を前に追加する Ubiquitous（普遍） <システム>は<応答>すること Event-driven（イベント） <トリガー>のとき、<システム>は<応答>すること State-driven（状態） <状態>の間、<システム>は<応答>すること 例：ログイン失敗が3回連続したとき、システムはアカウントを一時ロックすること 出典: INCOSE Guide to Writing Requirements (GtWR, 2023)／ISO/IEC/IEEE 29148:2018 §5.2 うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 4

機能要件と非機能要件を分離する STEP 3 「何をするか」だけでは、商用品質は保証できない なぜ大事か Why • • 機能は満たすのに「遅い・落ちる」は非機能の欠落 非機能要件の手戻りは設計全体に波及しやすい 機能要件 非機能要件 What it does How well it does it 何をするか What • • 機能要件＝システムが提供する振る舞い 非機能要件＝性能・安全性・保守性などの制約 • ログイン • 性能・応答速度 • 検索 • セキュリティ • 決済処理 • 可用性・保守性 どうやるか How • • 機能を洗い出したら、必ず品質特性で問い直す 非機能要件にも数値目標を必ず添える 出典: ISO/IEC/IEEE 29148:2018 §9.4「System Requirements」機能／非機能の分類定義 うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 5

システムアーキテクチャ設計 STEP 4 全体を要素に分解し、要求を構造に落とし込む なぜ大事か Why • • 要求のまま実装すると責務が混在し崩壊する 分解が粗いと変更時の影響範囲が読めない システム全体 何をするか What • • システムをサブシステム・要素に機能分解 各要素に要求を割り当て、責務境界を決める サブシステム A (認証 ) サブシステム B (業務ロジック ) サブシステム C (データ ) どうやるか How • • 「誰が何をするか」で線引きし構成図にする 重要な選定は ADR（決定記録）として残す 責務境界が明確 → 変更の影響範囲が要素内に収まる 出典: INCOSE SE Handbook 第5版（2023）第4章「System Architecture」 うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 6

トレーサビリティマトリクス STEP 5 要求→設計→実装→テストの連鎖を、双方向に追跡可能にする なぜ大事か Why • • 「この要求、実装済み？」に即答できないと監査で詰む 未実装・過剰実装（スコープ外実装）を検出できる 何をするか What • • 要求IDを設計・実装・テストに一貫して紐付け 前方／後方の双方向トレーサビリティを確保 要求ID 設計 実装 テスト REQ-01 ✓ ✓ ✓ REQ-02 ✓ ✓ △ REQ-03 ✓ ― ― REQ-03は未実装・REQ-02はテスト未完了 → 一目で判別できる どうやるか How • • 要求管理表に「設計」「実装」「テスト」列を追加 IDはコミット・Issue・テストコードに書き添える 個人開発の最小実践：コミットメッセージにREQ-IDを一言添えるだけでも機能する 出典: ISO/IEC/IEEE 29148:2018 §5.2.4「Requirements traceability」／INCOSE GtWR(2023) うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 7

検証（Verification）と妥当性確認（ Validation） STEP 6 「正しく作ったか」と「正しい物を作ったか」は別の問い Validation：ニーズを満たすか なぜ大事か Why • • 仕様通りでも「使えない」ものは作れてしまう 2つを混同すると片方の確認が抜け落ちる 何をするか What • • 検証＝仕様（要件）通りに作られたかを確認 妥当性確認＝本来のニーズを満たすかを確認 要件定義 受入テスト アーキテクチャ設計 統合・システムテスト Verification：仕様 通りか 実装 どうやるか How • • V字モデルで対応するテスト工程を先に決めておく 受入テストは必ずステークホルダー視点で行う 出典: ISO/IEC/IEEE 29148:2018 §5.2.6／INCOSE SE Handbook 第5版 V&Vプロセス定義 うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 8

まとめ：上流工程 品質ゲートチェックリスト STEP ゲート基準 NGサイン ① ステークホルダー 全利害関係者の成功定義を確認済み 「誰のため？」に即答できない ② 要求記述 EARS等の定型文で書かれている 「適切に」「なるべく」が残っている ③ 機能/非機能 非機能要件に数値目標がある 性能・セキュリティが未記載 ④ アーキテクチャ 要素ごとに責務が一意に決まる どの要素が担当か即答できない ⑤ トレーサビリティ 要求IDが設計・実装まで追える 「実装済みか」に即答できない ⑥ 検証/妥当性確認 V&V双方の計画が別々にある 受入テストが仕様確認のみで済んでいる うさうさ研修工房 ｜ Systems Engineering Complete Edition — 上流工程（商用レベル） 9

参照文献（国際規格・一次情報ベース） 01 02 03 04 05 06 ISO/IEC/IEEE 29148:2018. “Systems and software engineering — Life cycle processes — Requirements engineering.” INCOSE (2023). Systems Engineering Handbook, 5th Edition: A Guide for System Life Cycle Processes and Activities. INCOSE (2023). Guide to Writing Requirements (GtWR). SEBoK (2025). “ISO/IEC/IEEE 29148.” Guide to the Systems Engineering Body of Knowledge, v2.13. NASA (2017). NASA Systems Engineering Handbook（要求トレーサビリティ・V&Vプロセスの参照） Martin Fowler, bliki「Architecture Decision Record」（アーキテクチャ判断記録の実務手法） 本資料は国際規格・一次情報に基づき作成。実務適用時は最新版の規格原文をご確認ください。