【ITニュース解説】From Chaos to Cohesion: A Retrospective on How FSMs Connect Us to Domain Experts

ソフトウェア開発において、システムがどのように動作すべきか、その「ルール」や「手順」を正確に理解し、それをコードとして実現することは常に大きな課題である。特に、建設や製造、金融といった特定の専門分野（ドメイン）の深い知識を持つ専門家（ドメインエキスパート）の知見を、実際に動くソフトウェアに落とし込む作業は非常に難しい。専門家は自身の分野のエキスパートだが、必ずしもプログラマーではないため、その知識を直接コードに変換するのは困難を伴う。結果として、プログラマーは専門家の言葉を解釈し、コードに翻訳するプロセスに多大な時間と労力を費やすことになる。

このような状況を解決するために開発されたのが、FSM_APIというツールである。この開発者は長年にわたり、建設業界で複雑な図面や3Dモデルの作成、そして専門家の知識に基づいたソフトウェアの自動化に携わってきた経験を持つ。この経験を通じて、複雑なシステムの動作を効率的に記述する方法として、有限状態機械（FSM: Finite State Machine）が非常に重要であることに気づいたという。FSMは、システムが現在どの「状態」にあるか、そしてどのような「条件」が満たされたときに次の「状態」へと「遷移」するかを定義するモデルであり、信号機が「青」から「黄」、そして「赤」へと変わるような一連の振る舞いを表現するのに適している。

しかし、従来のFSMの実装方法にはいくつかの問題が存在した。一つは、FSMの動作順序や状態遷移の経路を常にプログラマーが手動で厳密に管理する必要があり、これが開発の進行を妨げることがあった点だ。また、似たような機能を持つFSMを開発する際に、何度も同じようなコードを記述しなければならない非効率性も問題だった。さらに、一度作成したFSMのロジックを、異なる状況（「コンテキスト」と呼ばれる）に合わせて柔軟に再利用することが困難であるという課題も存在した。システムを構成する要素ごとにFSMを個別に設計し直す必要があり、アプリケーション全体での一貫性を維持することも難しかった。

FSM_APIは、これらの課題を解決するために、いくつかの重要な設計原則に基づいて構築されている。その核となる考え方は、「Universal Unit of Work（普遍的な作業単位）」と「コンテキスト」という概念である。FSM_APIでは、FSMの「ロジック」（すなわち、どの状態が存在し、どのように遷移するかというルール）と、FSMが判断や動作のために必要とする「データ」（例えば、自動車の速度やブレーキの状態など）を明確に分離している。この「データ」のことをFSMの「コンテキスト」と呼ぶ。ロジックとデータを分離することで、同じFSMの設計図を、異なるデータを持つ多数のオブジェクトやシステムに適用できるようになった。これにより、コードの重複を減らし、開発効率を高め、アプリケーション全体でシステムの振る舞いの一貫性を保つことが可能になる。

FSM_APIの最も画期的な特長は、専門家がコーディングの知識がなくても、自分の専門知識を直接FSMの形で表現できる点にある。専門家は、複雑な業務プロセスを「状態」「条件」「遷移」という明確な要素で構成された図として記述できる。FSM_APIは、人間が理解しやすい、流れるようなAPI（プログラムの命令セット）を提供することで、専門家が描いた図を、ほとんどそのまま機能するプログラミングコードに変換することを可能にする。

具体的な例として、自動車の変速機の動作を考えてみよう。この複雑なシステムを通常のプログラミング手法、例えば多数のif/else文だけで実装しようとすると、非常に読みにくく、将来の変更や保守が困難なコードになりがちである。しかし、FSM_APIを使えば、変速機のすべての状態（パーキング、リバース、ニュートラル、各ギアの状態）と、それぞれの状態での動作、そして状態間の遷移条件（速度、ブレーキ、アクセルなどの入力）を、専門家が描いたプロセスフロー図をなぞるかのように、クリーンで保守しやすいC#コードとして記述できる。

FSM_APIを用いた変速機FSMのコード例では、まずCarContextというクラスが定義されている。このクラスは、自動車の現在の速度、ブレーキペダルが押されているか、アクセルペダルが踏まれているか、エンジンの故障状態など、FSMが判断を下し、動作するために必要となるすべてのリアルタイム情報を保持する。FSMのロジックはこのCarContextを参照して、適切な動作を決定する。

次に、CarTransmissionFSMクラス内で、CreateFiniteStateMachineメソッドを使ってFSMの設計図を構築していく。ここで、システムが取りうる様々な「状態」を定義する。例えば、「Park（駐車）」、「Reverse（後退）」、「Neutral（ニュートラル）」、そして「First_Gear（1速）」から「Fourth_Gear（4速）」までの各ギアの状態などがそれに当たる。各状態には、その状態に入ったときに一度だけ実行される処理（onEnter）、その状態にいる間に繰り返し実行される処理（onUpdate）、その状態から出る直前に実行される処理（onExit）を定義できる。例えば、「First_Gear」に入ったときに「1速に入りました」と表示する処理や、エンジンが故障した際に「CRITICAL FAULT」と表示し、エンジンの故障フラグを立てて、システムの安全を確保する処理などを記述できる。

FSMの開始状態はWithInitialState("Park")のように設定する。そして、最も重要な部分が「遷移」の定義である。Transitionメソッドを使用し、「Park」から「Reverse」へ、あるいは「Neutral」から「First_Gear」へといった具体的な状態間の移動経路を定義し、その遷移が発生するための条件（例えば、ブレーキペダルが押されているか、速度が特定のしきい値を超えているかなど）を記述する。これらの条件は、先に定義したCarContextのデータを用いて判断される。さらに、AnyTransitionという特別なメソッドを使えば、どの状態からでも特定の状態へ遷移する汎用的なルールを定義できる。これは、緊急停止やエンジンの故障など、システムのどの地点で発生しても即座に対処すべき事態を表現するのに非常に有効である。例えば、エンジンの故障フラグが立つと、どの状態からでも「Fault」状態に遷移する、といった安全プロトコルを簡単に実装できる。これらのすべての定義が終わると、BuildDefinition()メソッドでFSMの設計図が完成する。

このような方法で専門家の知識をFSMとして定義できるようになったことは、ソフトウェア開発のあり方に大きな変化（パラダイムシフト）をもたらす。これまで専門家の頭の中にのみ存在していた複雑なロジックが、目に見える形でコード化され、バージョン管理可能な資産となる。これは、単にプログラマーの作業を効率化するだけでなく、専門家とプログラマー間のコミュニケーションを大きく改善する効果も期待できる。専門家は自身の知識をFSMの図やAPIの定義として直接表現できるため、プログラマーはそれを正確に理解し、実装を進めることが可能になる。これにより、プロジェクトの初期段階から専門家の知識をソフトウェアに深く組み込むことが容易になり、開発プロセスの手戻りが減り、より堅牢で信頼性の高いシステムを効率的に構築できるようになるのだ。FSM_APIは、適切な開発ツールを用いることで、専門家が持つ複雑な世界の知識を、簡単にソフトウェアとして定義し、実現できることを明確に示している。