---
title: ①システム工学完全版_上流工程
tags:  #システム工学  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/9J29ZYK1ER.jpg?width=480
description: ①システム工学完全版_上流工程 by Yukiko
published: July 03, 26
canonical: https://www.docswell.com/s/yukiko_it/53JJXE-2026-07-03-181328
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/9J29ZYK1ER.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/DEY4RGN4JM.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJNYDGX678.jpg)

ステークホルダー分析とニーズ抽出
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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE9PGW8RJ3.jpg)

要求記述： 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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE8DVN8GED.jpg)

機能要件と非機能要件を分離する
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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LELM5PRX7R.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JMY34R3JW.jpg)

トレーサビリティマトリクス
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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PJR9QWRR79.jpg)

検証（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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PEXQ5PRYJX.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/3EK96DR4ED.jpg)

参照文献（国際規格・一次情報ベース）
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」（アーキテクチャ判断記録の実務手法）
本資料は国際規格・一次情報に基づき作成。実務適用時は最新版の規格原文をご確認ください。