モデリング講座2 “良い業務フローと悪い業務フロー（前編）”

モデリング講座 第二弾です。

前回の話を受け、今回は"良い業務フローと悪い業務フロー"の違いについて話してみます。

業務フローを記述するシーン

私たちは様々なシーンで業務フローを記述します。さて、どんな時にどんな目的で、誰が、誰に対して業務フローを記述するのでしょうか？主な目的に「誰が」、「誰に」を加え、下表のように整理してみました。

(表1 業務フローを記述する目的)

(※1) ISO: International Organization for Standardization
様々な分野の国際規格を策定する非政府組織

(※2) SLA: Service Level Agreement
サービスの提供事業者と発注者間で結ばれるサービスの定義、範囲、内容、達成目標等に関する合意内容

業務フローが求められるわけ

そもそもなぜ、業務フローを記述しなければならないのでしょうか？記述対象の「業務」には下記のような特徴があります。皆さんにも心当たりはありませんか？

• 誰も全体像を把握できていない
• 詳細は担当者しかわからない
• ITで実行されている業務の内容はわからない
• 他の担当者のやり方はわからない
• 言葉が部署・部門で統一されていない
• 新しい業務を行う場合、変更を行う場合の影響範囲が見えない
• 新しい業務手順を現場にうまく伝えることができない

カタチのない「業務」は人により捉え方が様々です。「業務」に対する認識が一致していなければ、前述した目的を達成することはできません。　そこで、捉えどころのない「業務」を明確にするために業務フローを作成するわけです。業務フロー記述の目的は下記の通りです。

• 関係者が業務の全体像や具体的手順を共有する
• ＩＴで実行されている業務内容も理解する
• 担当者や部門をまたがって共通認識を得る、
• 説明や業務移管を効率的に行えるようにする
• 業務変更の影響範囲を見えるようにする

「敵（目的）を知り己（業務）を知れば百戦危うからず」というわけです。

良い業務フロー、悪い業務フロー

ただし、単発の狭い範囲の業務改善ならいざ知らず、目的を違わず、素早く達成するためには良い業務フローを記述する必要があります。さて、良い業務フローとはどのような業務フローでしょうか？良い業務フローは下記のような状態である必要があります。

• 客観的： 誰が見ても同じ解釈で理解できること
• 一貫している： 記述方法や表現方法が一貫していること
• 連続している： 業務の始まりから終わりまで情報のバトンがつながっていること
• 記述が完全： 対象領域が全てカバーされていること
• 具体的： 実用可能なレベルまで具体的であること
• 保守性： 継続的な維持管理が容易であること

なんだかコムズカシイですか？しかし、上記のような状態ではない「悪い」業務フローで、例えばITの業務要件定義を行ったらどうなるでしょうか？

• 主観的： ベンダーが異なる認識でシステム要件を定義してしまった
• 一貫していない： 異なる様式で記述してあった箇所の開発が漏れていた
• 連続していない： 請求と入金を紐づける情報がなく、入金の消込に大量の人員が必要になった。
• 不完全： 最終テストで返品業務を提示していないことに気が付いた
• 抽象的： 業務フローを見たが内容がわからず、再度ヒアリングする必要がでてきた

よく聞くバグだらけ、納期遅延で、機能足らずのIT開発のデスマーチが発生します。上記は私が見聞きした本当にあった話です。ご愁傷様。。。

さて、後編では良い業務フローを書くためのコツをいくつかご紹介します。