状態遷移図とは？状態遷移表との違いや書き方のコツをわかりやすく

ソフトウェアの開発を行う際、同じテストを繰り返したり、テストの内容に抜けがあったりして開発がストップする事態が発生してしまうことがあります。

無駄な時間や労力を少しでもカットするために設計段階で活用されているのが「状態遷移図」です。

状態遷移図とは状態が遷移する様子を図に書いて図形や矢印などで表現したものです。状態遷移図では四角で表現された「状態名」、矢印で表現された「遷移」、その矢印のそばにどういう動作を行ったのか記入する「イベント（アクション）」で構成されます。

これは状態遷移図のイメージです。

上記のように状態遷移図を作成すると、仕様書に文章で個々の遷移について記載があるものを読むより、状態遷移全体の流れを視覚的に捉えることができます。

図に描かれた矢印を遷移の経路として、その通りに動くかどうか確認します。ソフトウェアの様々な経路のパターンを作成することでテストケースを導き出し、動作の全体像を掴むことができます。開発者とテスト担当者で完成イメージを共有するためにも、状態遷移図は非常に有用です。

開発仕様書だけでは全体の流れが適切ではないことも多々あり、必要な遷移が漏れてしまうことがあります。状態遷移図は、そのような設計の不備を見逃すことなく発見できます。

「状態遷移表」は、システムに何らかのイベントがある場合に、状態がどのように変化するかを表で示したものです。
各状態の遷移ごと、また状態とイベントの掛け合わせごとに表形式で表します。

それぞれの特徴は以下の通りです。

• 状態遷移図
  システムの全体像、一連の流れを理解しやすい
• 状態遷移表
  全ての状態とイベントの組合せを網羅でき、図では見えない、且つ想定しないイベントの対処も確認できる

下記は状態遷移表のイメージです。

状態遷移図はシステム全体を俯瞰で確認できますが、状態ごとのイベントの処理方法は分かりにくいという難点があります。
これに対して状態遷移表は、状態ごとのイベントの処理方法を網羅的に表せます。

このように、状態遷移図は「全体を俯瞰できる」というメリットがあり、状態遷移表は「各状態の動きを細かく漏らさず確認する」のに役立ちます。

状態遷移図と状態遷移表はどちらか片方ではなく、両方作成して活用することをおすすめします。

それぞれ「出来ること」「出来ないこと」が異なるため、目的によって使い分け、場合により相互補完的に利用していくと、効果的に活用できます。

状態遷移図と状態遷移表のどちらも利用することによって、状態遷移の全体の流れの把握、開発仕様書の抜け漏れの防止を行うことができます。それぞれの特徴をいかして、テスト設計に取り入れてみると良いでしょう。

状態遷移図を作成することにより、以下のメリットを得られます。

• 直観的に仕様を理解しやすい
• 仕様変更にも対応しやすい

それぞれ事項で詳しく解説します。

状態遷移表に比べて、状態遷移図は直観的に仕様を理解しやすく、開発に携わるメンバー間で認識齟齬が発生しにくいという利点があります。

仕様書で遷移を個別に確認することなく、流れをわかりやすく一覧することができ、プロジェクトのメンバー間で作業の全体的なイメージを合わせることが可能です。
また、何か不具合が発生した際に、状態遷移図を参照することで対処するポイントがすぐにわかります。

急な仕様変更の要望があった場合でも、状態遷移図上で修正することで、変更箇所をメンバー間で共有しやすくなります。

クライアントの要望で作業途中に仕様が変更されても、状態遷移図を活用すれば修正する時間を減らすことが期待できます。分析、設計の段階で状態遷移図を作成して発生する遷移をモデリングすると、仕様の漏れや抜けを発見しやすくなるのも大きなメリットです。

この章では、状態遷移図をどのように作成すれば有効に使えるかご紹介します。
状態遷移図を作成する際にはぜひ参考にしてみてください。

状態遷移図を書く前に、まずは状態遷移表を作成することでイベントを洗い出すことができます。
状態遷移表は、状態、イベントを網羅的に洗い出すことが大切です。遷移できない、仕様として起こりえないことについては「－」や「／」などを入力していきます。

設計で想定していない状態とイベントの組み合わせは、何が起こるか開発者も分からないことが多々あります。そのため、あらかじめ設計時に想定されたイベントよりもバグが潜みやすい部分となっています。
そのようなバグを検出できるテストを実施するために、状態遷移表は非常に効果的です。

ここから状態遷移図を書いていきます。
まず四角を作成し、そこに状態名（状態にふさわしい名前）を書き入れていきます。

状態名を書き出したいが、どう見つればよいかわからない時はシステムが待機している状態を探してみましょう。

状態遷移図の次にある状態から他の状態へ移行するものを矢印でつなぎます。その矢印が遷移です。
2つの状態名を矢印でつなぐことにより、状態がどう変化するか流れがわかります。

ここで注意するべきことは、矢印の向きは必ず1方向のみ記入するということです。もし互いを遷移で結ぶことがあっても、必ず1方向の矢印を2本使って互いを結びましょう。後述するイベントやアクションを記入するため、矢印は1方向で書く必要があります。

遷移の矢印のそばに、どういうことが起きて、状態が遷移したかというきっかけとなる情報「イベント」を記入します。
さらに遷移に付いてくる動作（アクション）があれば記入します。

また、逆方向の矢印（この図では「オン」から「オフ」）にも忘れずにイベントを記入し、遷移におけるアクションがあればそれもイベントの隣に記入しましょう。

状態遷移図を書き終えたら、状態名を1つずつチェックしていきます。どこにも遷移をしていない、どこからも遷移をされていない、複数遷移されているなど、遷移の数が0や複数ついている状態名は仕様の不備になります。必ず確認し、修正しましょう。

いかがでしたでしょうか？
状態遷移図を作成することで、遷移の道筋が一覧でき視覚的にわかりやすくなります。仕様書で遷移を個別に確認するよりもより全体のイメージが掴みやすくなり、開発に携わるメンバー間で共有しやすくなります。

今回はシンプルなものを例に挙げて説明しましたが、ソフトウェアの構造が複雑になると、状態名や遷移も、その分多くなります。抜けや漏れをなくすため、状態遷移図を作成する際は、複数名で確認を行うとより安心です。

状態遷移図をマスターして、手戻りを防ぎ、無駄なコストや時間の発生を防ぎましょう。