2024.10.29

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

著者株式会社SHIFT　マーケティンググループ

特定のソフトウェアがどのような条件や仕様で動くのか、また相互にどのような影響を与えているのかを理解しきれていないケースは少なくありません。ソフトウェア開発において各ソフトウェアの挙動は明確にしておかなければ、思わぬ不具合を起こす可能性があります。それを可視化し、わかりやすくしたのが状態遷移図です。

本記事では、状態遷移図の概要とメリット・デメリット、書き方や書く時のポイントを解説します。状態遷移図をよく理解できていない、うまく書けないという方はぜひ参考にしてください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

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

「状態遷移」とは、ソフトウェアやシステムの状態がさまざまな条件やイベントによって変化することを指しますが、それらの変化を図形や矢印で表現したものが「状態遷移図（ステートマシン図）」です。システムやソフトウェアの仕様が文章で書かれている場合に、ビジュアルでより俯瞰的に仕様をとらえることができます。

図A：状態遷移図

家電製品を例として見てみましょう。例えばエアコンを使用する際は、停止状態のエアコンの電源をオンにして初めて動き出します。その後、風量調整やモードを切り替えて使用し、最後は電源を落とします。

この電源のオン・オフや風量・モードの切り替えが図中のイベントに当たり、切り替わったあとのエアコンがどうなったかを示すのが状態となります。これを図式化し、一目でわかりやすくしたのが状態遷移図です。

状態遷移図を作成するメリット

状態遷移図を作成すると、次のようなメリットが得られます。

・直感的に全体像や流れを把握することができるため、メンバー間でイメージの共有がしやすい
・その結果、認識のズレが発生しにくくなる
・何か不具合が発生した際に、修正すべき箇所や仕様変更を実施する箇所が判断しやすい

細かく分けるといくつもありますが、状態遷移図を作る最大のメリットは、仕様書を追いかけなくても一目で全体像が把握できる点にあります。流れの確認を仕様書に任せることなく理解できるため、開発メンバーの間で認識がズレることが少なくなるでしょう。

また、不具合箇所の発見と対応が早くなるほか、仕様変更が起きた際にも状態遷移図を用いることでどこを変更すれば良いのかがわかりやすくなります。初見では何が書いてあるのかわからない人もおり、見慣れていない人に対しては教育が必要です。しかし、開発にかかる労力を削減できるという意味では非常に有効なものと言えるでしょう。

状態遷移図を作成するデメリット

状態遷移図のデメリットとしては、以下のような点をあげられます。

・作成や更新の手間がかかる
・各状態におけるイベント処理方法が把握しにくい

状態遷移図を作成するには、仕様書を確認してシステムの全体像を洗い出さなければなりません。そのため、仕様が複雑であったり量が多かったりすると、状態遷移図の作成そのものに時間がかかってしまうのです。

また、状態遷移図を作成することでシステムやソフトウェアの仕様自体はわかるようになるものの、状態ごとのイベント処理方法はわかりにくい傾向にあります。イベント処理まで可視化できるようにするには、次章で解説する状態遷移表を作成しなければなりません。

状態遷移図と状態遷移表の違い

状態遷移図に似ている言葉に「状態遷移表」があります。「状態遷移表」とは「状態」と「イベント」をマトリクスで表現したものです。

状態遷移図と比較すると、状態とイベントの組み合わせを網羅的に検討できるため、仕様として無効な組み合わせも検討することができます。

図B：状態遷移表①

状態遷移図と状態遷移表は、どちらも仕様の全体像を把握することや条件を整理することに適していますが、みえてくるものが異なります。

状態遷移図を活用すると、ソフトウェアやシステムの全体像を俯瞰的にとらえることができ、各状態とイベントが線で結ばれているため、流れを把握することができます。

例）状態A⇒（イベントa）⇒状態B⇒（イベントe）⇒状態C

一方で、状態遷移表は各状態とイベントに対する遷移後の状態をマトリクスで表現することになるため、条件や組み合わせの網羅性を検討することができます。

図Cの赤色ハイライト部分は、「組み合わせとして無効」となることが多いですが、状態遷移図では表現されていない条件・組み合わせについて検討するきっかけにもなります。

図C：状態遷移表②

仕様検討や設計工程の段階では、目玉機能のイベントや、条件が複雑なイベントに対しては「できること」「できないこと」がしっかり記載されているケースが多くあります。一方で、よくある処理や、こまかな例外処理などは検討がおざなりになることも珍しくありません。

認識齟齬を発生させないためにも、仕様検討や詳細設計工程で、状態遷移図や状態遷移表を適切に取り入れて、条件や組み合わせの仕様を明確にするのが効果的ともいえます。

ソフトウェアテスト入門動画

状態遷移図（ステートマシン図）の書き方

状態遷移図は、書き方を覚えればそれほど難しいものではありません。作図手順は次の通りです。

1．状態を書き出す
2．遷移を矢印でつなぐ
3．イベントを矢印のそばに記入する

詳細を見ていきましょう。

①状態を書き出す

まずは四角や丸などの図形を記載し、そこに状態名を書きます。エアコンで例えた場合、電源のオン・オフが状態名です。状態が変化する場合は図形と状態名を書き足します。エアコンの場合は冷暖房の切り替えや風量設定があります。今回は簡略化した図式ですが、仕様書にある状態をすべて図形とともに書き出すことが重要です。

②遷移を矢印でつなぐ

続いて、状態と変化した状態を矢印で結びます。矢印の部分が遷移と呼ばれる個所であり、変化の流れを可視化するために必要です。エアコンの場合は電源ボタンを押すことで状態が変化するため、上記の通りとなります。

注意点として、遷移を表す矢印は必ず一方方向で書く必要があります。互いに遷移が発生する場合は一方方向の矢印を2本記載しなければならず、⇔で記載してはいけません。次章で解説するアクションやイベントを書き込んだ際にわかりにくくなってしまうためです。必ず1方向1本の矢印で記載するようにしましょう。

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

最後に矢印の近くにイベントを記載します。イベントとは、何が起きて状態遷移が発生するのか、そのきっかけとなる情報のことです。イベントは詳細に記載することが求められます。エアコンの場合は電源ボタンを押した後、内部でモーターが起動して風を出すといった具合です。

完成したらもう一度全体を確認しましょう。どこからも遷移していない、遷移されていないなどの状態名があればその箇所が不備です。仕様書を再確認して修正してください。

状態遷移図（ステートマシン図）を書く際のポイント

仕様書がある場合には、仕様書から状態やイベントを列挙していけばよいので、あまり困らないとは思います。

ただし、実際の現場では十分なインプットを得られない場合や、リリースや開発を優先するあまり、仕様をドキュメント化していない（あるいは更新が漏れている）場面に遭遇することも多いと思います。今回はテスト工程において、少ないインプットで状態遷移図を書き起こす場合のポイントを紹介します。

イベントを洗い出す

テスト設計段階でのインプットが、「動くもの」や「現物」（開発途中のものも含む）である場合、状態を変化させるイベントを洗い出します。

GUI画面であればリンクやボタンの押下や、フォームへの入力など、状態を遷移させるイベントをすべてチェックし、遷移先の状態に矢印で結び、矢印のそばにイベントを記載するようにしてください。

図Dのように、「状態A」でイベントa,bを洗い出し、同様に状態B、状態Cでもイベントを洗い出します。

図D：状態遷移図の書き方

それぞれの状態の遷移パターンに過不足を検討する

状態遷移図がある程度完成したら、遷移パターンに過不足がないかをチェックしましょう。図Eでは、状態Cから状態Bへの遷移パターン（イベントfの存在）がないか確認します。

図E：遷移パターンの過不足確認

ここで遷移図から現物を書き起こす際に、注意しなければならないポイントがあります。

それは、現物からイベントや状態を洗い出しているため、そもそもイベントや遷移が正しいのか、遷移後の状態が正しいのか、テスト担当としては判断できないということです。

状態遷移図が完成したら、必ず仕様の責任者へ確認し、状態やイベントが正しいか（仕様どおりか）確認するよう心がけましょう。

状態遷移表の書き方

状態遷移表は、仕様書や状態遷移図をもとに作成します。一覧表の要領で表を作成し、横軸にイベントを、縦軸に遷移前の状態を記載します。その後、各状態がイベントを経ることで変化した結果を記して完成させる流れです。

状態遷移図が遷移する流れが明確になるのに対し、状態遷移表は遷移しない箇所が明確にできるという特徴があります。つまり状態遷移図では表現できないことが表現できるという点が最大のメリットです。仕様書にも遷移できないことについて記載していないことがほとんどであるため、状態遷移図と状態遷移表の両方を作っておくことが重要です。

作成したら状態遷移図と同様チェックをし、不備があれば修正するようにしましょう。状態遷移図と状態遷移表はセットで作成するのがおすすめです。

状態遷移表を書く際のポイント

状態遷移表は、状態、イベントを網羅的に洗い出すことが大切です。各状態やイベントを網羅的に検討し、遷移できない、仕様として起こりえないことについては「-」や「N/A（Not Applicable）」を入力していきます。

状態遷移表についても、そもそもイベントが網羅できているかの確認が必要です。

図Fで状態Cの行に注目すると、状態Aへの遷移はあっても状態Bへの遷移イベントがないことがわかるため、ここでもイベントfの可能性を検討することができます。

図F：状態遷移表

複雑なソフトウェアやシステムの場合は状態の数も多いです。テスト工程から仕様や全体像を把握するためにも、まずは状態遷移図を作成するのがおすすめです。イベントや条件の組み合わせの検討には状態遷移表を作成するなど、相互に補完しながら使い分けするのがよいでしょう。

状態遷移テストとは？

状態遷移テストは、仕様ベースで挙動を確認するテスト技法の1つです。

この技法は、状態遷移図や状態遷移表を基に以下の内容をチェックします。

・有効な状態遷移が正しく行われること
・無効な状態遷移が行われないこと

状態遷移図、状態遷移表を活用したテストについてそれぞれ見ていきましょう。

状態遷移図（ステートマシン図）を使った状態遷移テスト

状態遷移図によるテストでは、図に描かれた遷移の経路をそのとおりに動くかどうか（有効な状態遷移が正しく行われるか）、状態を網羅し、確認していきます。

その経路を検討する過程で、シナリオのパターンを検討することができます。テストケースを作成する際には、ソフトウェアやシステムの全体像と流れを把握するために状態遷移図を作成するのがよいでしょう。

状態遷移表を使った状態遷移テスト

状態遷移表によるテストは、状態遷移表で表現されたセルを「-」も含めて、「遷移できない（しない）こと」（無効な状態遷移が行われないこと）も含めてテストしていきます。

繰り返しになりますが、「状態」と「イベント」を網羅して検討することにより、設計段階では意図しないような挙動も確認することが可能です。結果、仕様の検討漏れやテストケースの抜け漏れを防ぐことができます。

ソフトウェアテスト入門講座

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「ソフトウェアテスト入門」をご視聴いただけます。ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの入門動画です。

ダウンロード

まとめ

状態遷移図とは何か、状態遷移表との違いやメリット、書き方について確認してきました。状態遷移図、状態遷移表はそれぞれで「できること」「できないこと」が異なるため、目的によって使い分け、場合によっては相互補完的に利用していくのが効果的です。今回はテスト工程での利用という点に着目しましたが、仕様を検討する際にも有効なツールであるため、ソフトウェアテスト設計段階だけではなく、上流工程での設計にも取り入れてみるのも一つの手といえるでしょう。

株式会社SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。

また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

よくある質問はこちら
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

ソフトウェアテストの悩みはSHIFTが解決できます！

「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」

といった悩みを抱えている企業は多いでしょう。

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

資料ダウンロード／動画視聴

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

テストサービス導入事例集

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

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

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

状態遷移図を作成するメリット

状態遷移図を作成するデメリット

状態遷移図と状態遷移表の違い