Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- As-Is業務フローおよび課題一覧
- 改善目標・ビジネス目標
- ステークホルダーからの要望
- 制約条件（コスト、期間、人員、法規制など）
- システム化方針・非機能要件の方向性
✅すること
| ステップ | タスク内容 | 目的 |
|---|---|---|
| ① 目標の確認 | As-Is課題と改善目標（プロジェクト目的、顧客要望）を明確化する | To-Be設計の方向性を定めるため |
| ② 制約条件の整理 | コスト・期間・組織構造・人員・システム制約を整理 | 実現可能な設計範囲を定義するため |
| ③ 変更方針の設定 | 業務削減・自動化・標準化・権限見直しなどの施策方針を決定 | どの方向で業務を変えるか明確にする |
| ④ To-Beフローの初期案作成 | BPMNまたはスイムレーン図で、新業務の流れ・責任・入出力を定義 | 新業務の姿を可視化するため |
| ⑤ 効果・影響の整理 | 各改善の効果（効率化・品質向上）と影響（負荷増・リスク）を整理 | 合理的な判断を下すための根拠作り |
| ⑥ 関係者レビュー | 関係部門（業務・IT・経営）のレビューを実施 | 部門間の整合と合意を得るため |
🚫しないこと
| NG項目 | 説明 | なぜ問題か（リスク） |
|---|---|---|
| 理想論で描く | 実行不能な完璧業務像を追求 | 現場が実現できず、定着しない |
| As-Isを参照せずに描く | 現状把握を飛ばしてTo-Be作成 | 根拠がなく、説得力がない |
| システム機能中心に設計する | 業務目的よりもツール機能に依存 | システム導入＝業務改善と誤認される |
| 制約条件を無視する | 組織構造や法令を考慮しない | 実施段階で頓挫・抵抗を受ける |
| 関係者レビューを省略 | 一部の判断でフローを確定 | 部門間不一致・後の抵抗を招く |
| 目的を記載しない | なぜその改善を行うかが曖昧 | 投資判断・優先順位が立てられない |
❤️🔥マインドセット（プロセスへの臨み方）
- 「To-Beは“理想”ではなく、“実現可能なベスト”」
- 「課題を解決するために業務を設計する」
- 「システム化は手段であり、目的は業務改善」
- 「すべての関係者にとって“理解できる図”を描く」
- 「現場の実行者と一緒に未来像を作る」
- 「根拠をセットで残す」
😵💫よくある失敗例
- As-Isをそのまま転写して終わる
- 改善点や新システム導入の意義が反映されず、後工程で不満が爆発。
- As-Is課題が曖昧なままTo-Beを作成
- 改善目的が不明確で、関係者の納得が得られない
- 業務担当を巻き込まずに設計
- 現場の抵抗を受け、実装後に運用されない
- システム中心でTo-Beを定義
- 業務改革が形骸化し、システム負担だけ増える
- 制約、実現可能性を無視
- 実現性がなく、プロジェクト計画が崩壊する
- 責任や役割が曖昧なまま残る
- 誰が承認するのか不明、誰が処理するのか不明 → 運用混乱。