業務管理システムの設計で状態と遅延を分ける

記事の位置づけ：設計資料作成・未実装

企業・個人・内部構成が特定されないよう、内容を一般化して紹介しています。

背景と課題

業務タスク、承認、期限、通知を扱う仕組みの検討では、遅延を一つの状態として扱うと「承認待ちで遅延中」のような情報を表しにくくなります。

対応・整理した内容

過去のAWS上の業務管理構想では、処理状態と遅延の属性を分け、通知の再実行、変更履歴、監視、テストの方針を設計資料として整理しています。

記録で確認できる結果

参照した履歴では設計段階までで、実装・本番稼働・利用効果は確認できません。システム開発の完成実績には含めていません。

同じ課題に取り組む際の確認事項

誰が何を判断するかと、変更時に整合性を保つデータを先に決めます。自動化は正常系だけでなく、取り消し、再試行、重複、期限変更を含めて設計します。

対応手順と図解

同じ課題に対応するときの確認手順です。対象環境と権限を確認してから進めてください。

手順 1

現行業務の開始条件・判断・担当・完了条件を図にする。

手順 2

不要工程と例外処理を整理して改善後の流れを合意する。

手順 3

代表案件を流れに通してからシステム化範囲を決める。

完了の判断

最後の手順で期待する結果が得られたことを記録します。設定変更や処理の受付だけで完了とせず、利用者の操作と実際の結果を確認してください。うまく進まない場合は、停止した手順・発生時刻・対象・確認済みの結果を担当者に伝えます。