冒頭：出張承認はグループメッセージに頼り、承認担当者を探すのは聞くだけ
約200人の製造企業では、年明け最初の出張申請が次のように進められました。社員がグループで上司を@し、上司が「OK」と返信すると、社員はスクリーンショットを保存します。月末に経理が旅費精算を行う際、スクリーンショットを基に予算と照らし合わせます。年末に人事部が「社員の出張日数」を集計したところ、スクリーンショットが不完全だったり、部門間のデータが整合していないことが判明しました。
これは一部の事例ではありません。国内の多くの企業で、承認業務は次のように回っています：
- 人を探すのは聞くだけ：新入社員が入社後最初の一週間で最もよく尋ねるのは、「休暇は誰に申請すればいいのか？経費精算は誰が審査するのか？」です。
- グループメッセージを証憑代わりに：WeChatやDingTalkのグループで「@上司 承認済み」というメッセージを見れば、承認済みとみなされ、後から監査できません。
- 部門間のデータが一致しない：営業部は顧客訪問が承認済みだと考えているのに、マーケティング部は承認されていないと考えており、経理は営業部のスクリーンショットに基づいて支払いを行いました。
- 権限は口頭に頼る：あるマネジャーが退職した後、権限が回収されず、新しい担当者が元マネジャーが承認した契約書が誰の手にあるのか分からなくなってしまいました。
これらの問題の根本原因は、「承認業務がどれほど複雑か」ではなく、承認フローがシステムに落とし込まれていないことです。グループメッセージ、口頭、スクリーンショットはいずれも一時的な手段であり、必要なのは構造化され、記録が残り、追跡可能な媒体です。OAシステム（オフィス自動化システム）は、このプロセスを構造化することで、「誰が、どの案件を、いつ、誰に、どのようなルールで承認し、承認後にデータがどのように蓄積されるか」を一つの承認フローにまとめます。
01 業務をどう分解するか：承認フローの三層構造
承認業務を分解すると、実は三層に分かれます：
- 案件層：社員が「出張、休暇、経費精算、契約、印鑑使用、購買」など具体的な案件を申請し、それぞれに金額、日数、添付ファイル、関連する業務対象（出張申請なら販売注文、経費精算なら請求書）が含まれます。
- プロセス層：案件は一つのノードから次のノードへと流れ、各ノードの承認担当者は部門・レベル・金額・品目ごとに動的に算出され、固定ではありません。
- データ層：承認が通った場合でも却下された場合でも、データは業務システム（人事、経理、営業、契約データベース）へ戻され、承認フロー内に留まるべきではありません。
三層の関係は次の通りです：案件が入口、プロセスが幹、データが出口です。OAシステムを構築する際に、プロセスだけを作ってデータ出口を無視すれば、承認フローは孤立した島となり、案件だけ作ってプロセスを作らなければ「フォーム入力システム」に退化してしまいます。
02 どう設計するか：動的ノード、権限マトリックス、記録残存の三つセット
ノード設計：承認担当者は固定ではない
多くのOAシステムでは、最初から承認担当者を固定してしまいます。「出張申請 → 部門マネジャー → 人事 → 総経理」といった具合です。その結果、部門マネジャーが異動したり、人事が総務部に統合されたり、総経理が外出したりすると、システム全体が混乱してしまいます。
正しいやり方は：承認担当者はルールに基づいて動的に算出されます。ルールの次元は通常四つあります：
- 部門次元：申請者の所属部門に対応する当該部門の現任責任者（組織図に基づきリアルタイムで確認）。
- レベル次元：金額、日数、契約金額が異なる区間に応じて、異なる承認階層が設定されます。
- 役割次元：契約金額が50万を超える場合、法務部門の介入が必須；海外出張の場合、安全・コンプライアンス上の要件により共同署名が必要。
- 代理人次元：承認担当者が休暇や出張の際には、自動的に代理人に権限が移行し、代理人は組織関係または人事によって設定されます。
これら四つの次元を組み合わせて「ルール式」を作成し、プロセスエンジンがルールに基づいてリアルタイムでノードを算出し、承認担当者の氏名を固定しないようにします。異動や組織調整があっても、プロセステンプレートを変更する必要はありません。
権限設計：メニュー、データ、フィールドの三段階
権限とは「システムに入れるかどうか」ではなく、三段階の制御を指します：
- メニュー級：このモジュールを見られるかどうか（一般社員は「組織構造管理」を見ることはできません）。
- データ級：このデータを見られるかどうか（営業第一部は自部門の社員の経費精算しか見られず、営業第二部のものは見えません）。
- フィールド級：このデータの特定のフィールドを見られるかどうか（一般の承認担当者は申請者の給与欄を見ることはできませんが、人事は見ることができます）。
三段階の権限を細分化することで、OAシステムは複雑な組織構造に対応できます：グループ―支社―部門―チームといった階層があり、跨階層のデータは「自分自身のラインを見られる＋自分がそのラインの責任者である」という二重のルールで並行して制御されます。
記録残存設計：承認ログの七要素
毎回の承認操作には必ず七要素を記録しなければなりません：
- 操作者：誰がクリックしたか。
- 操作時間：秒単位まで正確。
- 操作動作：承認、却下、転送、加署、撤回。
- 操作意見：却下意見は必ず記入、承認は空欄可。
- ノード位置：現在のプロセスのどのノードか。
- 関連データのスナップショット：承認時の業務対象のフィールド値（金額、添付ファイル）はそのまま保存され、後から業務対象を変更しても承認記録は変わらないようになっています。
- デバイスとIPの痕跡：どのデバイス、どのIPから発信されたか（コンプライアンス監査用）。
この七要素のうち一つでも欠けると、監査時に必ずもめ事が起こります。よくある失敗は「操作意見は空欄可」ということで、却下理由がなくなり、社員が何度も再提出し、承認フローが長引くという事態です。
03 どう開発するか：プロセスエンジン、フォームエンジン、メッセージバスの三つセット
OA開発の核心は三つのエンジンであり、N個のページではありません：
プロセスエンジン
プロセスエンジンはコードを書かず、設定だけでプロセスを実行できます。サポートすべき機能は次の通りです：
- 直列、並列、共同署名、あるいは署名の種類：四つの基本フローがあり、正規採用申請は直列（人事→主管→CEO）、購買の共同署名は並列（財務と購買主管が同時に審査）。
- 条件分岐：金額、品目、申請者のレベルに応じて分流し、5,000元以下は簡易フロー、5,000～50,000元は部門と財務の二重審査、5万以上はCEOの追加審査。
- 戻しと却下：申請者への戻し、任意のノードへの戻し、直前のノードへの戻し、これら三種類の却下をすべてサポートします。
- 追加署名と転送署名：承認者はタスクを同僚に転送（転送署名）したり、別の同僚を一緒に審査に加えたり（追加署名）することができます。
- 取り消しと廃棄：申請者は未承認の案件を取り消すことができ、管理者は異常な案件を廃棄できます。
プロセスエンジンが完成した後、新たにコードを書かずに済むタイプの承認を追加することができ、図を描き、フォームを設定するだけでシステムを稼働させることができます。これがOAが「承認の外部委託開発」と異なる点です。
フォームエンジン
フォームは「ゼロコーディング設計」でなければなりません：フィールドタイプ（テキスト、数字、日付、添付ファイル、関連業務オブジェクト）、検証ルール、必須・任意選択、表示・非表示の条件など、すべてを視覚的にドラッグ＆ドロップで設定できます。これにより、人事部が経費精算の項目を調整したり、営業部が契約書の項目を追加したりしても、IT部門のスケジュール調整が不要になります。
フォームエンジンは以下をサポートしなければなりません：
- フィールドレベルの権限：同一のフォームでも、異なる承認者が見られるフィールドは異なります（通常の承認者は申請者の携帯電話番号を見ることはできません）。
- フィールド連動：「契約タイプ＝サービス契約」を選択すると、サービス契約特有の項目が自動で展開されます。
- データの書き戻し：承認後、業務システム（契約ステータス、人事勤怠、財務伝票）へ自動的に書き戻されます。
メッセージバス
承認または却下の場合、申請者および関連する業務システム（人事、財務、営業）に即時通知が届きます。メッセージバスによる一括配信：
- システム内通知：サイト内メッセージに未処理案件を追加します。
- IM通知：企業微信、DingTalk、FeishuのWebhookを通じて、対応するグループや個人へプッシュ通知を送信します。
- メールおよびSMS：重要な節目におけるバックアップ通知（契約承認、海外出張など）。
- 業務システムからの通知：承認後、業務システムの未処理案件にメッセージを記録します（財務は経費精算の未処理案件、人事は入社手続きの未処理案件を受領）。
メッセージバスは“飾り”ではなく、承認フローの“循環路”です――通知がなければ、申請者は次の段階で誰に相談すればよいのか分からず、全体のプロセスが滞ってしまいます。
締めくくり：導入の順序、リスク、指標
OAシステムの導入は三段階に分かれます：
- 第1期（1か月）：休暇、出張、経費精算という頻度の高い三つの業務を導入し、全員をカバーします。まずはWeChatグループ内の承認をシステムに移行します。たとえこの三つだけでも、部門間のデータが即座に整合します。
- 第2期（2～3か月）：契約、印鑑使用、購買、支払いといった中程度の頻度の四つの業務を導入し、財務システムと連携します。この段階では、承認後のデータ書き戻し（契約承認後に自動で契約ライブラリへアーカイブ）を実現します。
- 第3期（必要に応じて）：評価、昇進、正規雇用、採用、離職など、人事全般のプロセスを導入します。この段階は人事主導となり、人事マスターデータとの連携を図ります。
よくあるリスク：
- ルールが過度に柔軟：承認フローの設定が自由すぎると、次に誰が担当するのか誰も分からなくなります。原則として：フローテンプレートは30個を超えないようにすること、それ以上になると制御不能になります。
- 代理人の設定漏れ：承認者が出張中に代理人を設定していない場合、フローが3日間停滞し、誰も審査しません。システムは「フローが24時間以上停止している」ことを検知して自動的に警報を発します。
- データの書き戻し不足：承認は完了したのに、人事システムでは勤怠が更新されず、財務システムでは伝票が作成されていません。書き戻しには「二重チェック」が必要で、OA側で書き込んだ後、業務システムのインターフェースを積極的に呼び出して受領確認を行います。
検証項目の達成度を示す指標：
- 承認の平均所要時間：導入前はグループ内で3日間かけて回っていたものが、導入後はシステム上で1日以内に完結するようになります。
- 部門間データの一貫性：人事、財務、営業の三つの基準による照合誤差率が80％以上低下しました。
- 監査の追跡可能性：過去の承認履歴をランダムに20件抽出し、七要素が揃っている割合が100％に達しました。
承認をWeChatグループからシステムへ移行するのは、「システム化」のためではなく、「人を探す」という行為を、人への依存からルールへの依存へと変えるためです。一度ルールを定めてしまえば、誰が退職しようと組織がどう変わろうとも、承認フローは乱れません。