思考実験で承認フローの要件定義してみた（お腹いっぱい編）
はじめに
最近、EpsoCRM で承認フローを作る話が出てきて、
「ちょっと要件整理してみるか」と軽い気持ちで始めたら、
途中でお腹いっぱいになったので、
そのまま“思考実験ログ”として残しておくことにした。
実際に作るかどうかはさておき、
現場アーキテクトの脳内メモとしては十分役に立つはず。
1. 承認対象（申請種別）
まずは「何を承認するのか？」の棚卸し。
最初に思いついたのはこのあたり。
- 経費申請（交通費含む）
- 休暇申請
- 勤怠修正申告
で、考えてるうちに「ありがちなの」も追加。
- 備品購入申請
- 支払依頼（請求書処理）
- 稟議申請
- 契約締結・捺印申請
- マスタ登録申請（顧客・仕入先・品名など）
- アカウント発行申請
- 在宅勤務申請
- 残業申請
- 休日出勤申請
気づいたら、
会社で承認が必要なものは全部ここに入るという結論に。
2. 承認経路（ワークフロー）の考え方
ここが一番“現場の泥”が出るところ。
● 経路はテンプレート化できる
- 個人用
- チーム用
- 全社共通
● 経路編集の自由度はオプション化
- 完全固定
- テンプレートから微調整OK
- フル編集OK
現場の人間関係や文化によって、
「どこまで自由にさせるか」が変わるので、
ここは柔軟にしておく。
3. 承認ステップの仕様
承認フローの“箱”の部分。
- 承認
- 否認
- 差し戻し
- 代理承認
- 自動承認（条件付き）
差し戻しは理由必須。
差し戻し先は申請者 or 任意ステップ。
並列承認（全員 or 誰か1人）も必要。
4. 承認者まわりの要件
ここは今回の思考実験で一番「おっ」と思ったところ。
● 承認者は“途中の未承認ステップ”も確認できる
- 自分の前後のステップがどうなってるか見える
- ただし編集は不可
● 必要なら“飛ばして承認”もできる
- 部長が不在で止まってる
- 緊急で進めたい
- 代理承認の権限があれば可能
5. 再申請って必要？
考えてみたら、意外と必要だった。
- 否認された
- 差し戻し後に内容を大幅修正
- 承認期限切れ
- 経路を変えたい
再申請は「前回申請をコピーして新規扱い」で良さそう。
6. EpsoCRM に落とすとこうなる
- 申請は target_type + target_id で疎結合
- 経路テンプレートを選ぶだけ
- 承認画面は
- 申請内容
- 添付
- ステップ全体図
- コメント履歴
が見える
EpsoCRM の構造と相性は悪くない。
7. ここまで書いてお腹いっぱい
最初は「軽く整理するか」くらいの気持ちだったのに、
気づいたら 承認フローの要件定義がほぼ全部出てきてしまった。
実際に作るかどうかはさておき、
思考実験としては十分に面白かったのでブログに残しておく。
おわりに
承認フローって、
「申請データ」と「承認の箱」を分けて考えると
一気に整理される。
今回はその“箱”の部分だけを思考実験で書き出したけど、
これだけでも現場の混沌はかなり浄化される。
次は気が向いたら、
DB構造編とか
UI編とか
承認エンジン編
に進むかもしれないし、進まないかもしれない。
今日はここまで。
なんか最終盤で省略されてたから 参考までに
＊＊＊＊＊
1. 承認者の対象範囲（あなたが言ったやつを正式要件化）
● 1-1. **承認者は「自分に回ってきたステップ」だけでなく、
経路途中の未承認ステップも確認できること**
- 承認者は、現在の自分のステップだけでなく
前後のステップの承認状況を閲覧可能 - ただし編集は不可（監査的にNG）
● 1-2. 経路途中の未承認ステップを“飛ばして承認”できる機能（任意）
- 例：部長が不在で止まっている → 課長が代理で承認
- これを許可するかどうかは
- 申請種別
- チーム
- 役職
で制御できる
2. 承認アクションの種類
● 2-1. 基本アクション
- 承認
- 否認
- 差し戻し
- 代理承認
- 自動承認（条件付き）
● 2-2. 差し戻しの仕様
- 差し戻し理由は必須
- 差し戻し先は
- 申請者
- 任意のステップ
のどちらか選択可能
- 差し戻し後の再承認フローは
- 元の経路を再利用
- 再申請扱いで経路を再選択
のどちらかを選択可能（設定）
3. 再申請の要件（あなたが言った“これ要る？”の正式化）
● 3-1. 再申請が必要なケース
- 否認された場合
- 差し戻し後、申請内容を大幅に修正した場合
- 承認期限切れ（タイムアウト）
- 経路変更が必要な場合（承認者変更など）
● 3-2. 再申請の仕様
- 元の申請データをコピーして新規申請として扱う
- 承認履歴は「前回申請」として紐づけて保持
- 再申請時に経路テンプレートを再選択可能
- 再申請理由の入力必須（設定でON/OFF）
4. 承認画面の要件
● 4-1. 承認者が見るべき情報
- 申請内容（経費・休暇など）
- 添付ファイル（PDF・画像）
- 承認ステップの全体図
- 現在のステップ
- 過去の承認履歴
- コメント履歴
- 差し戻し理由（あれば）
● 4-2. 承認操作
- ワンクリック承認
- コメント付き承認
- 差し戻し
- 否認
- 代理承認（権限がある場合）
5. 承認ステップの制御
● 5-1. 直列・並列
- 直列承認
- 並列承認（複数人が同時に承認）
- 並列のうち「全員承認」 or 「誰か1人承認」も設定可能
● 5-2. 条件分岐
- 金額による承認者切替
- 所属による承認者切替
- 申請種別による分岐
- 特例ルート（緊急時）
6. 代理承認の要件
● 6-1. 代理承認の種類
- 自動代理（長期不在設定）
- 手動代理（上長が設定）
- 一時代理（期間限定）
● 6-2. 代理承認のログ
- 誰が誰の代理で承認したか
- 代理理由（任意）
- 代理承認の可否は申請種別ごとに設定可能
7. 承認後の処理
● 7-1. 承認完了後
- 申請データをロック
- 会計・勤怠システムへ連携（任意）
- 申請者へ通知
- 承認完了のPDF生成（任意）
● 7-2. 否認後
- 申請は終了
- 再申請可能（設定でON/OFF）
8. 監査・ログ要件
- 誰がいつ承認したか
- 誰が経路を変更したか
- 差し戻し理由
- 否認理由
- 代理承認の記録
- 再申請の履歴
- 経路テンプレートの変更履歴
🎯 これで「承認まわりだけの要件定義」はほぼフル装備
あなたが言った
承認者は途中の未承認も確認して承認できる
再申請って要るのかｗ
この2つを軸に、
承認フローの“本丸”だけを独立させて完全に整理した版。
次のステップ（選んで）
- 申請まわり（入力・添付・申請ロジック）の要件も同じ粒度で作る？
- DB構造（route_template / route_instance / approval_step）に落とす？
- EpsoCRM の UI モックを作る？
どれ行く？＊＊＊＊＊
因みに 他のAIも中々なんだけど微妙にしりきれとんぼ
＊＊＊＊
ブログネタ：承認フロー設計の深淵（要件定義編）
1. 承認対象の拡大（「ありがちなの」追加）
- 経費・交通費申請（JANなし・金額揺れの伏魔殿）
- 休暇・勤怠修正（労基署への最終防衛ライン）
- 【追加】備品購入・支払依頼（見積書PDFという名の「非構造化データ」との戦い）
- 【追加】捺印・契約締結申請（「誰がハンコ押すんだっけ？」という権限の迷路）
- 【追加】マスタ登録申請（品名・顧客コードを勝手に作らせないための防壁）
2. 承認経路の「雛形」と「自由度」の二律背反
- 雛形保存機能: 「いつものメンバー」を毎回選ばせない。
- 権限のオプション化:
- 「ガチガチ固定（役職で自動決定）」
- 「雛形から微調整OK（部長が不在だから代理を入れる）」
- 「フルオープン（現場の自治に任せる）」
- これを選択可能にするのは、「現場の人間関係をシステムが規定しすぎない」ための優しさ。
3. チーム vs 全社のレイヤー構造
- 所属（チーム）単位: 「課内の飲み会精算」レベルの小回り。
- 全社共通: 「全社員共通の有給申請」といった大動脈。
- この出し分けができることで、「自分のチームに関係ない雛形が100個並んでて探せない」というUIの死を回避。
4. EpsoCRM 特化型の実装（ここが一次情報！）
- 所属チーム ＋ 経路一覧からの選択:
- 「今、俺はどのチームの人間として申請しているか？」というコンテキストの保持。
- 「承認種別」の後付け命名（メタデータ化）:
- システム側は「承認エンジン」に徹し、ラベル（経費、休暇、特例）は外から注入する。これで「新しく承認が必要な業務が増えるたびにコードを書く」という悪夢を終わらせる。
🔥 結びの「お腹いっぱい」ポイント（ブログの引き）
- 「申請の中身（経費データ）」と「承認の箱（フロー）」を切り離す。
- だからこそ、後から「承認種別」を命名できる。
- NIコラボの「毎回設定」の苦しみを、この「雛形×権限オプション」で昇華する。
まぁ、経費（交通費費）のワークフローはつくってみようとは思うけど
コメント