検証役に立てた別のAIに、要件の文書と実物を突き合わせてもらった。返ってきた判定は受入不可だった。理由を読んで、私はしばらく画面を見たまま動けなかった。指摘は不具合の話ではない。作りそのものが要件と違う、という話だった。
経営ゲームには、いつのまにか二つの版が並んで存在していた。数値だけで意思決定する古い版と、カードとAIの要素を足した新しい版。画面が二つ、データの置き場が二つ、計算の本体が二つ。どちらも動く。どちらも参加者が遊べる。ただ、要件として求められていたのは「古い版を土台にして、新しい機能をそこへ足す」ことであって、「新しい版を別に立てる」ことではなかった。
誰も決めていないのに、二つに分かれていた
厄介だったのは、この分岐をどこかで誰かが決めた覚えが無いことだった。新しい機能を足そうとしたとき、既存に手を入れるより新しく作るほうが速い場面が続いた。その積み重ねが、いつのまにか二系統になっていた。判定の言葉を借りれば、単体化は要件ではなく実装の解釈として生じたものだ。設計判断のふりをして、実装の都合が居座っていた。
期限は十八日後だった。ある地域の創業支援の催しで、参加者にこのゲームを実演することが決まっていた。土日を除けば稼働は十二から十四日しかない。私は三つ決めた。新しい住所は取らず今のサイトを上書きすること。古い版はその日から廃止してよいこと。有料化と複数主催者への対応は、この期限の範囲から外すこと。
書き直さずに、上へ薄い層を乗せる
最初の見積もりでは、統合したエンジンを書き直すのに五、六日かかるはずだった。ところが実物を読み直して気づいた。新しい版のエンジンは、すでに古い版の数値計算も内側に持っていた。二つの計算式があるのではなく、一つの計算式に、新しい要素を足すか足さないかの分かれ道があるだけだった。
それなら書き直す必要はない。上に薄い層を一枚乗せて、その層で「カードの仕組みを使うか」「AIを使うか」といった切り替えを受け取り、下のエンジンへ渡す。切り替えを全部切れば、古い版とまったく同じ数字が出る。この方針にしたら、五、六日の見積もりが一日で終わった。作り直しの大半は、書き直しではなく、境目をどこに引くかを決める作業だったということだ。
古い回を、読めるまま残す
統合にあたって迷ったのが、過去に開催した回のデータをどうするかだった。表の形が変わるので、消してしまえば移行は楽になる。けれど、過去に参加した人が自分の回の結果をもう一度開けなくなる。研修で使ってもらった以上、そこは残したかった。
そこで、古い表は読み取り専用のまま置いておくことにした。新しい仕組みは新しい列を足す形だけで進め、既存の列は一つも作り変えない。足すだけなら、うまくいかなかったときに足した分を外せば元に戻る。消す変更は戻せないが、足す変更は戻せる。期限が短いときほど、この差は効いてくる。
戻れる道を、一本だけ残しておく
本番当日に新しい仕組みが動かなかったら、という想定も要る。凝った切り戻し手順を書いても、当日の混乱の中では読めない。だから逃げ道は一つだけにした。設定を一か所だけ切ると、新しい入口が全部見つからない扱いになり、従来の進行画面だけが生き残る。判断も操作も一手で済む。
二つあったものを一つに戻す作業は、機能を足す仕事より地味だ。外から見て増えたものは何も無い。それでも、分かれたまま両方を保守し続けるほうが、この先ずっと高くつく。次は、この統合した土台の上に、AIをどう置くかの話になる。