POAとは？プロセス指向アプローチの意味・DOAとの違い・進め方
まず押さえたいことPOA（Process-Oriented Approach）とは、業務の手順や処理の流れを起点に、システムの機能や運用方法を設計するプロセス指向アプローチです。
この記事の要点
POAには複数の意味があります。この記事で扱うのは、業務プロセスからシステムを考えるProcess-Oriented Approachです。業務の開始条件、担当者、判断、入力・出力、例外を可視化し、必要な機能へ落とし込みます。現在のシステム開発ではPOAだけで完結させず、データを起点に考えるDOAと組み合わせることが重要です。
この記事でわかること
- POAとは：この記事で扱う意味
- POAとDOAの違い：どちらか一方を選ぶものではない
- POAが向いている場面と注意が必要な場面
- POAの進め方：現状の業務フローを6段階で整理する
- 具体例：見積承認の流れをシステム要件へ変える
- POAで起こりやすい5つの失敗
- POAを始める前のチェックリスト
POAとは：この記事で扱う意味
POAは文脈によって意味が変わる略語です。この記事では、業務システム設計で用いられるProcess-Oriented Approach（プロセス指向アプローチ）を扱います。
| 表記 | 意味 | 主な分野 |
|---|---|---|
| Process-Oriented Approach | プロセス指向アプローチ | 業務分析・システム設計 |
| Proof of Authority | 権威証明 | ブロックチェーン |
| Portable Object Adapter | ポータブル・オブジェクト・アダプタ | CORBA・分散システム |
Process-Oriented Approachの起点は、データベースや画面ではなく、仕事の流れです。「何を入力するか」だけでなく、「何をきっかけに始まり、誰が判断し、どの状態になれば完了するか」を先に整理します。
業務フロー図はPOAを進めるための代表的な成果物ですが、図を描くこと自体が目的ではありません。業務上の判断とシステムに任せる処理を分け、要件を関係者間で確認できる状態にすることが目的です。
POAとDOAの違い：どちらか一方を選ぶものではない
POAと対比されることが多いのが、DOA（Data-Oriented Approach／データ指向アプローチ）です。POAは処理の流れ、DOAはデータの意味と関係を起点にします。
| 比較軸 | POA | DOA |
|---|---|---|
| 設計の起点 | 業務の手順・処理・判断 | データの意味・関係・ライフサイクル |
| 最初の問い | 誰が、いつ、何をするか | 何を記録し、どのように共有するか |
| 主な成果物 | 業務フロー、処理一覧、例外一覧 | ER図、データ定義、状態遷移 |
| 確認しやすいこと | 担当、順序、待ち時間、判断の分岐 | 重複、整合性、再利用、システム間連携 |
| 単独で進める場合の注意 | 部門ごとにデータ定義が分かれやすい | 現場の手順や例外が要件から抜けやすい |
現在のシステム開発では、両者を組み合わせて進めます。最初にPOAで業務の流れと判断を確認し、各工程で扱う顧客、案件、申請、請求などのデータをDOAの視点で整理します。業務が変わってもデータを再利用でき、同時に現場の手順から離れすぎない設計になります。
「POAかDOAか」という選択ではなく、業務の流れとデータの整合性をどの順序で確認するかが重要です。
POAが向いている場面と注意が必要な場面
POAは、複数の担当者やシステムをまたぐ業務を整理するときに有効です。特に、担当と判断条件が曖昧な業務では、画面や機能を考える前に流れを確認する価値があります。
POAが向いている場面
- ・承認や引き継ぎが複数部署にまたがる
- ・同じ情報を複数の台帳へ転記している
- ・担当者によって処理方法が異なる
- ・SaaS導入前に現行業務を整理したい
- ・自動化する範囲と人に残す判断を分けたい
POAだけでは不足する場面
- ・全社共通の顧客・商品マスタを設計する
- ・複数システム間でデータを再利用する
- ・データ品質や保持期間を統一する
- ・会計や監査で厳密な整合性が必要になる
- ・リアルタイム連携や分析基盤を設計する
右側の場面では、POAによる業務整理に加えて、データモデル、権限、履歴、システム間連携を別途設計します。業務フローだけを要件書にすると、同じ顧客や案件が部署ごとに別の定義で保存される可能性があります。
POAの進め方：現状の業務フローを6段階で整理する
ここでは、POAの考え方を業務整理に使う場合の進め方を示します。最初から理想の流れを描かず、As-Is（現在の業務）を確認してからTo-Be（変更後の業務）へ進みます。
- 対象範囲を一文で決める
例として「顧客から見積依頼を受け、承認済みの見積書を送付するまで」のように、開始と終了を明記します。 - 担当者と利用システムを並べる
営業、上長、管理部、顧客などの役割と、メール、表計算、CRMなどの利用先を確認します。 - 通常の流れを業務単位で描く
「ファイルを開く」ではなく、「見積を作成する」「金額を承認する」のように、結果が残る単位で記載します。 - 判断条件と例外を加える
金額による承認者の違い、差し戻し、入力不足、担当者不在、システム停止時の代替手順を確認します。 - 入力・出力・記録先を紐づける
各工程で受け取る情報、作成する情報、更新する台帳を記録します。ここからDOAによるデータ整理へつなげます。 - 待ち時間と手戻りを確認する
処理時間だけでなく、承認待ち、確認の往復、重複入力を記録し、変更する順序を決めます。
フロー図の記法にはBPMNを利用できます。ただし、最初のヒアリングでは記号の正確さより、担当者が自分の業務として確認できる粒度を優先します。関係者の認識が揃った後に、必要な範囲を正式な記法へ整えます。
具体例：見積承認の流れをシステム要件へ変える
見積承認を例に、業務フローからシステム要件を作る流れを確認します。整理した承認フローを既存システムのまま速くする方法は、申請・承認をチャットにつなぐ設計で扱っています。
| 確認項目 | As-Isで確認すること | 要件への落とし込み |
|---|---|---|
| 開始条件 | 顧客から見積依頼を受ける | 案件に見積依頼を登録できる |
| 判断 | 金額や値引率により承認者が変わる | 条件に応じて承認経路を切り替える |
| 例外 | 入力不足や原価未確定で差し戻す | 差し戻し理由と再申請履歴を残す |
| 完了条件 | 承認済み見積書を顧客へ送付する | 承認日時、版、送付担当を記録する |
| データ | 顧客、案件、商品、価格、承認者 | 既存マスタとの重複と更新責任を確認する |
POAから得られるのは、処理順だけではありません。開始条件、判断、例外、完了条件を明記すると、権限、通知、履歴、再実行などの要件が見えてきます。
一方で、顧客や商品の定義、同一データの判定、保存期間は業務フローだけでは決まりません。これらはDOA、セキュリティ、法務・会計上の要件と合わせて設計します。
発生頻度が低く、担当者が安全に判断できる例外まで無理に自動化する必要はありません。システムに任せる範囲と、人が判断して記録する範囲を分けます。
POAで起こりやすい5つの失敗
- 現行業務をそのままシステム化する
現在の手順には、過去のシステム制約や不要になった承認が含まれる場合があります。To-Beを作る前に、廃止できる工程を確認します。 - 操作手順まで一枚の図へ入れる
「画面を開く」「ボタンを押す」まで書くと全体を追えません。フロー図は業務のまとまり、操作方法はマニュアルへ分けます。 - 通常の流れだけで要件を決める
差し戻し、取消、重複申請、担当者不在を後から加えると、権限やデータ状態を作り直すことになります。 - POAだけでデータ設計を終える
工程ごとに項目を追加すると、顧客や案件の定義が部門ごとに分かれます。共通データはDOAの視点で整理します。 - 更新責任者を決めない
組織やツールが変われば業務フローも変わります。変更を承認する人、更新する人、確認日を成果物に記載します。
初稿はIT部門だけで完成させず、実際に処理を行う担当者と確認します。正式な図に整える前に、漏れている判断や例外を見つけることが重要です。
POAを始める前のチェックリスト
業務フローの作成を始める前に、対象範囲と確認方法を揃えます。
押さえておきたい点
自社の状況を確認する
- □ 開始条件と完了条件を一文で説明できる
- □ 実際に処理する担当者が確認に参加する
- □ As-IsとTo-Beを別の図として管理する
- □ 通常の流れと例外を分けて確認する
- □ 各工程の入力、出力、記録先を確認する
- □ 承認条件と権限の違いを確認する
- □ 待ち時間、手戻り、重複入力を記録する
- □ 廃止できる工程を自動化対象から外す
- □ 共通データはDOAの視点で別途整理する
- □ フローの更新責任者と確認日を決める
よくある質問
Q. POAとは何の略ですか？
この記事で扱うPOAはProcess-Oriented Approachの略で、日本語ではプロセス指向アプローチまたはプロセス中心アプローチと呼ばれます。業務の手順や処理の流れからシステムを設計する考え方です。
Q. POAとDOAの違いは何ですか？
POAは業務の処理や判断の流れを起点にし、DOAはデータの意味や関係を起点にします。現在のシステム開発では、POAで業務を確認し、DOAで共通データと整合性を設計するなど、両方を組み合わせます。
Q. POAとBPMNの違いは何ですか？
POAはシステム設計の考え方で、BPMNは業務プロセスを図で表すための標準記法です。POAを進める際にBPMNを利用できますが、両者は同じものではありません。
Q. POAは現在のシステム開発でも使えますか？
使えます。SaaS導入、ワークフロー開発、業務自動化などで、担当、判断、例外を確認する際に有効です。ただし、データモデル、権限、履歴、システム連携は別の視点でも設計する必要があります。
Q. ブロックチェーンのPoAとは同じ意味ですか？
異なります。ブロックチェーンのPoAはProof of Authorityの略です。この記事では、業務分析とシステム設計におけるProcess-Oriented Approachを扱っています。
Q. 業務フロー図はどの粒度で書けばよいですか？
最初は、担当者、開始条件、判断、入力・出力、完了条件が分かる業務単位で記載します。画面操作やクリック手順はフロー図へ詰め込まず、操作マニュアルへ分けます。
ITの判断と実行を、経営のそばに。
外部IT責任者として、優先順位の整理から実装・運用まで支援します。
中小企業のための実践的DX推進ガイド：戦略立案から実行まで
この分野の全体像と判断の順序をまとめた記事です。