JP2019215606A - 施策決定システムおよび施策決定方法 - Google Patents

Abstract

【課題】特定領域での有効な施策を提示すること。【解決手段】施策決定システムは、記憶デバイスに、対象地域における特定領域内の問題を解消するための複数の施策案と、問題解消の目標値と問題の解消度とを対応付けた問題解消情報と、問題解消に必要な費用の目標値を記憶する費用情報と、問題の予測発生量と、複数の施策案の各々についての問題に対する供給可能量と、施策案を実行した場合の予測費用と、を記憶しており、問題に対する供給可能量と問題の予測発生量とに基づいて、問題解消の目標値に対応する解消度を問題解消情報から特定し、施策案を実行した場合の予測費用に該当する費用の目標値を費用情報から特定し、特定された問題の解消度と、特定された費用の目標値と、に基づいて、施策案の費用対効果を算出し、複数の施策案の中から、算出された費用対効果が相対的に高い２以上の特定の施策案を選出する。【選択図】図２

Description

本発明は、施策を決定する施策決定システムおよび施策決定方法に関する。

特許文献１は、電子マネーや定期乗車券の機能を搭載した携帯端末装置を開示する。特許文献２は、２駅間運賃を算出することについて正当性が検証済みの自動改札機等の運賃算出装置により、経路外中抜け精算運賃を算出できることを開示する。特許文献３は、一旦チャージされた電子マネー機能付きＩＣカードの残額の払戻しを可能にする電子マネー精算システムを開示する。特許文献４は、改札情報を利用して駅周辺の状況を推定する推定方法を開示する。

特開２００９‐２６５９９７号公報 特開２０１０‐００３１８０号公報 特開２０１０‐０８６１３４号公報 特開２０１４‐００６７４３号公報

対象地域外の流入者が対象地域内の特定領域に流入すると一時的に特定領域の人口密度が増大し、特定領域で渋滞が発生し、ゴミも大量発生することが懸念される。しかしながら、上述した従来技術では、特定領域での渋滞発生やゴミの増加について講じるべき対策について考慮されていない。

本発明は、特定領域での有効な施策を提示することを目的とする。

本願において開示される発明の一側面となる施策決定システムおよび施策決定方法は、プログラムを実行するプロセッサと前記プログラムを記憶する記憶デバイスとを有する１台以上のコンピュータ群により構成される施策決定システムであって、前記記憶デバイスは、対象地域における特定領域内の問題を解消するための複数の施策案と、問題解消の目標値と前記問題の解消度とを対応付けた問題解消情報と、前記問題解消に必要な費用の目標値を記憶する費用情報と、前記問題の予測発生量と、前記複数の施策案の各々についての前記問題に対する供給可能量と、前記施策案を実行した場合の予測費用と、を記憶しており、前記プロセッサは、前記複数の施策案の各々について、前記問題に対する供給可能量と前記問題の予測発生量とに基づいて、前記問題解消の目標値に対応する解消度を前記問題解消情報から特定する第１特定処理と、前記複数の施策案の各々について、前記施策案を実行した場合の予測費用に該当する前記費用の目標値を前記費用情報から特定する第２特定処理と、前記複数の施策案の各々について、前記第１特定処理によって特定された前記問題の解消度と、前記第２特定処理によって特定された前記費用の目標値と、に基づいて、前記施策案の費用対効果を算出する算出処理と、前記複数の施策案の中から、前記算出処理によって算出された費用対効果が相対的に高い２以上の特定の施策案を選出する選出処理と、前記選出処理によって選出された２以上の特定の施策案を出力する出力処理と、を実行することを特徴とする。

本発明の代表的な実施の形態によれば、特定領域での有効な施策を提示することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

図１は、施策決定システムによる活性化例１を示す説明図である。 図２は、施策決定システムによる活性化例２を示す説明図である。 図３は、施策決定システムのシステム構成例を示す説明図である。 図４は、図３に示したコンピュータのハードウェア構成例を示すブロック図である。 図５は、図３に示した鉄道会社の管理システムのハードウェア構成例を示す説明図である。 図６は、図３および図５に示した鉄道情報ＤＢの記憶内容の一例を示す説明図である。 図７は、図３に示した自治体情報ＤＢの記憶内容の一例を示す説明図である。 図８は、図３に示したファンド情報ＤＢの記憶内容の一例を示す説明図である。 図９は、協賛企業情報ＤＢの記憶内容の一例を示す説明図である。 図１０は、乗車券予約購入シーケンス例を示すシーケンス図である。 図１１は、寄付金取得シーケンス例を示すシーケンス図である。 図１２は、施策決定シーケンス例を示すシーケンス図である。 図１３は、問題解消ＫＰＩデータの一例を示す説明図である。 図１４は、施策案データの一例を示す説明図である。 図１５は、費用ＫＰＩデータを示す説明図である。 図１６は、図１２のステップＳ１２０７で示した分析装置による施策案決定処理手順例を示すフローチャートである。

以下、添付図面を用いて、本実施例における施策決定システムについて説明する。施策決定システムとは、対象地域外から当該対象地域内の特定領域へ来訪する人（以下、来訪者）から寄付金を用いて当該対象地域を当該対象地域の住民（以下、地元民）とともに、来訪者の来訪により当該対象地域で発生する問題を解消するための施策を決定する地元民参加型のシステムである。本実施例は、来訪者の移動手段の一例として鉄道を例に挙げて説明し、来訪者からの寄付金は、鉄道運賃への上乗せ料金として説明する。ただし、来訪者の移動手段は、鉄道に限らず、バス、船舶、飛行機などの他の交通手段でもよい。また、来訪手段は、交通手段に限らず、当該対象地域で開催されるコンサートやスポーツなどのイベントでもよい。この場合、寄付金は、交通手段の運賃への上乗せでもよく、イベントのチケットへの上乗せでもよい。

＜施策決定システムによる活性化例＞
図１は、施策決定システムによる活性化例１を示す説明図である。鉄道網１００は、電車１０９が移動する交通手段である。電車１０９は、鉄道網上の駅１０１，１０２に停車する。駅１０１，１０２には改札機１０３があり、来訪者１０４が通過可能である。来訪者１０４は、モバイル端末１０５を有する。来訪者１０４のモバイル端末１０５は、来訪者１０４が事前に駅１０１から駅１０２までの乗車券を購入済みである場合、購入済みであることを示す情報を保持する。来訪者１０４が駅１０１の改札機１０３を通過する際、改札機１０３との近距離通信（たとえば、ＲＦＩＤ）により、鉄道会社の管理システム３０２（図３を参照）は、当該来訪者１０４の入場許可を判断する。入場が許可された場合、鉄道会社の管理システム３０２は、改札機１０３を開門して来訪者１０４を通過させる。

なお、来訪者１０４が事前に駅１０１から駅１０２までの乗車券を購入済みでない場合、鉄道会社の管理システム３０２は、来訪者１０４のモバイル端末１０５と改札機１０３との近距離通信時にモバイル端末１０５にチャージされている金額から初乗り運賃の金額を取得する。

来訪者１０４は駅１０１から乗車し駅１０２で降車する。来訪者１０４は、駅１０２の改札を通過する。来訪者１０４が駅１０１の改札機１０３を通過する際、来訪者１０４のモバイル端末１０５と改札機１０３との近距離通信により、鉄道会社の管理システム３０２は、当該来訪者１０４の退場許可を判断する。退場が許可された場合、鉄道会社の管理システム３０２は、改札機１０３を開門して来訪者１０４を通過させる。この際、鉄道会社の管理システム３０２は、来訪者１０４のモバイル端末１０５から改札機１０３を介して寄付金を取得する。なお、寄付金の寄付については、事前に来訪者１０４が寄付金の取得許可の設定が来訪者１０４のモバイル端末１０５になされているものとする。

なお、来訪者１０４が事前に駅１０１から駅１０２までの乗車券を購入済みでない場合、鉄道会社の管理システム３０２は、来訪者１０４のモバイル端末１０５と改札機１０３との近距離通信時にモバイル端末１０５にチャージされている金額から、駅１０１から駅１０２までの運賃から初乗り運賃を引いた差額と寄付金とを取得する。来訪者１０４からの寄付金は、鉄道会社の管理システム３０２からＮＰＯ（Ｎｏｎｐｒｏｆｉｔ Ｏｒｇａｎｉｚａｔｉｏｎ）法人のようなファンド１２０にプールされる。

駅１０２は、地元民１３０の対象地域内の特定領域の一例である中心地１１０に存在する。中心地１１０には、来訪者１０４や地元民が来訪するための、たとえば、ホテルなどの宿泊施設１１１、商店舗１１２、商業ビル１１３、オフィスビル１１４、ホールやアリーナ、スタジアムなどのイベント会場１１５が存在する。

図２は、施策決定システムによる活性化例２を示す説明図である。活性化例２は、イベント会場１１５でイベントが開催される日に来訪者１０４が来訪した場合の問題発生例を示している。イベントの開催日には中心地１１０への来訪者１０４が急増するため、中心地１１０で渋滞が発生したり、イベント会場１１５周辺のゴミが増加したり、地元民１３０が中心地１１０との間の移動に支障をきたしたりするという問題が発生する。

このため、事前にファンド１２０にプールされた寄付金を用いて、ファンド１２０は、イベントの開催日における需要予測に基づいて、対象地域における特定領域内の問題を解消するための複数の施策案を提案する。複数の施策案には、たとえば、駅１０２とイベント会場１１５との間で来訪者１０４を輸送する臨時バスの運行、中心地１１０でのごみ回収頻度増加、地元民１３０へのシェアオフィス（中心地１１０外）の開門、駅１０２の混雑緩和のため前泊来訪者１０４の宿泊費割引サービスの提供が挙げられる。地元民１３０は、提案された複数の施策案について投票し、最も投票数の多い施策案が実行される。

このように、プールされた寄付金の使途は地元民１３０により決定され、プールされた寄付金は当該地域のために使用されるため、プールされた寄付金は、地元民１３０が気持ちよく暮らすための街の発展に平等に還元される。また、住民のための街づくり施策を策定するファンド１２０が介在することで、来訪者１０４増による街の変化に、鉄道を利用しない住民も主体的に加わる仕組みを提案することが可能となる。

また、来訪者１０４が来訪するほど、街が気持ちよく発展し続ける。たとえば、プールされた寄付金は、大量の来訪者１０４によって突発的、一時的に街に生じる交通渋滞やごみのポイ捨てによる美観の低下など地元住民にとって望ましくない状況を回避するために使用される。すなわち、来訪者１０４が増えて、地元民１３０にとってむしろ街が不便になった、魅力がなくなったということが低減される。

また、地元民１３０の選択で、街を良くする「使い道」が見えてくることになる。たとえば、街の需要予測をもとに、ファンド１２０のサービス事業者が、「臨時バスを走らせる」、「ゴミの回収頻度を上げる」「地元民１３０にシェアオフィスを無料開門する」など、短期スパンの使い道を複数提案する。最終的に住民が提案に投票することでプールされた寄付金の使い道が決定される。

また、施策決定システムの導入により、地元ビジネスを巻き込みながら、地元民１３０自ら街を良くする行動を起こすことが期待される。たとえば、ファンド１２０のサービス事業者が、プールされた寄付金の使い道自体の提案を地元民１３０に促し、「大都市から呼ぶ講師の旅費」「市民のためのワークショップ」など、より文化的にも発展できるような長期スパンの使い方を住民たちが提案できるようになる。街の変化が地元民１３０ごとに変わり、鉄道が街の成熟を支える存在として身近に感じるようになる。プールされた寄付金は地域に還元されるので地元ビジネスも活性化し、街の継続的な発展が支えられる。

＜施策決定システムのシステム構成例＞
図３は、施策決定システムのシステム構成例を示す説明図である。施策決定システム３００は、分析装置３０１、管理システム３０２、公共システム３０３、運営システム３０４、協賛企業システム３０５、来訪者１０４のモバイル端末１０５、デジタルサイネージ３６３、車内音声インタフェース３６２、および地元民１３０のモバイル端末３６１が、インターネットなどのネットワーク３１０を介して通信可能に接続される。なお、システムとは、１台のコンピュータまたは２台以上の連携しあうコンピュータである。すなわち、施策決定システム３００は、１台以上のコンピュータ群により構成される。

分析装置３０１は、中心地１１０の需要を予測し、地元民１３０に提案すべき施策案を分析するコンピュータである。管理システム３０２は、鉄道会社が鉄道網や駅を管理する特定のコンピュータシステムである。管理システム３０２は、鉄道情報を記憶する鉄道情報ＤＢ３２０を有する。また、管理システム３０２は、改札機１０３と通信可能に接続されている。改札機１０３は、対象地域外からの来訪者の端末１０５と近距離通信可能な特定領域内の検出機である。

公共システム３０３は、当該地域の自治体が管理するコンピュータシステムである。公共システム３０３は、当該地域の人口推移を記憶する人口推移ＤＢ３３１、当該地域の交通情報を記憶する交通情報ＤＢ３３２、当該地域の自治体情報を記憶する自治体情報ＤＢ３３３に接続されている。また、公共システム３０３は、中心地１１０を監視する監視カメラ３３０にも接続されている。

運営システム３０４は、ファンド１２０であるサービス事業者が運営するコンピュータシステムである。運営システム３０４は、ファンド１２０情報を記憶するファンド情報ＤＢ３４０に接続されている。協賛企業システム３０５は、当該地域に協賛する協賛企業が管理するコンピュータシステムである。協賛企業システム３０５は、協賛企業に関する情報（協賛企業情報）を記憶する協賛企業情報ＤＢ３５０に接続されている。協賛企業とは、たとえば、臨時バスの運行会社、宿泊施設１１１、シェアオフィスの運営会社、ゴミ清掃業者である。

デジタルサイネージ３６３は、当該地域に設置され、運営システム３０４からの施策案を表示する表示装置である。車内音声インタフェース３６２は、たとえば、地元民１３０が所有する自動車内に設けられ、運営システム３０４からの施策案を音声出力する。たとえば、車内音声インタフェース３６２は、運営システム３０４の制御により、施策案がシェアオフィスの無料開門である場合、自動車の現在位置から近隣の無料開門のシェアオフィスの位置を音声で案内する。地元民１３０のモバイル端末３６１は、スマートフォンなど地元民１３０が所有する端末であり、運営システム３０４からの施策案を表示したり、表示された施策案の選択を受け付けて運営システム３０４に送信したりする。

＜コンピュータのハードウェア構成例＞
図４は、図３に示したコンピュータのハードウェア構成例を示すブロック図である。コンピュータ４００は、プロセッサ４０１と、記憶デバイス４０２と、入力デバイス４０３と、出力デバイス４０４と、通信インタフェース（通信ＩＦ）４０５と、を有する。プロセッサ４０１、記憶デバイス４０２、入力デバイス４０３、出力デバイス４０４、および通信ＩＦ４０５は、バス４０６により接続される。プロセッサ４０１は、コンピュータ４００を制御する。プロセッサ４０１は、プログラムを実行する。記憶デバイス４０２は、プロセッサ４０１の作業エリアとなる。また、記憶デバイス４０２は、各種プログラムやデータを記憶する非一時的なまたは一時的な記録媒体である。記憶デバイス４０２としては、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリがある。入力デバイス４０３は、データを入力する。入力デバイス４０３としては、たとえば、キーボード、マウス、タッチパネル、テンキー、スキャナがある。出力デバイス４０４は、データを出力する。出力デバイス４０４としては、たとえば、ディスプレイ、プリンタがある。通信ＩＦ４０５は、ネットワーク３１０と接続し、データを送受信する。

＜管理システム３０２のハードウェア構成例＞
図５は、図３に示した鉄道会社の管理システム３０２のハードウェア構成例を示す説明図である。管理システム３０２は、寄付金管理装置５０１と、収入管理装置５０２と、運行管理装置５０３と、予約管理装置５０４と、改札機１０３と、鉄道情報ＤＢ３２０と、を有する。寄付金管理装置５０１、収入管理装置５０２、運行管理装置５０３、予約管理装置５０４、改札機１０３、および鉄道情報ＤＢ３２０は、バス５０５により接続される。

寄付金管理装置５０１は、来訪者１０４からの寄付金を管理するコンピュータである。収入管理装置５０２は、乗車券購入による収入を管理するコンピュータである。収入管理装置５０２は、たとえば、顧客のクレジットカードおよび銀行口座番号を含む個人情報を保有し、顧客が乗車券を購入した場合に決済することが可能である。運行管理装置５０３は、電車１０９の運行を管理するコンピュータである。予約管理装置５０４は、乗車日時、便および座席の予約を管理するコンピュータである。鉄道情報ＤＢ３２０は、利用履歴、利用予測、運賃、便および座席の乗車券情報、顧客情報、寄付金など、寄付金管理装置５０１、収入管理装置５０２、運行管理装置５０３、および予約管理装置５０４で用いられる情報を記憶するデータベースである。

来訪者１０４は、モバイル端末１０５を用いて予約管理装置５０４と通信して、乗車したい日時の便および座席を指定して乗車券を予約購入し、予約購入した乗車券情報をモバイル端末１０５の記憶デバイス４０２に記憶する。同様に、予約管理装置５０４は、乗車券情報を鉄道情報ＤＢ３２０に記憶する。改札機１０３は、モバイル端末１０５との近距離通信により、乗車券情報を予約管理装置５０４に送信する。予約管理装置５０４は、改札機１０３からの乗車券情報が鉄道情報ＤＢ３２０内の乗車券情報と一致すれば、改札機１０３を開門して来訪者１０４を通過させる。

＜鉄道情報ＤＢ３２０の記憶内容例＞
図６は、図３および図５に示した鉄道情報ＤＢ３２０の記憶内容の一例を示す説明図である。図６では、鉄道情報として利用予測について説明する。利用予測は、予約購入された乗車券情報に基づいて生成される。鉄道情報ＤＢ３２０は、利用駅６０１と、利用種別６０２と、人数６０３と、利用予定日時６０４と、を利用予測として記憶する。利用駅６０１は、利用者が利用（乗車または降車）する駅である。利用種別６０２は、利用駅６０１を利用する種別（乗車または降車）である。人数６０３は、利用駅６０１で利用種別６０２の利用をする利用者の人数である。利用予定日時６０４は、利用者が利用駅６０１を利用する日時である。

＜自治体情報ＤＢ３３３＞
図７は、図３に示した自治体情報ＤＢ３３３の記憶内容の一例を示す説明図である。図７では、駅１０２からイベント会場１１５までの対象経路における混雑状況が自治体情報としてあらかじめ管理者によって入力される。自治体情報ＤＢ３３３は、イベント７０１と、駅前交通量７０２と、信号の時間７０３と、交差点の数７０４と、路上駐車場の予想利用率７０５と、を混雑状況として記憶する。イベント７０１とは、特定地域で開催されるイベントを特定する情報である。駅前交通量７０２とは、駅１０２前における１時間当たりに通過する車両の台数である。信号の時間７０２とは、対象経路上に存在する信号の待ち時間の平均値である。交差点の数７０３とは、対象経路上の交差点の数である。路上駐車場の予想利用率７０５とは、対象経路上に存在する路上駐車場について予想した利用率である。

＜ファンド情報ＤＢ３４０＞
図８は、図３に示したファンド情報ＤＢ３４０の記憶内容の一例を示す説明図である。ファンド情報ＤＢ３４０は、ファンド情報として、地区名８０１と、事象発生日８０２と、投票者数８０３と、選択施策案８０４と、投票者の施策案利用状況８０５と、満足度８０６と、を記憶する。地区名８０１とは、事象が発生した地区である。事象はイベントを含む。イベント以外でも当該地区で混雑が発生する場合もある。事象発生日８０２とは、事象が発生した日である。投票者数８０３とは、施策案の選択に投票した地元民１３０の数である。選択施策案８０４は、投票の結果選択された施策案である。投票者の施策案利用状況８０５は、選択施策案８０４を利用した投票者の人数である。満足度８０６は、投票者のモバイル端末１０５から送信されてきた満足度の平均値である。

＜協賛企業情報ＤＢ３５０＞
図９は、協賛企業情報ＤＢ３５０の記憶内容の一例を示す説明図である。図９では、協賛企業としてバス運行会社を例に挙げて説明する。協賛企業情報ＤＢ３５０は、協賛企業情報として、会社名９０１と、保有台数９０２と、大きさ／収容人数９０３と、利用予定９０４と、稼働率履歴９０５と、を記憶する。会社名９０１は、バス運行会社の社名である。保有台数は、会社名９０１のバス運行会社が保有するバスの台数である。大きさ／収容人数９０３は、会社名９０１のバス運行会社が保有するバスの大きさおよび収容人数である。利用予定９０４は、１日の利用予定人数である。稼働率履歴９０５は、会社名９０１のバス運行会社における月あたりの稼働率である。

＜乗車券予約購入シーケンス例＞
図１０は、乗車券予約購入シーケンス例を示すシーケンス図である。来訪者１０４は、来訪者１０４のモバイル端末１０５に対し予約操作をする（ステップＳ１００１）。モバイル端末１０５は、予約操作を受け付けると（ステップＳ１００１）、予約操作で入力された情報を予約要求として予約管理装置５０４に送信する（ステップＳ１００２）。予約管理装置５０４は、予約要求を受信すると、予約要求で指定された発着日時、乗降車駅、および座席の仮予約処理を実行する（ステップＳ１００３）。予約管理装置５０４は、仮予約処理（ステップＳ１００３）で得られた降車駅情報を寄付金管理装置５０１に送信する（ステップＳ１００４）。

寄付金管理装置５０１は、降車駅情報を受信した場合（ステップＳ１００４）、当該降車駅について寄付金設定がされているか否かを判定する（ステップＳ１００５）。寄付金設定とは、来訪者１０４が降車駅の改札機１０３を通過する場合に、来訪者１０４のモバイル端末１０５から寄付金を取得する設定である。寄付金設定は、駅ごとに設定される。寄付金管理装置５０１は、寄付金設定の判定結果を予約管理装置５０４に返す（ステップＳ１００６）。

予約管理装置５０４は、判定結果を受信すると、判定結果が寄付金設定有りの場合、予約要求（ステップＳ１００２）の場合の運賃および寄付金の情報をモバイル端末１０５に送信する（ステップＳ１００７）。これにより、モバイル端末１０５は、運賃および寄付金の情報を表示する。

来訪者１０４は、モバイル端末１０５に表示されている運賃および寄付金の情報を見て、モバイル端末１０５に対し、来訪者１０４のクレジットカード番号を入力するなどの購入操作を行う（ステップＳ１００８）。モバイル端末１０５は、購入操作を受け付けると、モバイル端末１０５は、予約要求（ステップＳ１００２）で指定された発着日時、乗降車駅、および座席の購入を確定させるための決済情報を予約管理装置５０４に送信する（ステップＳ１００９）。

予約管理装置５０４は、決済情報を受信すると、たとえば、収入管理装置５０２またはクレジットカード会社のサーバ（当該来訪者１０４のクレジットカード番号および銀行口座番号を含む個人情報を保有）と通信して決済処理をおこない、チケットＩＤを発行する（ステップＳ１０１０）。予約管理装置５０４は、来訪者１０４、チケットＩＤ、到着日時、降車駅および寄付金の情報（以下、寄付情報）を寄付金管理装置５０１に送信する（ステップＳ１０１１）。

寄付金管理装置５０１は、寄付情報を受信すると、寄付情報を記憶デバイス４０２に記録し（ステップＳ１０１２）、記録完了を予約管理装置５０４に通知する（ステップＳ１０１３）。予約管理装置５０４は、記録完了の通知を受けると（ステップＳ１０１３）、運賃情報を収入管理装置５０２に送信する（ステップＳ１０１４）。

収入管理装置５０２は、運賃情報を受信すると、記録完了を予約管理装置５０４に通知する（ステップＳ１０１６）。予約管理装置５０４は、記録完了の通知を受けると、仮予約処理（ステップＳ１００３）の処理内容に基づいて、予約処理を実行してチケット情報を生成する（ステップＳ１０１７）。

チケット情報は、たとえば、チケットＩＤ、発着日時、乗降車駅、座席、運賃および寄付金の情報を含む。予約管理装置５０４は、チケット情報をモバイル端末１０５に送信する（ステップＳ１０１８）。モバイル端末１０５は、チケット情報を記憶デバイス４０２に記録して（ステップＳ１０１９）、チケット情報を表示する（ステップＳ１０２０）。これにより、来訪者１０４は、チケット情報を確認することができる。

＜寄付金取得シーケンス例＞
図１１は、寄付金取得シーケンス例を示すシーケンス図である。図１１の来訪者１０４は、図１０でチケット情報がモバイル端末１０５に記録された来訪者１０４である。降車駅である駅１０２で来訪者１０４は、改札機１０３にモバイル端末１０５をタッチする（ステップＳ１１０１）。モバイル端末１０５は、改札機１０３との近距離通信により改札機１０３に出場要求を送信する（ステップＳ１１０２）。

出場要求は、チケット情報内のチケットＩＤ、到着日時および降車駅の情報を含む。改札機１０３は、出場要求を受信すると、出場要求に基づいて出場可否判定を実行する（ステップＳ１１０３）。たとえば、改札機１０３は、出場要求内の降車駅の情報がその改札機１０３が設置されている駅を特定し、かつ、到着時刻が現在時刻以降であれば、出場許可と判定する。

改札機１０３は、出場許可と判定した場合、出場要求に含まれているチケットＩＤを寄付金管理装置５０１に送信する（ステップＳ１１０４）。寄付金管理装置５０１は、改札機１０３からチケットＩＤを受信すると、受信したチケットＩＤと一致するチケットＩＤを有する寄付情報を検索する（ステップＳ１１０５）。チケットＩＤが一致する寄付情報が検索された場合、寄付金管理装置５０１は、チケットＩＤが一致する寄付情報を運営システム３０４に送信する（ステップＳ１１０７）。

運営システム３０４は、受信した寄付情報を記憶デバイス４０２に記録し（ステップＳ１１０７）、寄付情報の記録完了を寄付金管理装置５０１に通知する（ステップＳ１１０８）。寄付金管理装置５０１は、送金した寄付金の情報を記憶デバイス４０２に記録し（ステップＳ１１０９）、寄付金送金の処理完了を改札機１０３に通知する（ステップＳ１１１０）。

改札機１０３は、処理完了を受信すると、モバイル端末１０５に出場許可を送信し（ステップＳ１１１２）、モバイル端末１０５は出場を記録する（ステップＳ１１１３）。また、改札機１０３は、処理完了を受信すると、出場を記録し（ステップＳ１１１１）、改札機１０３を開門して、来訪者１０４の出場を許可する（ステップＳ１１１４）。

図１０および図１１で説明したように、来訪者１０４が購入した乗車券の支払い金額は、乗車券購入時に収入管理装置５０２に記録され、来訪者１０４が寄付する寄付金は、乗車券購入時に、寄付金管理装置５０１に記録される。来訪者１０４が実際に降車駅から出場した場合、寄付金管理装置５０１から運営システム３０４に寄付金が送金される。

なお、乗車券の購入についてはクレジット決済とし、寄付金の払出については、降車駅の改札機１０３の出場時に、モバイル端末１０５がモバイル端末１０５にチャージされている電子マネーから寄付金分の電子マネーを改札機１０３を介して寄付金管理装置５０１に送金してもよい。

＜施策決定シーケンス例＞
図１２は、施策決定シーケンス例を示すシーケンス図である。分析装置３０１は、予約管理装置５０４に分析ソースデータ要求を送信する（ステップＳ１２０１）。分析ソースデータ要求には、たとえば、対象日時および対象利用駅が含まれる。予約管理装置５０４は、分析ソースデータ要求を受信すると、鉄道情報ＤＢ３２０にアクセスして、対象日時および対象利用駅６０１に該当するエントリの人数を分析ソースデータとして収集し（ステップＳ１２０１）、分析装置３０１に返す（ステップＳ１２０３）。

同様に、分析装置３０１は、公共システム３０３に分析ソースデータ要求を送信する（ステップＳ１２０４）。分析ソースデータ要求には、たとえば、対象イベントが含まれる。公共システム３０３は、分析ソースデータ要求を受信すると、自治体情報ＤＢ３３３にアクセスして、対象イベントに該当するエントリの駅前交通量、信号の時間、交差点の数、および路上駐車場の予想利用率を分析ソースデータとして収集し（ステップＳ１２０５）、分析装置３０１に返す（ステップＳ１２０６）。

また、図示はしないが。分析装置は、協賛企業システム３０５に分析ソースデータ要求を送信してもよい。協賛企業システム３０５は、分析ソースデータ要求を受信すると、自治体情報ＤＢ３３３にアクセスして、過去実績データを分析ソースデータとして収集し、分析装置３０１に返すことになる。

その後、分析装置３０１は、分析ソースデータを受信すると、需要予測を実行し、施策案を決定する（ステップＳ１２０８）。需要予測の結果が問題の予測発生量となる。なお、需要予測は公知の処理でよい。また、分析装置３０１が需要予測を実行してもよく、他のコンピュータが実行した需要予測の結果を取得してもよい。ステップＳ１２０８の詳細については後述する。分析装置３０１は、決定した複数の施策案を運営システム３０４に送信する（ステップＳ１２０８）。

運営システム３０４は、複数の施策案を分析装置３０１から受信すると、複数の施策案を地元民１３０のモバイル端末１０５に配信し、複数の施策案を表示させる（ステップＳ１２０９）。また、運営システム３０４は、デジタルサイネージ３６３にも複数の施策案を送信して表示させてもよい。地元民１３０は、モバイル端末３６１に対し、複数の施策案のうちいずれか１つを選択して投票操作する（ステップＳ１２１０）。モバイル端末３６１は、投票結果を運営システム３０４に送信する（ステップＳ１２１１）。

運営システム３０４は、投票結果を受信して集計し、最大投票数の施策案を実行する施策に決定し（ステップＳ１２１２）、決定した施策の案内通知をモバイル端末１０５に送信する（ステップＳ１２１３）。このあと、運営システム３０４は、運営システム３０４の管理者の操作により、協賛企業システム３０５に施策実行依頼を送信する（ステップＳ１２１４）。協賛企業システム３０５は、施策を実行する（ステップＳ１２１５）。たとえば、協賛企業がバス運営会社であり、決定された施策が『臨時バス無料運行』であれば、協賛企業は臨時バスの無料運行を実行する。協賛企業システム３０５は、施策の実行通知を運営システム３０４に送信する（ステップＳ１２１５）。

運営システム３０４は、施策効果を収集し（ステップＳ１２１６）、分析装置３０１に送信する（ステップＳ１２１７）。たとえば、施策が『臨時バス無料運行』であれば、施策効果は、臨時バスの台数や乗車人数、乗車率であり、施策が『ゴミ回収頻度増加』であれば、施策効果は、ゴミ回収車の出動台数や回収したごみの量であり、施策が『地元民へのシェアオフィスの無料開門』であれば、施策効果は、シェアオフィス数やシェアオフィスの稼働率であり、施策が『前泊来訪者の宿泊施設割引サービスの提供』であれば、施策効果は、前泊来訪者１０４の人数である。また、公共システム３０３は、施策実行中における監視カメラ３３０からの映像を施策結果として分析装置３０１に送信してもよい。

分析装置３０１は、施策結果を受信して分析し（ステップＳ１２１８）、分析結果を予約管理装置５０４や公共システム３０３に返す（ステップＳ１２１９）。分析装置３０１は、例えば、施策実行中の中心地１１０の人数を監視カメラ３３０の映像から特定する。分析装置３０１は、施策実行中の中心地１１０の人数と、平常時の人数と、を比較する。たとえば、比較結果が平常時の人数以下であれば、施策の実行に効果があったことが分かる。また、比較結果が平常時の人数よりも多い場合、分析装置３０１は、増加分の人数に応じて、施策を強化すべきといった提言情報を分析結果として予約管理装置５０１、公共システム３０３、運営システム３０４、および協賛企業システム３０５に返す。

たとえば、施策が『臨時バス無料運行』である場合、比較結果が平常時の人数よりも多いと、分析装置３０１は、臨時バスの運行台数を増加すべきといった提言情報を生成して分析結果として運営システム３０４および協賛企業システム３０５に返す。

＜分析装置３０１による施策案決定処理例＞
つぎに、分析装置３０１による施策案決定処理例について図１３〜図１６を用いて説明する。図１３は、問題解消ＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）データの一例を示す説明図である。問題解消ＫＰＩデータ１３００は、問題解消ＫＰＩごとに問題解消度を規定した問題解消情報を示すデータテーブルであり、分析装置３０１が保有する。問題解消ＫＰＩは、問題解消の目標値を示し、問題解消度は、問題解消ＫＰＩのランクを示す。問題解消度の値が高いほど、問題解消ＫＰＩの達成効果が高いことを示す。

図１４は、施策案データの一例を示す説明図である。施策案データ１４００は、複数種の施策案（図１４では、Ａ〜Ｃの３種）の各々について１以上の施策案を有するデータテーブルであり、分析装置３０１が保有する。図１４では、施策案Ｘ＃（Ｘは施策案種Ａ〜Ｃ、＃は番号）において、番号＃が小さいほど実行した場合の効果が高い施策案とする。

図１５は、費用ＫＰＩデータを示す説明図である。費用ＫＰＩデータ１５００は、費用ＫＰＩごとに費用ランクを対応付けた費用情報を示すデータテーブルであり、分析装置３０１が保有する。費用ＫＰＩは、問題解消に必要な費用の目標値である。費用ランクについては、Ｃが最低ランク、すなわち、最も費用が高い施策案であり、ＡＡＡが最高ランク、すなわち、最も費用が低い施策案である。

図１６は、図１２のステップＳ１２０７で示した分析装置３０１による施策案決定処理手順例を示すフローチャートである。まず、分析装置３０１は、来訪者１０４の予測流入出情報を問題の予測発生量として取得する（ステップＳ１６０１）。具体的には、たとえば、分析装置３０１は、鉄道情報ＤＢ３２０から取得した分析ソースデータ（対象日時および対象利用駅６０１に該当するエントリの人数）を予測流入出情報として取得する。

つぎに、分析装置３０１は、ステップＳ１６０１で取得した来訪者１０４の予測流入出情報が平常時以上であるか否かを判断する（ステップＳ１６０２）。平常時以上であれば、（ステップＳ１６０２：Ｙｅｓ）、渋滞発生と予測し（ステップＳ１６０３）、平常時以上でなければ（ステップＳ１６０２：Ｎｏ）、渋滞非発生と予測して（ステップＳ１６０４）、処理を終了する。

たとえば、分析装置３０１は、対象となる駅１０２の平常時の乗降車人数に対し、ステップＳ１６０１で取得した予測流入出情報の乗降車人数が、平常時比１５０％以上であるか否かを判断する。１５０％以上である場合（ステップＳ１６０２：Ｙｅｓ）、分析装置３０１は、渋滞発生と予測し（ステップＳ１６０３）、１５０％以上でない場合（ステップＳ１６０２：Ｎｏ）、渋滞非発生と予測して（ステップＳ１６０４）、処理を終了する。

渋滞発生と予測した場合（ステップＳ１６０３）、分析装置３０１は、施策案データ１４００から施策案Ａ〜Ｃ毎に問題解消度を特定する第１特定処理を実行する（ステップＳ１６０５）。具体的には、たとえば、分析装置３０１は、施策案種Ａ〜Ｃから１つずつ施策案を選択する。この場合、分析装置３０１は、番号＃が最小の施策案Ａ１，Ｂ１，Ｃ１を選択してもよく、対応可能な施策案の内最も番号＃が最小の施策案を選択してもよい。たとえば、協賛企業情報ＤＢ３５０から取得したデータにより、臨時バスの運行可能台数が７台の場合、施策案Ｂ１は選択不可能であるため、この場合は、分析装置３０１は、施策案Ｂ２を選択することになる。

そして、分析装置３０１は、施策案種ごとに選択した各施策案について、問題解消度を特定する。たとえば、施策案Ａ１が選択された場合、分析装置３０１は、問題に対する供給可能量として、たとえば、対象日前日の宿泊施設１１１の空き部屋数に基づく宿泊可能人数ａ１１を算出し、過去実績データから当日入りから前日入りに変更する人数ａ１２を取得する。分析装置３０１は、宿泊可能人数ａ１１と前日入りに変更する人数ａ１２とを比較し、少ない方の人数を、減少人数として取得する。そして、分析装置３０１は、当日の予測流入出人数のうち減少人数の割合を算出し、算出割合に応じた解消度を問題解消ＫＰＩデータ１３００から特定する。本例では、施策案Ａ１について解消度５が特定されたものとする。

また、施策案Ｂ２が選択された場合、分析装置３０１は、問題に対する供給可能量として、たとえば、当日の臨時バスの運行可能台数を取得し、当該運行可能台数と臨時バスの１台当たりの最大乗車人数とを乗算することで、減少人数を算出する。そして、分析装置３０１は、当日の予測流入出人数のうち減少人数の割合を算出し、算出割合に応じた解消度を問題解消ＫＰＩデータ１３００から特定する。本例では、施策案Ｂ２について解消度４が特定されたものとする。

また、施策案Ｃ１が選択された場合、題に対する供給可能量として、たとえば、当日に提供可能なシェアオフィスの座席数ｃ１１と、過去実績データから当日シェアオフィスを利用する推定人数ｃ１２とを取得する。分析装置３０１は、座席数ｃ１１と推定人数ｃ１２とを比較し、少ない方を、減少人数として取得する。そして、分析装置３０１は、当日の予測流入出人数のうち減少人数の割合を算出し、算出割合に応じた解消度を問題解消ＫＰＩデータ１３００から特定する。本例では、施策案Ｃ１について解消度４が特定されたものとする。

つぎに、分析装置３０１は、施策案ごとに費用ランクを特定する第２特定処理を実行する（ステップＳ１６０６）。具体的には、たとえば、施策案Ａ１の場合、分析装置３０１は、一人当たりの宿泊施設１１１の２０％割引分の割引額に、ステップＳ１６０５において施策案Ａ１で特定された減少人数を乗算することで、施策案Ａ１を実行した場合の予測費用として、施策案Ａ１に必要な費用ａを算出する。そして、分析装置３０１は、費用ＫＰＩデータ１５００を参照して、算出した費用ａを充足する費用ＫＰＩを特定し、特定した費用ＫＰＩに対応する費用ランクを特定する。たとえば、費用ａが８５万円である場合、費用ランクは「Ｃ」となる。

また、施策案Ｂ２の場合、分析装置３０１は、１人あたりの運賃に、ステップＳ１６０５において施策案Ｂ２で特定された減少人数を乗算することで、施策案Ｂ２を実行した場合の予測費用として、施策案Ｂ２に必要な費用ｂを算出する。そして、分析装置３０１は、費用ＫＰＩデータ１５００を参照して、算出した費用ｂを充足する費用ＫＰＩを特定し、特定した費用ＫＰＩに対応する費用ランクを特定する。たとえば、費用ｂが４２万円である場合、費用ランクは「ＡＡ」となる。

また、施策案Ｃ１の場合、分析装置３０１は、シェアオフィス１席あたりの費用をステップＳ１６０５において施策案Ｃ１で特定された減少人数に乗算することで、施策案Ｃ１を実行した場合の予測費用として、施策案Ｃ１に必要な費用ｃを算出する。そして、分析装置３０１は、費用ＫＰＩデータ１５００を参照して、算出した費用ｃを充足する費用ＫＰＩを特定し、特定した費用ＫＰＩに対応する費用ランクを特定する。たとえば、費用ｃが５９万円である場合、費用ランクは「Ａ」となる。

つぎに、分析装置３０１は、施策案ごとに費用対効果を算出する算出処理を実行する（ステップＳ１６０７）。本例では、費用対効果の指標値が低いほど費用対効果が高いことを示す。具体的には、たとえば、施策案Ａ１の場合、分析装置３０１は、施策案Ａ１の解消度５と、費用ランクＣにおける最大費用である「９０．０万円」と、を乗算することで、費用対効果の指標値「４５０．０」を算出する。また、施策案Ｂ２の場合、分析装置３０１は、施策案Ｂ２の解消度４と、費用ランクＡＡにおける最大費用である「４５．０万円」と、を乗算することで、費用対効果の指標値「１８０．０」を算出する。また、施策案Ｃ１の場合、分析装置３０１は、施策案Ｃ１の解消度４と、費用ランクＡにおける最大費用である「６０．０万円」と、を乗算することで、費用対効果の指標値「２４０．０」を算出する。

そして、分析装置３０１は、費用対効果が相対的に高い、たとえば、上位の施策案を選出する選出処理を実行して処理を終了する（ステップＳ１６０８）。具体的には、たとえば、分析装置３０１は、費用対効果の指標値が低い上位２つの施策案Ｂ２、Ｃ１を、地元民１３０に提案する施策案として選出する。選出される施策案は複数であれば３以上でもよい。

このようにして、分析装置３０１は、費用は安いが効果が高い施策案を自動的に選出することができ、地元民１３０に提案することができる。このため、地元民１３０は、提案された複数の施策案について投票し、最も投票数の多い施策案が実行される。

このように、プールされた寄付金の使途は地元民１３０により決定され、プールされた寄付金は当該地域のために使用されるため、プールされた寄付金は、地元民１３０が気持ちよく暮らすための街の発展に平等に還元される。また、住民のための街づくり施策を策定するファンド１２０が介在することで、来訪者１０４増による街の変化に、鉄道を利用しない住民も主体的に加わる仕組みを提案することが可能となる。

また、来訪者１０４が来訪するほど、街が気持ちよく発展し続ける。たとえば、プールされた寄付金は、大量の来訪者１０４によって突発的、一時的に街に生じる交通渋滞やごみのポイ捨てによる美観の低下など地元住民にとって望ましくない状況を回避するために使用される。すなわち、来訪者１０４が増えて、地元民１３０にとってむしろ街が不便になった、魅力がなくなったということが低減される。

また、地元民１３０の選択で、街を良くする「使い道」が見えてくることになる。たとえば、街の需要予測をもとに、ファンド１２０のサービス事業者が、「臨時バスを走らせる」、「ゴミの回収頻度を上げる」「地元民１３０にシェアオフィスを無料開門する」など、短期スパンの使い道を複数提案する。最終的に住民が提案に投票することでプールされた寄付金の使い道が決定される。

また、施策決定システム３００の導入により、地元ビジネスを巻き込みながら、地元民１３０自ら街を良くする行動を起こすことが期待される。たとえば、ファンド１２０のサービス事業者が、プールされた寄付金の使い道自体の提案を地元民１３０に促し、「大都市から呼ぶ講師の旅費」「市民のためのワークショップ」など、より文化的にも発展できるような長期スパンの使い方を住民たちが提案できるようになる。街の変化が地元民１３０ごとに変わり、鉄道が街の成熟を支える存在として身近に感じるようになる。プールされた寄付金は地域に還元されるので地元ビジネスも活性化し、街の継続的な発展が支えられる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加、削除、または置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カード、ＳＤカード、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１０４ 来訪者
１０５ モバイル端末
１０９ 電車
１１０ 中心地
１１１ 宿泊施設
１１２ 商店舗
１１３ 商業ビル
１１４ オフィスビル
１１５ イベント会場
１２０ ファンド
１３０ 地元民
３００ 施策決定システム
３０１ 分析装置
３０２ 管理システム
３０３ 公共システム
３０４ 運営システム
３０５ 協賛企業システム
３３０ 監視カメラ
３６１ モバイル端末
３６２ 車内音声インタフェース
３６３ デジタルサイネージ
５０１ 寄付金管理装置
５０１ 予約管理装置
５０２ 収入管理装置
５０３ 運行管理装置
５０４ 予約管理装置
１３００ 問題解消ＫＰＩデータ
１４００ 施策案データ
１５００ 費用ＫＰＩデータ

Claims (7)

1. プログラムを実行するプロセッサと前記プログラムを記憶する記憶デバイスとを有する１台以上のコンピュータ群により構成される施策決定システムであって、
   前記記憶デバイスは、対象地域における特定領域内の問題を解消するための複数の施策案と、問題解消の目標値と前記問題の解消度とを対応付けた問題解消情報と、前記問題解消に必要な費用の目標値を記憶する費用情報と、前記問題の予測発生量と、前記複数の施策案の各々についての前記問題に対する供給可能量と、前記施策案を実行した場合の予測費用と、を記憶しており、
   前記プロセッサは、
   前記複数の施策案の各々について、前記問題に対する供給可能量と前記問題の予測発生量とに基づいて、前記問題解消の目標値に対応する解消度を前記問題解消情報から特定する第１特定処理と、
   前記複数の施策案の各々について、前記施策案を実行した場合の予測費用に該当する前記費用の目標値を前記費用情報から特定する第２特定処理と、
   前記複数の施策案の各々について、前記第１特定処理によって特定された前記問題の解消度と、前記第２特定処理によって特定された前記費用の目標値と、に基づいて、前記施策案の費用対効果を算出する算出処理と、
   前記複数の施策案の中から、前記算出処理によって算出された費用対効果が相対的に高い２以上の特定の施策案を選出する選出処理と、
   前記選出処理によって選出された２以上の特定の施策案を出力する出力処理と、
   を実行することを特徴とする施策決定システム。
2. 請求項１に記載の施策決定システムであって、
   前記プロセッサは、
   施策案群の中から前記供給可能量を充足する施策案を施策案種ごとに選択する選択処理を実行し、
   前記第１特定処理では、前記プロセッサは、前記選択処理によって施策案種ごとに選択された前記複数の施策案の各々について、前記問題に対する供給可能量と前記問題の予測発生量とに基づいて、前記問題解消の目標値に対応する解消度を前記問題解消情報から特定する、ことを特徴とする施策決定システム。
3. 請求項１に記載の施策決定システムであって、
   前記出力処理では、前記プロセッサは、前記２以上の特定の施策案を、前記対象地域に設置されている表示装置に送信することを特徴とする施策決定システム。
4. 請求項１に記載の施策決定システムであって、
   前記出力処理では、前記プロセッサは、前記２以上の特定の施策案を、前記対象地域の住民の端末に送信することを特徴とする施策決定システム。
5. 請求項４に記載の施策決定システムであって、
   前記プロセッサは、
   前記２以上の特定の施策案の中から選択された施策案を前記端末から受信して、多数決により施策を決定する決定処理を実行することを特徴とする施策決定システム。
6. 請求項１に記載の施策決定システムであって、
   移動手段を管理する前記コンピュータ群の中の特定のコンピュータが、対象地域外からの来訪者の端末と近距離通信可能な前記特定領域内の検出機を有し、
   前記特定のコンピュータ内の特定のプロセッサが、
   前記来訪者が前記特定領域内へ前記移動手段の利用する場合の利用金額データおよび前記対象地域への寄付金情報を前記来訪者の端末から取得して、前記特定のコンピュータ内の特定の記憶デバイスに記憶する取得処理と、
   前記検出機が前記来訪者の端末を検出した場合、前記寄付金情報を前記特定の記憶デバイスから前記記憶デバイスに送信する送信処理と、
   を実行することを特徴とする施策決定システム。
7. プログラムを実行するプロセッサと前記プログラムを記憶する記憶デバイスとを有する１台以上のコンピュータ群により構成される施策決定システムによる施策決定方法であって、
   前記記憶デバイスは、対象地域における特定領域内の問題を解消するための複数の施策案と、問題解消の目標値と前記問題の解消度とを対応付けた問題解消情報と、前記問題解消に必要な費用の目標値を記憶する費用情報と、前記問題の予測発生量と、前記複数の施策案の各々についての前記問題に対する供給可能量と、前記施策案を実行した場合の予測費用と、を記憶しており、
   前記プロセッサは、
   前記複数の施策案の各々について、前記問題に対する供給可能量と前記問題の予測発生量とに基づいて、前記問題解消の目標値に対応する解消度を前記問題解消情報から特定する第１特定処理と、
   前記複数の施策案の各々について、前記施策案を実行した場合の予測費用に該当する前記費用の目標値を前記費用情報から特定する第２特定処理と、
   前記複数の施策案の各々について、前記第１特定処理によって特定された前記問題の解消度と、前記第２特定処理によって特定された前記費用の目標値と、に基づいて、前記施策案の費用対効果を算出する算出処理と、
   前記複数の施策案の中から、前記算出処理によって算出された費用対効果が相対的に高い２以上の特定の施策案を選出する選出処理と、
   前記選出処理によって選出された２以上の特定の施策案を出力する出力処理と、
   を実行することを特徴とする施策決定方法。