アプリを作るときに現実の例外を扱う方法

なぜきれいなアプリフローは現場で失敗するのか

図に描いたきれいなフローは、人が順序どおり、必要なデータを揃えて、適切なタイミングで動くことを前提にしています。現実の仕事はめったにそうではありません。誰かが申請を遅らせる、管理者が病欠する、顧客が重要な情報を抜かす、あるいは支払いに最初から想定されていなかった特別承認が必要になることがあります。

だから最初のバージョンはデモでは問題なく見えても、実際の利用が始まると壊れ始めます。ハッピーパスは動きますが、日常業務は長くハッピーパスのままでいません。

安全な出発点は、きれいな設計が不完全だと仮定することです。小さなズレで要求は大きく変わります。1つの欠落フィールド、1人の特殊な顧客、1つの遅れた承認がプロセス全体を止め、人々を途方に暮れさせます。

よくある失敗は案外シンプルです。

• 承認が進んだはずが、承認者が不在で停止する。
• 必須の詳細がまだ分からず、レコードを保存できない。
• 特殊ケースが通常ケースと同じ扱いをされ、後で手作業で直さなければならない。

これはちょっとした不便以上の問題です。1つの変則が後ろにあるすべてを塞ぎます。スタッフはチャットやスプレッドシート、メールでの回避策を使い始め、アプリが仕事の唯一の場でなくなります。

より良い目標は簡単です：ルールを書く前に例外を集めること。データがないとき、タイミングがずれたとき、要求が標準経路に当てはまらないときにどうなるかを尋ねる。そうした混乱した事例は副次的なものではなく、あなたのアプリが現実で機能するかを決めます。

最初に見つけるべき例外

最初に捕まえるべき問題は珍しい端っこケースではありません。毎週起きてきれいなワークフローを静かに壊すような出来事です。強い初版を作りたいなら、作業が遅延・停止・人の判断に委ねられる箇所を探してください。

遅れた承認は通常トップに来ます。管理者が締め切り後に承認する、給与処理が終わった後に承認される、あるいは在庫が既に発注済みの後に承認される。アプリはその瞬間に対するルールを必要とします。元のルートを再開するのか、新しいリクエストを作るのか、財務に通知するのか、それともレビューに回すのか――放置して「時間通り届いた」ふりはできません。

欠落データもよくある障害です。税ID、領収書、配達日、顧客連絡先が空のままフォームが送信されることがあります。次のステップがそのフィールドに依存しているなら、曖昧なエラーで止めるべきではありません。保留にして何が足りないかを示し、修正しやすくするべきです。

特殊ケースは、通常経路の限界を露呈します。ほとんどの返金は簡単でも、一定額を超える返金は追加の証拠が必要かもしれません。ある部署だけ別の承認ルールを使っていることもあります。これらは新しいアプリを作る必要はありませんが、明確な分岐が必要です。

最初のパスで見ると有用なのは次の4パターンです：元のルートに従えないほど遅れて到着する承認、次のアクションを塞ぐ欠落情報、別ルールが必要な珍しい要求、そしてシステムが停止して人に確認を求めるべき瞬間。

人的レビューは失敗ではありません。データが矛盾している、ポリシー上例外がある、または高コストの判断が必要なときは、人的確認が最も安全な選択であることが多いです。保留されたレビューキューは、見えないミスよりずっとマシです。

これらの例外を早期に見つけられれば、最初のバージョンはずっと現実的で脆弱さが少なくなります。

実例をどこで集めるか

悪い例外を見落とす最速の方法は、プロセスを設計したマネージャーだけに聞くことです。本当の問題は毎日仕事をする人のところにあります。どのステップが飛ばされるか、どのフィールドがよく空になるか、どの承認が遅れるか――彼らが知っています。

短い会話から始めましょう。人に通常のケースを説明してもらい、次に最後に混乱したときに何が変わったかを聞きます。プロセス全体の広い意見を聞くのではなく、本当の話を求めてください：何が起きたか、何が足りなかったか、誰が直したか、手作業で何をしたか。

過去の仕事も有益です。過去のメール、サポートチケット、チャット、引き継ぎメモは、きれいなフローが壊れた正確な瞬間を示すことが多いです。人々がトラブル時に使う言葉が残っているため、ドキュメント化された手順よりも生々しい情報が得られます。

また人が使っているサイドツールを確認しましょう。誰かが例外を追うためにスプレッドシートや付箋リスト、個人用ドキュメントを持っているなら、それは強いシグナルです。回避策は理由があって存在します。初日からアプリが必要とするルールを暴いてくれます。

最初にレビューすべきベストソースは、影のシステム（スプレッドシートや個人チェックリスト）、欠落情報や手動承認を求めるメールスレッド、緊急対応のチャット会話、遅延や却下を示すサポートチケット、そして直近で失敗したケースのフルタイムラインです。

特に直近の失敗ケースは重要です。古い要約より、最近の失敗の方がイベントの連鎖を正確に示すことが多いからです。承認が締め切り後に来るパターン、顧客が必要なファイルを送らないパターン、誰も文書化していない特別ルールを使っているパターンが見つかることがあります。

もしチャットベースのビルダーで最初のバージョンをスケッチするなら、ロジックを生成する前にこれらの例を集めてください。混乱したケースが早く見えるほど、安全なフローを作りやすくなります。

混乱した話をアプリのロジックに変える方法

理論ではなく、まずは実際の1件から始めましょう。チームメイトに説明するように書いてください：何をしようとしていたか、何がうまくいかなかったか、誰が介入したか、どう終わったか。

例えば「管理者が休暇中でリクエストが詰まったあと、財務が1つのフィールドが欠けたまま後で承認した」というような混乱した話の方が、きれいなフローチャートより有用です。どこで普通は壊れるかが分かるからです。

ストーリーからルールへ

各ケースから4つの事実を抜き出します：何が起きたか、誰が判断したか、なぜその判断をしたか、アプリが次に何をするべきか。

これにより画面ではなく振る舞いに焦点が当たります。初日からすべての奇妙なケースを網羅することが目標ではありません。繰り返し起こるパターンを見つけることが目標です。

いくつかのストーリーが集まったら、似たもの同士でまとめます。シンプルなバケットが自然に現れます：遅れた承認、欠落情報、間違った人が求められた、重複リクエスト、一定額以上で必要になる特別承認など。

次に各バケットを、動く最小限のルールに変えます。そのルールは常に完全自動である必要はありません。警告、保留、手動レビューが最良の選択であることもあります。

例えば承認が承認者不在で遅れたなら、アプリは24時間後にリマインド、48時間後に代替承認者へ再割当て、あるいはレビューへ回す、といったルールが考えられます。重要なフィールドが欠けているなら、ハードストップにするより下書き保存＆あとで戻れる仕組みの方がよいことが多いです。プロセスを止めずに問題を隠さないためです。

Koder.aiのようなチャットベースのツールで構築している場合、平易な言葉で書かれたケースはとても役立ちます。実際の決定に基づく最初のワークフローが作りやすくなります。

実例でテストする

ロジックを確定する前に、実際の事例を2〜3件通してテストしてください。基本的な質問を投げます。フローは実際のケースと同じ結末にたどり着くか？ 情報が欠けたときに安全に失敗するか？ 人に確認を求めるべきときに保留するか？

答えが「いいえ」なら、すぐに複雑化しないでください。まずそのルールをもっとシンプルな言葉に書き直しましょう。説明できない巧妙なルールより、明確なルールのほうが良いワークフローを生みます。

シンプルな例：経費承認

まずはきれいなバージョンを考えます。従業員がクライアント訪問で42ドルのタクシー代を申請し、日付・金額・プロジェクト名・領収書を添付します。マネージャーが給与締め切り前に承認し、財務が次の支払いに含める。

この経路は簡単にモデル化できますが、それだけでは不十分です。

最初の例外を加えます。従業員は期日内に申請したが、マネージャーの承認が給与締め切りの1日後に来た。アプリは何もなかったかのように通してはいけませんし、単に却下するべきでもありません。

良い対応は「締め切り後に承認された」という明確なステータスに移すことです。そこで支払いを次サイクルまで保留し、従業員に新しい支払日を通知し、会社の方針で手動のオフサイクル支払いが許される場合のみ財務へ回す、などの処理ができます。

そのためアプリは1つ以上の日付を保存する必要があります。申請日、承認日、どの締め切りを逃したかを追跡すべきです。

次に2つ目の例外を加えます。従業員が領収書を忘れ、マネージャーは説明だけで承認した。2日後に領収書が届く。

よく作られたアプリなら、ケースが消えたり最初からやり直したりしません。「領収書待ち」で保留にし、リマインドを送り、オープンな状態を保ちます。領収書が後でアップロードされたら、ケースは再開されて、まだ必要なステップだけに送られます。

このようなフローはシンプルな状態をいくつか通ります：submitted（申請済み）、waiting for manager approval（マネージャー承認待ち）、approved after cutoff（締め切り後承認）、on hold for missing receipt（領収書待ち）、そして財務レビューのためにreopened（再開）など。

これが実務での例外処理の実際です。アプリは単にYes/Noを決めるだけでなく、保留するか、ルーティングするか、再開するかを、コンテキストや日付、責任を失わずに判断します。

欠落データをフローを壊さずに扱う方法

情報の欠落は正常であり、稀な端っこケースではありません。アプリがすべてのフォームが初回で完全になることを前提にすると、現実のユーザーが必ずギャップにぶつかります。より良いルールはシンプルです：次のステップに必要なものだけを要求する。

段階ごとに計画してください。今アプリが知っておくべきことは何か、後でもよいものは何かを区別します。経費申請なら、提出段階では金額と従業員名が必要でも、最終的な領収書は支払い前で良いかもしれません。こうすることで管理を落とさずに作業を進められます。

未完成の作業を見える化する

ユーザーは一部の詳細が欠けていても進捗を保存できるべきです。再開できる下書きは、最初からやり直しを強いるフォームよりずっと良いです。欠落情報がマネージャーやベンダー、財務など他者に依存する場合は特に重要です。

わかりやすいステータスは誰にとっても助けになります。短くスキャンしやすいラベルにしましょう：情報待ち、書類不足でブロック中、レビュー必要、承認準備完了、差し戻しなど。

これらのラベルは2つの役割を果たします。現在の状態を示すと同時に、どんな問題に対処すべきかをユーザーに伝えます。

欠落項目ごとにオーナーを決めましょう。税IDがないなら誰が追加するのか？ 領収書が不明瞭なら誰が差し替えるのか？ 承認メモが足りないなら誰が提供できるのか？ 修正の担当が決まっていないと、レコードは宙に浮きます。

簡単な例を挙げます。従業員がホテルからの領収書をまだ受け取っていないために領収書なしで出張経費を申請する場合、アプリは「領収書待ち」のステータスで保存・申請できるべきです。財務は残りをレビューでき、従業員は何が足りないか分かり、申請は見えないエラーに消えません。

いつ自動化し、いつ人に聞くか

自動化は、同じ入力がほぼ毎回同じ結果をもたらすときに最も有効です。要求が明確なパターンに従うならルールを与えましょう。答えが欠けた文脈、珍しいタイミング、判断を要する場合は、人に任せます。

この分け方は重要です。通常のケースではアプリを速く動かし、不明瞭なケースでは減速させます。誤った自動判断は短い手動レビューより手間を増やすことがあります。

簡単なテストがあります：同じデータを見せたら2人のメンバーが同じ判断を下すか？ もしそうなら自動化してよい。そうでなければ人を残しましょう。

自動化に向くのは、必須フィールドがすべて揃った完全なフォーム、ポリシーの範囲内の要求、明確な締め切りを持つ繰り返し作業、常に同じ経路を辿る承認などです。

推測してはいけない状況もあります：重要な詳細が欠けている、要求が通常パターンを破っている、ルール同士が矛盾する、コストやリスクが高い、または誰かの説明が必要なときです。

例えば行き先がない、日付が差し迫っている、通常の限度を超える費用がある旅行リクエストなら、アプリは賢くするのではなくケースをフラグし、フローを停止して適切な人に回すべきです。

同じくらい重要なのは、例外の理由を常に見えるようにすることです。なぜアプリが停止したのか、どのルールがトリガーされたのか、何が足りないのかを示してください。レビューが速くなり、後でワークフローを改善しやすくなります。

避けるべき一般的な間違い

多くのアプリプロジェクトはロジックを書く前に間違いを犯します。チームがきれいな経路だけを描き、人々がそれに従うと仮定し、毎週起きる奇妙なケースを無視するのです。これが簡単なワークフローをサポートチケットや手動修正、混乱したユーザーの原因にします。

最初の間違いは、仮定だけで設計することです。承認や欠落フィールド、例外の起き方を推測すると、最も重要なケースを見逃します。マネージャーが遅れて承認する、顧客レコードが半端なまま届く、支払いが通常と違う理由で追加レビューが必要になる――こうしたことは実際に起きます。

別の間違いは、異なる状況を1つの曖昧なルールに押し込むことです。「何かおかしいときは管理者へ送る」というルールは柔軟に聞こえますが、誰が管理者なのか、何が「おかしい」のか、誰も2日間返信しなかったらどうするのか、といった新たな問題を生みます。

またアプリが全面的な再入力を強いるとユーザーに害になります。1つのドキュメントが欠けているか、1人の承認者が却下しただけで全てを再入力させるべきではありません。より良いフローは進捗を保存し、問題を明示し、ユーザーがブロックされている部分だけを直せるようにします。

見落としがちなその他の問題は、タイミング、所有権、履歴です。副次的ではありません。承認が締め切り後に来たとき、アプリは受け入れるか、エスカレーションするか、再開するかを知る必要があります。ケースがブロックされたら次のアクションの責任者が必要です。ステータスが変わったら誰がいつそれを変えたかが見える必要があります。

監査履歴は単純な理由で重要です。誰が値を変えたか、誰が例外を承認したか、いつステータスが移ったかを知る必要があります。

ロジックを生成する前の簡単なチェック

ワークフローをルールに変える前に、入力が実際の仕事と一致しているかを一旦止まって確認してください。きれいな図は遅延や混乱、後の手動修正の原因となる奇妙なケースを見逃しがちです。

簡単なレビュー項目：

• 推測ではなく実例から始める。
• 各例外を一文で名付ける。
• ブロックされたケースの所有者を決める。
• 欠落情報からユーザーがどう回復するか確認する。
• 開始から終了まで現実的なシナリオを1つテストする。

短い実例テスト1件で弱いロジックが露呈することが多いです。例えば仕入先名なしで提出された購入リクエストがあり、その後部門長が遅れて承認したとします。依頼者は欠落フィールドを修正できるか？ アプリはリクエストを再開すべきか、継続すべきか、財務に確認を求めるべきかを判断できるか？

これがロジック生成前に欲しいレベルの詳細です。短く現実的なストーリーが、安全な初版と実運用時の驚きを減らします。

安全な初版の次のステップ

小さく始めましょう。ビジネス全体ではなく1つのワークフローを選びます。次に、毎日仕事をする人から5件の実際の例外ケースを集めます。例えば遅れた承認、領収書欠落、マネージャーの不在、重複リクエスト、財務の介入が必要だったケースなどです。

その狭いワークフローと5つのケースを中心に最初のバージョンを作り、ルールは読みやすく保ちます。リクエストが不完全なら何が足りないかを表示する。承認が遅れたらいつリマインドするか、いつエスカレーションするか、いつ保留にするかを決める。通常経路と合致しない場合は誰がレビューするかを明確にする。

次に関係者を使ってテストします：申請者、最初の承認者、例外を直す人、エスカレーションを受けるマネージャー、最終結果を見る人。

どこで止まるか、推測するか、助けを求めるかを観察してください。そうした瞬間はスムーズに動いた箇所より重要です。もし3人が同じステップで詰まるなら、そのルールか画面を変える必要があります。

例えば経費アプリは、タクシー領収書にプロジェクトコードがなく送られた、あるいは月次締め切り後に送られた時点で問題が起きます。初版はすべての稀なケースを解決する必要はありません。よく起きる例外をキャッチし、次の行動を説明し、人的レビューのはっきりした道筋を残すことが重要です。

その後は小さなラウンドでルールを調整します。混乱を生むステップは削り、繰り返し起きる問題を防ぐためにフィールドを追加する。リマインドのタイミングが早すぎる・遅すぎるなら調整する。実運用での小さな修正は、早すぎる複雑な特殊ケースロジックより効果的です。

素早くプロトタイプしたければ、Koder.aiのようなチャットベースのビルダーが、実例を段階的に動くアプリに変えるのに役立ちます。ポイントは変わりません：まず混乱したストーリーを集め、それを中心にルールを作ることです。