Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
定義
サンエム標準は、本プロセスおよび成果物を以下のように定義する。
| プロセス名 | サービス構成図作成 |
|---|---|
| 成果物名 | サービス構成図 |
| 成果物テンプレート |
🚫
 Post not found |
| 成果物の統合先 | 要件定義書 |
| プロセス概要 | システムやサービスの構成要素（アクター、サーバ、アプリケーション、DB、ネットワーク、外部サービスなど）を視覚的に表現する |
| 目的(成果物の役割) | ・システム／サービス全体の構成を俯瞰できる ・関連システムや外部サービスとの接続関係を明示 ・設計・運用・保守の指針資料として利用 ・ステークホルダー間の共通認識と合意形成 |
| 実行タイミング | 要件定義の後期～基本設計前。 機能要件、非機能要件、外部インタフェースが概ね固まった段階 |
| 主な活動 | ・サービス／システム構成要素の洗い出し ・接続・依存関係の整理図面化（視覚化） |
| 文書の構造・形式 | ネットワーク図や、システム構成図などの図として表現 |
プロセスの位置
図解。
成果物の品質基準
業務一覧は、その役割を十分に達成するために、以下の品質基準を最低限満たすことが求められる。
いずれかが満たされていない場合、対応するリスクを抱える。すべての基準を満たすことが望ましい。
| 項目 | 基準 | 満たさない場合のリスク | 実装例 |
|---|---|---|---|
| 完全性 | 主要構成要素・外部サービスを漏れなく表現 | 運用・設計に支障 | サーバ、DB、アプリ、外部APIを網羅 |
| 明確性 | 役割・接続関係が一目で理解可能 | 誤解による手戻り | ブロック図＋矢印で依存関係表示 |
| 一貫性 | 用語・分類が統一されている | ステークホルダー間で認識齟齬 | 同一分類の要素は統一アイコン使用 |
| 変更容易性 | 修正・追加が容易 | 変更時に図が古くなり誤認 | Draw.io や Miro など GUI で表示、修正が可能なツールを使う |
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- 機能要件一覧
- 非機能要件一覧
- 制約条件一覧
- ToBe業務フロー
✅すること
| タスク名 | 目的 | タスク内容（詳細） |
|---|---|---|
| 構成要素洗い出し | サービス全体の部品を網羅 | サーバ、DB、アプリ、API、外部サービスを一覧化 |
| 役割・責任整理 | 各要素の機能と責任を明確化 | 各構成要素の役割、提供機能、運用責任を記載 |
| 接続・依存関係整理 | システム間の関係を明示 | ネットワーク接続、データ連携、外部依存関係を図示 |
| 図面化 | 関係者が理解できる形に整理 | ブロック図やレイヤ構造図を作成、色分けやアイコンで分類 |
| レビュー・承認 | 認識齟齬を防ぐ | 関係者レビューで不足や誤りを修正、承認を取得 |
🚫しないこと
| NG項目 | 説明 | なぜ問題か |
|---|---|---|
| 詳細設計まで踏み込む | OS設定やパラメータなど詳細情報を図に含める | 要件段階で過剰、変更時に手戻り発生 |
| 抽象化不足 | 部品や関係が多すぎて読めない | 共通理解ができずレビュー進まず |
| 役割不明確 | 各要素の機能・責任が不明 | 運用・保守で混乱、責任所在が不明 |
| レビュー省略 | 承認なしで作成 | 後工程で認識齟齬、手戻り発生 |
❤️🔥マインドセット（プロセスへの臨み方）
- 全体像を俯瞰して理解しやすく作る
- 詳細設計ではなく、構成と関係性を示す
- 関係者間の共通理解・合意を優先
- 将来変更・拡張を考慮して整理
😵💫よくある失敗例
- 構成要素の抜け → 運用時にサーバやサービスが不足
- 接続関係が不明確 → 開発・運用で通信トラブル
- 図が複雑すぎる → 誰も理解できずレビュー停滞
- 承認なし → 後工程で「認識違い」による手戻り発生