POAとは？プロセス指向アプローチの意味・DOAとの違い・進め方

業務システム設計で用いるPOA（Process-Oriented Approach / プロセス指向アプローチ）は、データベースや画面ではなく、仕事の流れを起点にシステムを考える方法です。「何を入力するか」を決める前に、「何をきっかけに始まり、誰が判断し、どの状態になれば完了するか」を整理します。

業務フロー図は、POAを進めるときの代表的な成果物です。図を使って、業務上の判断とシステムに任せる処理を分け、要件を関係者の間で確認できる状態にします。

なお、POAは分野によって別の意味でも使われる略語で、この記事では業務システム設計のProcess-Oriented Approachを扱います。

POAと対比されることが多いのが、DOA（Data-Oriented Approach / データ指向アプローチ）です。POAは処理の流れ、DOAはデータの意味と関係を起点にします。

表は横にスクロールできます →

同じ見積承認の業務でも、二つの視点では確認することが異なります。

• POAの視点：見積依頼の受付→見積作成→承認→送付という処理の順序、各工程の担当と判断、入力不足や原価未確定による差し戻しを確認します。
• DOAの視点：顧客・案件・見積の関係、同じ顧客や案件を何で識別するか、修正した見積の版をどう持つかを確認します。

この記事では、両者を組み合わせて要件を整理する方法を説明します。例えば業務の流れから確認する場合は、各工程で入力・出力するデータを、共通で使うデータと照らし合わせます。組み合わせるだけで再利用性や整合性が保たれるわけではないため、データの定義、識別の方法、更新の責任、履歴の持ち方もあわせて決めます。

実際の作業では、POAとDOAのどちらかを選ぶのではなく、業務の流れとデータの整合性を、どの順序で確認するかを決めておきます。

POAは、複数の担当者やシステムをまたぐ業務を整理するときに役立ちます。担当と判断条件があいまいな業務では、画面や機能を考える前に流れを確認しておくと、後の手戻りを減らせます。

「POAだけでは不足する場面」では、POAによる業務整理に加えて、データモデル、権限、履歴、システム間連携を別に設計します。業務フローだけを要件書にすると、同じ顧客や案件が部署ごとに別の定義で保存されるおそれがあります。

ここでは、POAの考え方を業務整理に使う場合の進め方を示します。最初から理想の流れを描かず、As-Is（現在の業務）を確認してからTo-Be（変更後の業務）へ進みます。

1. 対象範囲を一文で決める
   例として「顧客から見積依頼を受け、承認済みの見積書を送付するまで」のように、開始と終了を明記します。
2. 担当者と利用システムを並べる
   営業、上長、管理部、顧客などの役割と、メール、表計算、CRMなどの利用先を確認します。
3. 通常の流れを業務単位で描く
   「ファイルを開く」ではなく、「見積を作成する」「金額を承認する」のように、結果が残る単位で記載します。
4. 判断条件と例外を加える
   金額による承認者の違い、差し戻し、入力不足、担当者不在、システム停止時の代替手順を確認します。
5. 入力・出力・記録先を紐づける
   各工程で受け取る情報、作成する情報、更新する台帳を記録します。ここからDOAによるデータ整理へつなげます。
6. 待ち時間と手戻りを確認する
   処理時間に加えて、承認待ち、確認の往復、重複入力も記録し、変更する順序を決めます。

フロー図の記法にはBPMNを利用できます。ただし、最初のヒアリングでは記号の正確さより、担当者が自分の業務として確認できる粒度を優先します。関係者の認識がそろった後に、必要な範囲を正式な記法へ整えます。

見積承認を例に、業務フローからシステム要件を作る流れを確認します。整理した承認フローを既存システムのまま速くする方法は、申請・承認をチャットにつなぐ設計で扱っています。

表は横にスクロールできます →

開始条件、判断、例外、完了条件を明記すると、処理の順序に加えて、権限、通知、履歴、再実行などの要件も見えてきます。

一方で、顧客や商品の定義、同一データの判定、保存期間は業務フローだけでは決まりません。これらはDOA、セキュリティ、法務・会計上の要件と合わせて設計します。

発生頻度が低く、担当者が安全に判断できる例外まで無理に自動化する必要はありません。システムに任せる範囲と、人が判断して記録する範囲を分けます。

1. 現行業務をそのままシステム化する
   現在の手順には、過去のシステム制約や不要になった承認が含まれる場合があります。To-Beを作る前に、廃止できる工程を確認します。
2. 操作手順まで一枚の図へ入れる
   「画面を開く」「ボタンを押す」まで書くと全体を追えません。フロー図には業務のまとまりを書き、操作方法はマニュアルへ分けます。
3. 通常の流れだけで要件を決める
   差し戻し、取消、重複申請、担当者不在を後から加えると、権限やデータ状態を作り直すことになります。
4. POAだけでデータ設計を終える
   工程ごとに項目を追加すると、顧客や案件の定義が部門ごとに分かれます。共通データはDOAの視点で整理します。
5. 更新責任者を決めない
   組織やツールが変われば業務フローも変わります。変更を承認する人、更新する人、確認日を成果物に記載します。

初稿はIT部門だけで完成させず、実際に処理を行う担当者と確認します。正式な図に整える前の段階で、漏れている判断や例外を見つけておくと、後から作り直す手間を減らせます。

業務フローの作成を始める前に、対象範囲と確認方法をそろえます。