コード不要の承認ワークフロー：基幹システムで紙の決裁から解放される実践ガイド

木曜日の夕方6時40分、大阪府東大阪市にある精密部品メーカーで、業務責任者の佐々木さんがまだデスクにいます。原材料の48万円の発注書が、火曜日から紙のフォルダに入ったまま動いていません。課長が取引先訪問で不在で、役員は課長の押印がないと何も判を押さないためです。月末決算まであと5日。最初の回覧票はコーヒーをこぼされて使い物にならなくなり、彼女は二度目を印刷し直しています。

この光景に見覚えがあるなら、問題はあなたの人員ではありません。プロセスの配管が古いままなのです。現代の基幹システムを使えば、承認の経路を画面の上で描き、実際の文書に紐づけ、あとはシステムが正しい人に届けてくれます。開発者は不要、押印の位置をまとめたスプレッドシートも不要です。

本ガイドでは、コード不要の承認ワークフローが実際に何をし、今日の正直な限界がどこにあるかを説明します。

承認の摩擦が見た目より高いコストを生む理由

紙の承認は安く見えます。理由は、コストが見えない場所に隠れているからです。それは大きく三つあります。

第一に、時間です。物理的な押印を待つ依頼は、拘束された資金と同じです。遅れた発注は生産ラインを止めてしまいます。承認が受信箱とデスクの上に散らばっていれば、誰もキューを見えないため、誰も管理できません。

第二に、監査リスクです。日本の内部統制を取り巻く環境は厳格になりました。上場企業はJ-SOXの下で運営され、未上場の企業でも金融機関や取引先からの目は年々厳しくなっています。誰が何を承認したかの証拠がキャビネットにしかなければ、その痕跡は壊れやすいものです。水害、引っ越し、あるいは担当者の退職ひとつで消えてしまいます。

第三に、マクロの圧力です。経済産業省の2018年の「2025年の崖」報告書は、日本のデジタル化の遅れがこのまま続けば、2025年以降毎年約12兆円のコストを経済に与えると警告しています（経済産業省、2018年）。中堅・中小企業が最も重い荷物を背負っています。日本の労働力の約70%を雇用しながら、大企業に比べてデジタル化で大きく立ち遅れています（経済産業省、Richard Katz氏『Japan Economy Watch』2024年経由）。

承認ワークフローを内蔵した基幹システムは、この三つすべてに立ち向かいます。キューが見えるようになります。痕跡が恒久的なものになります。経路のルールが、ベンダーへの依頼を出さずに変更できるデータになります。

「コード不要」の承認ワークフローとは実際何を指すのか

この言葉は使い古されています。ここでは具体的な中身を示します。画面のキャンバスにブロックを置きます。開始、一つ以上の承認ステップ、任意の条件チェック、そして終了です。それらを線でつなぎ、各ステップで誰が動くかを決めて、公開します。人々はそのワークフローに対して依頼を出します。

これは上司をCCに入れたメールの差し込みではありません。キャンバスの背後にある本物のエンジンが、各依頼を評価し、正しい次のステップを選び、正しい承認者を見つけ、すべての遷移を記録し、あなたが書いたルールに基づいて連鎖を進めるか止めます。

期待すべき構成要素

ステップ。 すべてのワークフローはステップの連続です。大半は承認です（誰かが承認、却下、差戻しを決める）。一部は条件です（システムが値をチェックして分岐を選ぶ）。実用的なシステムは、二人以上の承認者が同時に動く並列ステップもサポートします。

担当者。 優れたエンジンは、単一の人物を固定で指名することを強要しません。役割、役職、チーム、部門、または特定のユーザーで割り当てられ、それらを組み合わせられます。「経理部の財務ロール」は「山田さん」より長持ちします。人は役割を変えるからで、そのときルールが壊れるべきではありません。

動的な担当者。 最も強力なエンジンは、実行時に組織図から承認者を解決します。管理者を固定で書き込むのではなく、ステップを「依頼者の上司」に設定します。佐藤さんが依頼を出せば佐藤さんの上司へ。田中さんが依頼を出せば田中さんの上司へ。一つのワークフローが会社全体を支えます。

解決モードと条件。 あるステップに複数の承認者がいる場合、誰か一人が通せばよい、全員が通す必要がある、あるいは一定数以上が通す必要がある（例えば3人中2人）のいずれかに設定できます。役員級の経費には一定数が必要です。法務と財務の並列レビューには両方のクリアが必要です。条件こそが、ワークフローが単なる一本道でなくなる場所です。5万円以下は課長へ、5万円超は役員へ、資本的支出はCFOへ。そして期限のないステップは永遠に待ってしまうため、本格的なワークフローは、土日祝日を飛ばす営業日単位の期限オフセットを設定できます。

おもちゃと本物の道具を分ける五つの能力

多くのツールがフローチャートを描けます。しかし本物の内部統制プロセスを回せるものは少ないです。以下の五つがその境界線です。

1. 金額、カテゴリ、任意のフォーム項目による条件ルーティング

承認の壁として古典的なのが金額の閾値です。ある数字を下回れば承認者は一人で足ります。上回れば二人必要です。コード不要の条件ステップを使えば、ルールを一度書くだけで、エンジンが以後のすべての依頼を正しく回します。

演算子は馴染みのあるものです。等しい、等しくない、より大きい、以上、より小い、以下、含む、で始まる、で終わる。これらをANDまたはORで組み合わせます。実用的なルールはこう読めます。金額が10万円超 かつ カテゴリが資本的支出に等しい。両方が真のとき、依頼は重い経路を自動的にたどります。

2. 並列、逐次、一定数の承認

単一承認者のワークフローは、大半のやさしい依頼を処理します。残りには構造が必要です。逐次承認は、依頼を一人ずつ鎖で通します。課長、次に役員、次に社長。並列承認は二人以上の承認者を一度に動かし、独立していればより速いです。一定数承認は承認の必要数を満たすことを求め、一つの拒否で進行を止めない委員会の決定に合います。

一つ正直な注意があります。一部のエンジンでは、厳密な一人ずつの順序付けはまだ発展途上であり、逐次ステップが担当者をまとめて起動し、「最初の承認が勝つ」ルールで動くことがあります。大半の業務承認ではこれは正しく振る舞います。厳密な順序決裁が必要な場合は、挙動を確認してください。

3. 自己承認スキップと、ルールによる自動承認

二つのルールが、煩雑な作業の大部分を静かに取り除きます。第一は自己承認スキップです。依頼者と承認者が同一人物であれば、システムはそのステップを飛ばし、理由を記録します。これにより、役員が自分の依頼を承認するという不条理を防ぎ、管理者が自分に戻るはずの依頼を出したときも組織図が正直に保たれます。

第二はルールによる自動承認です。あるステップを、人を介さずに承認される条件として設定します。閾値を下回る小さな経費で、全項目が入力済みであれば、自動でクリアできます。自動承認は常にあなたが書いたルールで動くべきであり、決して推測で動くべきではありません。自動承認されたすべてのステップには、発火したルールと一致したデータの記録が残るべきです。

4. 全記録を残す管理者による上書き

承認は予定を外れることがあります。承認者が休暇中です。依頼が至急です。ステップが止まっています。管理者には、強制承認、強制却下、再割当、依頼のキャンセルの力が必要です。

上書きの危険は悪用です。防ぐのは透明性です。本格的なエンジンは、すべての上書きに対して監査エントリーを書きます。誰が、いつ、どんな行動をとったか、依頼がどの状態間を移動したか、そして理由です。記録には本来の承認者と介入した管理者の両方が示されるべきで、監査人が実際の経路を復元できるようにします。これはJ-SOXの下で最も重要です。「誰が、いつこれを承認したか」に防御可能な答えがなければなりません。

5. バージョン管理された定義により、変更が進行中の依頼を壊さない

ワークフローを公開します。3ヶ月後に、大きな金額向けのステップを追加する必要が出ました。稼働中の定義をその場で編集すれば、履歴が壊れます。古いルールの下で承認された依頼が、起きたことと一致しない定義を指すようになります。

解決策はバージョン管理です。各定義にはバージョンがあります。下書きを編集して公開します。新しい依頼は公開されたバージョンに対して走り、すでに進行中の依頼は開始時のバージョンを維持します。進行中のものを邪魔せずに、古いバージョンをアーカイブして新しいものを公開できます。これが、単なるワークフローツールとコンプライアンスツールの違いです。

実例：紙のフォルダから予測可能な経路へ

従業員約70名の精密部品メーカーを想像してください。多階層の部品表と製造オーダーを運用しているため、原材料の購買依頼は頻繁に、大きさも様々に届きます。デジタル化の前は、10万円を超えるすべての依頼が紙の経路を歩んでいました。課長、次に購買責任者、そして50万円超は代表取締役。10万円以下の依頼は建前上は課長だけで済みましたが、実務上誰もそれを信じず、すべてが最終決裁者に上がり、役員は毎週40件の判を押していました。

基幹システムのコード不要承認ワークフローで、彼らは一度プロセスを描き直します。条件ステップが金額項目をチェックします。10万円以下なら課長に届いて終わります。10万円超50万円以下なら購買責任者を追加します。50万円超なら代表取締役を最終ステップとして追加します。

自己承認スキップをオンにし、役員が自分が出した依頼を形式的に承認しなくて済むようにします。ワークフローを購買依頼に紐づけ、承認されればその決定が依頼に対して記録され、ダッシュボードで見えるようにします。各ステップに土日祝日を飛ばす3営業日の期限を設け、遅れたステップが見えるようにします。

結果は魔法ではありません。一度書かれたルールが毎回走る、ということです。役員が見るのは週40件ではなく8件ほどで、すべて閾値を本当に超えています。小さな依頼は数日ではなく数時間で片付きます。そして会計事務所から先四半期の74万円の発注を誰が承認したかと聞かれたとき、答えはタイムスタンプのついた記録であり、記憶ではありません。

正直な限界：今日まだ手作業またはロードマップのもの

信頼できるガイドは、ツールがまだできないことを明示します。三つの限界を率直に述べておきます。

製造と会計はまだ互いに自動連携しません。 会計側では、売上請求書、買掛請求書、経費精算は仕訳を自動で生成します。しかし製造の活動、つまり製造オーダーに記録された労務、スクラップ、材料消費は、それ自体で帳簿に計上されません。あなたの承認が製造オーダーを管理している場合、承認すればオーダーは解放されますが、原価側には手作業の仕訳が必要です。在庫評価も今日では手作業の仕訳です。

通知機能はまだ発展途上です。 このエンジンには管理者による上書きや代理承認が組み込まれていますが、止まったステップ向けの高度なプッシュ通知はロードマップ上にあります。今日は、電話へのプッシュ通知ではなく、ダッシュボードと期限の見える化に頼ることになります。

独立した改ざん不可能な監査ログテーブルはありません。 監査証跡はワークフロー履歴そのものの中に存在します。すべての遷移は、誰が動いたか、いつ、前の状態、新しい状態、そして理由を記録します。大半の内部統制の目的では、これこそが監査人が求める「誰が・いつ」の記録です。最も厳格な認証向けに、暗号学的に封印され別に保管されたログが必要な場合は、今日の機能ではなくロードマップ項目になります。

これらの限界に名前をつけることが、約束で買って監査の最中にギャップを発見することを避ける道です。

基幹システムとどうつながるのか

承認ワークフローは、ERPに後付けした単体のアプリでないときに最も強力になります。それらは基幹システムの中に属し、管理する実体そのものに紐づくべきです。

ワークフローが発注書、経費精算、売上見積書に紐づけば、承認は文書そのものに対するゲートになります。依頼はフォームのデータを運び、条件ステップはそれを読み、承認者は実際の記録を見て、承認されれば結果が元の実体に流れ戻ります。

これがKikan Systemの背後にある設計です。複式簿記の会計、ロット追跡、製造オーダーを扱うのと同じプラットフォームが、承認エンジンも動かしています。あなたは文書のコピーではなく、本物の文書に対してワークフローを構築します。アクセスはロールごとに与えられ、ログインはパスキーでパスワードレス、そして会社ごとにデータは完全に分離されています。

承認、会計、運用が一つのシステムに住めば、内部統制の物語に一貫性が生まれます。承認記録、仕訳、在庫移動が一つのプラットフォームの上にあり、一つのエンジンが書き、同じロールベースのアクセスの下にあります。監査人は五つではなく一つの場所を見れば済みます。

よくある質問

切替えはリスクがあります。いまのプロセスは遅くても分かっているので安全では？

段階的にリスクを下げてください。経費精算や閾値以下の購買依頼など、低リスクのワークフローを一つから始めます。紙の経路と並行して一ヶ月走らせます。チームが信頼したら、閾値を上げて紙をやめます。バージョン管理された定義により、進行中の依頼に触れずにルールを変更できるため、間違えた場合のコストは小さく済みます。Kikan System は最大2ユーザーまで無料、クレジットカード不要で始められるため、まずは経費ひとつで安全に試せます。

コストはいくらか、ROIはあるでしょうか？

直接のコストはプラットフォームです。間接のコストは、最初のワークフローを描き、チームを訓練する数時間です。戻りは、回復した時間、速い決算、回避した監査指摘として現れます。今月3日以上止まったままの依頼を数えてみてください。それぞれが、ワークフローが自動で動かしていたはずの経路です。基幹システムの中で承認を動かすことで、これらの遅れを構造的に減らせます。

自社特有のルールに合いますか？

あなたのルールが「この項目がこの値のとき、この順序でこれらの役割へ回す」と読めるなら、コード不要のワークフローで表現できます。構成要素は金額の閾値、ロールベースの割当、並列レビュー、委員会の一定数をカバーします。できないのは、システムが持たないデータに依存するルールを表現することです。経路の決定がERPの外にある項目に依存するなら、その項目をまずシステムに入れる必要があります。

重要なポイント： コード不要の承認ワークフローは、決定から人を排除するためのものではありません。それは、依頼と決定の間の経路から、紙と遅れと曖昧さを取り除くためのものです。一つのワークフローから始め、ルールをバージョン管理し、経路の運搬はシステムに任せて、判断は人が担ってください。

はじめに

フォルダを追い回すのをやめる準備ができたら、基幹システムは、実際の業務文書に紐づくビジュアルなワークフロービルダーを提供します。条件ルーティング、並列と一定数の承認、自己承認スキップ、ルールによる自動承認、全監査記録つきの管理者上書き、バージョン管理された定義を備えています。

2ユーザーまで無料、カード不要のプランから始めてください。経費または購買依頼に対して最初の承認ワークフローを構築し、それが自分自身で経路をたどるのを見て、そこからどこまで広げるかを決めてください。

Kikan Systemを始める、またはプランを比較する。

-> 関連：J-SOX対応の承認ワークフロー -> 関連：承認から仕訳を自動生成する