状態遷移図とは何？ 状態遷移表・フロートチャートとの違いや書き方を解説

状態遷移図（ステートマシン図）とは何か

「状態遷移図（ステートマシン図）」とは、さまざまな条件・イベントによってソフトウェアやシステムの状態が変化する様子を、図形や矢印などの記号を用いて視覚的に表現したもののことです。文章だけで表すよりも、より俯瞰的にソフトウェアやシステムの仕様を把握できます。以下は状態遷移図の簡易的な例です。

これは家電製品をイメージすると理解しやすいかもしれません。例えば、冬場にエアコンを使用するときには、まず停止しているエアコンの電源をオンにして動作を開始させます。そして運転モードを暖房に切り替え、風量や風向、温度などを調整し、状況に応じて自動タイマーを設定したり電源をオフにしたりします。

この「電源をオンにする」「運転モードを切り替える」といった動作が図中の「イベント」に該当し、それらイベントによって動作が切り替わる前後のエアコンの様子が「状態」です。こうした一連の流れを網羅的かつひと目でわかるように示したものが状態遷移図です。

状態遷移表やフロートチャートとの違い

システム全体像や処理フローを把握する手法にはいくつかあり、状態遷移図と類似したものに、状態遷移表とフローチャートがあります。それぞれ共通する要素を持つ一方で、システムの動的なふるまい、状態ごとのイベント処理方法、アルゴリズムの流れなど各手法の得意分野は異なります。詳しく見ていきましょう。

状態遷移表とは

状態遷移表とは、システムの「状態」とシステムに起こる「イベント」をマトリクスで表現したものです。言葉としては状態遷移図と似ており、どちらも仕様の全体像を把握することに適している点では同じですが、その用途は異なります。

状態遷移図は、各状態とイベントを結びつけて図示するため、システムの全体像を俯瞰的に捉えながら挙動の流れを把握することができます。一方の状態遷移表は、各状態とイベントの「組み合わせ」を網羅的に検討できるため、仕様として不足しているイベントの存在や、無効な組み合わせを細かく検討できます。以下は状態遷移表のイメージです。

この表からは、例えば以下のような流れを把握することが可能です。

仕様を検討する設計工程では、特に重要視している機能のイベントや、複雑な条件の下で発生するイベントに関しては入念に検討されている場合が多いとされます。その一方で、よくある処理や細かな例外処理などに対するケアが甘いまま放置されてしまうことは少なくありません。また、開発途中でメンバー間に認識のズレが起こるなどすれば、余計な手戻りが生じてしまいます。

そういった状況を防ぐためには、仕様の検討や詳細設計を行う際に状態遷移表を積極的に取り入れて、各状態やイベントの組み合わせ、想定される挙動などを明確に整理しておくことが効果的です。

状態遷移図と状態遷移表はそれぞれに異なる特徴を持つため、どちらか片方ではなく両方を作成し、目的に応じて相互補完的に活用することが望ましいといえます。なお、それぞれの作成方法や作成時のポイントについては、のちほどご紹介します。

フロートチャートとは

状態遷移図とフローチャートの主な違いは、表現の焦点と用途にあります。

状態遷移図は、「システムの状態」と「状態間の遷移」を示すことで、特定の条件・イベントに応じたシステムの動的なふるまいを理解するのに役立ちます。例えば、ECサイトで「『商品の追加』操作を行えば、空だったカートの中身が変化する」という様子を状態遷移図で表せます。

一方、フローチャートは、プロセスや手順の「流れ」を表現し、アルゴリズムのステップ・バイ・ステップの流れを理解しやすくします。例えば、ECサイトでの商品注文から配送までの手続きを順序立てて示すのに適しています。

状態遷移図のメリット

状態遷移図を作成する最大のメリットは、仕様書を細かく読み込まなくても、システムの全体像をひと目で把握できる点です。その理解のしやすさから、重要な認識に対して開発メンバー間で誤解が生じるような状況を減らすことができます。具体的には、以下のようなメリットが挙げられます。

• システムの全体像と処理フローを明確に把握しやすく、抜け漏れが発生しにくくなる
• イメージの共有が容易なため、開発時に認識のズレを抑えられる
• 対処すべきポイントを判断しやすく、不具合の発生や仕様の変更に迅速に対応できる

なお、事前知識がない状態で状態遷移図を扱うことは難しいため、不慣れな場合には状態遷移図のルールや概念を学習して読み解く訓練が必要です。その学習コストを費やしたとしても、認識共有や急な修正対応のしやすさといった観点から、開発時に得られるメリットは大きく、状態遷移図の活用は有効だと考えられます。

状態遷移図のデメリット

状態遷移図を作成するデメリットには、以下のような点が挙げられます。

• 作成や更新に一定の手間がかかる
• 状態ごとのイベント処理方法が把握しにくい

状態遷移図の作成には、仕様書を確認してシステムの全体像を把握することが欠かせません。そのため、仕様書の分量が多く、複雑な仕様であるほど、状態遷移図の作成や更新にかかる労力は大きくなります。

また、状態遷移図によって仕様を把握しやすくなっても、状態ごとのイベント処理方法はわかりにくいという難点があります。状態ごとのイベント処理方法を網羅的に可視化するためには、状態遷移表が有効です。

状態遷移図の作成手順

状態遷移図を構成する要素はさまざまにありますが、初めて作成する場合は、まず大まかなイメージをつかむことが大切です。ここでは最も基本的な作成手順を3つのステップで説明します。

なお、当記事の後半には少々複雑な「活用事例」もご紹介していますが、状態遷移図の作り方は、慣れてしまえば決して難しいものではありません。

状態を書き出す

最初に、すべての状態を書き出します。状態の表現には四角形を用意し、その中に状態名を書きます。例えば扇風機を想定した場合には、最低限、「電源オフ」の状態と「電源オン」の状態があると考えられます。

さらに、風量レベルを「強」「弱」で調整したり、首振りモードの「オフ」「オン」を選択したりするなど、変化する状態がほかにもある場合には、対応する四角形と状態名を追加します。ここで表現している図は簡略化したものですが、この段階で仕様書に記されている状態を抜けもれなくすべて書き出すことが肝心です。

遷移を矢印で表現する

書き出したそれぞれの状態を矢印で結びつけ、状態の遷移を可視化します。扇風機の場合は、リモコンの電源ボタンを操作することで「電源オフ」の状態と「電源オン」の状態を変化させることができるため、以下のように表現します。

このとき、遷移を表す矢印は必ず特定の一方向を示すものである必要があります。「電源オフ」と「電原オン」のように、互いに遷移が発生する状態について表現する場合には、双方向の矢印を用いて1本にまとめるのではなく、一方向のみを示す矢印を2本記載します。これは、矢印一つひとつに対してどのようなイベントが起こるのかを明示する必要があるためです。

イベントを矢印のそばに記入する

最後に、矢印のそばにイベントを記載します。イベントとは状態遷移を発生させるきっかけとなる情報のことで、どのような動作によって何が起こるのかがわかるように記載する必要があります。例えば扇風機の場合なら、電原オフの状態で電源ボタンを押すとモーターが動作して羽が回転し、風が発生します。詳しく表すと下図のようになります。

イベントの書き込みまでが完成したら、改めて全体を確認します。状態として図の中にあるにもかかわらず、ほかのどの状態とも矢印で結びつけられていないものがあれば、その箇所が不備だとわかります。再び仕様書を確認し、適切な遷移が可能となるように修正が必要です。

なお、状態の遷移を表す矢印は必須ですが、イベントの書き込みは場合によって省略することも可能です。

状態遷移図を作成する際の2つのポイント

実際の現場で状態遷移図を作成する際には、ドキュメントなどから詳細な情報を得ることが必要です。ただし、開発を急ぐあまり仕様がドキュメント化されていなかったり、仕様書に更新漏れがあったりするケースもあり、常に完璧な状態で進められるとは限りません。

ここでは、テスト工程において、テスト担当者が少ない情報から状態遷移図を書き起こす場合のポイントをご紹介します。

すべてのイベントを洗い出す

すでに試作品などの動く「現物」がある場合、まずは状態を変化させるイベントをすべて洗い出します。

例えば、ECアプリのGUI画面であれば、配送時の要望を伝えるための「入力フォームへのテキスト入力」や、購入検討中の商品に対する「一時保存ボタンの押下」など、状態の遷移につながるイベントを挙げます。そして遷移元の状態と遷移先の状態を矢印で結びつけ、その矢印のそばにイベントの詳細を記します。

この図のように、まずは「状態A」を起点として「イベント1」「イベント3」を書き出し、状態Bと状態Cについても同様に、起こり得るすべてのイベントを洗い出します。

遷移パターンに過不足がないかを確認する

状態遷移図の作成がある程度進められたら、改めて遷移パターンに過不足がないかを確認します。以下の図では、状態Cから状態Bへの遷移パターン、つまり「イベント6」が本当に存在しないのかを確かめる必要があることがわかります。

ただし、開発途中の現物から状態遷移図を書き起こす際には、「そもそものイベント内容や遷移の仕方、遷移後の状態が正しいものなのかどうかは、テスト担当者には判断しきれない」という点に注意しなければなりません。完成した状態遷移図が正しく仕上げられているかどうかは、仕様を熟知している責任者に確認をとる必要があります。

状態遷移表の作成方法

状態遷移表は、主に仕様書や状態遷移図に基づいて作成します。ここでは、「START」「STOP」「RESET」の機能を備えたストップウオッチの状態遷移を例に挙げて説明します。

まずは縦軸に遷移前の状態を、横軸にイベントを記載し、二次元のマトリクス形式の一覧表を作ります。そして、各状態からそれぞれのイベントを経てどのような状態に変化するのかを記して、表を埋めていきます。

状態遷移表には「遷移しない箇所が明確になる」という特徴があります。遷移しない箇所は仕様書にも記載されていない場合が多く、状態遷移図でも直接的には表現できません。なお、上表の仕様を状態遷移図で表すと以下のようになります。

表が完成したら、状態遷移図と同様に内容面での正確性について責任者に確認をとり、不備があれば修正を加えていきます。この表によってすべてのイベントを洗い出すことができるため、状態遷移図を作成する前段階で作成することもあります。

状態遷移表を作成する際のポイント

状態遷移表の作成時には、状態とイベントを網羅的に洗い出すことが大切です。以下の表で「状態C」の行に目を向けると、状態Aへの遷移パターンはある一方で状態Bへ遷移するパターンがないことがわかり、「イベント6」が抜けている可能性を検討できます。

なお、各状態やイベントを網羅的に検討した結果、遷移する状況がない、または仕様として元から起こり得ない状態については、「-」のほかに、「N/A（Not Applicable）：該当なし」を入力することもあります。

また当然ながら、複雑な仕様であればあるほど、状態の数もイベントの数も多くなり、さまざまな遷移パターンが生じます。状態遷移表と状態遷移図のそれぞれの特徴を押さえつつ、相互に補完しながら作成、使い分けることで、遷移パターンを過不足なく反映できます。

状態遷移テストで仕様ベースの確認が可能

テスト技法の一種である「状態遷移テスト」によって、仕様ベースでの挙動に不具合がないかを確認できます。状態遷移図と状態遷移表に基づき、以下の内容を検査します。

• 有効な状態遷移が適切に行われるか
• 無効な状態遷移が行われないか

状態遷移図による状態遷移テスト

状態遷移図による状態遷移テストでは、遷移図の中に表現された有効な状態遷移が、描かれたとおり適切に行われるかを網羅的に確認します。

状態遷移が複雑なケースでは、ソフトウェアやシステムの全体像や動作の流れを直感的に理解しにくくなり、テスト設計での抜け漏れが発生しやすいという問題があります。状態遷移図の活用によって状態の遷移を視覚的に把握しやすくすれば、さまざまなテストのパターンを網羅的に検討することが可能になります。

状態遷移表による状態遷移テスト

状態遷移表による状態遷移テストでは、「-」や「N/A」で示された無効な状態遷移を含めて、表で表現されたすべてのパターンを考慮してテストしていきます。

状態遷移表では、状態とイベントのすべての組み合わせを詳しく把握できるため、設計段階では定義されていなかった挙動を確認することも可能です。結果として、本来は必要であるはずの仕様の検討漏れを防ぎ、テストケースの抜け漏れを防ぐことにつながります。

状態遷移図の活用事例3選

携帯電話で通話を行う状態遷移図の例

まずは基本的な事例を紹介します。以下は、携帯電話を利用して任意の相手と通話を行うプロセスを表した状態遷移図です。

通話の「接続」または「切断」のイベントを中心として、「待機中」「着信中」「発信中」「通話中」の4つの状態が遷移します。こちらが発信を試みた場合のみ条件分岐が発生し、相手が通話中の状態だった場合には再び「待機中」に戻り、相手が待機中の状態だった場合には接続され、「発信中」の状態へと移ります。

なお、黒塗りの円は「初期状態」を、中に黒塗りの円がある記号は「終了状態」を表します。

中学卒業から大学生になるまでの状態遷移図の例

次に、より多彩な構成要素を持つ例を紹介します。以下は、中学校を卒業した状態から「大学生」になるまでを形式的に表した状態遷移図です。

大学生になるためには、高校を卒業するか高卒認定試験に合格したのち、大学受験で合格する必要があります。高校に進学する場合、卒業までには3年生まで進級を繰り返す必要があります。

遷移を表す矢印に記している「大学受験[合格] / 入学」は、「契機[条件] / 効果」の書式にのっとり、受験で合格して大学に入学することを意味しています。高校生の箇所は、複数の状態を内包する「合成状態」で表し、両端の白丸とバツ印の丸はその入り口と出口を表す記号です。

空港での搭乗手続きにおける状態遷移図の例

最後に、少々発展的な事例をご紹介します。以下は、空港での接客業務を担うスタッフの立場で、搭乗手続きに必要な手順を簡略化して表した状態遷移図です。

まず、搭乗予約が適切になされているかを照合して、問題がなければ、予約内容に基づいて搭乗券の発行と荷物の預かりを並行して行います。その後、搭乗者へ渡航に必要な書類を渡してプロセスが終了します。予約の確認ができなかった場合には、空港の旅行代理店に案内するなどして対応します。

このような状態遷移図は、航空会社が手続きの流れを効率化し、不要なプロセスを取り除く方法を考える上で役立ちます。

まとめ

ここまで、状態遷移図（ステートマシン図）について、メリットや作成手順、状態遷移表との違いをはじめ、具体的な活用事例も挙げながらご紹介しました。

状態遷移図は、多彩な条件やイベントに応じてソフトウェアやシステムの状態が移り変わる様子を視覚的に表現したものです。状態遷移表と組み合わせるなどして有効活用できれば、より俯瞰的にソフトウェアやシステムのふるまいを把握でき、不具合の発生や仕様の変更にも迅速に対応することが可能になります。