UIより先に承認マトリクスを設計する — 画面の前にルールをマップする

画面はマトリクスがないと失敗する理由

見た目が整った画面でも、裏のプロセスが混乱していれば役に立ちません。承認ロジックを先に定義しなければ、ユーザーは「承認」「却下」ボタンを見ても、誰がいつ行動すべきか、次に何が起きるのか分かりません。

その混乱は実務であっという間に現れます。誰かが申請を出し、アプリに届くと最初の疑問は「これ、マネージャーに行くのか、経理か、両方か？」というものです。画面は完成しているように見えても、意思決定の経路が欠けています。

これは画面がルールを簡単に見せてしまうから起きます。フォームはステータス、コメント、操作ボタンを表示できますが、背後にある本当の承認マトリクスを推測することはできません。金額に応じた制限や部署ルール、一時的な代行者があると、そうしたケースが出始めた瞬間にUIは破綻し始めます。

多くの場合、例外が一つ出ただけで作業はアプリ外へ流れます。通常は部署長が承認するはずでも、緊急案件や一定金額を超える場合、あるいは承認者が休みのときは別の扱いになる場合があります。もしそのケースがマップされていなければ、人々はメールやチャット、スプレッドシートへ頼ることになります。

そしてさらに大きな問題が出ます：各チームが独自のルールを適用し始めるのです。オペレーションはある方法で送信し、経理は別の方法を取り、サポートはHRとは違う例外処理をします。アプリは一貫性のない決定のための共用画面になり、共通のプロセスではなくなります。

警告サインはたいてい見つけやすいです：

• 次のステップの担当者をユーザーが尋ねる
• 同様の申請がチームごとに違う結果になる
• 例外がチャットやメールで処理される
• ポリシー変更のたびに画面が変更されるべきになってしまう

ポリシー更新はこの弱点をすぐに露呈します。ロジックが画面内に埋め込まれていると、閾値の変更や役割変更のたびにUIの手直しが必要になります。それが作業を遅らせ、エラーを生み、ユーザーの信頼を損ないます。

画面は意思決定の経路を反映すべきであって、経路を定義すべきではありません。マトリクスを先に明確にしておけば、UIはよりシンプルで安定し、使いやすくなります。

ワイヤーフレームより先にマップすべきこと

画面ではなく意思決定ロジックから始めてください。しっかりした承認マトリクスは、誰が何を承認できるか、どの条件で、誰が不在のときにどうなるかを示すシンプルな表として始まります。ロジックが曖昧だと、どれだけ見栄えの良いインターフェースでもユーザーを混乱させます。

各申請タイプごとに、承認レベルを順番にマップしてください。各ステップを所有する役割と、そのステップでできること（承認、却下、レビュー、差し戻しなど）を書き出します。人名ではなく役割で管理する方が良いです。人は異動するしチームも変わるので、プロセスは耐えられる必要があります。

次にルートを変えるルールを定義します。金額は明白なトリガーですが、通常それだけではありません。承認ルールは地域、部署、ベンダー種別、申請カテゴリ、リスクレベルに依存することが多いです。同じ金額でも、あるチームでは日常的で別のチームでは敏感な案件かもしれません。

欠勤時のルールも必要です。主な承認者が不在なら誰が代わりに担当するのか？代行が期限付きならどの日付が適用されるのか？これが決まっていないと、今週は誰が担当か分からず申請が止まります。

時間制限も同じくらい重要です。返答がない場合に何が起きるかを決めてください。1日後にリマインダー、2日後にエスカレーション、3日後に運用に通知する、といった選択はステータスラベル、通知、キュービューに影響するため、画面設計の前に確定しておくべきです。

実用的なマトリクスは通常、以下の5つの基本的な問いに答えます：

• どの条件がこのルールを発動させるか？
• この段階で承認する役割は誰か？
• バックアップは誰か？
• 承認者にはどれくらいの時間があるか？
• 締切が過ぎたらどうなるか？

これらの答えを早期にマップすれば、残りの作業がずっと楽になります。

マトリクスを段階的に作る方法

テーブル、ホワイトボード、スプレッドシートを使ってください。マネージャー、チームリード、プロセスオーナーが一巡で理解できるほどシンプルに保ちます。

まず、承認が必要なすべての申請タイプを列挙します。既に業務上別扱いになっているものを無理に一つの汎用フローに押し込めないでください。購買申請、返金、値引き承認、アクセス要求は、それぞれ異なる承認者、上限、期限を必要とすることが多いです。

次に最初の承認者と、その後の各分岐点を書きます。各申請タイプについて、誰が最初に確認し、承認や却下の後に何が起きるかを記録します。最終的に承認、却下、差し戻し、キャンセルなどの結論に至るまで経路を追います。

その後、ルートを変える閾値を追加します。ここで多くのチームが後でつまずきます。例えば$500未満はチームリード、$500以上は部署長、といった具合です。緊急の申請がステップを飛ばすならそれも記載してください。

さらに例外、期限、終了状態を記録します。不足書類や重複申請、ポリシー違反、承認の遅延などのケースを含めます。問題が発生したときにどう振る舞うかが分かっていなければルールは完成していません。

最後に、現在承認を行っている人々と草案をレビューします。作業が通常どこで滞るか、人がどこでステップを飛ばすか、通常の承認者が不在のときに何が起きるかを尋ねます。実際の習慣は、文書化されていなかったルールを明らかにすることがよくあります。

小さな例を挙げれば分かりやすいでしょう。事務用品の購入申請を想定します。$200未満はチームリード、$200〜$2,000は部署マネージャー、それ以上は経理の確認も必要、という場合、フォームが金額とカテゴリを早期に取得していないと、UIは正しい経路に送れません。

実際に従える閾値を設定する

閾値は人がすばやく読んで毎回同じ選択ができるときにだけ機能します。「小さな購入」や「高リスクベンダー」といった表現は人によって解釈が分かれます。固定の数値、日付、明確な条件を使ってください。

より明確なルールの例：「1,000ドル以下はチームリードへ。1,001ドル〜5,000ドルは部署マネージャーへ。5,000ドル超は経理とディレクターの承認が必要。」誰もどこへ属するかを推測する必要がありません。

金額は一般的なトリガーですが、プロセスが他の要素に依存するならそれだけに頼ってはいけません。新規ベンダーからの安価なソフトウェア購入は、承認済みサプライヤーからの大きな注文よりも厳しく見られる場合があります。

多くのチームは少数のルーティングルールで十分です。よくある例は金額帯、ベンダーのステータス、購入カテゴリ、部署、緊急度です。重要なのはルールの多さではなく、誰もが同じ方法で適用するかどうかです。

ルールの順序も重要です。どの条件が優先されるか分からなければ、同じ申請が違う人によって違うルートへ送られます。優先順位を一つに決めて一貫性を保ってください。ベンダーステータス→カテゴリ→金額の順にチェックするのか、金額を先にチェックして例外を後で処理するのか、どちらでも構いません。重要なのは全員が同じ順序に従うことです。

また閾値を誰がいつオーバーライドできるかを定めるとよいです。それがないと担当者は待ちすぎたり、プロセスをメールやチャットで迂回したりします。「月末の締め時は経理ディレクターが上限超えの承認を行える」といった明確な例は有用です。「上級リーダーは例外を認める」といった曖昧な表現は避けてください。

シンプルなテストが有効です：同じ例の申請を3人に渡してどこに行くべきか尋ねてみてください。3人が違う答えを出すなら、閾値はまだ曖昧です。

フォールバック承認者、代行、エスカレーションを計画する

強固なマトリクスは主たる承認者だけで終わりません。誰かが休暇や病欠で不在、または単に応答しないときにも業務は進み続ける必要があります。早めにそれを計画していないと、画面は整っていてもプロセスは止まってしまいます。

まず各重要ステップのフォールバック承認者を特定します。これは単に「次のマネージャー」とするのではなく、適切なコンテクストを持つ人物や役割にしてください。例えば、特定額以上の経費を承認する経理担当が不在なら誰が代わるのかを決めます。

一時的な代行には制限を設けてください。代行には休暇期間など、定義された期間だけ承認権限を与えるべきです。そうすることで責任が明確になり、本来与えるべきでない期間まで承認権限が残るのを防げます。

シンプルな設定は次の4点に答えるべきです：主な承認者は誰か、バックアップは誰か、代行はどれくらいの期間行動できるか、そしていつリクエストが上位に移動するか。

エスカレーションは明確なトリガーに基づくべきです。時間、金額、リスク、情報不足などが一般的です。例えば10,000ドル超の購入申請が24時間放置されたら部署長へエスカレーションする、などです。

エスカレーション経路は短く保ちましょう。次に誰が受け取るか理解するのに複雑な図が必要なら、そのルールはおそらく複雑すぎます。1〜2段階の明確なジャンプで十分なことが多いです。

各決定の記録も残してください。誰が承認したか、誰が代行したか、引き継ぎがいつ起きたか、なぜエスカレーションしたかを保存します。後になって遅延の理由や代行承認の理由を問われたときに、その履歴が必要になります。

もう一つ重要なルール：ループを避けること。リクエストが既に承認した人に戻ったり、同じ人の代行に再度回ったりするべきではありません。アプリロジックを組む前にマトリクスを循環経路がないかチェックしてください。

シンプルな例：購買申請の承認

小さな会社が日常品を購入する場面を想像してください。従業員が1回の購買申請を行い、品目、金額、理由、必要日を記入します。ルーティングは誰がオンラインかではなくルールによって決まります。

申請が$420ならチームリードに直送されます。小額の購買が滞らないようにするためです。$3,200の申請はチームリードを飛ばして部署マネージャーへ行きます。予算への影響が大きいためです。

$7,800の機器購入になると部署マネージャーが確認しますが、それだけでは不十分です。金額が$5,000を超えるため経理のレビューも必要になります。ここでマトリクスが役立ちます：金額が大きくなるほどコントロールを増やすが推測は不要にするのです。

欠勤も重要です。部署マネージャーが不在なら申請は停滞してはなりません。指定された代行者が自動的に受け取り、定義された期間だけ行動できます。

時間制限も同レベルで明確にします。誰も2日以内に対応しなければ申請はオペレーションへエスカレーションされます。オペレーションはフォローアップ、割り当て直し、または作業が止まらないように措置を取ります。

この例では、マトリクスがいくつかの重要な問いに答えています：申請金額、各金額でどの役割が承認するか、いつ経理が入るか、欠勤時の代行、期限超過時の処理です。

これらの答えが定義されれば、画面設計は簡単になります。フォームは適切なデータだけを要求し、申請ページは現在の承認者、代行、エスカレーションのカウントダウンを表示すればよくなります。

再作業を招く一般的なミス

多くの再作業は画面が描かれる前に始まります。チームが承認経路を推測し、その後で合意されていないルールにUIを当てはめようとします。

よくあるミスの一つは組織図をそのままワークフローと呼ぶことです。一見きれいに見えるかもしれませんが、実際の申請は金額、リスク、場所、申請タイプで動くことが多いです。マトリクスがそれを無視すると、後で画面に余計なフィールドや状態、例外処理が必要になります。

また特別なケースを忘れることも問題です。緊急申請、規制対象の購入、部門横断の申請は別ルートが必要なことが多いです。そうした例外を早期にマップしないと、人々は手動の回避策を求め、インターフェースは一時的なオプションで溢れて混乱します。

2人に同じ仕事を与えて決め手がない状態もトラブルを生みます。両者が承認できるなら誰が先に行動するのか？意見が分かれたとき誰の決定が有効なのか？その答えがなければ申請は行ったり来たりして信頼を失います。

代行ルールも弱点になりがちです。代行は不在をカバーするためのものです。いつまでも第二のオーナーになってしまうべきではありません。一時的なカバーと恒久的な所有権が混ざるとレポートは混乱し責任が不明瞭になります。

ルーティングが確定する前にフォームを設計すると再作業が発生します。フォームは一見完成していても、承認ルールが最終決定されると金額帯、部署、緊急度、ポリシーフラグなどの必須フィールドが欠けていることに気づきます。するとレイアウト、バリデーション、通知を変更する必要が生じます。

早めに現実チェックを行うと発見が早まります：

• 同じ申請を2人の承認者が同時に受け取れるか？
• 一時的なバックアップと恒久的な所有者に明確な差があるか？
• 緊急や規制対象のケースは別ルートか？
• 各ルーティング判断は既存のフィールドに依存しているか？
• ある承認者が会社を去った場合でもプロセスは成り立つか？

どれかが不明ならそこで止めてください。画面を磨く前にマトリクスを修正してください。

画面設計前のクイックチェック

フォームやステータスバッジを描く前に、ロジックを平易な言葉で説明してテストしてください。良い承認マトリクスは図を開かなくても説明しやすいはずです。マネージャー、経理責任者、オペレーション担当者が1分ほどでルートを説明できないなら、UI作業に進むにはまだ曖昧です。

実際の例を使って素早くレビューします。1人に申請から最終決定までの全経路を説明してもらい、あらゆる可能な結果に対して次に名指しの承認者がいるかを確認します。曖昧な閾値は「$1,000以下」や「10%以上の値引き」など正確なルールに書き換えます。フォールバックやエスカレーションは「24時間後」「2営業日後」のように明確な時間制限を使ってください。

次にトレーサビリティをテストします。後で誰かがなぜ申請が遅れたのか、誰が例外を承認したのか、代行がいつ入ったのかを尋ねるでしょう。プロセスはこれらに答えられるようにしておくべきです。タイムスタンプ、決定履歴、明確なステータス変更はオプションではなくルールセットの一部です。

簡単なシナリオで弱点が露呈します。例えば金額$4,800の申請が金曜午後に届き、通常の承認者が不在だった場合を想像してください。次に誰が受け取るか？システムはどれくらい待つか？バックアップも何もしなかったらどうなるか？これらが書かれていなければ、UIは混乱を隠すだけです。

これらのチェックに合格すれば、画面設計はずっと楽になります。何を表示すべきかを推測する必要がなく、明確なルールに基づいて形を作れます。

次のステップ：マトリクスを実働アプリにする

ルールが明確になったら、画面を磨く前にプロセスを組み立ててください。まずロジック、データフィールド、承認ステータスを作ります。ルーティングが機能すれば、インターフェース設計はずっと簡単になります。ルーティングがまだ流動的なら、見た目の良い画面は問題を隠すだけです。

実用的な最初のバージョンには基本が含まれます：申請タイプ、金額、部署、現在の承認者、最終ステータス、各決定の履歴。そして申請を進めるルール、フォールバック承認者へ送るルール、誰も応答しないときにエスカレーションするルールを追加します。

最初の画面はシンプルに保ってください。申請者は提出、ステータス確認、追記への対応ができればよく、承認者はレビュー、承認、却下、再割り当てができれば十分です。それだけで日常運用でワークフローが有効かどうかテストできます。

合理的な構築順序は次の通りです：

• コアとなるデータフィールドとステータス値を定義する
• 閾値、フォールバック承認者、代行、エスカレーションのルーティングルールを追加する
• 申請者と承認者向けの基本画面を作る
• すべてのチャネルが同じ真実のソースを参照するようにする
• 広く展開する前に1件の実際の申請を最初から最後までテストする

この「共通の真実のソース」は多くのチームが想像するより重要です。モバイルで一つのステータス、Webパネルで別のステータス、バックエンドで別の閾値が使われていると、信頼はすぐに失われます。

もしAppMasterでこれを構築するなら、明確なマトリクスが設定をずっと簡単にします。データ、ビジネスロジック、承認フローを先にモデル化し、その同じプロセスをバックエンド、Web、モバイルに渡して、別々のツールでルールを書き直す必要をなくせます。

最初のテストには実際のケースを1件だけ使ってください。閾値、代行承認者、期限超過のエスカレーションを伴う購買申請を実際に動かし、人がどこで躓くか、どのデータが不足するか、どのステータスラベルが混乱を招くかを観察します。

その後で文言とレイアウトを改善してください。実際の申請でプロセスが機能すれば、画面設計はずっと楽になり、1週間後に作り直す可能性も低くなります。