Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定)
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定)
🚧 SoE 向け(※追記予定)
個別業務詳細
業務フロー・例外・ルール・ロジックを明文化し、システム化後の業務を詳細に定義する成果物。後工程の迷い・手戻りを減らすための重要なドキュメントです。
🎯 概要
- 目的: 業務フロー(AsIs/ToBe)・例外・ルール・判断ロジックを明文化し、後工程の迷い・手戻りを減らす。
- スコープ(この成果物で扱うこと)
- AsIs(任意): 現状フローと課題(手作業・ボトルネック・属人化ポイント)
- ToBe(基本): システム化後の正常系フロー(必要に応じてスイムレーン等)
- 例外/代替フロー(重要なもの): 逸脱時の分岐、戻り、制約、運用対応
- ルール・ロジック: 業務ルール一覧、計算ロジック、承認ロジック(権限・期限・通知等)
- 入出力の概要: 主要な入力・出力(粒度は項目名レベルでなくてもよい)
- 境界・責任分担: 他ドメイン/他システム/他チームとのインターフェースと責務
📄 成果物の定義
- テンプレート: 📄
[テンプレ]個別業務詳細
🧪成果物のサンプル
# B001: 見積書作成
業務概要を簡潔に記述
**記述例:**
顧客からの問い合わせに基づき、商品・サービスの見積書を作成する
---
## 業務フロー
### AsIs業務フロー(現状)
任意項目。
現状の業務フローを記述する。システム化前の手作業や課題を明確にする。
**記述例:**
```mermaid
graph TD
A["顧客から問い合わせ"] --> B["営業担当者が<br/>商品情報を確認"]
B --> C["Excelで<br/>見積書を手作業作成"]
C --> D{"金額チェック"}
D -->|100万円以上| E["上長に<br/>メールで承認依頼"]
D -->|100万円未満| F["見積書を<br/>メールで顧客に送付"]
E --> G["上長が<br/>メールで承認"]
G --> F
F --> H["終了"]
style C fill:#fff3cd
style E fill:#fff3cd
```
**AsIs業務の課題:**
- Excelテンプレートの管理が煩雑で、バージョン違いが発生
- 商品マスタ情報を手動転記するため入力ミスが発生
- 承認フローがメールベースで、承認状況の把握が困難
- 過去の見積履歴の検索・参照が困難
---
### ToBe業務フロー
システム化後の業務フローを記述する。
Mermaid などのフローチャート形式でもよいし、作図ツールを用いたスイムレーン形式でもよい。
複数のアクターが関わる複雑な業務の場合は、スイムレーンを推奨する。
**記述例:**
```mermaid
graph TD
A["顧客から問い合わせ"] --> B["営業担当者が<br/>システムにログイン"]
B --> C["顧客情報を検索・選択"]
C --> D["商品マスタから<br/>商品を選択"]
D --> E["数量・単価を入力"]
E --> F["システムが<br/>自動計算・見積書生成"]
F --> G{"金額チェック"}
G -->|100万円以上| H["システムで<br/>承認申請"]
G -->|100万円未満| K["見積確定"]
H --> I["承認者がシステムで<br/>承認処理"]
I --> J{"承認結果"}
J -->|承認| K
J -->|却下| L["却下理由確認・<br/>内容修正"]
L --> E
K --> M["見積書PDF出力"]
M --> N["顧客にメール送付"]
N --> O["終了"]
style F fill:#e1f5e1
style H fill:#e1f5e1
style I fill:#e1f5e1
style M fill:#e1f5e1
```
**凡例:**
- 緑: システム処理
- 白: 手作業
**ToBe業務のポイント:**
- 商品マスタ連携により入力ミスを削減
- 金額計算を自動化し計算ミスを防止
- 承認フローをシステム化し進捗を可視化
- 見積履歴をデータベース管理し検索・参照を容易化
---
#### 例外フロー・代替フロー
通常フローから外れるケースや代替処理を記述する。
**例外フロー1: 在庫不足の場合**
```mermaid
graph TD
A["商品選択"] --> B{"在庫確認"}
B -->|在庫あり| C["見積作成続行"]
B -->|在庫不足| D["在庫不足アラート表示"]
D --> E{"対応選択"}
E -->|納期延長| F["納期調整後<br/>見積作成"]
E -->|代替品提案| G["代替商品を選択"]
E -->|取消| H["見積作成中止"]
F --> I["見積完成"]
G --> I
```
**例外フロー2: 特殊割引適用の場合**
```mermaid
graph TD
A["見積金額計算"] --> B{"特殊割引<br/>必要?"}
B -->|不要| C["通常フロー続行"]
B -->|必要| D["特殊割引申請"]
D --> E["営業部長承認"]
E --> F{"承認結果"}
F -->|承認| G["割引適用後<br/>見積作成"]
F -->|却下| H["通常価格で<br/>見積作成"]
```
---
## ルール・ロジック
ToBe業務フローで表現しきれない詳細なルールやロジックを記述する。
### 業務ルール
ToBe業務フローに現れる業務上の様々な規程・決まり事の一覧。
**記述例:**
| ルール名 | ルール内容 |
|----------|------------|
| 見積有効期限 | 見積書の有効期限は発行日から30日以内 |
| 見積承認権限 | 見積金額が100万円以上の場合、営業部長以上が承認できる |
| 割引上限 | 通常割引の上限は定価の15%まで可能 |
| 最低受注金額 | 1案件あたりの最低受注金額は10,000円 |
### 計算ロジック
**見積金額計算式:**
```
小計 = Σ(商品単価 × 数量)
消費税 = 小計 × 消費税率(10%)
合計金額 = 小計 + 消費税
※ 端数処理: 小計・消費税ともに円未満四捨五入
```
**割引適用ロジック:**
```
IF 顧客ランク = "A" THEN
割引率 = 10%
ELSE IF 顧客ランク = "B" THEN
割引率 = 5%
ELSE IF 顧客ランク = "C" THEN
割引率 = 3%
ELSE
割引率 = 0%
END IF
割引後単価 = 商品単価 × (1 - 割引率)
```
### 承認ロジック
**承認者決定ロジック:**
| 見積金額 | 承認者 | 備考 |
|----------|--------|------|
| 100万円未満 | 承認不要 | 営業担当者のみで確定可能 |
| 100万円以上<br/>500万円未満 | 営業部長 | 1段階承認 |
| 500万円以上<br/>1,000万円未満 | 営業部長<br/>→ 営業本部長 | 2段階承認 |
| 1,000万円以上 | 営業部長<br/>→ 営業本部長<br/>→ 取締役 | 3段階承認 |
**承認期限:**
- 各承認者は申請から3営業日以内に承認・却下を実施
- 期限超過の場合、システムから自動リマインド通知
--- ✅ 品質基準
| 区分 | 観点 | 内容 |
|---|---|---|
| 必須 | 対象業務(B***)の識別 | 成果物のタイトルに 業務ID(例: B001) と 業務名 が含まれている |
| 必須 | 業務概要の明確さ | 冒頭で「この業務で何をするか」が一文〜数文で説明されている |
| 必須 | ToBe業務フローの提示 | システム化後の ToBe業務フロー が、文章または図(Mermaid/作図)で示されている |
| 必須 | 重要分岐・例外の列挙 | 通常フローから外れる重要ケース(例外/代替)と、その扱いが少なくとも列挙されている |
| 必須 | ルール・ロジックの明文化 | ToBeの実現に必要な 業務ルール および必要に応じて 計算ロジック/承認ロジック が記述されている |
| 必須 | 入出力に関する振舞い定義 | システムと外部(利用者や対向システム、DBなど)の入出力が表現されている |
| 推奨 | AsIsの把握 | AsIs業務フロー(現状)と課題が、任意項目として記載されている(現状把握が必要な場合) |
| 推奨 | 境界・責任分担 | 他ドメイン/他システムとの境界と責務(誰が何を決め、どこまで実施するか)が説明されている |
| 推奨 | 用語・表現の一貫性 | 同一ドメイン内で用語や前提が矛盾しておらず、読み手が誤解しない |
👁️🗨️ レビュー観点
| 観点カテゴリ | 質問例 |
|---|---|
| 対象業務の特定 | タイトルの業務ID・業務名は、業務要件一覧や関係者の呼称と一致しているか |
| 業務概要 | この説明だけで「何をする業務か」が誤解なく伝わるか。前提(誰が、何のために)が抜けていないか |
| ToBe業務フロー | 主要アクターと流れが分かるか。入力→処理→出力のつながりが追えるか。図と説明に矛盾がないか |
| 例外・代替 | 実務で起きがちな例外(在庫不足、承認却下、期限超過など)が落ちていないか。例外時の戻り先・継続条件が明確か |
| ルール・ロジック | 計算式、権限、期限、承認条件、端数処理などが実装できる粒度か。曖昧語(適切に、必要に応じて等)が残っていないか |
| 整合性 | フローとルールが矛盾していないか。同じ条件が複数箇所で違う書かれ方をしていないか |
| 境界・責任分担 | 他ドメインや外部(他システム/他部門)に委ねる範囲が明確か。インターフェースの前提が不足していないか |
| 後工程への有用性 | この情報で、基本設計・詳細設計・テスト設計に進めるか。追加で確認が必要な論点が残っていないか |
📚 参考資料・関連リンク
🚧 追記予定
テンプレートサイト: 📄テンプレート集