Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- 業務ヒアリング記録、観察メモ
- 業務マニュアル、業務手順書、帳票、画面サンプル
- 組織図、役割一覧
- 現行システム構成図、利用ログ
✅すること
| ステップ | タスク内容 | 目的 |
|---|---|---|
| ① 対象範囲の確認 | 対象とする業務領域・部門・プロセスを定義する | 分析の漏れ・過剰範囲を防ぐため |
| ② 関係者の特定 | 業務担当者、責任者、他部門連携先を洗い出す | 正確な情報源を確保し、ヒアリング効率を上げる |
| ③ 情報収集 | マニュアル、帳票、画面、報告書などを収集する | 現場の「実作業」を把握するための一次資料を得る |
| ④ ヒアリング実施 | 業務担当者に実際の手順、分岐条件、判断基準を聞き取る | 手順書にない「実態」と「例外処理」を把握する |
| ⑤ フローの暫定作成 | BPMNやスイムレーン形式で業務フローを可視化する | 業務の流れ、担当、情報を構造的に整理する |
| ⑥ 現場レビュー | 担当者と一緒にフローを確認・修正する | 認識齟齬を解消し、現場との共通理解を形成 |
| ⑦ 差分メモの整理 | ヒアリング中に得た課題・改善点を併記する | To-Be設計の前提情報として利用する |
🚫しないこと
| NG項目 | 説明 | なぜ問題か（リスク） |
|---|---|---|
| 机上でフローを描く | 現場確認せず、資料だけで作成 | 実態と乖離し、改善の根拠にならない |
| 一部の担当者だけにヒアリングする | 特定視点だけで業務を定義 | 他部門・連携業務が抜け、誤解が生じる |
| To-Beを意識して改変しながら描く | 現行分析の段階で未来像を混入 | 現状把握と課題特定が曖昧になる |
| 業務単位を曖昧にする | 「なんとなくの流れ」でフロー化 | 境界・責任が不明確になり、後工程に影響 |
| 記号・表記ルールを統一しない | 各担当が自由に描く | 可読性・再利用性が低下し、レビューが困難 |
| レビュー記録を残さない | 修正版だけが残り、経緯が不明 | 後からのトレーサビリティが失われる |
| 課題メモを別管理にする | フローと課題が分離 | To-Be設計時に改善根拠を辿れなくなる |
| 現場の反応を「口頭合意」で済ませる | 文書化せず了承だけ取る | 合意の証跡がなく、後で否認される恐れ |
❤️🔥マインドセット（プロセスへの臨み方）
- 「正しさより、まず事実を描く」
- 「課題を探すために、まず理解する」
- 「相手の言葉で業務を表現する（専門用語で置き換えない）」
- 「図を描くことが目的ではなく、共通認識を作ることが目的」
- 「自分の理解が正しいかどうかを、必ず現場に確認する」
😵💫よくある失敗例
- 「現場ヒアリングを十分に行わず机上でAs-Isを描いた」
- フローが実態と乖離し、顧客のユーザー部門から信頼を失う。
- 業務として妥当ではない ToBe のフローを描いてしまう。
- 「記号や表現に凡例などの説明がない」
- 後から見返したときに、フロー図だけでは説明不足になる。
- ただし、ステークホルダー間で共通認識があればよいので、過度な説明は不要。
- 「記号や表現が統一されていない」
- 読み手によって解釈が異なり、認識齟齬が生じる。