複数人で進めるシステムでは、一人の操作待ちで全体が止まることがある。研修や経営ゲームでは進行時間が決まっているため、参加者全員の入力が必ず揃うとは限りない。
「DX経営ゲーム」では、管理者がターンを開始し、参加者が意思決定を提出し、締切後に計算を実行する。ターンの状態は、待機、入力受付、締切、計算済みの順に変わる。
入力が揃わない場合にも進行できるよう、締切時に未提出企業へフォールバック処理を行いる。前ターンの意思決定があれば、それを引き継ぎる。最初のターンで前回値がない場合は、価格15、各投資0などの初期値を使用する。
ただし、フォールバック企業を通常企業と同じように市場競争へ参加させる設計にはしていない。未提出企業はそのターンの計算対象から外し、会社の財務状態を前ターン末のまま凍結する。売上、利益、市場シェアなどの活動値は0として結果を記録する。
ここで、以前は一つの不具合がありた。フォールバック企業について、会社状態を更新しないだけでなく、結果レコードの作成まで飛ばしていた。そのため、ターン計算自体は進んでも、結果比較や診断に未提出企業が表示されなかった。
修正では、財務状態を凍結したまま、参照用の結果レコードを作成するようにした。市場活動値は0、財務状態は前ターン末の値を使いる。これにより、未提出だった事実を保ちながら、比較、診断、ランキング履歴のデータ構造を欠かさずに済みる。
全体を止めないためのフォールバックは便利だが、参加者が提出したように見せてはいけない。意思決定にはis_fallbackフラグを持たせ、本人が提出したデータと自動補完を区別する。提出状況を確認するAPIでも、この違いを扱いる。
進行には、やり直しの仕組みも必要だ。管理者が誤って締め切った、イベント設定を間違えた、計算後に異常が見つかった、といった場合に備え、強制再計算と巻き戻しを用意している。
通常、計算済みターンをもう一度計算しようとすると409エラーにする。これは二重計算を防ぐためだ。同じ処理を繰り返すと、費用や投資が二重に加算される危険がある。明示的に強制再計算を指定した場合だけ、既存の結果とDX関連データを削除して再計算する。
巻き戻しは、指定したターン以降の結果、DXデータ、イベントログを削除し、ターン状態を待機へ戻する。そして、直前ターンの結果から各企業の状態を復元し、対象ターンを再び入力受付にする。最初のターンへ戻す場合は初期状態を使いる。
ゲームがすでに終了状態でも、巻き戻した場合は進行中へ戻する。結果だけを消してゲーム状態を終了のままにすると、参加者が再入力できない。データ、ターン状態、ゲーム全体の状態を一緒に戻す必要がある。
この機能は便利である一方、当該ターン以降のデータを削除する。そのため運用マニュアルでは、巻き戻しは緊急時に使い、実行前に参加者へ告知するよう注意している。技術的に可能であることと、気軽に実行してよいことは別だ。
検証では、未提出企業がある状態で締め切れること、フォールバック値が作られること、計算結果が保存されることを確認する。計算済みターンの通常再実行が拒否され、強制指定時のみ成功することも確認する。
巻き戻しについては、指定ターン前の状態へ戻ること、未来のターンを指定するとエラーになること、巻き戻したターンを再計算できることを確認する。削除と復元の両方を見る必要がある。
状態遷移の検証も欠かせない。入力受付中でなければ意思決定を変更できず、締切前には計算できないという順序を守る必要がある。状態の確認が甘いと、参加者が入力している途中で計算されたり、結果公開後に入力が書き換わったりする。
強制再計算と巻き戻しも同じ機能ではない。強制再計算は、同じターンの入力を使って計算結果を作り直する。巻き戻しは、指定ターン以降を取り消し、参加者が再び入力できる状態へ戻する。運営者が目的に合わない方を選ぶと、残したい入力まで失う可能性がある。
この違いを管理画面と運用マニュアルで説明し、通常の進行操作とは分けて扱いる。復旧機能は、存在するだけでなく、どの場面で使うかが理解されて初めて役に立ちる。
運用システムには、理想どおり全員が操作する前提だけでは足りない。未提出、誤操作、再計算、やり直しといった例外を受け止める仕組みが必要だ。同時に、例外処理によって履歴や計算が壊れないよう、通常処理以上に厳密な設計が求められる。
止まらずに進めることと、間違えたときに戻せること。この二つを両立させることで、システムはデモ用から実際の運営に使えるものへ近づきる。
それが運用を支える。