社内申請をどう見直す？ 既存ワークフローの棚卸し・再設計・システム移行の実務

数百人規模の新会社立ち上げでも使った、承認経路・組織マスター・代理承認・実務連携の整理法

社内の申請・承認フローは、会社の成長とともに少しずつ複雑になっていきます。

導入した当初はシンプルだった仕組みでも、組織変更や事業拡大を重ねるうちに、似たような申請が増え、承認経路が分かりにくくなり、承認後の実務処理が別のExcelやシステムへ分断されることがあります。

営業部門だけでも、値引き申請、キャンペーン利用申請、分割払い申請、特別対応申請などがあります。

人事領域では、入社、退職、異動、産休・育休、復職、傷病による欠勤・休業、資格試験や自己学習支援制度の利用申請。

IT・インフラ領域では、システムアカウントの発行・削除、パソコンやスマートフォンの貸与、権限変更、端末故障、過失報告。

コーポレート領域では、押印、電子契約、設備投資、購買、業務上の事故・過失に関する報告などがあります。

挙げ始めると、きりがありません。

しかも、これらが一つのワークフローシステムに統一されているとは限りません。

• 紙の申請書

• メール

• チャット

• Excel

• Microsoft Forms

• Power Automate

• kintone

• 社内ポータル

• 部門ごとに作られた独自フォーム

といった複数の手段が、社内に併存している会社も少なくありません。

このような状態で、ワークフローシステムの入れ替えや業務改善を進めるとき、つい次のように考えてしまいます。

しかし、既存の申請をそのまま新しいシステムへ再現するだけでは、現在抱えている複雑さや不合理まで引き継ぐことになります。

本当に必要なのは、システム移行の前に、現在の申請・承認フローを一度ほどいて整理することです。

• その手続きは、本当に承認が必要なのか

• 維持・廃止・統合・分割のどれにするのか

• 誰が、何を判断するのか

• どの役職まで決裁権限があるのか

• 承認後に、誰が実務を行うのか

• 承認者が不在のとき、誰が代行するのか

• 組織変更や上司変更を、どのマスターへ反映するのか

• 既存の自動化やデータ連携を、何として残すのか

• 誰が申請フォームを作り、誰が維持するのか

を整理したうえで、新しい仕組みへ移す必要があります。

私は最近、数百人規模の新会社立ち上げに関わり、社内の申請・承認フローを再設計する機会がありました。

その会社は、ゼロから自由に制度を作れる新会社ではありません。

数千人規模の企業から事業が切り出されたカーブアウト会社であり、旧会社で使われていた申請や自動化を引き継ぎながら、新しい親会社の規程やシステムへ合わせる必要がありました。

旧環境では、Microsoft 365を基盤として、Teams、Power Automate、Microsoft Forms、kintoneなどが使われていました。

一方、新しい環境では、Google Workspace、kickflow、Garoonなどが利用されていました。

この状況で難しかったのは、「どのツールが一番優れているか」を決めることではありません。

この方針を決めることでした。

これは新会社立ち上げの事例ですが、そこで必要になった考え方は、カーブアウトに限られるものではありません。

• 既存の承認フローが複雑化している

• 古いワークフローシステムを入れ替えたい

• メールやExcelによる申請を減らしたい

• 組織再編に合わせて承認経路を見直したい

• 承認後の実務処理まで一つにつなげたい

• 内部統制や監査への対応を強化したい

• 申請の乱立や属人化を解消したい

という既存企業でも、同じ論点が発生します。

本記事では、実際の会社や個人を特定できないよう内容を一般化したうえで、既存の申請・承認フローを棚卸しし、新しい仕組みへ再設計・移行するための方法を整理します。

このような状態なら、ワークフローを見直すタイミングかもしれない

ワークフローの見直しが必要なのは、システムが停止したときだけではありません。

例えば、次のような状態が増えてきた場合は、現在の仕組みを再点検する余地があります。

• 似た名前の申請が複数あり、どれを使えばよいか分からない

• 承認者が異動・退職しても、古いルートが残っている

• 承認後に、担当者が別のシステムへ手入力している

• 申請フォームと実務管理用のExcelやアプリが分かれている

• メールやチャットで例外対応が行われ、記録が残らない

• 承認者が休むと処理が止まる

• 申請の作成者しか設定内容を把握していない

• 権限規程とシステム上の承認経路が一致しているか分からない

• 同じ内容を複数のフォームへ入力している

• 新しいワークフロー製品を導入したが、旧運用が残り続けている

• 申請数が増えすぎて、全体像を誰も把握できていない

こうした問題は、単に新しいツールを導入するだけでは解決しません。

今ある手続きを棚卸しし、必要性、判断基準、承認者、後続処理、管理責任まで見直す必要があります。

申請フォームを作る前に、会社のルールを決める

ワークフローシステムを導入すると、申請フォームや承認経路を画面上で作れます。

そのため、最初に「どんな画面を作るか」「どのツールを使うか」から考えがちです。

しかし、実務では順番が逆です。

先に決めるべきなのは、次の内容です。

• その手続きは、本当に承認が必要なのか

• 誰に、何を判断してもらうのか

• どの役職まで決裁権限があるのか

• 承認後、誰が実務を行うのか

• 承認者が不在のとき、誰が代行するのか

• 組織変更や上司変更を、どのマスターへ反映するのか

• 申請を一つにまとめるのか、目的別に分けるのか

• 誰が申請フォームを作り、誰が維持するのか

権限規程や運用ルールが曖昧なままシステム化すると、曖昧な判断を高速で回す仕組みが出来上がります。

「なぜこの申請は課長承認で、別の申請は部長承認なのか」と聞かれたとき、説明できないのであれば、システム設定の前に権限規程を見直す必要があります。

ワークフローのリプレイスは、単なるシステム入れ替えではありません。

会社の権限、責任、実務の流れを整理し直す機会です。

すべてを「申請」にしない

会社内の手続きには、性質の異なるものが混在しています。

承認

実行前に、権限を持つ人の許可が必要なものです。

• 値引き

• 設備投資

• 押印

• 契約締結

• キャンペーンの例外利用

届出

原則として、発生した事実や変更内容を会社へ知らせるものです。

• 住所変更

• 連絡先変更

• 一部の休業・復職に関する届出

• 組織上必要な情報変更

報告

事故や問題の発生後に、事実・原因・対応を共有するものです。

• 端末故障報告

• 過失報告

• 業務事故報告

• セキュリティインシデント報告

作業依頼

承認後、または承認不要で、実務担当者に作業を依頼するものです。

• アカウント発行

• アカウント削除

• パソコン貸与

• 権限変更

• 契約書への押印・電子署名作業

これらをすべて「承認申請」として作ると、不要な承認が増えます。

本当に必要なのは承認ではなく、受付、記録、担当者への引き渡し、完了確認かもしれません。

既存システムのリプレイスでは、現在「申請」と呼ばれているものを、そのまま申請として移行しないことが重要です。

承認者だけを決めても、業務は完了しない

アカウント発行を例に考えます。

申請者がフォームを入力し、上司が承認しただけでは、アカウントは発行されません。

実際の流れは、次のようになります。

1. 申請者が必要なアカウントと権限を入力する

2. 所属長が業務上の必要性を承認する

3. 必要に応じて情報セキュリティやシステム管理者が確認する

4. IT担当者へ作業が割り当てられる

5. IT担当者がアカウントを発行する

6. 管理台帳を更新する

7. 申請者や利用者へ完了を通知する

8. 将来の削除・棚卸し対象として記録する

ワークフロー設計では、「誰が承認するか」に目が向きます。

しかし、承認後に何が起こるのかを設計しなければ、承認済みの案件が実務担当者へ届かず、処理が止まります。

営業の値引き申請でも同じです。

承認後に営業担当者が顧客へ提示するだけなのか。

営業企画や請求担当者が価格マスターを変更するのか。

契約書や見積書を差し替えるのか。

売上計上や請求条件へ反映する必要があるのか。

承認と実務処理は、一つの業務としてつなげて考える必要があります。

既存の仕組みを見直すときは、申請画面だけでなく、承認後に行われている手作業や別システムへの転記も確認します。

「一つにまとめる」ことが正解とは限らない

旧環境では、複数の営業申請を「特別対応申請」という一つのアプリへまとめていました。

値引き、分割払い、キャンペーン利用などを、申請種別の項目で切り替える形です。

一見すると、申請先が一つにまとまり、管理しやすく見えます。

ところが、実務では問題が起きました。

共通項目だけでは、値引き申請に必要な情報が足りません。

そこで、値引きの詳細を記録する別アプリを作り、承認用アプリと実務用アプリを分けることになりました。

結果として、

• 承認のために見るアプリ

• 実際の対応に必要な情報を見るアプリ

が分かれ、利用者は二つの情報を行き来する必要がありました。

今回の再設計では、原則として申請目的ごとに分ける方針を採りました。

例えば、

• 値引き申請

• キャンペーン利用申請

• 分割払い申請

を、それぞれ別の申請として設計します。

申請を分ければ、フォームや管理対象は増えます。

一方で、申請ごとに必要な項目、権限、承認条件、承認後の処理を適切に設計できます。

大切なのは、アプリやフォームの数を減らすことではありません。

この原則です。

既存申請の整理では、「申請数を減らすこと」を目的にしすぎない方がよいと考えています。

統合した結果、例外分岐や入力項目が増え、利用者が迷うのであれば、本来の目的を失っています。

承認者が一人しかいない設計は、いつか止まる

例えば「代表取締役が承認する」と決めたとします。

代表取締役が一人であれば、通常時は問題なく動きます。

しかし、その人が長期出張、療養、休暇などで対応できない場合、フロー全体が止まります。

そこで必要になるのが、次の設計です。

• 正承認者

• 代理承認者

• 代理できる期間

• 代理承認できる申請の範囲

• 一定時間・日数を超えた場合のエスカレーション

• 代理承認した事実の記録

• 組織変更時の更新方法

Power Automateでは、個人だけでなくMicrosoft 365グループへ承認を割り当て、グループ内の一人の回答を採用する構成も可能です。

kickflowには、期間を指定した代理承認を運用している公式事例があります。

重要なのは、ツールの機能名ではありません。

これを設計段階で確認することです。

既存ワークフローの見直しでは、「現在止まっていないから問題ない」と判断せず、長期休暇、異動、退職、組織変更が起きた場合にも動くかを確認します。

組織・上司マスターが間違っていれば、正しい承認者には届かない

「申請者の上司へ自動で回す」という設定は便利です。

しかし、この機能は人員・組織マスターが正しいことを前提にしています。

少なくとも、次を管理する必要があります。

• 社員・従業員の識別情報

• 所属組織

• 役職

• 上司

• 兼務

• 在籍状態

• 異動の適用日

• 承認権限

• 代理承認者

• 組織の有効期間

組織変更や上司変更が頻繁な会社では、フォーム作成よりもマスター更新の運用設計の方が重要です。

誰が、いつ、何を根拠に更新するのか。

将来日の組織変更を事前登録できるのか。

異動日前に申請された案件は、旧上司と新上司のどちらが承認するのか。

退職者や休職者が承認者として残っていないか。

ここが決まっていなければ、システム上で正しいルートを作っても、運用開始後に崩れます。

ツールの優劣ではなく、会社の基盤と統制で選ぶ

ワークフローを見直すときには、複数の選択肢があります。

• Microsoft Forms

• Microsoft Lists

• Power Automate

• Teams

• kintone

• kickflow

• Garoon

• Google Workspace

どの製品にも、向いている役割があります。

Microsoft 365中心で、比較的シンプルな承認を作る

Microsoft Forms、Microsoft Lists、Power Automate、Teamsなどを組み合わせる方法があります。

Power Automateの承認では、承認・却下、全員承認、最初の回答者などの承認方式があり、承認者はメール、Teams、承認センターなどから回答できます。

業務データと進行状況を同じアプリで管理する

kintoneでは、アプリ内のレコードに対して、ステータスと作業者を管理するプロセス管理を設定できます。

アプリ、レコード、フィールド単位の権限も設計できます。

申請後の実務や案件管理まで、同じデータを使いたい場合に候補になります。

多数の申請と組織変更を、専用基盤で統制する

数百人規模以上で、申請数が多く、組織変更、条件分岐、代理承認、監査への対応が重い場合は、kickflowのような専用ワークフロー製品が候補になります。

グループ会社や親会社の標準基盤へ合わせること自体が重要な場合もあります。

つまり、選定基準は「機能としてできるか」だけではありません。

• 会社の標準基盤

• 組織規模

• 申請数

• 承認経路の複雑さ

• マスター管理

• 監査・内部統制

• 外部システムとの連携

• 保守担当者

• 親会社・グループ会社との整合

• 将来の組織変更

• 運用を継続できる人員

を踏まえて判断します。

この順番が重要です。

ここから先は有料部分です