画面遷移図と画面遷移表
画面遷移図は、画面の遷移を直感的に理解するのにとても役立つドキュメントです。が、画面の遷移に関する情報は、それぞれの画面個別の仕様書にも書かれている。つまり情報が重複しているため、不整合のリスクを常に抱えた不遇のドキュメントでもありますね。
設計段階でその不整合を除去するための「検算」のネタとして、わたしは「画面遷移表」*1を作ることにしています*2。
ここでいう画面遷移表とは、状態遷移図に対する状態遷移表のようなものを意図しています。つまり、2次元マトリクスの縦軸に遷移元画面が、横軸に遷移先画面があり、その遷移を起こすためのイベントが書かれているものです。
たとえば次の画面遷移図を考えてみましょう。
社員のデータの参照や更新をするシステムとしましょうか。
システムを起動すると、社員の一覧画面が出ます。検索を行ってデータを絞り込み、一覧の中から選んだデータを参照。必要に応じて編集モードにして、内容を編集するといったものとします。
単純化してたった3画面ですが、イベントは14個あります。実際のシステムでは画面もイベントももっと多いですし、イベントが条件分岐するようなことまで考えると、逆に「よく画面遷移表なんて描けるな・・・狂気の沙汰だ・・・」と思ってしまいます（自動化しているところもあるのでしょうが）。
つまり、画面やイベントの数が多くなると、画面遷移図って絶対間違うだろ、とわたしは思っています。なので、検算のために、別ルートから起こした画面遷移表との突き合わせをしたくなるのです。
画面遷移をピボットテーブルで表現する
さて、その画面遷移表をどう作るか。
縦軸と横軸にすべての画面名を書き、各画面の定義書を見ながらセルを1つずつ埋めていくことになるのでしょうか。50画面あったら2,500セル。そんなお絵かきロジックはやっておれぬ。
そこで、Excelマジックを使いましょう。
まずは各画面の画面定義書から、画面遷移に関する情報、つまり「遷移元画面」「イベント」「遷移先画面」の3つを集めます。これはいずれにしても避けられません。イベントと画面遷移の仕様は、定義書内の各地に散らばっているのではなく、1箇所に整理しておくのがよいですよね。
Excel上でこれを1つのデータテーブルにすれば、準備は完了です。例にあげたシステムでは、たとえばこんな感じになります。
次に、このテーブルからピボットテーブルを作成しましょう。行ラベルに「元」「イベント」をおき、列ラベルに「先」をおいて、値は「データの個数」とします。すると、こんなピボットテーブルができます。これが画面遷移表です。一瞬でできるのがステキです。
ピボット遷移表を使ってみる
ピボットテーブルから状態遷移表（以下「ピボット遷移表」）を生成しました。では、このピボット遷移表の利用方法を考えてみましょう。
まず、ピボット遷移表の行ラベルから「イベント」を外してみましょう。すると、「ある画面からある画面への遷移がいくつ存在するか」を表現した表になります。
各セルの数字が、その遷移を起こすイベントの数です。たとえば「A1_一覧」から「A2_参照」への遷移を起こすイベントは、2つあるということになります。数字がない（または0）ならば、遷移がないということですね。
この表では、たとえば次のようなことをチェックできるでしょう。
その遷移はなくて大丈夫？
遷移の仕様を検討するにあたって、「なくてもいいのにある遷移」より、「あるべきなのにない遷移」の方が見つけづらいでしょう。ノードとノードが恣意的に配置される画面遷移図だけでそれを見抜くのは難しいと思いますが、ピボット遷移表では空白セルに注目することでそれがチェックできます。
たとえば上の表では、「A3_編集」と「A3_編集」との交差セルが空白、つまり自分自身に遷移することができません。このことから、「一度編集内容を保存した後、その画面で編集を続ける」といった使い方ができないが、それでいいのか？という気付きに至ります。
そうはいっても、画面が増えれば、ピボット遷移表は空白セルだらけ。そのセルをすべてチェックするのは相当虚しい作業です。ピボット遷移表の拡張によって、その作業を改善する方法を、後ほど紹介します。
その画面はスタート？ゴール？
ピボットテーブルで注意しなくてはならないことがあります。それは、データがなければピボットテーブルにも現れないということです。
たとえば「A3_編集」画面から、「A4_袋小路」画面に飛ぶが、「A4_袋小路」からはどこにも行かないものとして、これをデータテーブルに追加すると、ピボット遷移表は以下のようになります。
「A4_袋小路」は、横軸（遷移先）にはあるが縦軸（遷移元）にはありません。この画面が元になるような遷移が存在しないためです。
このように、ピボット遷移表の縦軸・横軸には、すべての画面が現れるとは限りません。
それが気持ち悪ければ、明示的に、イベントと遷移先を「-」などとしたデータを追加しておくとよいでしょう。これにより、その画面は行き止まりであることが明確になります。開始画面についても同様です。
こうしておけば、ピボットテーブルのフィルタを使って、「遷移先が1つもない画面」「遷移元が1つもない画面」を一覧化することができ、それらの画面から/への遷移がなくていいか、ということに注目したチェックができます。
複数遷移していない？
今一度、行ラベルに「イベント」を追加してみましょう。
今度は行の「総計」（一番右の列）に着目します。これは通常1になります。上で述べた通り、0であればそもそも表に現れません。
2以上になるケースとしては、以下が考えられます。
1. データテーブルに同じデータを2つ以上書いている 2. 誤って、複数の画面遷移を定義してしまっている 3. 本当に、1つのイベントから複数の画面を開く仕様である 4. 条件によって遷移する先が異なる
1.のケースは、総計だけでなく、個別のセルが2以上になっているはずです。データテーブルから重複するデータを消してください。Excel2007以降なら、「重複の削除」という機能を使うと速いですね。
2.のケースは、おめでとうございます。欠陥を検出することができました。どちらかの遷移は誤っているので、検討して設計書にフィードバックしてください。
3.のケースは正直、通常の画面遷移図でもどう表現するべきなのかがわかりません。そんな遷移に出会わないことを祈っています。
4.のケースは、おそらくよくあるものと思います。これはデータテーブルに「条件」列を追加することで解決できます。これについても後述しす。
・・・タイトルは「検算」でしたが、画面遷移図との突き合わせより、仕様検討のネタとしての話ばかりしていることに気付きました。
ピボット遷移表を拡張する
ピボットテーブルを利用した画面遷移の検証についてお話しています。この手法は「トランプ法（TRAMP: Transition Matrix by Pivottable）」といい、我が社では全社的に適用され・・・ているはずもなく、個人的にほそぼそとやってます。名前も今決めました。なお「tramp」を英英辞典で調べると「to travel about on foot」という意味があり、この作業の地味さ加減に合っていますね！
さて、前節までにピボット遷移表の作り方と利用方法をお話しました。
本節では、ピボット遷移表の拡張についてお話します。まずは、いきなりデータテーブルを拡張してみましょう。せーのっ、ドン。
データテーブルの列として、「元機能」「先機能」「*」「分岐」と追加しています。それぞれの意味は以下。
・元機能：遷移元画面が属する機能 ・先機能：遷移先画面が属する機能 ・*：元機能と先機能が一致すれば「機能内」、しなければ「機能間」とするIF文 ・分岐：イベント発生の際の分岐条件
データ行として、元あった機能を「機能A」と名づけて、それと似た様な画面遷移をもつ「機能B」を追加（緑色の行）。たとえば、機能Aは社員登録、機能Bは部署登録というイメージですね。さらに「一覧」画面から、機能Aと機能Bを行き来できるようにしているのが、オレンジ色の行。
また条件分岐として、「A3_編集」画面で「編集終了」ボタンを押下した際、問題なければ「A2_参照」へ（青い行）、入力値エラーなどがあれば「A3_編集」に留まる（赤い行）、という遷移分岐にしています。
一気に書いて意味不明かも知れませんが、勢いつけていきます。
条件分岐を表現する
ピボットテーブルの行ラベルに「元画面」「イベント」、列ラベルに「先画面」、値に「データの個数」を設定してください。すると、ピボット遷移表は以下のようになります（簡単にするため、機能B系の画面は除外してあります）。
「A3_編集機能」で「編集終了」した際の遷移の「総計」が2。確かに、遷移先が2つあります。ここで行ラベルに「分岐」を追加してもいいのですが、ここでは「編集終了」セルをダブルクリックしてみましょう。すると、フィールドを選択するダイアログが現れますので、「分岐」を選択します。
すると、この「編集終了」にのみ、「分岐」の値が表示されます。
これで「総計が1じゃない問題」が解消されました。また、明示的に「分岐」列が表示されることで、「分岐」に値のないイベントについて「本当にないっけ？」という再考を促します。
機能内と機能間でチェックする
今度は、行ラベルを「元機能」「元画面」、列ラベルを「先機能」「先画面」に、値に「データの個数」を設定してください。すると次のようなピボット遷移表になります。
空白セルが多いですね。前節で、遷移漏れのチェックのため空白セルに注目！と書きましたが、大半が空白だとそれはツライ。
この例で、空白はどこに現れているでしょう。よく見ると空白は、機能Aから機能B、あるいは機能Bから機能Aに行くようなセルに多い。機能同士が独立していため、機能間の遷移が少ないということです。
そういうときはまず、機能内に閉じた遷移をチェックしましょう。元・先ともに、機能Bを省いたピボット遷移表が以下です。前節の初めにあるピボット遷移表と、ほとんど変わりませんね。
各機能内をチェックしたら、次に機能間の遷移を見ます。ここで、先の「*」が使えます。ピボットテーブルのレポートフィルタに「*」を追加し、値として「機能間」を選択してください。これにより、遷移元先と遷移で機能が異なるような遷移のみが現れます。ここで、機能をまたがるような画面間での遷移にのみフォーカスしてチェックを行います。
もっと極端には、上のピボットテーブルから「元画面」「先画面」を外します。するとこう。
2機能しかないと面白みがないですが、画面間の遷移からズームアウトし、機能間の遷移の要否を確認するのに使えますね。
以上、ピボットテーブルをいじくり回して、色んなチェックが簡単にできるのでは？というアイデアの紹介でした。
追記
『ウィリアムのいたずらの開発日記』さんのエントリの通り、画面定義書と画面遷移図の一貫性を保つ方法としては、もっとスマートなやり方がありますね。ピボット遷移表はより地味な、愚直系チェックの際に思い出していただければ・・・というところです。
*1:このエントリを書くにあたって「画面遷移表」について調べてみたのですが、上のピボットテーブルで作ったようなものを「画面遷移表」と呼んでいる例が見当たりませんでした。ピボットテーブルを作る前身のデータテーブルのことを「画面遷移表」と呼ぶことはあるようです。状態遷移図-状態遷移表のアナロジーから、前者のことを「画面遷移表」と呼びたいものですが・・・。
調べる中で見つけた『WEBシステムにおける画面遷移図表表記法の提案と効果的なテストケースの作成』（主査・秋山浩一氏、副主査・奥村有紀子氏）という論文にある「XSTD表」というものが、わたしのイメージしている「画面遷移表」の表構成です。
*2: 「画面遷移図と各画面の定義書のうえに、さらにそんなもんを作ったら３重管理になって、むしろ状況が悪化するじゃないか！」と怒られそうですが、このデータテーブルは一生メンテし続けることを意図しているわけではなく、設計がおおよそ固まった時点で、おそらく変転してきたであろう画面遷移の仕様に関する記述の整合性が取れていることをチェックするための、補助的な資料と位置づけています。
