🚧 個別業務詳細

個別業務詳細

業務フロー・例外・ルール・ロジックを明文化し、システム化後の業務を詳細に定義する成果物。後工程の迷い・手戻りを減らすための重要なドキュメントです。


🎯 概要

  • 目的: 業務フロー(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業務フロー 主要アクターと流れが分かるか。入力→処理→出力のつながりが追えるか。図と説明に矛盾がないか
例外・代替 実務で起きがちな例外(在庫不足、承認却下、期限超過など)が落ちていないか。例外時の戻り先・継続条件が明確か
ルール・ロジック 計算式、権限、期限、承認条件、端数処理などが実装できる粒度か。曖昧語(適切に、必要に応じて等)が残っていないか
整合性 フローとルールが矛盾していないか。同じ条件が複数箇所で違う書かれ方をしていないか
境界・責任分担 他ドメインや外部(他システム/他部門)に委ねる範囲が明確か。インターフェースの前提が不足していないか
後工程への有用性 この情報で、基本設計・詳細設計・テスト設計に進めるか。追加で確認が必要な論点が残っていないか

📚 参考資料・関連リンク


🚧 追記予定


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集