経営ゲームへ外部環境イベントを入れるとき、単に全社の売上を増減させるだけでは、運の要素が強くなる。参加者がどのような意思決定をしても同じ被害を受けるなら、振り返りで残るのは「今回は運が悪かった」という感想だ。
「DX経営ゲーム」では、イベントを経営判断の結果が表れる仕組みとして設計した。共通イベント、特殊イベント、条件連動イベントを分け、同じ環境変化でも会社の準備状況によって影響が変わるようにしている。
共通イベントは15種類ある。景気回復や景気減速は市場需要を変え、原材料高騰や安定は仕入単価を変える。物流混雑はスピード、品質要求強化は不良率、EC需要増や店舗来客増は販売チャネルの適合度へ影響する。
これらは全社共通の外部環境だが、最終的な結果は同じにならない。たとえばEC需要が増えたとき、オンライン販売比率を高め、販売・顧客デジタル化へ投資していた会社は恩恵を得やすくなる。店舗中心の会社は、同じ市場にいても効果が小さくなる。
価格比較が激しくなるイベントでは、価格に対する市場の感応度が上がりる。高価格を維持する会社には厳しい環境だが、価格だけでなくブランド、広告、販売能力、在庫状況なども競争力へ影響する。イベント一つで結果を決めるのではなく、それまでの蓄積と今ターンの判断を組み合わせる。
特殊イベントとして、サプライチェーン攻撃も実装した。序盤とそれ以降で発生確率が異なり、データ基盤が一定水準に達していない企業が攻撃対象になる。被害額は現金の割合を基に計算するが、最低額も設定している。攻撃対象は現金とブランドへ被害を受ける。
さらに、別企業へ巻き添え被害が出る場合がある。ただし、DX変革を達成している企業やデータ基盤が一定水準以上の企業は、巻き添え対象から除外される。事前の投資が、イベント発生後の耐性として働く設計だ。
このイベントでは、一度不具合も発生した。管理者がサプライチェーン攻撃を強制発動すると、画面が「計算中」のまま止まる現象だ。原因はイベントの内容ではなく、データベース制約とコードの不一致だった。
コードは特殊イベントをspecialとして記録しようとしていたが、データベースの制約はglobalとconditionalしか許可していなかった。そのため保存時にエラーとなり、さらに管理画面側のエラー処理が不足していたため、利用者には処理中のままに見えた。
修正では、データベースがspecialとDX関連のdxも許可するよう制約を変更し、管理画面へ通信エラーの表示処理を追加した。また、攻撃によって現金が減った後に自己資本と破綻判定を再計算するようにした。イベントを適用しただけで、その財務的な結果を再評価しなければ整合しないためだ。
条件連動イベントは、参加者自身の行動から発生する。欠品があればブランド低下、借入が自己資本を上回れば金利上昇、在庫が多ければ保管費増加、設備投資を長期間行わなければ生産能力低下といった仕組みだ。
この設計によって、イベントは突然降ってくる演出だけではなくなる。日々の判断が将来のイベントを呼び、その影響を受ける。参加者は結果を見て、「運が悪かった」ではなく、「欠品を防げなかった」「設備更新を後回しにした」「データ基盤を整えていなかった」と原因を考えられる。
結果画面には、一部のイベントについて「あなたへの影響」を表示する。恩恵を受ける条件を満たした場合と、準備不足の場合で説明を変える。同じイベント名を全員へ見せるだけでは、会社ごとの違いが伝わらないからだ。
運営者は、共通イベントをランダムに任せるだけでなく、学習テーマに合わせて手動選択できる。価格判断を考えさせたい場合、販売チャネルの違いを見せたい場合、セキュリティ投資を振り返らせたい場合で、適したイベントは異なる。ゲーム進行上の演出と、研修で扱う問いを結びつけるための機能だ。
一方、効果が強すぎると、それまでの経営判断を一度のイベントが消してしまう。需要倍率や費用、競争力ボーナスを変更したときは、単体の計算確認だけでなく、複数ターンを通したゲームバランスの検証も必要だ。
検証では、イベントの数値効果だけでなく、対象企業の選定、ログへの保存、画面表示、破綻判定まで確認する。対象外企業へ被害が出ないこと、条件を満たす企業が免除されること、強制発動時に確率判定を飛ばすことなど、反対側の条件も重要だ。
外部環境は企業が選べない。しかし、同じ環境へどう備えるかは選べる。イベント設計を通じて表現したかったのは、この違いだ。偶然を入れながらも、準備と判断が結果へつながる。その構造があって初めて、イベントは学習材料になる。