システムの機能一覧に「採用を追加する」と書くと、簡単な変更に見える。参加者画面に「採用する」という選択肢を置き、押されたら人数を1人増やせばよいように思える。
しかし、経営ゲームの中で採用を成立させるには、画面、API、データベース、計算エンジン、結果表示、テスト、マニュアルまで一貫して変更する必要がある。「DX経営ゲーム」で採用機能を実装した際も、一つのボタンを追加するだけでは終わりなかった。
入力値はhire_employeeというフラグで表し、0なら採用しない、1なら採用するという仕様だ。従業員数はemployee_countとして会社の状態に保持する。最大人数は5人で、解雇機能はない。
採用による効果は、生産能力に現れる。生産能力は従業員数に45を掛けて計算する。従業員が2人なら90、3人なら135だ。一方で、従業員が増えると労務費も増え、1人当たり毎ターン30万円の負担が続く。
この組み合わせにより、採用は単純な強化ボタンではなくなる。生産能力が不足して販売機会を逃している企業には有効だが、需要が少ない企業が採用すれば固定的な費用だけが増える。採用したターンだけ費用を払うのではなく、その後も負担が続く点が重要だ。
実装で注意したのは、入力フラグと会社の状態を混同しないことだ。hire_employeeは、そのターンに採用するかという意思決定だ。employee_countは、これまでの採用結果を含む現在の従業員数だ。ターンが変わったら採用フラグは0へ戻するが、従業員数は維持しなければならない。
もし採用フラグまで持ち越されると、参加者が一度だけ採用したつもりでも、毎ターン自動的に人数が増えてしまう。反対に従業員数を初期値へ戻してしまえば、採用の効果が翌ターンに消える。似た二つの数値でも、寿命と役割が違いる。
画面側にも連動が必要だ。採用後に従業員数が増えれば、生産量を入力するスライダーの上限も変わる。計算エンジンだけが135個まで生産できる状態になっても、画面の上限が90個のままなら、参加者は増えた能力を使えない。
テスト仕様には、この点も明記した。採用後に従業員数が増えること、上限5人を超えないこと、次のターンで採用フラグがリセットされること、生産スライダーの上限が45×employee_countへ更新されることを確認対象にしている。
実際の回帰検証では、基本シナリオを6ターン完走させるだけでなく、採用結果も別に確認した。検証したゲームでは、意思決定に応じて従業員数が3人になるケースと2人になるケースを確認し、採用が会社状態へ反映されていた。
さらに、費用計算も無視できない。人数が増えれば労務費が増え、それが製造原価へ含まれる。製造原価報告書、損益計算書、キャッシュフローにも影響する。採用人数だけが増え、費用が変わらなければ、ゲームバランスも会計結果も壊れる。
採用のタイミングも仕様として固定する必要がある。今回の設計では、そのターンに送信された採用判断をターン計算内で適用する。どの処理段階で人数を増やすかが曖昧だと、同じターンの生産能力へ反映されるのか、次のターンからなのかが実装箇所によって変わってしまう。
テストでは、結果の人数だけでなく、入力値の境界も確認する。採用フラグとして許可する値、上限人数に達した会社の扱い、意思決定を再送信した場合の扱いなどだ。1回の操作が二重採用にならないことも重要だ。ターン計算は再実行される可能性があるため、同じ処理で状態が重複更新されない設計が必要になる。
複数の参加者がいるゲームでは、他社の採用が自社へ混ざらないことも確認しなければならない。意思決定は会社単位で保存され、計算結果も会社ごとに更新される。全体のターン処理が成功していても、会社IDの対応を誤れば、別企業の人数や費用が変わる危険がある。
このように整理すると、採用機能のテストは「ボタンを押したら数字が増えた」で終わらないことが分かりる。入力の妥当性、状態更新、計算時期、上限、継続費用、画面上限、会社間の分離、次ターンへの引き継ぎまでが一つの機能だ。
マニュアルでは、採用を「能力不足を解消する手段」として説明するだけでなく、固定費増加との関係も示している。利用者が仕様を知らなければ、採用後に利益が下がった理由を不具合だと思う可能性がある。機能追加時には、正しい動作を実装することと、その意味を利用者へ伝えることの両方が必要だ。
小さく見える機能ほど、影響範囲を見落としやすいものだ。入力欄を追加してAPIが受け取れれば完成、ということではない。保存されるか、計算に使われるか、次のターンへ正しく引き継がれるか、画面の制約が変わるか、帳票へ反映されるかまで追う必要がある。
「社員を1人採用する」という一つの意思決定は、経営の中では能力、費用、在庫、販売機会、利益、現金へ連鎖する。システムも同じだ。一つのボタンの背後にある連鎖を最後まで実装し、検証して初めて、機能が完成したと言える。