第一回では、購買サイクルを依頼から支払いまでの七つのステーションとして整理し、簡単な演習を提案しました。直近で支払った仕入先の請求書を十件取り出し、それぞれを依頼、承認、発注書、受入記録までさかのぼってたどる、というものです。この演習で最初に探した文書が購買依頼でした。依頼のない請求書があったなら、ここから始めます。その後に続くすべての文書には、さかのぼって指し示す対象が必要だからです。

今回は最初の二つのステーションをまとめて扱います。ニーズを記録する依頼と、会社がそれにお金を使うと決める承認です。事務的に聞こえて、実は業務そのものに関わる問いに答えます。誰が何を、どの限度まで承認するのか、その人が不在のときは誰が代わりに承認するのか、そしてニーズが待てないときはどうなるのか。

購買依頼：その後のすべてがぶら下がる文書

購買依頼は、仕事の上に積み増される書類ではありません。ニーズが電話の中の一言であることをやめ、番号の付いた記録になる瞬間です。依頼がなければ、発注書には指し示す先がなく、現場で受け取る担当者は何が届くのかを知らず、経理担当者はなぜ支払うのかを知りません。よい依頼は五つの基本的な問いに答えます。

  • 誰が必要としているのか？ 依頼者の氏名と役職であって、メッセージを取り次いだ人の名前ではありません。現場のエンジニア、生産ラインの監督者、ホテルの保守責任者などです。
  • 正確に何が必要なのか？ 品目、その仕様、数量、単位。「配管資材」といった一行は基準になりません。後で届いたものをそれと照合できる人がいないからです。
  • どのプロジェクト、現場、物件のためか？ この項目こそが、費用を本来あるべき場所へ振り向けます。どのプロジェクトにも属さない購買は、誰も追跡できない一般経費になってしまいます。
  • なぜか？ 一行で十分です。数量明細書の一項目、停止した機械の部品、来シーズンの消耗品など。その一行が、承認者が確認のために電話をかける手間を省きます。
  • いつまでに？ すべての依頼に「緊急」と書くのではなく、実際に必要な日付です。購買部門はその日付を仕入先の納期と比較します。

依頼には、概算でもよいので見積金額も必要です。金額で承認するには金額が必要だからです。依頼者が知らなければ、依頼が承認に回る前に購買部門が記入します。その後、依頼には番号が付与され、承認、発注書、受入記録、仕入先の請求書と、後続のすべての文書がシステム上でその番号に紐づきます。これは作業指示書と、費用がぶら下がる依頼番号で説明したのと同じ考え方です。すべての文書が同じ番号に紐づいていれば、チェーンのどこから始めても、誰にも尋ねずにその起点にたどり着けます。

承認マトリクス：金額だけでは足りない

承認マトリクスとは、一つの問いに答える表です。この依頼に「はい」と言えるのは誰か？ 最も単純なマトリクスは、金額という一つの軸で作られます。ある限度までは部門長が承認し、それを超えれば財務部長、さらにその上はオーナーです。金額は有効な軸ですが、購買の種類によって承認者が答える問いが変わります。

  • 在庫資材。 現場向けの鉄筋やセメント、生産ライン向けの原材料、ホテル向けの清掃用品。ここでの問いは、本当にこの数量が必要か、そして購入する前に、それがすでに別の倉庫や別の現場にないか、です。だからこそ、承認者が承認の時点でその品目の在庫を確認できると役立ちます。
  • サービスと下請業者。 エレベーターの保守、下請業者による断熱工事、清掃契約。ここでは価格よりも範囲が重要です。正確に何が行われ、それが完了したことをどう判断するのか。そのため依頼には、異なる二つの問いに対応する承認者が必要です。技術的な知識を持つ人が範囲を承認し、マトリクスがその金額に指定する人が支出を承認します。
  • 固定資産。 機器、車両、発電機、生産ライン用の機械。これは何年も続く約束であり、運用費と保守費を伴うため、金額だけで求められるよりも上のレベルに回すのが妥当な場合があります。
  • 緊急購買。 これには独自のルートがあり、後で説明します。緊急事態を想定していないマトリクスは、最初の緊急事態が起きたときに迂回されてしまうからです。

数値そのもの、つまり依頼があるレベルから次のレベルへ移る限度額は、オーナー、または取締役会がある場合は取締役会が決めます。それは会社の規模、利益率、そしてオーナーが自分で直接確認したい範囲を反映するからです。すべての会社に合う一般的に正しい限度額はなく、他社から借りてきた限度額は、厳しすぎて仕事を止めてしまうか、緩すぎて何も統制できないかのどちらかになりかねません。

どの種類にも当てはまるルールが二つあります。第一に、誰も自分自身の依頼を承認しません。承認者本人の依頼は一つ上のレベルに回ります。第二に、承認権限は人ではなく役職に属します。そのため現場責任者が別の現場に異動すれば、誰かが変更を思い出すのを待つのではなく、権限は新しい役職とともに移ります。この原則は権限：データがファイルを出たら誰が何を見るのかで詳しく説明しました。承認マトリクスは、同じ原則をお金に適用したものです。

では、承認者が出張中のときは誰が承認するのか？ 不在を想定していなかったマトリクスが壊れるのはここで、その隙間は「代わりに承認しておいて」というメッセージや、二人で共有するパスワードで埋められてしまいます。解決策は、システム上で事前に設定しておく委任です。誰に、どのくらいの期間、どの限度内で。代理人の承認は代理人本人の名前で表示され、本来の承認者の代理であることが明記されます。委任は期日に自動的に終了し、承認者は戻ったときに不在中に何が承認されたかを確認できます。また、オーナーが決めた期限を過ぎても判断が下されないままの依頼は、休暇中の人の受信箱で待ち続けるのではなく、次のレベルへエスカレーションされます。

システムが塞ぐべき二つの抜け道

どれほどよく設計されたマトリクスでも、その周りには二つの抜け道が開いたままです。それを使うのに悪意は要りません。承認が遅く、仕事が待ってくれないだけで十分です。そこでシステムは二つの側面から抜け道を塞ぎます。抜け道を阻む統制と、誰も抜け道を必要としないほど速い承認です。

  • 依頼の分割。 現場責任者の限度額を超える依頼が、限度額を下回る二件や三件に分割されます。同じ品目を、同じ仕入先から、数日のうちに。個々の依頼はそれぞれ問題ありませんが、合わせると限度額を超えており、しかもそれに対する権限を持つ人には一度も届きません。システムはこれを、単一の依頼ではなく合計を見ることで塞ぎます。オーナーが決めた期間内に、同じプロジェクトで品目または仕入先が共通する依頼を合算し、合計が限度額を超えれば、それを承認できるレベルに回します。
  • WhatsAppでの承認。 管理者が、何十件もの別のメッセージが流れるグループで、見積書の写真に「OK」と返信しました。承認は本物でしたが、何に対する承認でしょうか？ 見積のどの版、どの数量、どのプロジェクト？ 二か月後、そのメッセージは何千件もの他のメッセージの下に埋もれているか、その後買い替えられたスマートフォンの中に残っています。その一方で、付加価値税の課税対象となる事業者の場合、それを根拠に支払った請求書は、付加価値税施行規則第66条に基づき、関連する課税期間の終了から少なくとも六年間保存しなければなりません。ところが、その購買の裏付けとなる承認がどこにあることになるのかは、誰にもわかりません。

解決策は、紙とペンによる署名に戻ることを意味しません。電子取引法は、同法が定める条件のもとで、電子取引、電子記録、電子署名に拘束力を認めています（第5条）。また、電子取引の証拠価値を評価する際には、記録の作成、保存、伝達に用いられた方法の信頼性と、それが改変されうるものだったかどうかを考慮します（第9条(4)）。WhatsAppでの承認の問題は、それが電子的であることではなく、承認対象の依頼から切り離されていることです。そこで承認はシステム内の依頼そのものの上で行い、承認者の氏名、時刻、金額、承認された版を記録します。その後で依頼の数量や金額が変われば、再び承認に回ります。WhatsAppは通知チャネルとして残ります。承認者は依頼へのリンク付きの通知を受け取り、ノートパソコンを開かずにスマートフォンから承認できます。こうして、承認の遅さが迂回の理由ではなくなります。

緊急購買：抜け道ではなく公式のルートを

宿泊客の到着前のホテル客室での水漏れ、生産ラインで停止したポンプ、すでに始まっているコンクリート打設を終えるために資材を待っている現場。そうした瞬間には、誰も承認サイクルを最後まで待ちませんし、待つべきでもありません。この現実を無視するマトリクスは緊急購買を止めるのではなく、システムの外へ押し出します。その結果、品目は現金や従業員の自腹で購入され、二週間後に依頼も承認もないまま帳簿に現れます。

誠実なアプローチは、緊急事態が存在することを認め、明確な条件を伴う公式のルートを与えるシステムです。

  • 誰が起動できるか。 現場責任者や当番の保守責任者など、特定の役職であって、すべての従業員ではありません。
  • 何を緊急とみなすか。 感覚ではなく書面による定義です。安全上のリスク、業務の停止、または遅れると広がる損害。これは報告から完了まで：保守依頼の運用で保守依頼について提案したのと同じ考え方です。
  • 最小限の情報。 何を、なぜ緊急なのか、可能なら写真。完全なフォームではなく、現場からスマートフォンで入力します。
  • 支出上限。 緊急ルートで購入できる額についてオーナーが決める限度です。それを超える場合は、購入前に承認者が自分のスマートフォンから依頼そのものの上で承認します。
  • 期限付きの事後承認。 購入はすぐに進め、その承認はオーナーが決めた期限内に完了させます。承認されないまま期限が過ぎれば、その依頼はオーナーが自ら確認するリストに表示されます。

そのうえで、全体に占める緊急依頼の割合を注視してください。本当の緊急事態は起こります。しかし、特定の部門や現場で緊急が通常のルートになっているなら、それは人の怠慢ではありません。そこでの計画を見直す必要があるか、通常の承認が業務の耐えられる速さより遅いことの表れです。

Origamiの視点

企業のために購買ワークフローを構築するとき、私たちはポリシーマニュアルに書かれた形ではなく、実際に機能している現在のマトリクスから始めます。今日誰が承認しているのか、どこで承認が滞るのか、そして人々がどこで、なぜそれを迂回しているのか。チームが使っている抜け道は、どこで統制を強化すべきかを教えてくれる前に、どこで設計を変える必要があるかを教えてくれます。

次に、マトリクスをシステムが強制する表に変えます。オーナーが決める限度額、購買の種類、委任とエスカレーション、そして期限付きの緊急ルート。承認は承認者のスマートフォンに届き、依頼そのものの上に記録されます。組織構成が変わったときに、プログラマーを必要とせずにオーナーが限度額を変更できるように設計します。これは私たちが構築するカスタムシステムの一部であり、私たちのサービスで紹介しています。

今週の演習：自社のマトリクスを一枚の紙に描く

どんなシステムよりも先に、会社が現在運用しているマトリクスを、たとえ一度も文書化されたことがなくても書き出してください。オーナーは業務部長と財務部長とともに、一回か二回の打ち合わせでこれを行えます。

  • 購買の種類を列として並べます： 在庫資材、サービスと下請業者、固定資産、緊急購買。四つのどれにも当てはまらないものを会社が購入しているなら、種類を追加してください。
  • 金額のレベルを行に置きます。 自社にとって適切と考える限度額で区切り、各セルには人の名前ではなく、承認する役職を書きます。
  • 承認者ごとに代理人を指名し、 不在時に承認できるようにします。また、依頼が次のレベルへエスカレーションされるまでの期限を設定します。
  • 緊急を書面で定義し、 誰が起動できるか、その支出上限、承認を完了させる期限を決めます。
  • 第一回の演習で使った十件の請求書に戻り、 それぞれについて問いかけてください。このマトリクスが有効だったら、誰が承認していたか？ そしてその人は実際に承認したか？

この最後の問いで見える紙と現実のギャップこそ、システムが埋めるべきものです。ギャップが見つかったら、まず承認者がその時点で単に不在だっただけではないかを確認してください。その場合の解決策は、より厳しい統制ではなく、明確な委任だからです。

次回

ニーズには番号付きの依頼ができ、判断には承認者が明らかな承認ができました。次回は次の二つのステーション、仕入先と見積、そして発注書に進みます。一度だけ入力され、仕入先の追加時に確認される仕入先記録から始め、次に見積を同じ基準で比較し、選んだ見積を、価格、数量、条件を記載し依頼に紐づく発注書に変えます。こうしてそれは、請求書が届く前にオーナーが把握できる約束になります。

出典