はじめに
新システム導入プロジェクトでは、
要件定義、機能設計、テスト、移行計画などに多くの工数が割かれます。
一方で、軽視されがちだが、失敗要因になりやすいものがあります。
それが、
現行運用と新システム導入後の新運用を対比した運用フロー図です。
情シス・業務改善担当の立場で見ると、
このフロー図は「あると便利な資料」ではありません。
プロジェクトの成否を左右する設計成果物です。
1.システムは完成しても、運用は完成していない
よくある導入後の状況です。
- システムは要件通り
- テストも完了
- なのに現場が混乱している
原因の多くは、
運用がどう変わるのかが正しく共有されていないことです。
情シス視点では「効率化されている」運用でも、
現場から見ると、
- 作業が増えた
- 責任範囲が不明確
- システム外対応が増えた
と感じられるケースは珍しくありません。
この認識ズレを事前に炙り出す唯一の手段が、
新旧運用を対比した運用フロー図です。
2.業務改善の本質は「差分」を説明できるか
業務改善とは、
「新しい仕組みを入れること」ではありません。
- 何がなくなったのか
- 何が追加されたのか
- 誰の仕事がどう変わったのか
これを説明できて初めて、業務改善と言えます。
新運用だけを描いたフロー図では、
この差分が見えません。
現行運用と並べて可視化することで、
- 改善効果の妥当性
- 業務負荷の偏り
- 新たなボトルネック
が明確になります。
新旧運用フロー図は、
説明資料であると同時に、改善内容の自己チェックツールです。
3.情シスにとっての「守り」のドキュメント
運用フロー図は、攻め（改善）のためだけのものではありません。
情シスにとっては守りのドキュメントでもあります。
稼働後によく出る声です。
- 「そんな運用になるとは聞いていない」
- 「それはシステムの仕様が悪い」
このとき、
合意済みの新旧運用フロー図が存在するかどうかで状況は変わります。
- どこまでがシステム対応
- どこからが業務判断
- 誰が責任を持つ運用なのか
これを示せるフロー図は、
トラブル時の説明責任を支える重要な証跡になります。
4.よくある「ダメな運用フロー図」と「使える運用フロー図」
ダメな例①：新運用しか描かれていない
問題点
- 変更点が分からない
- 差分説明が口頭頼み
- レビューが形骸化する
良い例
- 現行／新運用を左右に並べる
- 変更・追加・廃止を色や記号で明示
- 凡例で差分の意味を定義
業務改善は差分を示して初めて成立する。
ダメな例②：誰の仕事か分からない
問題点
- スイムレーンが曖昧
- 「システム」「ユーザ」だけの区分
- 責任の所在が不明
良い例
- 部門・役割単位でレーンを分ける
- 人手作業とシステム処理を区別
- 責任移動ポイントを明示
「誰がやるか」を曖昧にしない。
ダメな例③：正常系しか存在しない
問題点
- エラー・差戻しが描かれていない
- 現場の実態と乖離する
良い例
- 例外処理・差戻しフローを明示
- システム外対応を正直に描く
- 手作業に戻るポイントを隠さない
業務改善の効果は例外処理で決まる。
ダメな例④：作って終わりのフロー図
問題点
- 更新されない
- 他ドキュメントと紐づかない
- 稼働後に参照されない
良い例
- 要件定義・運用手順書と連携
- 変更管理対象として扱う
- 教育・説明資料として再利用
フロー図は「運用資産」。
5.情シス／業務改善担当向けチェックリスト
フロー図完成時に、最低限これを確認します。
- 現行運用との差分は一目で分かるか
- 誰の業務が増減したかを説明できるか
- 例外処理が現場任せになっていないか
- 稼働後にこの図を使うシーンが想像できるか
すべてにYESと言えなければ、
そのフロー図はまだ設計途中です。
まとめ：フロー図は「説明資料」ではなく「設計成果物」
現行運用と新運用を対比した運用フロー図は、
- 業務改善の妥当性を検証する成果物
- 関係部門との合意形成ツール
- 稼働後トラブルを防ぐための保険
です。
情シス・業務改善担当こそ、
システム設計と同じ温度感で運用フロー図を作るべきです。
新システム導入を
「動いた」で終わらせず、
「定着した」と言える状態にすることが目標です。
新旧運用フロー図を、
単なる資料ではなく武器として使いましょう。