システムの変更は速い。ドキュメントの更新は遅い。これは多くのシステム開発プロジェクトで起きる問題だ。コードが変わっても、マニュアルや仕様書が追いつかない。DX経営ゲームも例外ではなかった。
「ドキュメント類」の全体像
このプロジェクトで管理しているドキュメントは10種類を超える。仕様書、設計書、主催者マニュアル、参加者マニュアル、運用マニュアル、企画提案書、ファシリテータースライド、ファシリテータースクリプト、テスト仕様書——これら全てを「ドキュメント類」として管理している。
仕様書との照合で発見した不一致
ファシリテータースライドとスクリプトを、現行仕様と照合した。「倒産（復活不可）」——実際は緊急融資で復活可能なのに誤記。「市場シェアは各社のスコアの比率で配分」——実際は二乗の比率。生産指示量の説明に「45×従業員数」が欠如。採用メカニズムの記載なし——これら全て修正した。
AIによる照合と修正
「仕様書と照合して、不一致箇所を全てリストアップしてほしい」。AIにこのタスクを依頼すると、システマティックに比較してくれる。項目ごとに現在の記述と正しい記述を並べて出力する。修正作業もAIと進める。最終的な判断と確認は人間がする。AIは「一致しているか」の確認と「修正案の作成」を担い、「これでよいか」の判断は私がする。
不整合が見つかったドキュメントの具体例
AIとドキュメントを照合した作業で、発見された不整合の具体例を記録する。「こういうことが起きる」という実例として残しておきたい。
不整合1：ファシリテータースライドの「破産ルール」記述
スライドには「現金が0を下回り、かつ追加借入が限度額に達した場合に破産」と書かれていた。実際のシステムは「現金が0を下回った瞬間に破産」だ。「かつ追加借入が限度額に達した場合」という条件は、初期設計のルールを修正したときにスライドの更新が漏れていた。
この誤記のまま研修が行われていたら、「なぜ借入余裕があるのに破産したのか」という参加者の混乱を生んでいた可能性が高い。
不整合2：参加者マニュアルの「DXロードマップ」説明
参加者マニュアルには「L1→L2→L3→L4の順番でDX投資を進める必要がある」と書かれていた。実際のシステムは「前のレベルに一定以上の投資をしていれば次のレベルに投資できる」という設計で、厳密な順番制約は設けていない。
この差は「研修の誘導」として意図的に設計されたものだったが、「仕様」として記載してしまっていた。修正方針として「推奨順序はL1→L2→L3→L4だが、他の順序も可能」という記述に変えた。
AIによる照合の限界：
AIは「テキストの記述と仕様書の記述が一致しているか」は正確に比較できる。しかし「この記述がゲームバランスとして意図通りか」という判断はできない。上記の不整合2では、AIは「不一致あり」とフラグを立てたが、「どちらの記述が正しいか」の判断は私がした。
照合と修正をAIに任せ、判断は人間がする。この分担が機能した。
*次回は「モニター体験会を設計した話」*
AIが見逃して人間が発見した不整合
AIとドキュメント照合を進める中で、「AIが見逃して私が発見した不整合」があった。
ファシリテータースクリプトの記述で「参加者が生産量を入力する際、スライダーの上限は生産能力と一致します」という説明があった。AIはこれを「正しい記述」と判定した。しかし実際のシステムでは「スライダーの上限は生産能力の80%に設定されている」。100%フルに生産すると在庫リスクが高まるため、上限を80%に制限していた。
なぜAIが見逃したか。仕様書には「スライダー上限 = 生産能力」と記載されており、スクリプトの記述と一致していた。実際のコードで0.8という係数が掛かっていることは、仕様書に記載がなかった。コードと仕様書の差異を、ドキュメント同士の照合では発見できなかった。
この発見のきっかけは、実際に管理画面を操作したことだ。生産能力90単位の会社のスライダーが72で止まることに気づき、コードを確認した。「動いているシステムを自分で操作する」という確認が、AIによるテキスト照合では発見できない差異を見つけた。
今回の照合作業で見つかった不整合は合計7項目だった。うち5項目はAIが検出し、2項目は私が実際のシステム操作で発見した。「AIが5割以上見つける」は十分な価値だが、「AIが全て見つける」は過信だ。照合はAIに任せ、最終確認は実際のシステムで行う。この組み合わせが完全な品質チェックになる。
*シンプルシステム株式会社 代表 伊藤勝彦*