# 制約条件整理

**ステータス:** レビュー可能  
**工程:** 要件定義  
**種別:** 実践ガイド

---

## 📚 Get Started

- [これはなにか？](#)
- [おすすめ作図ツール](#)
- [おすすめMarkdownエディタ](#)

### 要件定義

#### 規格を知る
- [用語・概念の定義](#)
- [要件定義工程とは？](#)
- [要件の品質特性](#)
- [要件定義書とは？](#)
- [要件定義書の完成条件](#)
- [要件定義書の構成要素](#)
- [要件定義のプロセス](#)

#### 実践する
- [要件定義 実践ガイド](#)

### 基本設計

#### 規格を知る
- [基本設計工程とは？](#)
- [外部仕様と内部仕様の区別](#)
- [基本設計書とは？](#)
- [基本設計書の完成条件](#)
- [基本設計書の構成要素](#)

### Reference
- [サンエム標準ドキュメント](#)

---

# 🧭実践ガイド

## 🐾具体的なステップ

> 以下に示すステップは、定義ではなく、おすすめのサンプルです。
> 実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。

### 📘インプット

- 法令・規程・内部統制資料
- 契約書・SLA・既存ガイドライン
- To-Be業務フロー案
- 業務ルール定義書
- プロジェクト計画・リソース計画

### ✅すること

| ステップ | タスク | 目的 |
|---------|--------|------|
| ① 制約条件の収集 | 法令・規程・社内ルール・契約・リソースなどの情報収集 | 全ての制約を把握 |
| ② 制約条件の分類 | 制約条件を分類（法令、内部統制、技術、組織、コストなど） | 抜け漏れ防止とレビュー効率化 |
| ③ 判断基準の明確化 | 適用範囲・影響範囲・優先度を明記 | 設計・改善判断の基準を明確化 |
| ④ 関係者レビュー | 関係者レビュー・確認 | 制約条件が正確で、誤認されない状態を確保 |
| ⑤ 承認・確定 | 承認・登録 | 正式な前提条件としてプロジェクト文書に反映 |

### 🚫しないこと

| NG項目 | 説明 | なぜ問題か |
|--------|------|-----------|
| **漏れや抜けを放置** | 法令や内部規程の一部を無視 | 後工程で設計違反、監査指摘や法令違反 |
| **曖昧な記述** | 「必要に応じて」「可能な範囲で」など | 設計者が判断に迷い、実行可能性が不明確 |
| **影響範囲を記載しない** | 制約がどこに適用されるか不明 | 設計や運用で誤用・抜け漏れ発生 |
| **承認を取らない** | 関係部門レビューなし | 後工程で承認異議が出て手戻り発生 |
| **変更履歴管理を怠る** | 制約条件変更時の履歴なし | 過去の判断根拠が不明確、監査で不備扱い |

## ❤️‍🔥マインドセット（プロセスへの臨み方）

- 「制約条件は守るべき前提であり、改善の妥当性判断基準」
- 「曖昧な条件は設計リスクにつながる」
- 「漏れを防ぐために多方面の情報を確認する」
- 「承認は制約の正式化を意味する」
- 「変更や更新は必ず履歴管理する」

## 😵‍💫よくある失敗例

- **クリティカル（致命的）な制約条件を収集できていない**
  - 設計段階で法令違反や運用困難が発覚、手戻り増加
- **顧客のレビューを省略**
  - 制約誤認によるプロジェクト中の変更要求が頻発