JP6176773B2 - ビジネスゲーム実行管理装置、ビジネスゲーム実行管理プログラム、及びビジネスゲーム実行管理方法 - Google Patents

Description

本発明は、ビジネスゲーム実行管理装置、ビジネスゲーム実行管理プログラム、及びビジネスゲーム実行管理方法に関する。

従来、対面型授業により、学習者と監督者とが一堂に会して行うビジネスゲームが知られている（例えば、特許文献１参照）。ビジネスゲームでは、主となる１台のサーバコンピュータと、従となる複数台の端末とをネットワークを介し接続して、学習システムを構築する。この学習システムでは、サーバコンピュータに仮想的な経済市場環境を構築する。そして、複数の学習者それぞれが疑似的に企業経営者となり、製品の製造や販売の意思決定データを端末に入力する。入力されたデータは、サーバコンピュータで集計され、さらに各学習者の経営結果の売上高や利益などが演算される。各学習者は、この結果を確認して、更に次の意思決定を行う。このプロセスを繰り返すことにより、学習者は、経営能力を高めていく。

特開２００５−２８４２３０号公報

上述した従来技術において、ビジネスゲームを実施する場合には、全ての学習者の意思決定データの入力が完了したかの確認や、入力までの制限時間管理などに監督者の管理が必要であった。そのため、複数の学習者、及び監督者が、同じ時間に同じ場所に集合して対面で実施せざるを得なかった。これは、学習者が学習するための時間と場所に制約を与えることとなり、学習参加の機会を少なくする要因であった。また、ネットワークを利用して、学習者が異なる時間と場所からゲームに参加する実施形態は、監督者にかかる負担が高いだけでなく、学習者の参加数が少ない時点では、競争的環境での経営を体験する効果が少なかった。

本発明は、このような事情を考慮してなされたものであり、監督者の管理を不要とし、実施の負担を軽減することができるビジネスゲーム実行管理装置、ビジネスゲーム実行管理プログラム、及びビジネスゲーム実行管理方法を提供することを目的とする。

上述した課題を解決するために、本発明による一態様は、複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するビジネスゲーム実行管理装置であって、前記ビジネスゲームの実行手順が記述されたシナリオを格納するシナリオデータベースと、所定の時間間隔で、前記シナリオデータベースに格納された前記シナリオを解釈して実行する実行処理部と、ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別部と、前記判別部が、前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理部と、前記総需要を学習者に対応付けて分配する総需要配分処理部と、前記総需要配分処理部が分配した分配結果を、前記学習者端末により表示させる結果表示処理部と、学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理部と、前記成績に基づいて、学習者の改善点を提示する改善点助言処理部と、を備え、前記総需要設定処理部は、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持する、ことを特徴とするビジネスゲーム実行管理装置である。

上記の発明による一態様において、前記総需要設定処理部は、前記ビジネスゲームに参加している学習者の数に応じて、総需要を随時設定することで、その時点での最適の総需要を設定することを特徴とする。

上記の発明による一態様おいて、前記総需要設定処理部は、新規の意思決定データがある場合には、前記意思決定データに対応する学習者の参加を記録し、前記新規の意思決定データを学習者データに代入し、総参加者数に１を加え、前記新規の意思決定データがなく、且つ前回の意思決定データがない場合には、学習者データ、及び総参加者数を初期化し、前記新規の意思決定データがなく、且つ前回の意思決定データがある場合には、前回の意思決定データを今回の意思決定データとして採用し、総参加者数として前回値を維持し、いずれの場合も、ラウンドごとの参加者１人当たりの需要を示す基準需要に総参加者数を乗ずることにより、総需要を算出することを特徴とする。

上記の発明の一態様において、前記成績評価処理部は、成績の評価基準となる、全参加者の経営結果の各項目について、最高値、最小値、平均値を算出し、各学習者の同項目について、前記評価基準と比較して優劣を求め、前記優劣に従って各学習者の順位を決定し、各学習者の順位成績を通知するメッセージを前記学習者端末により表示させる、ことを特徴とする。

上記の発明の一態様において、前記改善点助言処理部は、全参加者の経営結果の各項目について、所定の変化率を超えて変化した項目がある場合に、前記変化の原因を抽出し、前記原因に対する改善点の助言メッセージを、前記学習者端末で表示させる、ことを特徴とする。

また、上述した課題を解決するために、本発明による一態様は、複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するコンピュータを、前記ビジネスゲームの実行手順が記述されたシナリオを格納するシナリオデータベースと、所定の時間間隔で、前記シナリオデータベースに格納された前記シナリオを解釈して実行する実行処理部と、ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別部と、前記判別部が、前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理部と、前記総需要を学習者に対応付けて分配する総需要配分処理部と、前記総需要配分処理部が分配した分配結果を、前記学習者端末により表示させる結果表示処理部と、学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理部と、前記成績に基づいて、学習者の改善点を提示する改善点助言処理部と、として機能させ、前記総需要設定処理部を、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持するよう機能させるためのビジネスゲーム実行管理プログラムである。

また、上述した課題を解決するために、本発明による一態様は、複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するビジネスゲーム実行管理方法であって、所定の時間間隔で、実行処理部が、前記ビジネスゲームの実行手順が記述されたシナリオを解釈して実行するステップと、判別部が、ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別ステップと、前記判別ステップにおいて前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて、総需要設定処理部が学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理ステップと、総需要配分処理部が、前記総需要を学習者に対応付けて分配する総需要配分処理ステップと、前記総需要配分処理ステップにおいて分配された分配結果を、結果表示処理部が、前記学習者端末により表示させる結果表示処理ステップと、成績評価処理部が、学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理ステップと、改善点助言処理部が、前記成績に基づいて、学習者の改善点を提示する改善点助言処理ステップと、を有し、前記総需要設定処理ステップでは、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持する、ことを特徴とするビジネスゲーム実行管理方法である。

この発明によれば、監督者の管理を不要とし、実施の負担を軽減することができる。

本発明の実施形態によるビジネスゲームシステムの構成を示すブロック図である。 本実施形態によるシナリオデータベースに格納されているシナリオの一例を示す図である。 本実施形態によるシナリオデータベースに格納されているシナリオの一例を示す図である。 本実施形態によるシナリオデータベースに格納されているシナリオの一例を示す図である。 本実施形態によるシナリオデータベースに格納されているシナリオの一例を示す図である。 本実施形態によるシナリオデータベースに格納されているシナリオの一例を示す図である。 本実施形態によるビジネスゲーム実行管理サーバの動作を説明するためのフローチャートである。 本実施形態による総需要設定処理のシナリオ（図２〜図６の一部）を示す概念図である。 本実施形態による総需要設定処理の動作を説明するためのフローチャートである。 本実施形態による成績評価処理のシナリオ（図２〜図６の一部）を示す概念図である。 本実施形態による成績評価処理の動作を説明するためのフローチャートである。 本実施形態による改善点助言処理のシナリオ（図２〜図６の一部）を示す概念図である。 本実施形態による改善点助言処理の動作を説明するためのフローチャートである。 本実施形態による学習者端末の表示画面（入力画面）の一例を示す模式図である。 本実施形態による監督者端末の表示画面（データ入力状況）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（結果表示）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（改善点メッセージ）の一例を示す模式図である。 本実施形態による監督者端末の表示画面（データ入力状況）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（結果表示）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（入力画面）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（結果表示）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（改善点メッセージ）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（結果表示）の一例を示す模式図である。 本実施形態による学習者端末の表示画面（成績評価メッセージ）の一例を示す模式図である。

以下、本発明の一実施形態を、図面を参照して説明する。
図１は、本発明の実施形態によるビジネスゲームシステム１の構成を示すブロック図である。図１において、ビジネスゲームシステム１は、ビジネスゲーム実行管理サーバ（ビジネスゲーム実行管理装置）１０、監督者端末１１、及び学習者端末１２−１、１２−２、…、１２−ｎを含んで構成される。ビジネスゲーム実行管理サーバ１０、監督者端末１１、学習者端末１２−１〜１２−ｎは、ネットワーク１３に接続される環境であれば、設置される場所はどこでもよい。なお、以下の説明において、学習者端末１２−１〜１２−ｎを総称または個別に学習者端末１２という。

ビジネスゲーム実行管理サーバ１０は、シナリオ実行部１０−１、シナリオデータベース１０−２、基準需要データベース１０−３、メッセージデータベース１０−４、及び変化原因データベース１０−５を備えている。シナリオ実行部１０−１は、シナリオデータベース１０−２に格納されている、例えば、製造業、小売業、サービス業などのビジネスゲームのシナリオを解釈して実行することにより、ビジネスゲームを実現する。シナリオは、ビジネスゲームの実行手順を記述したものであり、ユーザである監督者によって容易に作成できるよう、テキスト形式のソースコードである。

具体的には、シナリオ実行部１０−１は、シナリオを解釈して実行する実行処理部、学習者により意思決定データが入力されたか否かを判別する判別部、ラウンドごとにゲームに参加している学習者の数によって、最適な総需要を設定する総需要設定処理部、学習者の意思決定データに応じて総需要を配分する総需要配分処理部、配分した結果を表示する結果表示処理部、学習者の成績を評価する成績評価処理部、及び学習者の成績に基づいて改善点を提示する改善点助言処理部を実現する。各処理部の詳細な機能、動作については以下で説明する。

シナリオデータベース１０−２は、シナリオに加えて、シナリオ実行に必要となる各種データも格納している。基準需要データベース１０−３は、ラウンドごとの基準需要（参加者１人当たりの需要）を格納する。メッセージデータベース１０−４は、学習者端末１２に提示する各種メッセージを格納する。変化原因データベース１０−５は、学習者の経営効果の各項目(例えば、売上高、販売数など）が、前ラウンドより大きく変化（所定の変化率を超えて減少）した原因と考えられる、内部環境（自身の意思決定データなど）と外部環境（他の学習者の意思決定データなど）を予め想定されるパターンとして格納する。

監督者端末１１は、監督者によって操作され、ウェブブラウザ上でビジネスゲーム実行管理サーバ１０にアクセスし、このウェブブラウザ上でビジネスゲームを実行する。監督者端末１１は、例えば、入力された、学習者のＩＤ（ユーザコード）やパスワードを、ビジネスゲーム実行管理サーバ１０に登録させる。また、監督者端末１１の画面には、学習者のデータ入力状況などが表示される。

学習者端末１２は、学習者によって操作され、監督者端末１１と同様に、ウェブブラウザ上でビジネスゲーム実行管理サーバ１０にアクセスし、このウェブブラウザ上でビジネスゲームを実行する。学習者端末１２は、学習者により、ゲームで指定された意思決定データ（例えば、商品の販売価格）が入力されると、ビジネスゲーム実行管理サーバ１０に登録する。

ビジネスゲーム実行管理サーバ１０において、シナリオ実行部１０−１がシナリオデータベース１０−２に格納されている、ビジネスゲームのシナリオを記述したプログラムを起動すると、監督者端末１１、学習者端末１２から、ネットワーク１３を介して、２４時間いつでも所望する時刻にアクセスできるようになる。

ビジネスゲーム実行管理サーバ１０は、タイマ管理機能を有し、監督者が指定した時間間隔（例えば、１時間間隔）で、シナリオ実行部１０−１により、ビジネスゲームの実行処理を起動する。ビジネスゲーム実行管理サーバ１０において、シナリオ実行部１０−１は、起動されたシナリオを解釈して実行することにより、学習者の意思決定データの内容を分析、計算し、経営結果（例えば、売上高、利益など）を計算し、学習者が確認できるように学習者端末１２に結果を表示する。学習者は、学習者端末１２に表示される、自身の経営結果を確認し、次の意思決定を行う。

本実施形態のビジネスゲームシステム１では、上記一連の処理が指定された回数繰り返される。１回の繰り返しをラウンドという。このようにしてゲームが１ラウンドずつ逐次進行していく。そして、予め指定された期間（例えば１週間、または所定ラウンド）が経過すると、ゲームが終了し、学習者端末１２によるアクセスができなくなる。

このように、本実施形態では、ビジネスゲーム実行管理サーバ１０が、ビジネスゲームの自動進行を実現するため、監督者の管理が不要になり、実施の負担を軽減することができる。また、学習者がいつでもどこでも学習することができ、特に、社会人の学習の機会を多くすることができる。本実施形態では、ビジネスゲームの自動進行を実現するため、以下に述べる機能を有している。

図２から図６は、本実施形態によるシナリオデータベース１０−２に格納されているシナリオの一例を示す図である。シナリオは、例えばテキスト形式で記述される。ビジネスゲーム実行管理サーバ１０のシナリオ実行部１０−１は、シナリオを解釈して実行することで、ビジネスゲームの一連の処理を実現する。

シナリオで使用される各命令の意味は、以下のとおりである。
「gcon」命令は、ゲーム中の全ラウンドを通じて各チームに共通の定数を設定する。
「tvar」は、ビジネスゲームを行う各チームの状態を表すチーム変数を定義（設定）する。
「tlet」命令は、チーム変数の演算実行や代入実行を示す。
「tlet if（）｛｝」命令は、もし()内が真ならば、｛｝を実行することを意味する。
「svar」命令は、各ラウンドで全チーム共通の１つの変数を定義（設定）する。
「slet」命令は、「svar」で指定した変数の内容を設定する。
[ivar」命令は入力変数を指定する。テキスト入力を行う場合には、「texarea ｎ ｍ（ｎ，ｍは数値）」と指定することで、ｎ字×ｍ行の入力エリアが表示される。学習者は、この入力エリアに対してテキストを入力する。
「opage」命令は、output pageを意味し、画面上への表示を行う。
「<P>〜</P>」命令は、〜部分のテキストの画面上への表示を行う。${}で囲まれた部分は、その変数名の中身（テキスト）を表示することを意味する。

図示するシナリオにおいて、行番号３７で、チーム数「５」を定義し、行番号３８で、最大ラウンド数「６」を定義している（ここで設定した数より１だけ少ないラウンドまで実行可能）。行番号４２〜４５で、学習者に対して意思決定データ（販売価格）の入力とその意思決定理由の入力を催促する処理を行う。行番号４９〜５７で、ゲームで用いる変数を定義する。行番号６４〜９７が、後述する「総需要設定処理のロジック」である。

また、行番号９９〜１１１で、一般管理費、来店客数（＝総需要／販売価格）、売上高（＝販売価格／来店客数）、売上原価（＝材料費＊来店客数）、売上総利益（＝売上高−売上原価）、営業利益（＝売上総利益−一般管理費）、累積営業利益（＝累積営業利益＠１＋営業利益）を計算する処理を行う。なお、上記「＠１」は、１つ前のラウンドの累積営業利益を意味する。

次に、行番号１１３〜１２８が、学習者端末１２への「改善点助言処理のロジック」であり、行番号１３２〜１６３が、学習者端末１２への「成績評価処理のロジック」である。また、行番号１６５〜２０６で、学習者端末１２への「結果表示処理のロジック」である。なお、上記「改善点助言処理のロジック」、「成績評価処理のロジック」、及び「結果表示処理のロジック」についても後述する

（１）ビジネスゲームの実行処理手順
図７は、本実施形態によるビジネスゲーム実行管理サーバ１０の動作を説明するためのフローチャートである。ビジネスゲーム実行管理サーバ１０において、シナリオ実行部１０−１は、指定された時間間隔で、シナリオデータベース１０−２に格納されているビジネスゲームのシナリオを解釈して実行する。

まず、ゲーム実行処理では、ビジネスゲームに参加登録されている学習者全員が、現在のラウンドの意思決定データ（販売価格）を入力しているか否かを判別する（ステップＳ１：判別部）。全員がデータ入力していない場合には（ステップＳ１のなし）、入力されるまで待機し、一方、全員がデータ入力した場合には（ステップＳ１のあり）、ステップＳ２へ進む。

通常のビジネスゲームでは、１人でもデータを入力していない学習者がいると、総需要を分配するような処理を実行することができない。対面型授業の場合には、監督者が学習者を督促して意思決定データを入力させる必要があり、監督者の負担の一つとなっている。この場合に、例えばシステムが強制的に初期値を入力して実行処理を進める方法もあるが、学習者の意図しないデータとなるので、教育効果上好ましくない。

また、対面型授業と異なり、学習者は、予め指定された期間（例えば１週間）の任意の時点で意思決定データを入力する。したがって、ある時点で何人の学習者がゲームに参加しているかは流動的に変化する。一般にビジネスゲームでは、学習者の人数に、１人当たりの基準需要を乗じて、総需要を決定し、これを意思決定データの良否に基づいて各学習者に分配するという構造となっている。もし、参加する学習者の数が変化すると、この仕組みがうまく働かず、参加している学習者の数が少ないときには、分配される数量が多くなってしまうため、教育効果上好ましくない。

そこで、本実施形態では、総需要設定処理を実行し、ゲームに参加している学習者の数に応じて、総需要を随時設定することで、その時点での最適の総需要を設定する（ステップＳ２：総需要設定処理部）。なお、総需要設定処理の詳細については後述する。

次に、ビジネスゲーム実行管理サーバ１０では、シナリオ実行部１０−１が、設定された総需要を、各学習者に分配する処理を行い（ステップＳ３：総需要配分処理部）、学習者端末１２に結果を表示する（ステップＳ４：結果表示処理部）。次に、予定ラウンド数や期間が終了したか否かを判定し（ステップＳ５）、終了していない場合には（ステップＳ５のＮＯ）、ステップＳ１に戻り、上述した処理を繰り返す。

一方、予定されたラウンド数や期間が終了した場合には（ステップＳ５のＹＥＳ）、学習者のゲーム結果である成績を算出し、この成績を学習者提示する成績評価処理を実行し（ステップＳ６：成績評価処理部）、上記成績に基づいて学習者の改善点を提示する改善点助言処理を実行し（ステップＳ７：改善点助言処理部）、学習者の学習を支援する。なお、成績評価処理、及び改善点助言処理の詳細については後述する。

なお、図７に示すフローチャートでは、予定ラウンドが全て終了した後に、成績評価処理、及び改善点助言処理を実行するようにしているが、１ラウンドが終了する度に、成績評価処理、及び改善点助言処理を実行するようにしてもよい。ラウンドごとに成績評価処理、及び改善点助言処理を実行することによって、ラウンドごとに、リアルタイムで学習者に助言することができる。

（２）総需要設定処理
図８は、本実施形態による総需要設定処理のシナリオ（図２〜図６の一部）を示す概念図である。また、図９は、本実施形態による総需要設定処理の動作を説明するためのフローチャートである。本実施形態では、ラウンドごとにゲームに参加している学習者の数によって、最適な総需要を設定する機能を実現している。

図８において、行番号６４〜６８で、意思決定データの入力があれば入力された値を販売価格とし、未入力であれば前回の値を継続するなどの振り分けを行う。行番号７０〜７４で、意思決定データの入力に応じて、ゲームへの参加の有無を示すゲーム参加フラグの設定を行う。行番号９１〜９７で、基準需要、総需要を定義し、基準需要の算出、総需要の算出を行う。

図９において、総需要設定処理では、まず、新規入力データ（意思決定データ入力）があるか否かを判定する（ステップＳ１０）。そして、新規入力データ（意思決定データ入力）がある場合には（ステップＳ１０のあり）、初参加設定処理として、新規参加フラグを１として、その学習者の参加を記録し、その新規入力データを意思決定データとして採用すべく学習者データに代入し、総参加者数に、１を加える（ステップＳ１１）。ある時点で、新規にゲームに参加した学習者があった場合も同様である。

一方、新規入力データ（意思決定データ入力）がない場合には（ステップＳ１０のなし）、前回入力データがあるか否かを判定する（ステップＳ１２）。そして、前回入力データがない場合には（ステップＳ１２のなし）、全くの初期状態では、参加している学習者の数はゼロであり、新規入力データや前回入力データも存在しないため、未参加設定処理として、学習者データも経営結果データも初期化（例えばゼロ）し、総参加者数もゼロとする（ステップＳ１３）。

また、新規入力データ（意思決定入力）がなく（ステップＳ１０のなし）、前回入力データがある場合には（ステップＳ１２のあり）、例えば、一旦、ゲームに参加した学習者が、何らかの都合で次の時間に意思決定データの入力を行わなかった場合に相当するので、継続設定処理として、前回入力データを今回の意思決定データとして採用し、総参加者数として前回値を維持する（ステップＳ１４）。これによって、ゲームの連続性を維持することができる。これは、現実社会のビジネスにおいても、販売間隔などを変更しなければ、それまでの値が維持されることを模擬している。

その後、総需要計算処理として、基準需要データベース１０−３から、ラウンドごとの基準需要（参加者１人当たりの需要）を取得し、この基準需要に総参加者数を乗ずることで、総需要を算出する（ステップＳ１５）。

（３）成績評価処理
図１０は、本実施形態による成績評価処理のシナリオ（図２〜図６の一部）を示す概念図である。また、図１１は、本実施形態による成績評価処理の動作を説明するためのフローチャートである。ゲーム時間が終了した時点、または各学習者が一定回数の意思決定を終了した時点で、成績評価を行うことが、教育効果上必須である。

図１０において、行番号１３２で、最終ラウンドが「５」であることを定義し、行番号１３３〜１３５で、学習者の順位を求め、行番号１３６〜１４２で、順位に応じたメッセージの表示を行う。実際には、さらに、図５に示すシナリオの行番号１４６〜１６３で、最高営業利益のチームやメッセージの表示を行う。

図１１において、成績評価処理では、まず、評価基準作成処理として、成績評価の基準となる、全参加者の経営結果の各項目（例えば利益など）について、最高値、最小値、平均値等を算出する（ステップＳ２０：図４の行番号１１６〜１１８）。次に、対象者評価処理として、各学習者の同項目について、上記評価基準と比較して優劣を求め、さらに、この優劣に従って各学習者の順位を決定する（ステップＳ２１）。次に、メッセージデータベース１０−４から、各学習者に成績に応じた最適なメッセージを抽出し（ステップＳ２２）、成績データとともに学習者端末に表示する（ステップＳ２３）。

（４）改善点助言処理
図１２は、本実施形態による改善点助言処理のシナリオ（図２〜図６の一部）を示す概念図である。また、図１３は、本実施形態による改善点助言処理の動作を説明するためのフローチャートである。ゲーム終了後に、学習者が自身の経営結果を振り返り、改善点を考慮することは教育上の効果が大きい。

図１２において、行番号１１３〜１１８で、最高価格、最低価格、平均価格を算出し、行番号１２０〜１２８で、学習者の経営効果の各項目(例えば、売上高、販売数など）が、前ラウンドより大きく（所定の変化率を超えて）変化したラウンドを抽出し、大きく変化した原因を抽出して、改善点の助言メッセージの表示を行う。

図１３において、改善点助言処理では、変化点抽出処理として、学習者の経営効果の各項目(例えば、売上高、販売数など）が、前ラウンドより大きく変化（例えば減少）したラウンドを抽出する（ステップＳ３０）。次に、変化原因抽出処理として、大きく変化した原因と考えられる内部環境（自身の意思決定データなど）と外部環境（他の学習者の意思決定データなど）とを、変化原因データベース（予め想定されるパターンが登録されている）１０−５から抽出する（ステップＳ３１）。そして、判定された変化原因に対する最適な改善点の助言メッセージを、メッセージデータベース１０−４から抽出し（ステップＳ３２）、学習者端末１２に表示する（ステップＳ３３）。

次に、本実施形態のビジネスゲーム実行管理サーバ１０によるビジネスゲーム（レストランゲーム）の進行について説明する。図１４から図２４は、本実施形態による学習者端末１２、及び監督者端末１１の表示画面の一例を示す模式図である。なお、以下では、図７に示すフローチャートにおいて、ラウンド終了ごとに改善点助言処理を実行し、全ラウンド終了後に、成績評価処理を実行する場合について説明する。また、学習者をプレーヤという。

まず、レストランゲームのルールについて説明する。このレストランゲームでは、プレーヤは、学習者端末１２から、毎日のランチの販売価格（意思決定データ）を入力する。価格が安いほど客が入る。各プレーヤは、他の店（他の学習者）と客を取り合う。客の数は、１店舗当たり１５０人程度で毎日変化する。学習者端末１２には、１日ごとの営業利益と、初日からの累積営業利益が表示される。累積営業利益の多いチームを勝ちとする。

５チームで、５ラウンド（１ラウンドは１日に相当）実施する。ゲームは毎正時（００分）に自動進行される。プレーヤが販売価格を入力していれば、その値を使用する。この値は、次にデータを入力するまでは継続される。

（第１ラウンド）
第１ラウンドにおいて、チーム＃１のプレーヤの学習者端末１２の画面には、図１４に示す入力画面が表示される。プレーヤは、学習者端末１２から、販売価格（意思決定データ）として、７００円とその理由「初日は様子を見るため、勘で決めた。」とを入力する。同様に、チーム＃２とチーム＃３も７００円とその理由とを入力する。また、チーム＃４とチーム＃５は、まだゲームに参加していない。

意思決定理由が入力されると、ビジネスゲーム実行管理サーバ１０は、そのプレーヤがゲームに参加したと判断し、参加人数分の総需要を設定する（図７のステップＳ２、または図８、図９に示す総需要設定処理を参照）。次に、毎正時（００分）になると、ゲームが自動進行され、データを入力してないプレーヤには、ビジネスゲーム実行管理サーバが自動で初期値（このゲームでは０）を入力する。

監督者端末１１には、図１５に示すデータ入力状況画面が表示される。図１５に示すデータ入力状況画面では、横がチーム番号で、縦がラウンド番号である。データ入力状況画面では、第１ラウンドにおいて、チーム＃１、＃２、＃３は、プレーヤが入力したので○印、チーム＃４、＃５は、プレーヤが入力せず、コンピュータが入力したので、▲印が表示される。

（第２ラウンド）
次に、ビジネスゲーム実行管理サーバ１０は、第２ラウンドに進めて、図１６に示すような計算結果（モデルの計算結果）を学習者端末１２の画面に表示する（図７のステップＳ４：結果表示処理）。３チームが参加しているため、需要は、１５０人×３店舗くらいになっている。参加チームが増えると、自動的に増加する（図７のステップＳ２：総需要設定処理）。

チーム＃１、＃２、＃３が同じく７００円の価格を付けたので、来店客数は３等分され、売上高や営業利益が計算される（図７のステップＳ３：総需要配分処理）。また、学習者端末１２の画面には、営業利益と累積営業利益について、図１７に示すような、メッセージが表示される（図７のステップＳ７：改善点助言処理）。図示の例では、「１．トップチームの累積営業履歴は、１３２００円。」、「２．これまでの営業利益の最高は、３チームの、１３２００円。」というようなメッセージが表示される。

第２ラウンドから、チーム＃４が参加し、価格８００円と意思決定理由とを入力し、チーム＃５は、まだゲームに参加していない。チーム＃１、＃２、＃３は、データを入力しないまま、次の正時（００分）が来たので、ビジネスゲーム実行管理サーバ１０が前回の入力値７００円を採用して入力する。チーム＃５には、初期値０を自動入力する（図７のステップＳ２：総需要設定処理）。

監督者端末１１には、図１８に示すデータ入力状況画面が表示される。図１８に示すデータ入力状況画面では、第２ラウンドにおいて、チーム＃１、＃２、＃３は、データを入力しないまま、ビジネスゲーム実行管理サーバ１０が前回の入力値７００円を入力したので、▲印が表示される。チーム＃４は、新たに参加し、価格８００円と意思決定理由とを入力したので○印、チーム＃５には、ビジネスゲーム実行管理サーバ１０が初期値０を自動入力したので、▲印が表示される。

（第３ラウンド）
次に、ビジネスゲーム実行管理サーバ１０は、第３ラウンドに進めて、図１９に示すような計算結果を学習者端末の画面に表示する（図７のステップＳ４：結果表示処理）。参加チームが４になったので、需要も１５０人×４＝６００くらいに増えている。チーム＃４は、価格が高いので客数が少ないが、営業利益は他店よりも多くなっている（１９，０００円）。

第３ラウンドでチーム＃５が参加し、６００円とその理由とを入力する。また、チーム＃１が価格を５００円に下げ、その理由「低価格で客数を増やす」を入力する。ここで、図２０に、チーム＃１の入力画面を示す。他のチームは、入力しないまま、次の正時（００分）が来たので、ビジネスゲーム実行管理サーバ１０は、データ自動入力とモデル計算を実行し、図２１に示すような計算結果を学習者端末１２の画面に表示する。

図２１に示すように、学習者端末１２の画面には、第３ラウンドの結果として、５チームが参加したので、需要は、１５０人×５＝７５０人程度に増加している。チーム＃１は、価格を５００円に下げたので、客数は、１９１人に増加したが、営業利益は、赤字となってしまった（−１１，８００円）。

ビジネスゲーム実行管理サーバ１０は、営業利益の変化原因と改善点を分析し、図２２に示すような助言メッセージをチーム＃１の学習者端末１２に表示する（図７のステップＳ７：改善点助言処理）。図示の例では、「１．販売価格が低いので営業利益が減っています。販売価格を少し上げてみてはどうでしょうか。」、「２．トップチームの累積営業利益は、３１２００円。」、「３．これまでの営業利益の最高は、４チームの、１９０００円。」というようなメッセージが表示される。

（第４ラウンド＆第５ラウンド）
その後、チーム＃１は、価格を８００円に値上げし、他チームは入力しないまま、第４ラウンドと第５ラウンド（最終ラウンド）が自動進行される。学習者端末１２には、図２３に示すように、第５ラウンド（最終ラウンド）の結果表示が表示される（図７のステップＳ４：結果表示処理）。チーム＃１は、価格を８００円に値上げしたので、営業利益を「１７，５００円」の黒字に戻したことが分かる。

最終ラウンドが終了すると、ビジネスゲーム実行管理サーバ１０は、各チームの成績を評価し、学習者端末１２にメッセージを表示する（図７のステップＳ６：成績評価処理）。図示の例では、「１．あなたの順位は、５チーム中、４位でした。もっとがんばりましょう。」、「２．トップチームの累積営業利益は、６３０００円。」、「３．これまでの営業利益の最高は、４チームの、１７５００円。」というようなメッセージが表示される。

上述した実施形態によれば、監督者の管理が不要になり、実施の負担を軽減することができる。また、学習者は、いつでもどこでも学習することができ、特に、社会人の学習の機会を多くすることができる。

以上、本発明の実施の形態について図面を参照して詳述したが、具体的な構成はその実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計等も含まれる。

１ ビジネスゲームシステム
１０ ビジネスゲーム実行管理サーバ（ビジネスゲーム実行管理装置）
１０−１ シナリオ実行部
１０−２ シナリオデータベース
１０−３ 基準需要データベース
１０−４ メッセージデータベース
１０−５ 変化原因データベース
１１ 監督者端末
１２、１２−１〜１２−ｎ 学習者端末

Claims (7)

1. 複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するビジネスゲーム実行管理装置であって、
   前記ビジネスゲームの実行手順が記述されたシナリオを格納するシナリオデータベースと、
   所定の時間間隔で、前記シナリオデータベースに格納された前記シナリオを解釈して実行する実行処理部と、
   ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別部と、
   前記判別部が、前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理部と、
   前記総需要を学習者に対応付けて分配する総需要配分処理部と、
   前記総需要配分処理部が分配した分配結果を、前記学習者端末により表示させる結果表示処理部と、
   学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理部と、
   前記成績に基づいて、学習者の改善点を提示する改善点助言処理部と、
   を備え、
   前記総需要設定処理部は、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持する、ビジネスゲーム実行管理装置。
2. 前記総需要設定処理部は、
   前記ビジネスゲームに参加している学習者の数に応じて、総需要を随時設定することで、その時点での最適の総需要を設定する
   ことを特徴とする請求項１に記載のビジネスゲーム実行管理装置。
3. 前記総需要設定処理部は、
   新規の意思決定データがある場合には、前記意思決定データに対応する学習者の参加を記録し、前記新規の意思決定データを学習者データに代入し、総参加者数に１を加え、
   前記新規の意思決定データがなく、且つ前回の意思決定データがない場合には、学習者データ、及び総参加者数を初期化し、
   前記新規の意思決定データがなく、且つ前回の意思決定データがある場合には、前回の意思決定データを今回の意思決定データとして採用し、総参加者数として前回値を維持し、
   いずれの場合も、ラウンドごとの参加者１人当たりの需要を示す基準需要に総参加者数を乗ずることにより、総需要を算出する
   ことを特徴とする請求項２に記載のビジネスゲーム実行管理装置。
4. 前記成績評価処理部は、
   成績の評価基準となる、全参加者の経営結果の各項目について、最高値、最小値、平均値を算出し、各学習者の同項目について、前記評価基準と比較して優劣を求め、前記優劣に従って各学習者の順位を決定し、各学習者の順位成績を通知するメッセージを前記学習者端末により表示させる、
   ことを特徴とする請求項１から３のいずれか一項に記載のビジネスゲーム実行管理装置。
5. 前記改善点助言処理部は、
   全参加者の経営結果の各項目について、所定の変化率を超えて変化した項目がある場合に、前記変化の原因を抽出し、前記原因に対する改善点の助言メッセージを、前記学習者端末で表示させる、
   ことを特徴とする請求項１から４のいずれか一項に記載のビジネスゲーム実行管理装置。
6. 複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するコンピュータを、
   前記ビジネスゲームの実行手順が記述されたシナリオを格納するシナリオデータベースと、
   所定の時間間隔で、前記シナリオデータベースに格納された前記シナリオを解釈して実行する実行処理部と、
   ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別部と、
   前記判別部が、前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理部と、
   前記総需要を学習者に対応付けて分配する総需要配分処理部と、
   前記総需要配分処理部が分配した分配結果を、前記学習者端末により表示させる結果表示処理部と、
   学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理部と、
   前記成績に基づいて、学習者の改善点を提示する改善点助言処理部と、
   として機能させ、
   前記総需要設定処理部を、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持するよう機能させるためのビジネスゲーム実行管理プログラム。
7. 複数の学習者端末から入力される意思決定データに基づいてビジネスゲームを実行するビジネスゲーム実行管理方法であって、
   所定の時間間隔で、実行処理部が、前記ビジネスゲームの実行手順が記述されたシナリオを解釈して実行するステップと、
   判別部が、ラウンドごとに、前記学習者端末から前記意思決定データが入力されたか否かを判別する判別ステップと、
   前記判別ステップにおいて前記意思決定データが入力されたと判別した場合に、新規入力された前記意思決定データの有無と前回入力された前記意思決定データの有無とに基づいて、総需要設定処理部が学習者の数を計算し、その学習者の数に応じて総需要を設定する総需要設定処理ステップと、
   総需要配分処理部が、前記総需要を学習者に対応付けて分配する総需要配分処理ステップと、
   前記総需要配分処理ステップにおいて分配された分配結果を、結果表示処理部が、前記学習者端末により表示させる結果表示処理ステップと、
   成績評価処理部が、学習者の成績を算出し、前記成績を前記学習者端末により表示させる成績評価処理ステップと、
   改善点助言処理部が、前記成績に基づいて、学習者の改善点を提示する改善点助言処理ステップと、
   を有し、
   前記総需要設定処理ステップでは、前記学習者の数の計算において、新規入力された前記意思決定データが無く、且つ前回入力された意思決定データがある場合、前回の意思決定データを今回の意思決定データとして採用し、当該前回の意思決定データを採用した学習者については、学習者数として前回値を維持する、
   ことを特徴とするビジネスゲーム実行管理方法。

Images