承認と発注（PO）のための調達リクエストアプリ設計図

内部調達リクエストアプリが解決すべきこと

メールスレッドやスプレッドシートはいつも同じ問題でつまずきます。リクエストが埋もれる、ファイルが「final_v7」のように分裂する、承認がサイドチャットで行われて記録が残らない。誰かが「これを買っていいか？」と聞くと、答えはオンラインの人や信じられているシート次第になります。

リクエストアプリは、どの時点でもステータスが一目で分かるようにするべきです。リクエストを開けば、誰が出したのか、何を買いたいのか、見積りコスト、次に何が起きるのかがすぐ分かるべきです。また履歴がきれいに残っている必要があります：誰が承認／却下したか、いつ行ったか、その後に何が変更されたか。

最低でも、各リクエストは以下の問いに掘り下げずに答えられる必要があります：

• 次のステップの所有者は誰か？
• 何が保留中か（承認、予算チェック、ベンダー見積、PO作成など）？
• 何が承認されたか（金額、ベンダー、範囲）、そして変更はあったか？
• いつ必要で、その理由は何か？
• 監査トレイルはどうなっていて、財務が信頼できるか？

スコープが大きくなりすぎるチームは多いです。最初に「リクエストから発注まで（Request→PO）」だけを対象にするのか、請求照合や受領まで含めるのかを決めてください。Request→POは一般に良い最初のマイルストーンです：承認と予算チェックを厳格にしつつプロジェクトを小さく保てます。

最初のバージョンはシンプルに保ってください。1つのチーム、1つの承認経路、そして「完了」の明確な定義から始めます。例えば、ITの$1,000未満のリクエストはマネージャー承認のみで、より大きな購入は財務に回す、などです。

コードを書かずに素早く構築したいなら、AppMasterは実用的な選択肢です。リクエストデータをモデル化し、承認ステップを設定し、同じ設計図から本番対応のWebおよびモバイルアプリを生成できます。

ユーザー、役割、アクセスルール

調達リクエストアプリは権限設計次第で成否が決まります。承認後に間違った人がリクエストを変更できたり、チームが必要な情報を見られなければ、プロセスは遅く危険になります。

まず明確な役割名を決めてください。名称は会社によって異なりますが、一般的には安定した責任範囲が必要です：リクエスター（リクエスト作成と質問対応）、マネージャー（必要性とタイミングの確認）、購買（ベンダーの検証とPO作成）、財務（予算と方針の確認）、および1人以上の承認者（決裁権）。ワークフローによっては、外部向けの限定的なベンダー連絡者を含めることもあります。

次に、各役割が各ステージでできることを定義します。あるルール一つで多くの論争を防げます：リクエストが提出されたら、リクエスターは補足（メモ、添付、納品詳細）のみ編集できるようにすること。価格、ベンダー、数量、通貨、コストセンターは厳格なフィールドとして扱い、正式な変更と再承認を必要とします。

可視性ルールも同様に明確にします。リクエスターは自分のリクエストとそのステータスを見られるべきです。マネージャーは直属の部下のリクエストを見られるように。購買と財務は通常部門横断の可視性が必要です。ベンダー連絡先は内部メモや予算データ、他のベンダー情報を見てはいけません。

承認の委任は重要です。誰かが休暇で不在でも承認は止まってはいけません。計画的な委任（休暇）と緊急バックアップ（病欠）をサポートしてください。委任は承認権を渡しますが、リクエストを書き換える権利は渡さないべきです。

部門横断のリクエストは一般的です（例：ITがMarketingのためにソフトを買う）。「リクエスターのチーム」と「コストセンターの所有者」を分けて扱ってください。承認はコストセンターの所有者にルーティングし、記録には要求者と支払責任者の両方を表示して誰が要求し誰が支払うか明確にします。

AppMasterでは、データモデルとビジネスプロセスで役割、レコード所有者、ステージに基づくアクションをモデル化できるため、Webとモバイルの画面で同じルールが適用されます。

データモデル：主要エンティティとフィールド

良い調達リクエストアプリはきれいなデータモデルから始まります。テーブルが明確なら、承認、予算チェック、発注書の自動化や報告が容易になります。

含めるべき主要エンティティ

多くのチームは少数のエンティティで大半のケースをカバーできます：

• Requests：調達リクエストごとのヘッダレコード。
• RequestItems：ラインアイテム、数量、見積単価。
• Vendors：仕入先マスタデータ（リクエストやPOで再利用）。
• Budgets：コストセンター、プロジェクト、部門、期間ごとの利用可能残高。
• PurchaseOrders：承認済みのリクエストから作成される正式な発注書。
• Approvals：各承認ステップ、決定、コメント。

後で効いてくるフィールド

Requestsにはルーティングを助けて往復を減らすフィールドを入れてください：リクエスター、部門、コストセンター、必要日、ビジネス理由、添付（見積、仕様書、スクリーンショット）。推奨ベンダー参照を簡単にしておくと、ベンダー選定が後で確定する場合でも有用です。

ステータスは明示的でタイムスタンプを伴うと使いやすいです。Requestsに単一のステータスフィールドを置き（Draft, Submitted, Approved, Rejected, Ordered, Closed）、submitted_at、approved_at、rejected_at、ordered_at、closed_atのような主要日付を保存してください。これでログから推測せずにサイクルタイムや滞留をレポートできます。

PurchaseOrdersはPOヘッダ（番号、ベンダー、出荷先、請求先、支払条件）とPOラインを分け、元のリクエストとアイテムにリンクしてください。価格が変わった場合のトレーサビリティが重要です。

監査トレイル設計

承認は監査トレイルの核ですが、通常は「承認/却下」以上の情報が必要です。誰が、いつ、何を決め、なぜかを保存してください。

軽量な方法はActivity/Auditテーブルで、actor_user_id、entity_type、entity_id、action、old_value、new_value、created_atを記録することです。AppMasterではこれをData Designerでマッピングし、ビジネスプロセスから自動で埋められるようにしておくと、すべての変更が追跡可能になります。

ベンダーレコードとコミュニケーションの追跡

全員が同じベンダー情報を使うことが、調達アプリが機能する鍵です。ベンダーテーブルを都度入力するのではなく、単一の真実のソースとして扱ってください。ベンダー情報が一元化されていると承認が速くなり、財務の驚きも減ります。

ベンダーレコードには再利用する基本情報を入れてください：正式名称、表示名、税ID（使うなら）、デフォルト通貨、請求先住所、支払条件。メインのA/Pメールを保存し、見積用と請求用など複数の連絡先を持てるようにすると適切な担当者に届きます。

ベンダーにステータスを付けてリスクのある購買を一貫してブロックできるようにします：Active（選択可）、Pending review（選択可だが追加検証へルーティング）、Blocked（事前レビュー無しには使用不可）。

コミュニケーション追跡は「最後に誰がメールしたか？」問題を防ぎます。Vendorに紐づくCommunication（またはVendorInteraction）エンティティを作成し、可能なら特定のRequest、Quote、POにもリンクしてください。各レコードはチャネル（メール、電話、会議）、方向（送信/受信）、タイムスタンプ、担当者、短い要約を記録します。見積を集めるなら構造化された見積レコード（金額、通貨、有効期限）を保存し、必要に応じてファイルを添付します。

ベンダーデータを清潔に保ちながら速度を落とさないためのルール例：

• ベンダーはフリーテキストではなくリストから選ぶこと。
• PO作成後は支払条件をロックする（承認が必要な場合を除く）。
• Pending reviewのベンダーは自動で購買部に回すこと。
• 高額購入では少なくとも1件のログ化されたやり取りと見積のタイムラインを必須にすること。

AppMasterで作る場合は、Vendor、VendorContact、VendorCommunicationをData Designerでモデル化し、リクエストやPO画面にタイムラインを表示して履歴をワンクリックで見られるようにできます。

予算チェック：承認前に支出をどう検証するか

予算チェックは単純な問いに答えます：今、このリクエストに対して十分な承認済み資金があるか？会社が予算をハードストップと扱うか警告と扱うかを早めに決めてください。その選択はリクエスターと承認者の体験を大きく変えます。

予算はさまざまな場所から来るため、ソースを明示してください。一般的には年次部門予算、プロジェクト予算、コストセンターの月次上限などです。リクエストが複数ソースに分割できるなら、ソースごとの分割金額を保存して報告をきれいに保ちます。

驚きを避けるには、期待支出を財務が後で計算するのと同じ方法で算出してください。リクエストアプリは承認前に全員が同じ数字を見られなければ役に立ちません。

多くのチームが使うシンプルな計算チェックリストは、ラインアイテム合計（数量×単価）、割引、税金、送料、通貨換算（レートと日付を保存）を含めることです。そして期待支出を利用可能予算（予算−既にコミットされた額）と比較します。コミットを追跡するなら、保留中のリクエストや未決のPOも含めます。

予算が不足している場合は、リクエスターに推測させないでください。次のいずれかをワークフローで定めてください：予算オーナーにソースを割り当てる、財務承認付きの一時的なオーバーライドを許す、"予算詳細"タスクで差し戻す、常に予算が必要なカテゴリは自動却下する、など。

例：チームが新しいノートPCバンドルをリクエストしたとします。アプリはアイテム費用＋税＋送料を計算し、部門通貨に換算して$1,150のリクエストに対して利用可能残高が$900しかないことを示します。これを警告として扱うならマネージャーが進められますが、財務承認を必須にするかどうかを決める必要があります。

AppMasterでは、Data Designerで予算ソースをモデル化し、最初の承認決定前にBusiness Processステップとしてチェックを実行できます。

承認ワークフローとルーティングルール

承認は、リクエストアプリが時間を節約するか、遅いインボックス中継に変わるかを決める場所です。デフォルトの経路はシンプルに保ち、実際のリスクを防ぐ場合にのみルールを追加してください。

まず各承認が何を守るのかを定義します。一般的なセットはマネージャー承認（必要性と優先度）、財務承認（予算と会計）、購買承認（ベンダーと購買方法）。特定のカテゴリやベンダーで必要ならセキュリティや法務も追加します。

ルーティングルールは予測可能にしてください。ユーザーはSubmitする前に次に何が起こるか推測できるべきです。典型的なルーティング要因は金額閾値、カテゴリ別ルーティング（ソフトはセキュリティ、契約は法務）、ベンダーリスクレベル、部門やコストセンターのルール、購入タイプ（CapEx vs OpEx、サブスクリプション vs 単発）です。

順次承認は順序が重要な場合に使います。例：コストセンターがないリクエストは財務で止めるべきなので、購買に回す前に財務を先に通す方がよいです。並列承認は、セキュリティと法務が独立してレビューできる場合に有効です。

差し戻しのためのきれいな再作業ループを設計してください。承認者がリクエストを差し戻したら、リクエスターは不足情報を追加して再提出でき、履歴は失われないようにします。承認ログにはタイムスタンプ、コメント、金額・ベンダー・カテゴリなど主要フィールドのバージョンを残してください。

例：$12,000のSaaSツールはまずマネージャーと財務へルーティングします。両方が承認すると、セキュリティと購買が並列で動きます。セキュリティがデータ処理の詳細不足を指摘した場合はリクエスターに戻り、修正後に同じステップに戻って監査証跡を保ちます。

AppMasterで作る場合は、Business Processでワークフローステートと遷移をモデル化し、ルーティングを見える化して方針変更を容易にしてください。

ステップバイステップ：リクエストから発注まで

良いフローはリクエストを動かし続けつつ、重要事項が漂わないようにします。早い段階で十分な情報を捕捉し、レビュー開始後は重要項目を固定します。

多くのチームにとって実用的な順序は次のとおりです：

• リクエストを下書き：ラインアイテム、数量、目標価格、推奨ベンダー（またはベンダー未定）、ビジネス理由、コストセンター、必要日を追加。見積や背景を添付して承認者が追いかけなくて済むようにします。
• 提出して主要フィールドをロック：Submitするとベンダー、通貨、コストセンター、合計見積をロックします。レビュー用の短いコメント欄は編集可能にして質問対応できるようにします。
• 予算チェックと承認ルーティング：人が承認する前に支出を検証します。閾値超過、見積不足、制限カテゴリなどがあれば適切なグループへ回します。予算不足なら具体的な理由を付けて差し戻します。
• 最終承認後にPOを作成：承認済みリクエストからPOを生成し、承認されたラインをコピーします。POがベンダー向けの信頼できる基準になります。
• PO送付と確認の追跡：POを送った時点、ベンダーの承認、納期、分納などを記録します。ベンダーが変更を提案したらリビジョンとして記録してください。

例：サポートチームがヘッドセット10個をリクエストします。見積を添付し、IT備品カテゴリを選んで提出。アプリはIT予算をチェックし、チームリードへ（$1,000未満のため）ルーティングし、$500超なら財務もルーティングします。承認後にPOが生成され送付され、バイヤーが確認と納品日を記録します。

AppMasterのようなノーコードツールでは、これが数個の画面（Draft、Review、PO）と、フィールドをロックし予算ロジックを実行してPOレコードを自動作成するBusiness Processになります。

発注書（PO）：番号付与、ライン、変更管理

発注書は一貫性があり、追跡可能で、誤って変更されないことが重要です。ワークフロー内でPOはベンダーと財務が信頼できる安定したレコードにしてください。

PO番号：いつ生成するか

PO番号は『正式にベンダーへ発行したとき』に生成します。ドラフト段階で生成するとギャップや重複が発生します。

重複を避けるには、次のPO番号を一元管理し、アトミックなステップで割り当ててください。人間に分かりやすい番号が欲しければ法人や年のプレフィックスを付けても構いませんが、一意のカウンター部分は繰り返さないようにします。

POの構造：ヘッダ、ライン、合計

POはヘッダとラインに分けます。ヘッダは文脈、ラインは購入内容です。

ヘッダにはベンダーと連絡先、出荷先と請求先、通貨、支払条件、想定納期、ステータス（Draft、Issued、Acknowledged、Closed）、見積参照を入れてください。

ラインは請求照合のために厳格にします：説明、数量、単位、単価、税、割引、コストセンターまたは予算コード。合計は手入力ではなく計算で出してください。

変更管理：リビジョン vs キャンセルして再発行

どの変更をリビジョンで扱い、どの変更をキャンセルして再発行するかを事前に決めます。納期など小さな変更はリビジョン（例：PO-1042 v2）で上書きの形にし、大きな変更（ベンダー、通貨、合計額の大幅な変更）はキャンセルして再発行する方が安全です。

例：10台のノートPCで納期が2週間から8週間に変わった場合は、納期更新のリビジョンを作成し、元の見積を添付したままにしておけばPOは常に合意内容と一致します。

AppMasterで作る場合は、POヘッダ、ラインアイテム、POバージョンを別エンティティとしてモデル化し、リビジョンをきれいに保てます。

通知とベンダーとのやり取りワークフロー

通知がうまく機能するかどうかで内部調達の体験はスムーズに感じるか、メール追跡地獄になるかが決まります。メッセージをプロセスの一部と見なして、ステータス変更や次の明確なアクションに紐づけてください。

まずは少数の内部通知に絞って人が無視しないようにします：承認／却下、予算チェック失敗または要確認、PO作成と送付準備、承認遅延または納期遅延、PO変更またはキャンセルなど。

各通知は10秒で読めるようにしてください。リクエストタイトル、合計金額、現在のステータス、受け手が次にすべきことを一貫したテンプレートで伝えます。承認者向けには支出理由と主要ラインを短く含めます。

ベンダーとのやり取りも構造化してください。ベンダー側が必要なのは主にPO送付、PO変更、キャンセル、納品に関する質問です。POやリクエストに紐づくベンダーの送受信メッセージをすべてスレッドに保存し、状態（draft、sent、delivered、failed）、vendor_response（none、replied、bounced）、follow_up_needed（yes/no）とフォローアップ日を追跡してください。

例：ノートPCのリクエストが承認されPOを送付した後、ベンダーから回答がありモデルがバックオーダーだとします。アプリは返信をログに残し、follow_up_neededをyesにして代替品選定のためにリクエスターに通知します。AppMasterではステータス変更をメール/SMS/Telegram等に連携し、メッセージ結果をPO横に保存できます。

よくある失敗と落とし穴

最大のリスクは機能不足ではなく、間違ったルールを作って会社がそれを回避するように覚えてしまうことです。

よくある失敗はステータスを迷路のように増やすことです。「Pending validation」と「Under review」の違いが分からなければ人は更新をやめ、データはノイズになります。各ステータスは「次に何が起き、誰が担当か」を一つの質問で答えるべきです。

別の罠は責任者や期限のない承認です。承認者が休暇で止まるのを防ぐため、グループに割り当てるだけでなくバックアップも用意してください（"Finance"は人ではない）。

最も手戻りを生む間違い：

• ビルダーだけが分かるような多数のステータスと例外
• 代替がないグループ割当てによる承認停止
• 承認後に価格や数量、ベンダーを編集して再承認を強制しないこと
• 財務が追う方法（月次か四半期か、コミットか実績か）と合わない予算チェック
• 理由が残らない手動オーバーライド

承認後の編集は特に注意が必要です。小さな変更でもリスクを変えます。10台×$900で承認を取った後に上位モデルや数量を増やしたら、承認内容と実購入が一致しなくなります。

また、予算検証を単一のはい／いいえで扱わないでください。財務は部門、プロジェクト、GL勘定、時間窓での報告を気にします。アプリが月次でチェックしているのに財務が四半期で報告していると、常に「利用可能残高」が合いません。

AppMasterで作るなら、承認後に主要フィールドをロックし、例外は誰がいつ何を変更したか理由付きでイベントとして記録してください。その監査証跡が紛争や監査時に重要になります。

クイックチェックリスト、例シナリオ、次のステップ

ローンチ前に基本ルールを書き出してください。多くの"承認混乱"は一つの小さなルールや必須フィールドが欠けていることで起きます。

シンプルなローンチチェックリスト：

• 役割と権限（requester、approver、finance、procurement、admin）
• 承認ルール（金額、部門、カテゴリ、場所）
• ステータスと所有（Draft、Submitted、Needs info、Approved、PO created、Closed）
• 必須フィールド（ベンダー、コストセンター、納期、ビジネス理由）
• 必須添付（見積、契約、セキュリティレビュー、仕様書）

これらのルールがあれば、リクエストが次に進む前に実行される簡単な検証を追加します：ベンダーの選択（または新規ベンダーの明確な経路）、適切な期間の予算カバー、価格証拠、請求/配送の完全な情報、実際のビジネス理由。

例シナリオ：チームリードが新入社員用のノートPCをリクエストします。推奨ベンダーを選び見積を添付し、適切なコストセンターをタグ付けします。マネージャーは採用計画に合致するため承認、財務は予算チェックで承認、購買がPOを作成してベンダーへ送り、ベンダーの確認と納期を同一レコードに記録するのでリクエスターは余分なメールなしで進捗を追えます。

次のステップ：データモデルとワークフロールールをプロトタイプ化し、小さなパイロットチームと1〜2カテゴリでテストしてください。AppMasterではData Designerでテーブルを作り、Business Process Editorでルーティングロジックをマップできます。短いパイロットを実行し、どこで詰まるかをレビューして必須フィールドを絞り込み、その後段階的に展開します。実際のアプリ化の例を見たい場合、AppMaster（appmaster.io）は承認ロジック、API、Webとネイティブの両方に対応した内部ツールを同じモデルから作成するために設計されています。