Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- ToBe業務フロー図
- 改善テーマ／KPI・業務目標
- 制約条件一覧（法令・内部統制・システム制約）
- 現行運用マニュアル・例外対応記録
✅すること
| ステップ | タスク | 目的 |
|---|---|---|
| ① ルール洗い出し | ToBeフローから判断・条件分岐を洗い出す | システム化・標準化が必要な判断箇所を明確化 |
| ② ルールの形式化 | 各判断に関する条件・基準・責任を明文化 | 誰が・いつ・何を根拠に判断するかを定義 |
| ③ 例外ケースの形式化 | 例外処理・制約条件を整理 | 想定外ケースへの対応を事前に決める |
| ④ 関係者レビュー | 関係者（現場・法務・システム）とレビュー | 業務的・技術的に実行可能かを確認 |
🚫しないこと
| NG項目 | 説明 | なぜ問題か |
|---|---|---|
| 属人的な判断を前提にする | 「経験者が判断」「担当者の裁量で可」など | 標準化・引継ぎが困難、システム要件化できない |
| 根拠のないルール定義 | 「今までそうしているから」だけで設定 | 法令違反・内部統制違反のリスク |
| フローと整合しないルール定義 | 実際の手順と異なる条件設定 | システム動作と現場運用が乖離 |
| 条件を曖昧に記述 | 「原則」「基本的には」などの表現 | 判断がブレて再作業や手戻りが発生 |
| 例外対応を省略 | 「レアケースだから」と未定義にする | 想定外時に業務停止・トラブルを誘発 |
❤️🔥マインドセット（プロセスへの臨み方）
- 「ルールは現場を縛るためではなく、迷いを減らすために作る」
- 「人ではなく仕組みで品質を守る」
- 「判断の透明性＝説明責任の基盤」
- 「例外は例外として明文化し、再現可能にする」
- 「ルールは守らせるものではなく、合意で運用するもの」
😵💫よくある失敗例
- 曖昧な条件を放置
- 例：「基本的に承認」
- システム実装時に分岐条件が定義できず、開発工数が増大。
- 顧客レビューを省略
- 業務が回らず、顧客満足度の低下、変更リスクの増大
- 法務・統制ルールを反映しない
- 内部統制・監査で指摘を受ける
- システム中心でTo-Beを定義
- 業務改革が形骸化し、システム負担だけ増える
- 実現可能性を無視
- 実現性がなく、プロジェクト計画が崩壊する