ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その4。
今回は第2回の後半で学んだTransition Diagram（画面遷移図）について。課題はWebサービスの画面遷移を図に表し、現状の構造問題を可視化した上で「ありたい姿」を設計するというものだった。やってみたら、UIデザインの話ではなくビジネス戦略の話になった。
Transition Diagramとは何か
Transition Diagramは、ユーザーがサービスを利用するときの「状態の移り変わり」を図にするツールだ。画面遷移図、状態遷移図とも呼ばれる。
Webサイトやアプリを設計するとき、「今、ユーザーはどの状態にいるのか」「次にどこへ遷移できるのか」を可視化することで、設計上の問題点が浮かび上がってくる。テクノベート・シンキングでは、ありたい姿（To-Be）を描くためのツールとして位置づけられている。
インフラの仕事でも、状態遷移図を扱う場面はある。たとえばサーバーの起動・停止・異常検知・復旧といった状態遷移を設計するとき、あるいは監視ダッシュボードで「正常→警告→障害→回復」の状態フローを定義するとき。ただ、それをユーザー体験の分析ツールとして使うという発想は新鮮だった。
As-Is（現状）を図にした瞬間、構造問題が見えた
課題で選んだのは、多くの人が使ったことがあるであろう「予約系Webサービス」だ。PC版のWebサイトを分析対象にしたのは、画面単位の情報分離が明確で構造を可視化しやすかったからだ。
実際にTransition Diagramに落としてみて驚いたのは、その画面数の多さだった。基本的な予約完了までのフローだけで8画面前後。さらにログイン処理、決済方法の分岐、予約後の変更・キャンセルといった付随処理を加えると、10画面以上を行き来する構造になっていた。
1つ1つの画面は丁寧に作られている。しかし全体をTransition Diagramで俯瞰すると、「断続的で中断しやすい」体験の構造が一目で見えてくる。個別のUI改善では気づけない、構造レベルの問題だ。
ブロック分けで見えた「関心事の混在」
遷移図を整理するために、処理を機能ブロックごとに色分けした。予約フロー、決済フロー、認証フロー、予約後処理──こう分けて色を塗った瞬間、遷移図の見通しが劇的によくなった。
色が混ざっている箇所＝異なる関心事が1つの画面に混在している箇所だと一目でわかるからだ。
たとえば決済フローだけで複数の分岐がある。支払い方法ごとに遷移先が完全に変わる。しかも、この分岐はフローの終盤にあるため、ここで迷ったユーザーが離脱する可能性が高い。最も慎重になるべきステップに、最も複雑な構造が来ている。
認証フローも興味深い。ログインはフローの冒頭でも途中でもできるが、いつログインするかによって以降のフローが微妙に変わる。会員情報が自動入力されるタイミングが異なるのだ。一見ユーザーフレンドリーに見えて、実は遷移図を複雑にしている最大の原因だった。
画面単位ではなくブロック単位で構造を見ることで、個別のUI改善では解決しない根深い問題が浮かび上がった。これはインフラ設計で「レイヤーごとに問題を切り分ける」手法と同じ発想だと感じた。
「可視化」の力──描いた瞬間に見えるものがある
今回の課題で最も強く感じたのは、「頭で理解しているつもりのことも、図に描くと初めて見えるものがある」ということだ。
サービスを普段ユーザーとして使っているときは、「画面が多いな」とぼんやり感じる程度で、それが構造的な問題なのかどうかまでは考えない。しかしTransition Diagramに落とした瞬間、「ここに分岐が集中している」「このブロックだけ異常に複雑だ」「戻り導線が設計されていない」──具体的な問題箇所がピンポイントで浮かび上がる。
これはインフラ設計でも経験がある。ネットワーク構成を頭の中だけで把握しているつもりでも、構成図を描くと「この経路、冗長化されていない」「ここがボトルネックになりうる」と気づく。可視化は分析そのものだ。描く行為が思考を強制的に整理し、曖昧さを許さない。
ビジネスの場面でも同じことが言える。業務フローを口頭で説明するのと、フロー図に落とすのとでは、得られる理解の深さがまるで違う。テクノベート・シンキングでTransition Diagramを学ぶ意義は、ツールそのものの使い方だけでなく、「可視化することで構造問題を発見する」という思考法を身につけることにあると感じた。
To-Be（ありたい姿）を描く──ステップの圧縮と連続的な体験
As-Isの問題を踏まえて、To-Be（ありたい姿）を設計してみた。
核心はシンプルで、多数の画面遷移を最小限のステップに圧縮するというもの。条件入力と選択を1画面のマルチステップフォームで一括処理し、ページ遷移なしで次のステップに進める。情報入力と支払をまとめ、最終確認で完了する。
戻り操作も、画面を遷移し直すのではなく同一画面内でステップを戻れる構造にする。入力済みの情報は保持されたまま。「断続的で中断しやすい」を「連続的で完結型」に変える設計だ。
もちろん、これは「理想論」であって、実装にはシステム面の大きな制約がある。レガシーな基幹システムとの連携、セッション管理、決済APIの仕様──そういった技術的な事情が、今のAs-Isの画面構造を生んでいることは容易に想像できる。IT畑にいる私としては、「なぜ簡単に変えられないのか」の理由も同時に見えてしまう。だからこそ、To-Beを描くときには「技術制約を理由にしない」というルールを自分に課した。
「暫定的最適解」の正体──現在の最適は未来の最適ではない
As-IsとTo-Beを並べて考える中で気づいたのが、現状のUIには「なぜそうなっているか」の理由がちゃんとあるということだ。
画面数が多いのは、ネットに不慣れなユーザーへの配慮で、1画面の情報量を減らし、1ステップずつ丁寧に確認させる設計思想から来ている。「1画面で全部やる」より「1画面1アクション」の方が、迷いにくく、誤操作も減る。コールセンターへの問い合わせを減らすという運用コストの観点からも、この設計には合理性がある。
つまり、今のUIは現時点の主要顧客層に合わせた「暫定的最適解」なのだ。「使いにくい」のではなく、「ある層にとっては使いやすい」。
しかし、この「暫定的」がいつまで持つかは別の問題だ。モバイルネイティブ世代──スマホで育ち、2〜3タップで完結する体験を「普通」と感じている層──が顧客の中心になるにつれて、「手順が長い」「戻れない」「デザインが重い」という評価が主流になっていく。今の最適解は、5年後の最適解ではない。
この問題は特定の業界に限らない。オンラインバンキング、保険の見積もりサイト、行政のオンライン申請──多くのサービスUIに同じ構造の「暫定的最適解」が存在する。世代交代が進んだとき、この暫定解を引きずっているサービスは一気に「使いにくい」の烙印を押される。
ここで重要なのは、「暫定的最適解」を批判することではなく、そのライフサイクルを見極めることだ。今の設計が合理的である理由を理解した上で、「いつ、どのタイミングで、どこから変えていくか」を計画できるかどうか。Transition Diagramは、そのリスクを事前に見積もるツールにもなると感じた。
Transition Diagramとインフラ畑のつながり
今回の課題を通じて面白かったのは、Transition Diagramの考え方がインフラ畑の発想と意外なほど近かったことだ。
たとえば、監視ダッシュボードの設計。サーバーの状態が「正常→注意→警告→障害→復旧」と遷移するフローを設計するとき、まさに状態遷移図を描く。「どの状態からどの状態に遷移できるか」「戻れない遷移はないか」「想定外の状態に遷移した場合のフォールバックはあるか」──これらはすべて、今回のサービスフロー分析と同じ問いだ。
あるいは、ネットワーク構成図。パケットがどのルートを通ってどの機器を経由し、最終的にどこに到達するかを設計する作業も、本質的にはTransition Diagramと同じ構造を持っている。
違うのは、「誰の視点で遷移を見るか」だ。インフラ設計ではシステムの視点で遷移を見る。今回の課題ではユーザーの視点で遷移を見る。同じツールを使いながらも、見る角度を変えるだけで、まったく異なる気づきが得られる。
さらに言えば、インフラ設計では「異常系の遷移」を徹底的に洗い出す。正常系だけなら遷移図はシンプルだが、タイムアウト、リトライ、フォールバック、ロールバック──異常系を加えた瞬間に複雑さが爆発する。今回のUI分析でも同じことが起きた。基本的な予約フローだけならシンプルだが、ログインのタイミング違い、決済方法の分岐、エラーからの復帰──「例外的な遷移」を加えた瞬間に構造の複雑さが一気に上がる。この共通性に気づけたのは、インフラ畑にいる私にとってかなり大きな発見だった。
学び：画面遷移の設計はUIの問題ではなく、ビジネス戦略の問題
テクノベート・シンキングの授業では、Transition Diagramは「ありたい姿を描くためのツール」として紹介された。
実際にやってみて、その意味がよくわかった。現状（As-Is）を図にするだけで構造的な問題が可視化され、そこから逆算してTo-Beを設計できる。「今何が問題か」ではなく「全体の状態遷移の中でどこに歪みがあるか」を見る視点が手に入る。
そして異なるタイプのサービスを比較したことで、もう一つの大きな学びが得られた。画面遷移の設計はUIの問題ではなく、ビジネス戦略の問題だということ。「どんなユーザーに、どんな体験を提供し、どこで収益を上げるのか」という経営判断が、遷移図の構造にそのまま表れる。UXデザインは見た目の改善ではなく、事業の意思決定そのものだった。
たとえば、画面数を極限まで削って衝動的な購買を最大化するサービスもあれば、1画面ずつ丁寧に確認させて安心感を重視するサービスもある。どちらが「正しい」かではなく、どちらがそのサービスのビジネスモデルに合っているかが本質だ。遷移図の構造を見れば、そのサービスが何を大事にしているかが透けて見える。
業務システムの設計でも画面遷移図を使うことはあるが、「ユーザー体験の構造問題を炙り出す」という目的で描くのは新鮮だった。技術的な設計ツールとしてだけでなく、ビジネス判断のツールとしてTransition Diagramを使えるようになったのは、この回の一番大きな収穫だった。
次回：バブルソートで「アルゴリズム」の本質に触れる
第3回ではいよいよアルゴリズムの話に入る。シンプルなソートアルゴリズムを自分の手で組み立てることで、「良いアルゴリズムとは何か」を体感した話を書く。