俯瞰思考とは、物事を分解するときに考える軸が2つ以上あるなら、軸を掛け合わせた表を作って全パターンを洗い出す方法です。会議で話している1つのケースだけでなく、表の空いているマスが「まだ考えていない組み合わせ」として目に見えるようになります。この記事では、軸の選び方と表の埋め方を、業務設計とシステム設計の例で説明します。
なぜ抜け漏れが起きるのか
要件定義のあとで「この場合はどうなるんですか」と聞かれて詰まる経験は、上流工程に入ったばかりのエンジニアなら一度はあるはずです。原因の多くは、知識不足よりも、いま議論している1つのケースしか見えていないことにあります。
たとえば問い合わせ窓口の改善を話し合っていて、議題が「個人のお客様からの電話対応」だったとします。議論は電話の話で盛り上がり、そのまま方針が決まります。しかし実際には、問い合わせの相手は個人のほかに法人もあり、チャネルは電話のほかにメールやWebフォームもあります。
| 電話 | メール | Webフォーム | |
|---|---|---|---|
| 個人 | ← 今話している | ? | ? |
| 法人 | ? | ? | ? |
表にすると、議論したのは6マスのうち1マスだけだとわかります。問題は、議論を始める前に「これは何と何の組み合わせの話か」を決めていないことです。
俯瞰思考を使う条件
いつでも表を作ればよいわけではありません。次の3つが揃ったときに使います。
- 達成したい目的がある（設計する、決める、整理する）
- その目的のために対象を分解しようとしている
- 分解の視点、つまり軸が2つ以上見つかった
軸が1つなら、イシューツリーのような階層での分解で足ります。イシューツリーは問いを1つの切り口で枝分かれさせる道具で、俯瞰思考は切り口が2つ以上になったときに表で網羅する道具です。イシューツリーで分けた枝の1つを、さらに2軸で整理する使い方もできます。
会話の中で次のような言葉が出たら、軸が隠れている合図です。
| 聞こえた言葉 | 隠れている軸 |
|---|---|
| 「〇〇の場合は」 | 別の値が抜けていないか |
| 「誰が担当するのか」 | 役割（ロール）の軸 |
| 「どのデータについて」 | データの種類の軸 |
| 「この状態のときは」 | ステータスの軸 |
| 「それはどのお客様の話か」 | 顧客の種類や規模の軸 |
3つのステップ
ステップ1：軸を特定する
いまの議論で変わりうる条件は何かを考えます。軸は次のどれかから選ぶと外れにくくなります。
- 対象が増えたり減ったりする軸（顧客の種類、ロール、拠点）
- 条件で分岐する軸（操作の種類、問い合わせの種類）
- 時間とともに変わる軸（業務のステップ、ステータス）
ステップ2：全パターンの表を作る
各軸がとりうる値を書き出し、掛け合わせて表にします。この時点ではマスは空のままで構いません。空のマスが見えることに意味があります。
ステップ3：マスを埋める
目的に応じて、マスに入れる内容を決めます。
| 目的 | マスに入れるもの |
|---|---|
| 業務設計 | 担当者、手順、必要書類、対応期限 |
| 課題整理 | 論点、調べること、打ち手 |
| システム設計 | 操作権限、遷移先のステータス |
| 意思決定 | 判断基準、承認者、エスカレーション先 |
最初から全部のマスを正確に埋めようとすると手が止まります。まずは「○（ある）／×（ない）／不明」の3段階で粗く埋めます。「不明」のマスが、次のヒアリングで確認すべき論点の一覧になります。
実務でよく使う3つの型
型1：業務マトリクス
縦に顧客や問い合わせの種類、横に担当やチャネルを取り、マスに対応方法を入れます。先ほどの問い合わせ窓口の例を埋めると、次のようになります。
| 電話 | メール | Webフォーム | |
|---|---|---|---|
| 個人 | 一次窓口で即答、難しければ折り返し | 2営業日以内に返信 | 自動返信のあと担当が返信 |
| 法人 | 担当営業に転送 | 担当営業に転送 | 担当営業に自動で通知 |
表にすると、法人はチャネルによらず担当営業に回すルールで揃えられそうだ、と気づけます。個人のWebフォームだけは自動返信の文面を決める必要がある、という作業も見えてきます。
型2：CRUD表
縦にデータの種類、横にロールを取り、マスに作成（C）・参照（R）・更新（U）・削除（D）の権限を入れます。ある会社の備品貸出システムを例にすると、次のとおりです。
| データ | 一般社員 | 総務担当 | 管理者 | 外部の保守業者 |
|---|---|---|---|---|
| 貸出申請 | CRU（自分の分） | RU | CRUD | ー |
| 備品マスタ | R | RU | CRUD | R（担当機器のみ） |
| 貸出履歴 | R（自分の分） | R | R | ー |
表を作ると、外部の業者にはデータの範囲を絞る必要があること、削除を管理者だけに限定していることが一目でわかります。誰も更新できないマスや、必要以上の権限を持っているロールがあれば、それは設計の見直し候補です。
型3：ステータス×ロール表
縦にステータス、横にロールを取り、マスにできる操作と次のステータスを入れます。この型では、ロールの列に必ず「システム自動」を加えてください。通知やデータ連携のような、人が操作しないけれど実装が必要な処理を拾うためです。
| ステータス | 申請者 | 承認者 | 総務担当 | システム自動 |
|---|---|---|---|---|
| 下書き | 作成・編集・申請 | ー | 参照 | ー |
| 承認待ち | 参照・取り下げ | 承認・差し戻し | 参照 | 承認者へ通知 |
| 承認済み | 参照 | 参照 | 貸出処理 | 申請者へ通知 |
| 貸出中 | 参照 | 参照 | 返却処理 | 返却期限の前日に通知 |
| 差し戻し | 編集・再申請 | 参照 | 参照 | 申請者へ理由を通知 |
| 返却済み | 参照 | 参照 | 参照 | ー |
「システム自動」の列を埋めると、通知が4か所必要だとわかります。この列がない状態で仕様を書くと、通知の実装が抜けやすくなります。また、申請者が編集できるのは下書きと差し戻しのときだけ、というルールもこの表で確認できます。ステータスの設計そのものはステータス設計とテーブル分割の記事で詳しく扱っています。
表を作ったあとの確認
表ができたら、次の4点を見ます。
- 空のマスの意味を区別する。「その組み合わせは存在しない」のか「まだ考えていない」のかを分けます。後者はヒアリングの論点です
- 同じ内容が並ぶ列や行を探す。ルールを1つにまとめられる可能性があります
- システム自動にできるマスを探す。人がやっている処理のうち、ルールが決まっているものは自動化の候補です
- 全部のマスに担当がいるか確かめる。誰の責任でもないマスは、運用が始まってから問題になります
よくある失敗
- 軸を決めずに議論を始める。話しやすいケースから話し始めると、その1マスで結論が出てしまいます。議題を出す前に「今日は何と何の組み合わせを話すか」を書き出します
- 軸を増やしすぎる。3軸、4軸と増やすと表が読めなくなります。まず2軸で作り、どうしても必要なら軸の値ごとに表を分けます
- 全マスを完璧に埋めようとする。粗く埋めて「不明」を残すほうが、次に何を聞けばよいかがはっきりします
- 「システム自動」列を入れない。ステータス遷移の表でこの列を省くと、通知やデータ連携の実装が漏れます
- 空のマスを「なし」と決めつける。考えていないだけのマスを「該当なし」として扱うと、リリース後に問い合わせが来ます
この記事のまとめ
- 俯瞰思考は、分解の軸が2つ以上あるときに、軸を掛け合わせた表で全パターンを洗い出す方法
- 抜け漏れの原因は、議論している1マスしか見えていないこと
- 手順は「軸を特定する→表を作る→マスを埋める」の3ステップ。最初は○×不明で粗く埋める
- 実務で使う型は業務マトリクス、CRUD表、ステータス×ロール表の3つ
- ステータス×ロール表には「システム自動」列を必ず入れる
俯瞰思考はロードマップのステップ3「課題を構造化する」で学ぶ技術で、仮説思考と並んで、要件定義の抜け漏れを減らす土台になります。軸の選び方と例題の全体はFDEガイドの「俯瞰思考」で読めます。スライド、ワークシート、演習問題、テストは lecture.iplot.jp で取り組めます。