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

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

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

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

なお作成の際はUML（統一モデリング言語）という共通のルールに従って、状態遷移図を作成します。

状態遷移表や状態遷移図との違い、開発における利点や書き方ついてはこちらをご覧ください。
状態遷移表とは？状態遷移図との違いは？開発における利点や書き方のコツを解説

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状態遷移図は、システムの振る舞いを視覚的に表現する強力なツールですが、設計時にはいくつかの重要な注意点があります。

状態が細かすぎると図が複雑になり、逆に粗すぎるとシステムの詳細な動作が表現できません。システムの目的に合わせて、適切な粒度で状態を定義することが重要です。

状態間の遷移を漏れなく記述することで、システムのあらゆる動作を正確に表現できます。特に、例外的な状況やエラー処理も考慮に入れることが重要です。

イベントは状態遷移のトリガーとなるため、具体的かつ明確に定義する必要があります。曖昧なイベントは、システムの誤動作やバグの原因となる可能性があります。

ガード条件は、状態遷移の条件を詳細に記述するために使用されますが、過剰に使うと図が複雑になり、理解しにくくなります。ガード条件は必要最小限に留め、状態遷移図をシンプルに保ちましょう。これらのアンチパターンに陥ると、状態遷移図がシステムの設計や理解を妨げるだけでなく、開発やテストの効率を低下させる可能性があります。アンチパターンを理解し、適切な設計と作成方法を心がけることで、状態遷移図はシステムの品質向上に大きく貢献するでしょう。

状態遷移図が複雑になりすぎると、理解や保守が困難になります。そのため、いくつかの工夫が必要です。まず、状態の階層化です。状態をグループ化し、階層構造にすることで、複雑な状態遷移を整理できます。次に、状態遷移表との併用です。状態遷移図と状態遷移表を組み合わせることで、状態遷移の全体像を把握しやすくなります。さらに、ツールを活用することも有効です。状態遷移図作成ツールは、図の作成や編集を効率化し、複雑な図の管理を容易にします。また、レビューを徹底することも重要です。複数人で状態遷移図をレビューすることで、設計上の誤りや改善点を見つけやすくなります。これらの注意点と工夫を考慮することで、状態遷移図はシステムの設計と理解を強力にサポートするツールとなるでしょう。

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

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

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

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

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

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

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

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

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

状態遷移表は、状態とイベントの組み合わせを網羅的に記述し、システムの動作を詳細に把握するための有効な手段です。状態遷移表を作成することで、仕様の網羅性向上、テストケースの作成効率化、関係者間の認識共有、仕様変更への対応力向上など、多くのメリットが得られます。

状態遷移表は、考えられる全ての状態とイベントの組み合わせを記述するため、仕様の抜け漏れを防ぎ、網羅性を高めます。特に複雑なシステムにおいては、状態遷移図だけでは表現しきれない詳細な条件や例外的なケースも、状態遷移表を用いることで明確に記述できます。

状態遷移表は、テストケースの作成を効率化します。状態遷移表を基にテストケースを作成することで、網羅的かつ効率的なテスト設計が可能となり、テストケースの作成漏れや重複を防ぎ、テスト品質の向上に貢献します。

状態遷移表は、開発者、テスト担当者、顧客など、関係者間の認識共有を促進します。状態遷移表を用いることで、システムの動作を明確に伝え、認識の齟齬による手戻りやトラブルを未然に防ぐことができます。

システムの仕様は、開発途中で変更されることもあります。状態遷移表は、仕様変更が発生した場合でも、影響範囲を特定しやすく、修正作業を効率的に行うことができます。また、仕様変更によるテストケースの修正も容易に行うことができます。

状態遷移表は、状態遷移図と併用することで、システムの振る舞いをより詳細に把握し、高品質なシステム開発に貢献する強力なツールとなります。

状態遷移表は、システムの振る舞いを明確にするための有効なツールですが、効果的に活用するためにはいくつかのコツがあります。以下に単にまとめます。

状態遷移表の詳細ついてはこちらをご覧ください
状態遷移表とは？状態遷移図との違いは？開発における利点や書き方のコツを解説

まず、システムが取りうる全ての状態と、状態遷移を引き起こす全てのイベントを洗い出します。この際、抜け漏れがないように、関係者間で十分に議論することが重要です。

洗い出した状態とイベントを基に、状態遷移表を作成します。一般的に、縦軸に状態、横軸にイベントを配置し、各セルに遷移先の状態を記述します。

各セルには、イベントが発生した場合の遷移先の状態を記述します。状態遷移が発生しない場合は、現状維持を示す記号（例：-）を記述します。

必要に応じて、ガード条件を追加します。ガード条件は、状態遷移が発生するための条件を記述するもので、遷移先の状態をより詳細に定義することができます。

作成した状態遷移表を関係者間でレビューし、誤りや矛盾がないか確認します。レビューを通じて、仕様の曖昧な部分や抜け漏れを発見することができます。

これらのコツを踏まえ、状態遷移表を作成することで、システムの振る舞いを正確に把握し、高品質なシステム開発に貢献することができます。

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

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

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