例外パス設計：承認の前に却下を想定する

ハッピーパス（理想経路）だけでは不十分な理由

ほとんどのチームはきれいなワークフローから始めます。申請が来て、誰かが確認し、承認される。効率的に感じますが、実際の作業がどこで発生しているかは隠れてしまいます。

ハッピーパスは通常、最短経路です。フォームは完全で、添付ファイルは揃っていて、審査者は何をすべきか明確に分かっています。現場では、遅延が発生するのは稀です。

遅延は何かが欠けている、曖昧である、提出が遅れている、あるいは部分的にしか受け入れられない瞬間から始まります。マネージャーが予算は承認するが項目の一つを却下するかもしれません。経理が税関連の書類を要求するがそれがアップロードされていないかもしれません。サポートの責任者が理由欄が不明瞭だとして申請を差し戻すこともあります。そのような瞬間が追加の手順、追加のメッセージ、追加の待ち時間を生みます。

これらの状況を早期に計画していないと、人々は場当たり的に判断します。ある人はメールを送り、別の人はツールにコメントを残し、三人目は説明なしに申請を却下します。申請者は戸惑います：問題を修正すべきか、最初からやり直すべきか、誰かに助けを求めるべきか。

その混乱にはコストがあります。申請した人、審査している人、説明のために巻き込まれた誰にとっても作業が遅くなります。ホワイトボード上では単純に見えたワークフローが、フォローアップのチャット、重複した申請、手作業の引き継ぎに変わってしまいます。

基本的な承認フローは描くのが簡単です。

• 申請を送信
• 申請を確認
• 申請を承認

しかし実際はもっと複雑です。書類が欠けていたら？申請の一部しか承認されなかったら？審査者が却下したがユーザーが修正できる場合は？これらは珍しいケースではありません。多くのチームにとって、それが通常のケースです。

だからこそ、画面を描いたりステータスに名前を付ける前に例外パス設計に注意を払うべきです。例外パスは現実が計画を中断したときに何が起きるかを定義しますが、現実は頻繁に中断します。

内部の承認アプリを作る場合、AppMasterのようなノーコードプラットフォームであっても、却下や不完全なケースは承認ケースと同じくらい注意深く設計する必要があります。これらは人々が見るメッセージ、次に取れるアクション、そしてワークフローが人を支援して回復を助けるか、それとも行き詰まらせるかを決めます。

ハッピーパスは意図を示します。例外パスはそのプロセスが実際の運用に耐えられるかを示します。

例外パスの姿

例外パスとは、申請が通常どおり進められないときに起きる処理です。稀なエッジケースではありません。申請が却下される、フォームが不完全である、申請の一部だけが承認される、あるいは作業が単に停滞する——こうした現実の混乱を扱う部分です。

明快な例外パスは平易な言葉を使います。曖昧なステータス「Failed（失敗）」の代わりに、「予算が上限を超えているため却下」「身分証明書の提出待ち」など、何が起きたのかを示します。人々は何が問題で、誰が行動する必要があり、次に何が起きるかを知るべきです。

ほとんどのワークフローは予測可能な数種類の方法で破綻します。

• 明確な理由で申請が却下される
• 必須の書類や項目が欠けている
• 申請の一部しか承認されない
• 所有者がいない、次のステップが定義されていない

情報の欠落は最も一般的な問題の一つです。例えば、税関連書類と銀行口座番号が必要なサプライヤーのオンボーディングフォームを想像してください。どちらかが欠けているなら、システムは単に停止してはいけません。申請を「不完全」とマークし、何が欠けているかを明示し、適切な担当者に差し戻すべきです。

部分承認も同様に重要です。フライト、ホテル、食費を含む出張申請を考えてみてください。マネージャーがフライトとホテルは承認するが食費は削減する場合、その後のルールが必要です。従業員はその変更を受け入れるのか、申請を更新するのか、旅行を中止するのか？

停滞も問題です。担当審査者が退職した、バックアップ承認者が設定されていない、次の所有者が定められていないなどで申請が放置されることがあります。技術的には壊れていなくても、申請は前に進みません。

これらの経路を早期に設計しないと、人々はメールやチャット、スプレッドシートのメモで対処します。すぐにどのバージョンが最終なのか誰も分からなくなります。

簡単な承認の例

営業マネージャーが2日間のカンファレンスに参加するための出張申請を例にとります。紙の上ではフローは単純です：従業員は日程、概算費用、出張理由を入力する。マネージャーが承認し、経理が予算を確認し、予約に進む。

そのフローはクリーンですが、不完全でもあります。

同じ申請を壊してみましょう。従業員はフライト見積もりとカンファレンス参加チケットをアップロードしたが、ホテル見積もりを忘れたとします。システムが「提出済み」と「承認済み」しか知らない場合、人はすぐに行き詰まります。経理は申請が不完全だと気づき、マネージャーは準備ができていると思い込み、従業員は何が欠けているのか分かりません。

より良いフローはその申請に固有の状態を与えます。例えば「書類待ち」や「更新が必要」など。従業員には明確なメッセージが表示されるべきです："ホテル見積もりを追加してください。経理へ進む前に必要です。" マネージャーが全体を却下して1ファイルだけを求める必要はありません。

さらに別の問題を加えます。マネージャーは出張自体は了承するが金額は全額認めない。フライトとホテル1泊は承認するが、ワークショップ費用と2泊目のホテルは却下する。

ここで多くのチームは部分承認プロセスを持っていないことに気付きます。

ワークフローが申請の一部だけを承認できない場合、人々は回避策を使い始めます。申請全体を却下して従業員に再提出させるか、あるいはシステムが一つのYes/No決定しか保持しないため経理が誤って全額承認してしまうかもしれません。

より明確なモデルは各費目を追跡するか、少なくとも承認された合計を記録します。申請には次のように表示されるかもしれません：

• フライト：承認済み
• ホテル：1泊分承認
• ワークショップ追加：非承認
• 合計請求額：$1,450
• 承認合計：$980

この単一の例から、承認ワークフローのエラーは不注意な人によるものではなく、ルールが欠けていることが原因であることがよく分かります。画面を設計する前にそれらのルールを定義すれば、ワークフロー全体の信頼性が格段に高まります。

画面より前に例外を設計する

ワークフローを改善する良い方法は、申請がきれいに通らないことを前提にすることです。その思考の切り替えだけで設計の質は急速に変わります。

まずは混乱するケースから始めます：フォームが不完全、ポリシーが不明瞭、承認者が不在、あるいは申請の一部だけが進むべき場合。多くのチームはこれらを主に三つのパターンに分類できます。

• 却下
• 情報の欠落
• 部分承認

こうすることで作業が管理可能になります。すべてのエッジケースに新しい答えを考える代わりに、少数のパターンを定義して各申請タイプに適用します。

作業手順は次の通りです。

まず、申請が止まる可能性のあるすべてのポイントを列挙します。書類の欠落、無効な値、ポリシー違反、期限切れ、重複申請、手動レビューなどを考えます。申請が待機するのか、失敗するのか、送信者に戻るのかを書き出してください。

次に、各ケースで何が起きるかを決めます。すべての例外について、次の四つの簡単な質問に答えてください：

• 誰に通知されるのか
• 申請はどのステータスを表示するのか
• ユーザーは次に何をする必要があるのか
• いつ申請は再び動くのか

例えば、従業員が$600の出張精算を提出し、ホテルの領収書が欠けていて、ある食費がポリシーを超えているとします。ハッピーパスだけを設計していると、申請は行き詰まるか、すべて一括で却下されます。例外を先に設計すれば、システムは不足領収書のために申請を一時停止し、従業員に明確なメッセージを送り、許容される項目を条件付きで承認したままにできます。

ここで部分承認ルールが重要になります。承認された金額をすぐに進めるのか、残りは保留にするのか、申請者は問題のある部分だけ編集できるのか、それとも全体を再提出しなければならないのかを決める必要があります。

AppMasterでプロセスを構築する場合、UIを整える前にビジネスロジックの中でこれらの分岐をマッピングする時です。却下、編集返却、条件付き承認をそれぞれ別経路として扱えば、あいまいな単一ステータスに隠れた振る舞いよりもずっと信頼できるワークフローになります。

最後に、実際のシナリオを一つ、最初から最後までテストしてください。実際の数字、一つの書類の欠落、一つのポリシー例外を使います。フローを読んだ人が1分以内に次に何が起きるか説明できなければ、設計はまだあいまいです。

インターフェイスより先にルールを決める

画面は具体的に感じられるため、多くのチームはそこから始めがちです。ボタンやフォーム、ダッシュボードをスケッチする前にルールに合意しないと問題が後で生じます。インターフェイスが誰も決めていない判断を隠してしまうからです。

より良い順序はシンプルです：状態、引き継ぎ、期限、前進するために必要な証拠を先に定義し、その後で画面を作ります。

例外パス設計はルールセットが小さく明確なほど簡単になります。申請が承認、却下、修正返却、部分承認のいずれかになりうるなら、それらの状態は一つの意味だけを持つ平易な名前で呼びましょう。「Returned」「Reopened」「Needs changes」のような近い意味を持つ複数のラベルは、本当に違う振る舞いをする場合にのみ使ってください。

購買申請を例に取ってください。マネージャーが開いて見積が欠けていることに気づいたとします。チームが次にどうするか決めていなければ、人々は即興で対応します。一人は却下し、別の人は保留にし、三人目はチャットで連絡してシステムには何も変えない。すぐにステータスは信用されなくなります。

まずルールを書いてください。見積が欠けている場合、申請は「書類が必要」に移る。申請者が次の行動を取る所有者です。申請は5営業日そのまま待ち、何も届かなければ「期限切れ」に変わり新しい提出が必要になります。

その一つのルールはモックアップよりも製品設計に大きな影響を与えます。ユーザーが何を見るべきか、どのリマインダーを送るべきか、どの履歴を保持すべきかが分かります。

実用的なルールセットは四つの質問に答えるべきです。

• 毎日使う少数のステータス名は何か？
• 各ステータスで次に誰が行動するのか？
• どれくらいの間その項目は留まれるのか（エスカレーション、期限切れ、クローズのルール）？
• 前に進むためにどのフィールド、ファイル、チェックが必要か？

部分承認も同じ注意が必要です。出張が承認されたがホテル代が承認されない場合、申請者は同じレコードを編集するのか新しい申請を作るのか？経理は変更部分だけを再確認するのか、それとも全体をもう一度見るのか？早期に決めておかないと、画面は整っていても裏のプロセスは混乱したままです。

チームが先にルールを固めると、インターフェイスは簡素になります。さらに重要なのは、ユーザーが次に何をすべきかを正確に知ることができる点です。たとえ答えが「まだ承認されていない」であっても。

ユーザーが行動できるメッセージを書く

不適切な例外メッセージは全体を遅くします。人々は単に何かが失敗したことを知るだけでなく、何が起きたか、それが何に影響するか、次に何をすべきかを知る必要があります。

ここで設計が実際のユーザーにとって現実味を帯びます。内部ルールが明確でも、画面に「Error（エラー）」や「Pending review（審査待ち）」とだけ表示されれば、人々は推測し、間違ったファイルを送り直したり、サポートに問い合わせたりします。

ベンダー承認の例を取ってみましょう。ユーザーが税関連書類、銀行情報、保険証明を提出したとします。銀行情報は問題ないが、税関連書類が古く、保険証明が欠けている。システムが「Request not approved（承認されていません）」だけを表示すると、ユーザーには次に何をすべきかが分かりません。

より良いメッセージはこう言います：「銀行情報は承認されました。最終承認には最新の税関連書類と保険証明が必要です。」この一文で、完了した部分とまだ必要な部分が分かれ、時間を節約できます。

良いメッセージは通常、次の四つの小さな質問に答えます。

• どの部分が拒否、欠落、または審査中か？
• どの部分が既に受理されたか？
• ユーザーは何をアップロード・変更・確認する必要があるか？
• 再提出後に何が起きるか？

最後の点は重要です。次のステップが明確であれば人は作業を完了しやすくなります。「欠けているファイルをアップロードして再提出してください」は「アクションが必要」のような曖昧な文言よりずっと良いです。

曖昧なラベルは不安を生みます。「Pending review」は人待ち、データ欠落、内部チェック待ちを意味し得ます。理由が分かっているならはっきり書きましょう。「マネージャーの承認待ち」と「住所確認書類待ち」は同じではなく、同じ見え方をしてはいけません。

プロセスが部分承認を許す場合は、ステータス自体でそれを示してください。短い内訳を見せる方が一つのラベルより有効なことが多いです。

• 承認：身分証明書
• 要更新：税関連書類
• 欠落：保険証明

これでユーザーは必要な部分だけを直せばよく、最初からやり直す必要がありません。

再提出のアクションはメッセージのそばに置くべきです。別の画面に隠してはいけません。AppMasterで構築する場合、ユーザー向けのステータステキストを実際のビジネスプロセス状態に合わせると、アプリがワークフローで実際に何をしているかを正確に伝えられます。

良いメッセージはサポートチケットを減らし、承認を早め、プロセスを公正に感じさせます。人は理由が分かれば拒否を受け入れやすくなります。

手戻りを生む間違い

ほとんどの手戻りは一つの誤った前提から始まります：通常の経路だけを設計すれば十分だという考えです。チームは申請提出、承認、完了をマップしてそこで止めます。すると現実が現れます：ファイルが欠ける、マネージャーが変更を求める、申請の一部だけが進む。これらのギャップがあっという間に手戻りを生みます。

その結果、人々は手動で穴を埋める回避策を考え、サイドメッセージを送り、ステータス名を臨時で変更します。数週間後には誰もワークフローを信用しなくなり、すべての例外が特別扱いに感じられます。

よくある間違いの一つは、理想経路を製品とみなし、それ以外を後始末と扱うことです。領収書、部門承認、経理レビューが必要な精算を想像してください。領収書が欠けている場合、その申請は一時停止するのか、従業員に返すのか、却下するのか？そのルールが最初から明確でなければ、チームは後でメールやコメントで穴を埋めることになります。

曖昧なステータス名も別の手戻りを生みます。「In review 2」や「Pending action」のようなラベルは一見無害ですが、人々に次に何が起きるかを推測させます。明確な名前は問題、所有者、結果、または次のステップのいずれかを示すため、ミスを減らします。

所有権もワークフローが壊れる場所です。申請が誰のものでもない状態に留まってはいけません。待機中のケースには必ず誰かが責任を持ち、前に進める、追加情報を求める、またはクローズする役割を担わなければなりません。そうでないと沈黙の遅延が積み重なり、ユーザーはシステムが申請を失ったと思ってしまいます。

部分承認も扱いが悪いことが多いです。チームは単純さのためにそれを全面的な却下のように扱いがちですが、これらは異なる結果です。フライト、ホテル、食費の申請でフライトとホテルだけ承認され食費が否認された場合、そのケースは専用の経路、固有のメッセージ、そして多くの場合フォローアップのアクションを必要とします。

部分承認が却下と一緒くたにされると、人々は申請を再提出し、書類を重複させ、既に完了しているレビューをやり直します。これが純粋な手戻りです。

簡単なテストが役立ちます：ハッピーパス以外の各ステータスを読み、「誰が所有し、ユーザーは何を見るか、次に何が起きるか？」と問いかけてください。答えがあいまいなら、その場所でプロセスは将来また壊れるでしょう。

構築前の簡単チェック

画面を作ったり自動化したりする前に、混乱するケースをもう一度確認してください。良い例外パス設計は、多くの場合、混乱が手戻りに変わる前に早めに決める少数の明確な判断です。

申請が却下、保留、または部分承認された場合、次に何が起きるか、誰が行うか、どの情報が欠けているかは常に明確でなければなりません。

各例外について次の簡単チェックを実行してください：

• すべての例外に担当者がいる。
• すべてのステータスが一つの明確な次のステップに繋がっている。
• 欠けている項目は平易な言葉で明記されている。
• 部分承認にはルールがあり推測ではない。
• 期限が明確である。

その後、簡単なテストを行います。設計に関わっていない人にプロセスを渡し、却下された申請と一つの書類が欠けた申請を渡してください。1分以内に何をすべきか説明できなければ、プロセスはまだあいまいです。

小さな例で要点が分かります。マネージャーがソフトウェア申請を承認しハードウェア部分を却下したとします。ステータスが「部分承認」のみだと、従業員はすべてが進められると誤解するかもしれません。より良いステータスは何が承認され、何が否認され、従業員が欠けている部分を再提出できるかどうかを正確に示します。

これらのルールを実働アプリに落とし込むなら、まず例外状態をマップしてからハッピーパスを構築してください。AppMasterでは、ステータス、ビジネスルール、必須フィールドを画面より先に定義することで、理想版ではなく実際の業務を扱えるノーコードアプリを作る実用的な方法になります。

次のステップはシンプルです：上位5つの例外を列挙し、それぞれに担当者を割り当て、ユーザーに表示するメッセージを書いてください。この三つが明確なら、構築は通常ずっと容易になります。