原因結果グラフは設計モデル
原因結果グラフ法は、テスト領域で広く知られるに至っています。それはテスト数をオーダーレベルで減らすことができるというわかりやすい効用があるからだと思われます。しかし、筆者は設計モデルとしての効用も大きいと考えています。
この技法によって出てくるデシジョンテーブルは、全組み合わせではなく、この技法としての以下の考え方に基づいて、テストケースとして必要なものだけになります。
ルールを構成する条件やその組み合わせが、仕様上意図したとおりに（そして意図しない形では結びつかないことを含めて）結果へ結びついているかを、仕様側から系統的に確認する考え方です。
出てきたデシジョンテーブルは、テストケースの根拠になるだけでなく、仕様として必要な条件と結果の対応関係を明示しています。基本的には、実装はこの対応関係をそのまま判定表・ルールテーブル・小さな判定関数として表現すれば足り、仕様にない追加の分岐や複雑な制御構造を持ち込む必要はありません。ここに、原因結果グラフ技法の面白さがあります。
NeoCEGでは、下部の「skeleton」タブを開くと、仮想プログラミング言語による制御構造が表示されます。そこで、AIにコード生成させる際に、仕様とともにこのスケルトンを渡し、次のようなプロンプトを与えるとよいでしょう。
AIに与えるプロンプトの例
添付の言語表現されている原因結果グラフに示される仕様部分について、添付のスケルトンに従ってPythonでコードを書いてください。理由なく制御構造を複雑にしないでください。グラフに示される制約はすでに達成されている前提としてください。制約をコードで実現する必要はありません。引数は共通因子ごとにまとめてください。
グラフが正しく定義されていること、またその中に定義されている制約が、今から生成するスケルトンに対応するコードの外側で実現されていることが前提です。例えば今回の事例に表れるOne制約はプルダウンメニューなどのGUI部品によって実現されるものとします。制約については次回詳しく説明します。
このNeoCEGで生成されたスケルトンに忠実に対応するコードは、原理的には同時に生成されたテストケースだけでMC/DCカバレッジが可能です。
バイブコーディングとデシジョンテーブル
バイブコーディングでは、最初は典型的な振る舞いを与えるので、うまく動作しているように見えます。しかし実務適用を考えると、次第にレアなケースや例外を扱う必要が出てきます。そういうことを発見するたびに、固有の条件と振る舞いを付け足していくことになります。
この手順は、デシジョンテーブルの上で考えてみると、思いついた順に五月雨式に列の情報を与えたり、発見した列を突如付け加えたりしているようなものです。その度にコードを修正することになります。条件分岐やネストが必要以上に増えてスパゲッティ化してしまう様が容易に想像できます。
実はこの状態、従来のウォーターフォール開発の現場でもときどき見かけます。レアなケースの扱いが抜けていたと気づいたとします。しかし抜本的に考え直す時間はありません。また、せっかく他の場合にうまく動いているコードを壊したくはありません。そこで、できるだけ今のコードを触らずに、その問題のケースだけをうまく動かすコードを付け足す。そうしてコードはスパゲッティ化していきます。
スパゲッティ化したコードは、ソフトウェア開発における「技術的負債（Technical Debt）」の最も代表的かつ深刻な症状のひとつです。治療策としてのリファクタリングだけではなく、予防策も必要です。本稿に示した方法論は、どちらに対しても有効性が高いはずですので、ぜひご活用ください。
おわりに
従来、「ビジネスルールや論理関係が複雑な部分はデシジョンテーブルで整理しましょう」と言われてきました。でもそれは複数のルールが組み合わさった結果のすべてのバリエーションの実例（外延）を漏れなく列挙しようとする行為です。AIは確かに少数の例示（Few-Shot手法）から期待の振る舞いをしてくれるようになりますが、大量の実例を与えればルールをより正確に理解できるようになるわけではありません。
必ずどこかで人間が論理的な仮説を立て（アブダクションを行い）、ルール（内包）表現に変換・整理してあげないと、AIが生成するプログラムは容易にスパゲッティ化してしまいます。
ルールを整理・理解し、レビューを効率化するのにモデル化はとても役立ちます。
次回は、制約関係を取り上げます。多くの設計者が論理関係と制約関係の違いや境界をあまり意識せずに設計しているのではないでしょうか。テスト技術者のほうが意識する機会が多いように思います。例えばテスト技術者は状態遷移図がある場合にも状態遷移表も作成します。その理由をご存じでしょうか？
両者の違いを理解し、うまく使い分けることで見通しの良い設計を行うことができます。詳細は次回、説明します。
