出荷と顧客支援の月次判断を設計する

ソフトウェア会社シミュレーションでは、ひと月の限られたスタッフ時間をリリース準備に使うか、販売と顧客支援に使うかという見える緊張感が必要です。月2回の行動、機能マイルストーン1つ、既存の支払顧客1人、転換待ちのトライアル1件、簡単な月締めから始めます。製品ラインやランダムイベントを追加する前に、制作者が考えられるループになります。

Northstar Deskは独自の架空教材シナリオです。クレジット、アカウント、ルール、3か月比較は手作業で計算した設計前提で、実在企業、業界指標、AI出力、プレイ可能ビルド、テスト結果ではありません。

ゲーム規模の小さなスタジオから始める

スタッフの配置ごとにプレイヤーが見える変化を作れる小規模な会社を選びます。Northstar Deskには進行中の機能1つ、支払顧客1人、転換待ちトライアル1件、月2回のスタッフ行動があります。実際のソフトウェア事業すべてを再現するのではなく、プロジェクト進捗、顧客増、継続率、現金のつながりを追いやすくします。

最初の月締め前に、マイルストーンが空の状態で選択が見えるようにします。進捗の公開しきい値が紙上版間で変わる唯一のルールです。開始画面では目標2点か3点か明かしません。まず作業、顧客、トライアル、行動選択を表示します。

行動可能条件が明示されたループを書く

各行動にコスト、条件、見える効果を与えます。行動ポイントをちょうど2つ割り当て、選んだ順で解決します。開発は機能を1ポイント進め、公開後に停止。販売は公開まで使用できません。使用可能になると請求前に待機トライアル1件を転換します。サポートは月初からいる支払顧客1人を解約から守ります。

割り当て後、完了した機能を公開します。次に条件を満たす販売を解決します。その後、該当すれば保護されていない月初の顧客を解約させます。新規転換顧客は翌月まで解約しません。活動中の各アカウントに4クレジット請求し、固定スタジオ費2を1回差し引きます。現金変化は活動顧客数×4、その後−2です。この教材モデルには借金、税、延滞、追加コスト、ランダムイベント、2つ目のトライアルはありません。

順序が重要です。サポートした月初顧客は請求まで残ります。公開後に販売でトライアルが転換すれば、その新規顧客も当月に支払います。順序を記すことで、売上、解約、請求がいつ起きたかを画面が隠すのを防ぎます。

他システムを増やす前に3か月を手で解決する

v0では機能公開に開発3ポイントが必要です。この例は3か月とも開発+サポートに割り当てます。サポートで既存顧客を維持し、毎月締めで4クレジットを加えて2を引きます。3か月目に機能公開しますが、2枠目はすでにサポートに使われているためトライアルは待機のまま。販売は翌月までできません。

架空の目標は3か月目の終わりまでに支払顧客2人以上、現金18クレジット以上です。v0は顧客1人、16クレジットで両方の確認に失敗します。これは選んだルールと行動予定の紙上結果で、実在ソフトウェア会社についての報告やゲームバランスの測定ではありません。

ルール1つを変えて月締めを再確認する

次に公開しきい値だけを開発3ポイントから2ポイントに変えます。開始現金、顧客、トライアル、行動枠、行動効果、請求、締め順はすべて同じにします。1・2か月目は引き続き開発+サポートですが、機能が1か月早く公開されます。次の画像は2ポイント目の開発後のv1・2か月目状態です。

機能が公開されたため、3か月目に販売が可能です。販売+サポートを割り当てます。請求前にトライアルを支払列へ移し、サポートで既存顧客を守ります。締め時には活動中顧客2人に請求します。

違いは「同じ予定でスコアが上がった」だけではありません。しきい値が下がることで販売可能時期が変わり、3か月目の行動は開発+サポートから販売+サポートに変わります。短い最初のマイルストーンなら、出荷と顧客拡大の選択が早く分かるという設計仮説を立てられます。この比較でプレイヤーが短いしきい値を好む、経済が均衡する、生成ゲームが記載どおり実装することは証明されません。

ルール仕様を焦点の合ったビルド依頼にする

紙上追跡が明確になったら、将来の試作に1つの役割を与えます。2行動を表示し、公開条件付き販売を守り、請求前にサポートを解決し、結果状態を示すことです。以下のスタータープロンプトは未実行の指針で、Northstar Deskがプレイ可能なゲームとして存在する証拠ではありません。

架空のルール概要から小さなソフトウェア会社経営ゲーム「Northstar Desk」を作る。開始状態は現金10クレジット、支払顧客1人、待機トライアル1件、機能進捗0、月2回のスタッフ行動。各月に開発、販売、サポートから行動を正確に2つ割り当てる。開発は公開まで機能を1ポイント進める。販売は公開まで使用不可で、請求前にトライアル1件を転換する。サポートは月初にいた最古の顧客を保護する。使わない場合、その顧客は請求前に解約する。締め時に活動顧客ごとに4クレジットを加え、固定費2を1回引く。各段階の状態を表示し、開始状態に戻す再開を用意する。v0は開発3ポイント、v1は2ポイントで公開。両版の同じ開始値を表示して比較できるようにする。

将来のビルドを確認するときは、同じ開始状態から同じ選択を再生します。開発は公開後に止まるか、公開前は販売不可で請求前に転換するか、サポートは月初顧客を保護するか、新規顧客が即時解約しないか、現金が記載した締め式になるか。結果が違えば、ランダムイベント、機能追加、顧客種別を増やす前に正確な遷移を記録してルールを1つ直します。

自分のルール概要から一般的なプレイ可能ゲームの出発点を作る準備ができたら、Free AIゲームメーカーを利用できます。

最初のループを小さく保ちます。月のスタッフ行動2回、公開条件1つ、更新リスク1つ、手計算できる締めです。しきい値比較で将来の試作に向けた問いは得られますが、楽しさや事業予測の証明ではありません。制作フローで試すなら行動順と開始状態を持ち込み、見える結果を確認して一度に1ルールずつ変えます。

よくある質問