POA（プロセス指向アプローチ）とは？業務フロー可視化の重要性

システム設計のアプローチには、大きく分けて2つの流派があります。

DXや業務改革の文脈では、DX推進ガイドでも触れた通り、まず「現状の業務」を可視化する必要があるため、POAからのアプローチが必須となります。

SaaS全盛の現代において、スクラッチでシステムをゼロから作る機会は減りました。代わりに「既存のSaaSに合わせて業務を変える」ことが求められます。

しかし、自社の業務フローが可視化されていない（ブラックボックス化している）状態では、「どのSaaSが適合するか」も「どこをSaaSに合わせ、どこを残すべきか」も判断できません。

POAによって業務フローを可視化することは、システム導入の「地図」を手に入れることと同義です。

業務フロー図を描く際、国際標準規格であるBPMN (Business Process Model and Notation) の記法を参考にすることをお勧めしますが、厳密すぎると誰も読めなくなります。

以下の5つのステップで作成します。

1. 関係者・役割（レーン）の定義：
   「誰が」登場するかを洗い出し、縦軸（スイムレーン）を用意します。（例：営業、経理、上長、顧客）
2. ハッピーパス（正常系）の記述：
   一番頻度が高い「すべて上手くいった場合」の流れを一本線で描きます。これで骨格ができます。
3. 例外・分岐（条件）の追記：
   「在庫がなかったら？」「承認否認されたら？」という分岐（ひし形）を書き加えます。システム化の難所はここに潜みます。
4. 課題・KPIのマッピング：
   「ここで3日滞留する」「転記ミス多発」といった課題を吹き出しで追記します。
5. 合意形成と承認：
   関係者に見せ、「現実はこうなっていない」というフィードバックを反映し、As-Is（現状）を確定させます。

フロー図ができたら、以下の「ECRSの原則」で課題を洗い出します。

To-Be（理想）のフロー図は、そのままシステム要件定義書の骨子になります。

「この処理は手作業（Manual）」から「システム処理（Service Task）」に置き換える、というマークを付けるだけで、開発ベンダーへの指示書として機能します。

重要なのは、「全ての業務をシステム化しようとしない」ことです。年に数回しか発生しない例外処理は、高額なシステム改修をするより「マニュアル対応（人手）」として残した方がROI（費用対効果）が良い場合が多々あります。

フロー図作成における最大の失敗は「細かく書きすぎて更新されなくなる」ことです。

「マウスをクリックする」「画面を開く」といった操作レベルの手順は、フロー図ではなく「操作マニュアル」に書くべきです。フロー図はあくまで「業務の連なり（パス）」を表現するものです。

回避策：
「担当者が変わる」または「システムが変わる」タイミングでのみ、ボックス（処理）を分けるルールにしましょう。

POAプロジェクトを開始する前に確認すべき項目です。