ノーコードで承認アプリを作るときは、先に申請を1種類選び、誰が何を根拠に判断し、その後を誰が実行するのかを1枚に書き出しましょう。画面から作り始めると、差し戻しや不在時の扱いが後から見つかり、設定をやり直すことがあるためです。最初に1人承認の流れを試すなら、もともとの社内規程で1人が決裁できる範囲を選びます。試作のために、本来の承認者や必須の判断を減らすわけではありません。
この記事では、口頭、紙、チャットの申請をアプリに移したい少人数会社向けに、作り始める前の設計を説明します。まず業務の流れを決め、それを入力欄、操作権限、状態表示へ置き換える順番です。下の表で未決定の項目があれば、通知やボタンを増やす前に、業務責任者と扱いを決めてください。
| いまの状況 | 判断 | 最初の対応 | 次に決めること |
|---|---|---|---|
| 申請の種類が多い | 1種類に絞る | 頻度があり、正式な決裁条件を試作で守れる申請を選ぶ | 申請から実行完了までの担当 |
| 承認者の不在で止まりそう | 代理ルールを先に決める | 待機・代理判断・連絡のどれにするか記録する | 代理者が判断できる範囲 |
| 差し戻しの扱いが曖昧 | 構築を始めない | 戻す相手、コメント、再申請先を決める | 修正前の内容を残す方法 |
| 金額などの例外が多い | 範囲外は既存の正式経路へ回す | 範囲外を保留し、追加承認などの正式な経路へ引き継ぐ | 範囲外の受付を防ぐ方法と、引き継いだ記録 |
最初は申請1種類を選び、承認者1人の試作も規程の範囲に限る
最初の対象は、ある程度繰り返し発生し、申請者と判断者が決まっている業務から選ぶと考えやすくなります。たとえば、設備修理依頼、少額の購入依頼、外注依頼などです。ただし、名称が簡単でも、金額や対象物によって決裁条件が変わることがあります。実際の規程を読み、申請から実行まで説明できる1種類を選びましょう。試験には、その種類に当たる申請を1件ずつ使います。
複数人の全員承認や、金額・部門ごとの経路が欠かせない業務を、便宜上1人承認へ変えてはいけません。初回の試作で扱えないなら、別の対象を選ぶか、受付部分だけを試し、決裁は既存の正式な経路へつなぎます。試作の目的は、承認規程を簡略化することではなく、限定した範囲で記録と引き継ぎが機能するかを調べることです。
対象を決めるのは業務責任者とし、申請者、承認者、承認後に作業する担当者の3者で、実際の流れをたどってください。対象を変えた場合は、変更日、変更者、理由、適用する版を設計シートへ残します。口頭だけで差し替えると、入力項目は新しい業務、通知先は以前の担当者という食い違いが起きやすくなります。
画面を作る前に、12項目の設計シートを埋める
次の12項目は、画面の部品一覧ではなく、業務ルールを設定へ落とし込むための設計シートです。業務責任者が内容を決め、構築担当者がフォーム、承認権限、通知、一覧へ対応付けます。申請・判断・実行の各担当者が読んで答えられない欄は、未決定として残しましょう。仮の承認者や期限を入れて、本番の申請を流し始めないことが大切です。
| 記入欄 | 決める内容 | 記入例 |
|---|---|---|
| 1.対象申請 | 初回に扱う申請を1種類にする | 設備の修理・部品交換依頼 |
| 2.開始条件 | いつ申請を起こすか | 異常時の安全対応を行い、修理手配の判断へ回す時 |
| 3.申請者 | 入力・送信できる人 | 設備を使う作業者または班の担当者 |
| 4.承認者・代理者 | 判断者と不在時の扱い | 対象範囲の決裁権限を持つ担当者。不在時は許可された代理者へ連絡 |
| 5.必須項目 | 承認の判断材料と、規程・安全上欠かせない記録 | 設備名、異常内容、停止・安全措置の状況、希望対応日 |
| 6.判断基準 | 何を見て判断するか | 安全上の対応状況、生産影響、対応期限、費用と決裁範囲 |
| 7.結果の種類 | 使用する状態と結果 | 申請中、差し戻し、承認、却下、完了 |
| 8.差し戻し | 修正者と再申請先 | 申請者が修正し、同じ承認者へ再申請 |
| 9.実行担当 | 承認後に手配・作業する人 | 修理手配を担う担当者 |
| 10.残す履歴 | どの版に対し、誰が何を判断・実行したか | 申請と添付の版、判断者、日時、コメント、引受け・完了内容 |
| 11.通知先 | 誰へ、どの状態で知らせるか | 申請時は承認者、承認時は申請者と実行担当 |
| 12.試作で扱わない例外 | アプリ外の正式な手順へ回す条件 | 緊急停止・安全措置、規程上の追加承認、複数拠点への振り分けは既存手順へ |
上の表は、設備修理依頼を想定した架空の記入例です。回答欄に加え、見直した日、決定者、変更理由を残すと、誰の判断で設定したかをたどれます。たとえば承認者の交代や必須項目の追加があれば、まず設計シートを改訂し、その版に合わせて設定を変えます。変更後は各担当者が自分の権限で操作し、意図した流れになったかを照らし合わせてください。
申請フォームには判断材料と必須の記録をそろえる
入力欄は多ければよいわけではありませんが、減らすこと自体を目的にもしないようにしましょう。承認者が、対象、希望時期、理由、数量や費用を判断できる項目を基本に、安全・契約・社内規程で求められる記録を加えます。後から一覧で比べる情報は、自由記述だけにせず、日付、数量、選択肢、管理番号を分けておくと、同じ条件の申請を探しやすくなります。
申請後に依頼内容や金額が変わるなら、元の申請を残したうえで、変更理由、変更者、日時、新しい版を記録します。承認済みの内容だけを上書きすると、どの金額や図面に対して許可したのか分からなくなるためです。添付も差し替え前の版をたどれるようにし、図面番号や見積書番号を申請へひも付けます。番号が同じでも改訂版が違う場合は、同じ承認を使い回さない運用にしてください。
設備修理依頼の項目例
下の表は、設備修理依頼の入力項目例です。費用が未定なら、分からない金額を0として入力せず、見積取得と支出承認を分けて扱います。また、停止状況の記録は、設備を止めるかどうかを生産都合だけで決める欄ではありません。異常時の停止や安全措置は既存手順に従い、その実施状況と修理手配に使う情報を申請へ残します。
| 項目 | 入力形式の例 | 承認者が判断すること |
|---|---|---|
| 設備名・管理番号 | 選択または入力 | 対象設備を特定できるか |
| 異常内容 | 短い記述 | 報告された現象と修理・部品交換の判断材料 |
| 停止・安全措置の状況 | 選択肢 | 設備の稼働状態、既に行った停止・安全措置、所定担当への連絡状況 |
| 希望対応日 | 日付 | 手配の期限 |
| 概算費用 | 数値または未定 | 支出判断の材料 |
| 写真・図面番号 | 添付または入力 | 対象・状態・図面の版が判断に使えるか |
承認者と代理者を実際の権限・アカウントへ対応付ける
承認者を「部長」とだけ決めると、異動、不在、兼務の際に設定と実態がずれることがあります。そこで、決裁権限を持つ人、許可された代理者、閲覧だけする人、実行する人を分け、実際に使うアカウントへ対応付けましょう。自己承認の可否も、アプリの都合ではなく社内規程で決めます。画面上でボタンを隠すだけで済ませず、データや添付の閲覧・変更権限も合わせて設計します。
不在時は、待機できる期限、代理者が判断できる範囲、期限を超えたときの連絡先を決めます。自動的な切り替えを作らなくても、担当者が承認待ち一覧から連絡する方法は選べます。ただし、待てないからといって権限のない人が判断したり、不在者のアカウントを借りたりする運用にはしません。人の交代時に設定を変更する責任者も、設計シートへ書いておきましょう。
状態ごとの担当と、例外を正式な経路へ回す方法を決める
状態表示は、現在の結果と次の行動をつなぐために使います。「申請中」と表示されても、誰が編集でき、誰が判断するのかが曖昧なら案件は進みません。次の表を参考に、状態ごとの操作者、次の担当、残す記録を決めてください。同時に別の人が操作した場合や、古い画面から判断した場合に、変更後の申請へ以前の承認が付かない設計も考えます。
| 状態 | 操作する人 | 次の担当・通知先 | 残す内容 |
|---|---|---|---|
| 下書き | 申請者 | 申請者 | 作成者、作成日時 |
| 申請中 | 申請者 | 承認者 | 申請日時、申請時点の内容 |
| 差し戻し | 承認者 | 申請者 | 差し戻し理由、判断者、日時 |
| 承認 | 承認者 | 実行担当、申請者 | 承認した版、判断者、結果、条件、コメント、日時 |
| 完了 | 実行担当 | 申請者、権限のある閲覧者 | 対象範囲の実行内容、実行者、完了日時、残る処置 |
| 却下・取下げ | 却下は承認者、取下げは許可された申請者 | 関係者 | 理由、操作した人、日時 |
差し戻しは、直して再申請してもらうための状態です。戻す相手、理由、修正後の提出先を定め、却下して終える場合と区別しましょう。また、承認の後に購買や修理手配があるなら、承認と完了を分けます。許可が出たことと、物品が届いたこと、修理が終わったこと、設備の再開が認められたことは、それぞれ別の事実だからです。何をもって完了とするかは、対象業務に合わせて決めてください。
条件分岐は設定を複雑にしますが、決裁条件まで後回しにはできません。承認者を1人に固定する試作なら、その1人に決裁権限がある対象だけを受け付けます。金額や設備区分が範囲を超えた申請は保留し、既存の追加承認へ回すか、アプリ外の正式経路で扱います。後から自動化を検討できるのは、その正しい振り分けを人が行っている部分です。分類項目と振り分け先を残しておくと、設定へ移す際にも判断根拠が分かります。
履歴・一覧・通知を担当者の行動につなげる
通知が届くと便利ですが、それだけで承認待ちを管理しきれるとは限りません。承認者は、毎営業日の開始時や終了前など、未処理一覧を見る時刻を決めましょう。一覧には、申請番号、件名、申請者、申請日、状態、現在の担当者、希望日、最終更新日を表示します。通知の送信記録と、相手が案件を受け取り判断した記録を分ければ、止まっている場所をたどりやすくなります。
履歴には、申請時点の内容と添付の版、判断結果、コメント、判断者、日時、差し戻し回数を残します。管理番号の考え方はスプレッドシートで連番を自動採番し管理番号を重複させない方法を参考にしてください。同じ番号で改訂する場合も、各版の判断を区別します。受付後の振り分けにはGoogleフォームの回答を担当者へ振り分ける方法が参考になりますが、振り分けやメール送信の成功だけで承認済みにはしません。
通知先は、申請時は承認者、差し戻し時は申請者、承認時は実行担当と申請者というように、状態ごとに決めます。通知内のリンクから、対象の申請と添付をその人の権限で開けるかも試してください。通知が失敗した場合は、失敗記録と未処理一覧から担当者が拾う流れにします。再送や自動処理の再試行で、同じ申請が二重に承認・手配されないことも検査対象です。
設備修理依頼を例に、試作する範囲と検査方法を決める
ここでは架空の試作として、「設備の修理・部品交換依頼」を選びます。申請者は設備を使う作業者または班の担当者、承認者は対象範囲の修理・支出を決裁できる人、実行担当は手配を担う人です。基本の流れを「下書き→申請中→差し戻しまたは承認→手配中→完了」とし、却下や取下げの経路も用意します。実際の修理作業や再開判断は、その資格・権限・安全手順を満たす担当へ引き継ぎます。
この試作では、緊急停止、一定額を超える追加承認、複数拠点への振り分けを、アプリ内で処理しない範囲として明記します。ただし、業務上の対応や承認を省くという意味ではありません。緊急時はアプリ入力を待たず、所定の停止・安全措置・連絡を優先します。範囲外の案件は既存経路へ渡し、正式な決裁が出る前に手配を始めないようにします。
構築後は、下の3つのテスト用申請を用意し、申請者、承認者、実行担当が各自のアカウントで操作します。結果は設計シートへ残しましょう。そのうえで、権限のない人の操作、承認者の不在、金額の範囲超過、承認中の変更、取下げ、通知失敗や再試行も試します。正常に進む3件だけでは、本番で誤って承認・実行される経路を見つけきれないためです。
- 決裁範囲内の申請を1件作り、承認された版が実行・完了記録までつながるか試す
- 情報不足の申請を1件作り、理由付きの差し戻し、修正版の再申請、再判断を試す
- 実行担当への引き継ぎを1件試し、引受け前と処理完了後の状態・日時を区別する
画面名称や設定範囲はツールごとに異なります。採用候補の公式仕様を読み、決めた権限、履歴、変更時の扱いを実現できるかを照らし合わせてください。たとえば、フォームを送って通知メールが届く試験と、承認結果に応じて処理が進む試験は別です。添付の保存先や元データの権限も含め、自社の環境で検査したうえで本番へ移します。
作り始める前に、業務ルールの未決定をなくす
次のチェックリストは、設定を作り始める前に、業務責任者と構築担当者が共有するためのものです。各項目を決められれば設計を設定へ移す段階に進めますが、それだけで本番運用の合格にはなりません。未決定の欄は担当者を決めて持ち帰り、仮のルールで実際の申請を流さないようにしましょう。
- 対象にする申請が1種類に決まっている
- 申請者、承認者、代理者、実行担当が決まっている
- 必須入力項目が承認の判断基準と対応している
- 差し戻し、却下、承認後の行動が決まっている
- 一覧で読む項目と、申請・添付の各版を含む履歴が決まっている
- 通知先と時機、未処理一覧を読む担当と時刻、通知失敗時の対応が決まっている
- 初回の範囲外と、既存の正式な手順へ渡す経路を書き出している
- 申請、差し戻し、承認後の引き継ぎを試す3件が用意できる
設計後に承認者、必須項目、状態の意味を変える場合は、申請中の案件も含めて扱いを決めます。すでに承認を受けた版を残し、どの案件から新しいルールを適用するかを明記してください。その後、構築担当者が設定との差分を反映し、各担当者へ変更点を伝えます。画面だけを変更すると、利用者は以前の意味でボタンを押し続けるおそれがあります。
よくある質問
ここからは、試作の範囲が決まった後に迷いやすい点を説明します。代理、変更、通知、引き継ぎの扱いを先に書いておくと、機能を追加する理由も明確になります。
承認者が不在のとき、代理承認は最初の試作から入れるべきですか？
承認者が不在になるなら、最初から連絡先と代理権限の範囲を決めておきましょう。ただし、代理者への切り替えを自動化するかどうかは別の判断です。まずは許可された代理者へ人が連絡し、誰がどの権限で判断したかを残す方法でも試せます。不在のたびに止まるようなら、その運用を基に設定の追加を検討してください。
申請後に内容や金額が変わった場合、同じ申請を修正させるべきですか、それとも再申請にすべきですか？
判断に影響する変更は、理由と変更前後の版を残し、改めて承認を受けます。同じ申請番号を使う場合でも、以前の承認が新しい内容へ自動的に引き継がれないようにしてください。変更者と日時を記録するだけでなく、実行担当へ変更中であることを伝え、承認前の新版や失効した旧版で手配が進むのを止める流れまで決めます。
チャット通知だけで承認待ちを管理すると、どんな漏れが起きやすいですか？
チャットだけでは、他の連絡に埋もれた案件や、担当が変わった案件を追いにくくなります。そのため、通知は気付く入口に使い、処理状況は状態と担当者のある一覧で管理しましょう。誰がいつ一覧を開き、期限を過ぎた案件を誰へ連絡するかまで決めると、通知を見逃した場合も追いやすくなります。
承認済みの依頼を、購買や現場の実行担当へ確実に引き継ぐには何を記録すればよいですか？
対象物、承認された版、実行担当、希望日、コメント、添付や資料番号を同じ案件に残し、実行担当が引き受けたことまで記録します。完了時には実施内容と日時を残してください。ただし、修理手配の完了が設備全体の使用許可を意味するとは限りません。部品の受入れ、修理、検査、再開判断のどこまでを扱う申請なのかを決め、その範囲に合う完了記録にします。
参考にした公式情報
下記のMicrosoftの資料は、承認者の応答に応じて流れを進める設定例です。全員承認と最初の応答で進む方式では意味が異なるため、自社の決裁条件に合わせて選びます。一方、AppSheetの資料は、フォーム回答を基に通知を送る初歩的な例です。これだけで承認権限や再申請まで実装できたとは扱わず、各機能と利用条件を実装時点の公式資料で調べてください。
- 全員が承認する必要のある承認フローを作成する – Power Automate | Microsoft Learn
- Power Automate での承認ワークフローを作成し、テストします – Power Automate | Microsoft Learn
- Quick start: Build your first app and automation using Google Forms – AppSheet Help
まとめ
まずは、正式な決裁条件を守れる申請を1種類選び、設計シートの12項目を埋めてみましょう。次に、入力内容、状態ごとの担当、承認した版、実行結果をつなげ、通知がなくても未処理を追える一覧を作ります。運用後は、差し戻しの理由や引き継ぎで止まる場所を見て、手作業の振り分けを自動化するかを考えます。ツールに合わせて決裁を省くのではなく、決めた業務を正しく進められるかを試すことが、最初のアプリ作りの基準になります。
滞留在庫の転用や再加工を申請の対象にする場合も、先に判断材料をそろえましょう。長期滞留在庫リストの22項目では、数量・金額、使用可否、処置案、担当者・決裁者、期限を同じ一覧で追う方法を説明しています。処置案が書かれたことと、実施が許可されたことを区別して承認フローへつなげてください。
