ゲーム理論(二人・二択)の混合戦略の確率の求め方

ゲーム理論については前回の記事で触れましたが、今回の記事はその続きです。

今回の記事では、混合戦略の確率の求め方について、詳細を書いていきます。

混合戦略は、何度も同じゲームを繰り返す場合において、相手がどのような確率で選択肢を選んだとしても、全ゲームで得られる平均の利得を一定にすることを意図したものです。
長期的な目で見て、利得が下がるリスクを最も軽減できる戦略です。

この戦略の実現方法について直感的に書くと、リスクの高い選択肢(相手が選ぶ選択肢によって利得が大きく変わる選択肢)を選ぶ確率を少なめに、リスクの低い選択肢(相手が選ぶ選択肢によって利得が大きく変わるらない選択肢)を選ぶ確率を多めにすると、混合戦略に近くなります。

各選択肢の選択確率を正確に求めるには、連立方程式や微分方程式等を用いて計算を行う必要があります。
今回の記事では以下の前提で計算を行います。

  • 劣等戦略(相手がどのような選択肢を選んだとしても、他のある選択肢以下の利得しか得られない選択肢)はあらかじめ除外
  • プレイヤーが二人で、選択肢は二択のゲームを想定

【今回の例で取り扱う利得表】

【混合戦略の求め方】

1.連立方程式を解く方法

選択肢Aを選ぶ確率をp、選択肢Bを選ぶ確率を1-pとおく。
混合戦略が成り立つ時、相手が選択肢aを選んだ場合の期待利得と相手が選択肢bを選んだ場合の期待利得は等しくなるため、以下の式が成り立つ。

以上より、選択肢Aを選ぶ確率が0.2、選択肢Bを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。

2.微分方程式を解く方法

選択肢aが選ばれる確率pが決まる時、選択肢bが選ばれる確率は1-pという形で一意に求まる。
また、混合戦略の定義は、「相手が選択肢aを選んだ場合の期待利得と相手が選択肢bを選んだ場合の期待利得が等しくなるように選択肢を選ぶ」である。
そのため、混合戦略の定義は、「相手が選択肢aを1の確率で選ぶ場合の期待利得と相手が選択肢aを1-1(=0)の確率で選んだ場合の期待利得が等しくなるように選択肢を選ぶ」と置き換えることができる。

そこで、相手が選択肢aを選ぶ確率をx軸、自分の利得をy軸に置くと、以下のグラフを得られる。
下記のグラフについて、線分A-A’は選択肢Aを選んだ場合の利得、線分B-B’は選択肢Bを選んだ場合の利得、線分C-C’は混合戦略となる場合の利得を示している。

線分A-A’と線分B-B’を式に表すと以下のようになる。

線分A-A’と線分B-B’を微分し傾きを求めると、以下のようになる。

ここで、線分C-C’は混合戦略であり、xの値によらずyは一定のため、傾きは0である。
線分A-A’をpの比率で、線分B-B’を1-pの比率で合成し、線分C-C’を生成する場合、比率pは以下の式で求まる。

以上より、選択肢Aを選ぶ確率が0.2、選択肢Bを選ぶ確率が1-0.2(=0.8)の時に、混合戦略となる。

【検算】

選択肢Aを選ぶ確率が0.2、選択肢Bを選ぶ確率が0.8の時の期待利得を求める。

相手が選択肢aを選んだ場合、自分の期待利得は以下のようになる。

相手が選択肢bを選んだ場合、自分の期待利得は以下のようになる。

①と②が等しいため、選択肢Aを選ぶ確率が0.2、選択肢Bを選ぶ確率が0.8の時に混合戦略となる。

【混合戦略の簡単なイメージ】

教育機関で教えられるのは連立方程式を解く方法で、複雑な状況に対応することを考えるとこちらの方法を用いるべきです。
しかし、プレイヤーが二人で選択肢が二択というような簡単な状況では、微分方程式を解く方法の方が簡単にイメージできます。

傾きを合成して0にするだけなので、簡単に書いてしまうと「選択肢Aの傾き:選択肢Bの傾き*-1」の逆数がそのまま「選択肢Aを選ぶ確率」と「選択肢Bを選ぶ確率」になります。
上記の例で言うと、「4:1」の逆数「1/4:1」=「1:4」=「0.2:0.8」が「選択肢Aを選ぶ確率」と「選択肢Bを選ぶ確率」になります。
手続き型のプログラムで計算できるように計算式を書くと、以下のようになります。


いかがでしたでしょうか。

今回の記事では、前回の記事では簡単にしか触れなかった混合戦略について、詳しく書いていきました。
実際にゲーム理論を応用する場合は、数字や確率で状況を表すことが難しい場合が多いので、「リスクの高い選択肢を選ぶ確率を少なめに、リスクの低い選択肢を選ぶ確率を多めにする」という直感的な理解で問題無いと思います。

ゲーム理論を現実世界に応用する際には、いくつかの注意点があります。
それを、今後の記事で書いていきたいと思います。

ゲーム理論の説明(情報処理技術者試験対策)

今回の記事では、OR・IE分野のゲーム理論について、情報処理技術者で出題される可能性がある範囲に絞って説明します。

ゲーム理論は、複数のプレイヤーが存在する状況下において、最適な選択肢を選択するために使われる理論です。
主に「ゲーム木」と「利得表(利得行列)」を用いて状況を分析するのですが、情報処理技術者試験で集中的に出題されるのは利得表の方です。
とは言えゲーム木も出題される可能性があるので、簡単に説明します。

ゲーム木は、選択肢による分岐と各々の分岐で得られる利得を記述する方法です。
それぞれのプレイヤーが交互に意思決定を行う(相手がどの選択肢を選んだのかを見てから自分の選択肢を選べる)場面で有効な方法であり、例としては下記のように記述します。

利得表は、各々のプレイヤーの選択肢の組み合わせと、各々の組み合わせの利得を表形式で記述する方法です。
それぞれのプレイヤーが同時に意思決定を行う(相手がどの選択肢を選んだのかわからない状態で自分の選択肢を選ぶ)場面で有効な方法で、例として下記のように記述します。

利得表から導き出せる戦略・状況としては、下記のようなものがあります。
もしかしたら下記にない戦略・状況が出題されるかもしれませんが、その場合は問題文中で何かしらの説明があるはずです。
(下記にない戦略・状況については、利得表外のパラメータが別途必要となるため)

・ナッシュ均衡

お互いに最適戦略(相手が選ぶ選択肢によらず、必ず他の選択肢よりも高い利得を得られる選択肢)が存在する場合に、お互いに最適戦略を採用する状態のことを指す。
この状態の時は、お互いに他の戦略を選択する動機が生まれず、状況が硬直化する。
例1ではお互いに最適戦略が存在するため、ナッシュ均衡の状態になる。
プレイヤーaの最適戦略はa1である。
(プレイヤーbがb1を選ぶ場合は、a1なら40、a2なら30の利得となりa1が優れる。プレイヤーbがb2を選ぶ場合は、a1なら50、a2なら25の利得となり、この場合もa1が優れる。)
また、プレイヤーbの最適戦略はb2である。
(プレイヤーaがa1を選ぶ場合は、b1なら20、b2なら30の利得となりb2が優れる。プレイヤーaがa2を選ぶ場合は、b1なら10、b2なら25の利得となり、この場合もb2が優れる。)
よって、a1とb2でナッシュ均衡となる。

・純粋戦略

ある一つの選択肢を常に選ぶ戦略。
上記のナッシュ均衡の例で言うと、プレイヤーaはa1を選び続ける純粋戦略であり、プレイヤーbはb2を選び続ける純粋戦略である。

・ラプラス原理

相手の各選択肢の選択確率が不明の場合に、各々の選択肢が等確率で選ばれると仮定して期待利得を算出し、最も期待利得が高くなる選択肢を選択する。
例2において、プレイヤーbの戦略b1と戦略b2の選択確率が共に0.5であると仮定すると、戦略a1と戦略a2の選択確率は以下のようになる。例2ではどちらも期待利得が変わらないのでどちらを選んでも良い。

・期待値原理

相手の各選択肢の選択確率が予測できる場合に、各々の選択肢の選択確率を考慮して期待利得を算出し、最も期待利得が高くなる選択肢を選択する。
例2において、プレイヤーbの戦略b1の選択確率が0.8、戦略b2の選択確率が0.2であると仮定すると、戦略a1と戦略a2の選択確率は以下のようになる。この場合は戦略a2を選択するべきである。

・混合戦略

相手がどのように選択肢を選んだとしても、常に一定の期待利得を得らえるように一定の確率で各選択肢を選択する戦略。
例2においては、プレイヤーaは戦略a1を0.5、戦略a2を0.5の確率で選択することで、プレイヤーbがどのように選択肢を選択したとしても2.5の期待利得を得ることができる。また、プレイヤーbは、戦略b1を0.5、戦略b2を0.5の確率で選択することで、プレイヤーaがどのように選択肢を選択したとしても-2.5の期待利得を得ることができる。
混合戦略となる選択肢の選択確率を算出する方法としては、連立方程式を解く方法、微分を用いる方法等があるが、試験では出題されないと思われるため詳細は割愛する。
(仮に混合戦略が出題されたとしても選択式問題であるため、逆算して、期待利得が変わらない選択肢を選べば良い)

・マクシミン原理

相手が自分にとって最も望ましくない(最も自分の利得が少なくなる)選択肢を選ぶという前提において、得られる利得が最も大きくなる選択肢を選択する。
損失を避けたい場合に採用する原理である。
例2において、プレイヤーaが戦略a1を選択した場合は、戦略b1が最も望ましくない選択肢であり、この場合のプレイヤーaの利得は-15である。戦略a2の場合は、戦略b2が最も望ましくない選択肢であり、この場合のプレイヤーaの利得は0である。よって、マクシミン原理に従うならプレイヤーaは戦略a2を選択するべきである。

・マクシマックス原理

相手が自分にとって最も望ましい(最も自分の利得が多くなる)選択肢を選ぶという前提において、得られる利得が最も大きくなる選択肢を選択する。
一般的には楽観的な原理であるとされているが、筆者の見解としては相手が選ぶ選択肢をコントロールできる場合に採用するべき原理であると考えている。
例2において、プレイヤーaが戦略a1を選択した場合は、戦略b2が最も望ましい選択肢であり、この場合のプレイヤーaの利得は20である。戦略a2の場合は、戦略b1が最も望ましい選択肢であり、この場合のプレイヤーaの利得は5である。よって、マクシマックス原理に従うならプレイヤーaは戦略a1を選択するべきである。


いかがでしたでしょうか。

技術者の実務で直接的に使う知識ではありませんが、状況を分析したり意思決定を行ったりする際に広く応用できる知識ではあります。
社会人であれば知っていて損はない知識だと思います。

今回の記事では混合戦略に関する詳細は割愛しましたが、これはまたの機会に書きたいと思います!

「新たな導線の追加」という現行踏襲案件

要件が「現行踏襲」である案件の代表的なリスクとして、「現行の仕様を調査してその仕様に合わせる工数、が過小評価されやすい」というリスクがあります。
そして、要件が「新たな導線を追加する」である案件は、一見現行踏襲でないように見えて、実際は現行踏襲案件と同じようなリスクを抱えます。

今回は、私が体験した案件を例に出して説明します。


今回例として挙げるシステムは、「営業員がプランを勧めて、最終的にエンドユーザーが個人情報を入力する」という営業システムです。
この営業システムのUIは、前半の営業員画面と、後半のエンドユーザー画面に大別できます。
前半は営業員が使うことを想定したシンプルな画面であり、プランを表示・入力する機能があります。
後半はエンドユーザーが直接目にするリッチな画面であり、個人情報を入力する機能や、入力内容を確認する機能があります。

この営業システムについて、「営業員によるプランの勧誘もエンドユーザー画面上で行うようにして、エンドユーザーだけで操作が完結するようにしたい」という要件の保守案件が発生しました。
システム的に見た場合は、前半の営業員画面だけではなく、別のエンドユーザー画面(以下「新エンドユーザー画面」)でもプランの表示・入力を可能とする、というものです。言い換えれば、前半の導線を増やす、というものです。

ここまで説明したことを図に表すと以下の通りです。

新エンドユーザー画面もエンドユーザーが直接目にするため、リッチなUIが必要になります。要件として示されたデザイン案も、これまでシステムでは取り入れていなかったデザインが採用されていました。
そのため、見積もりの段階では、リッチなUIに対応することが焦点に置かれ、技術的なリスクが重く見られました。

しかし、技術的な問題は、一旦技術検証が済んでしまえば、その後にリスクとして顕在化することはありませんでした。
代わりに、実際にリスクとして顕在化し、工数増大の原因となったのは、現行踏襲のリスクでした。

新エンドユーザー画面では、営業員画面と同じ機能を提供する必要があります。
また、最終的には後半のエンドユーザー画面に合流するため、内部的なデータ構造も営業員画面と同じように保持する必要がありました。
更に、営業員画面と新エンドユーザー画面では、見せ方の違いにより入力順や入力内容が微妙に異なっていたため、単純な機能移植で済むというものでもありませんでした。

これらの要因により、「現行仕様をデータ構造まで踏み込むレベルで調査・理解した上で、営業員画面と新エンドユーザー画面の差異に気を付けながら仕様を策定する」という作業が発生しました。この作業の工数は、見積もり時点では過小評価されていました。
そして、設計工程の工数増加や、仕様考慮漏れによるテスト工程での大量のバグ検出に繋がりました。


いかがでしたでしょうか。

「要件が現行踏襲である案件は危ない」というのは良く言われることですが、要件に「現行踏襲」と書いてなくとも似たようなリスクを持つ案件というのも存在します。
この類のリスクは、「要件に現行踏襲と書いてあるか」という観点ではなく、「現行の仕様にどの程度合わせ込む必要があるのか」という観点で見つけるべきです。

これからも、今回のような教訓を広めていきたいと思います!

アンカリングを用いた交渉術と見積もりへの応用

「アンカリング」とは、先に与えられる情報をベースに意思決定してしまうことを指す心理面の現象のことであり、心理学の用語です。
この現象は交渉の場面で役に立ちます。
先に厳しめの要求を出すことで、その要求をベースに交渉を進めることができます。
厳しめの要求を出した後、相手に合わせて譲歩するのですが、厳しめの要求をベースに譲歩をすることができるので、こちらが飲めるギリギリのラインよりもこちらにとって有利なラインで交渉を成立させることができます。


ITシステム開発の受注者としては、工数の見積もりの場面で応用できます。
工数を正確に見積もることができる案件であれば正直に見積もりを出せば良いのですが、不確実性がありそれが難しい案件ではある程度のリスクバッファが必要になります。
「不確実性コーン」と呼ばれる有名な研究成果があるのですが、最も初期の段階では見積もり工数に±4倍のブレが発生します。
(詳しくは、「見積もり概論」社内勉強会用のパワポの3ページ目を参照して下さい)

そこで、リスクバッファを確保するために、交渉で工数が削られることを見越して多めの工数で見積もるということをします。
(最低でも、不確実性コーン上での最悪のケースを想定した工数で見積もりを行った方が良いです)
発注側が想定している工数から4倍以上も離れている場合は流石に工数を削るように要求されることが多いのですが、その場合はお互いに考えている要件や工数をすり合わせた上で、要求を満たすのに最低限必要な要件と、それに基づいた工数が決まることになります。
始めに多めの工数を出しておくことで、その結果として平均的な工数よりも多めの工数を確保できることが多くなり、リスクバッファを確保しやすくなります。

なお、多めの工数を出す理由としては「楽をしたい」「儲けたい」といった理由ではなく、あくまでもリスクバッファの確保なので、開発者が開発期間の長さに安心して平時からリスクバッファを食いつぶすようなことがあってはなりません。
そのため、開発者には逆に厳しめのスケジュールを伝えて、スケジュールの調整をしたりします。そうすることで、スケジュール的な余裕が生まれ、不測の事態が起きた時に取れる選択肢が広がります。


いかがでしたでしょうか。

今回紹介したような手法は多くの経験者が実践していることだとは思いますが、形式知として広まることは少ないかもしれません。
形式知として広まっていない以上、知らない・実践していない方がいても不思議ありません。
そこで、心理学のような学問の知見を借りることで、手法を形式知として表現することが容易になり、手法を広めやすくなります。

これからも、多くの人が知らず知らずの内に使っている手法を形式知として広める、ということをしていきたいと思います。

自社の製品を俯瞰的に考える思考フレームワーク「プロダクトポートフォリオマネジメント」

今回はプロダクトポートフォリオマネジメントについてです。
市場成長率と市場シェアを元に投資戦略を考えるためのモデルであり、市場成長率を考えるという点では前回書いたプロダクトライフサイクルとも通じる部分があります。

プロダクトポートフォリオマネジメントでは、下記のように「問題児」「花形商品」「金のなる木」「負け犬」の4つの象限に分けて考えます。

4つの象限について、以下で2010年頃の携帯市場の例を挙げて説明します。

・問題児

市場成長率は高いが市場シェアが低い商品。
投資を強化し、市場シェアを拡大を図り、花形商品とすることが有効になる。
アップル以外のスマホがこの象限に該当する。

・花形商品

市場成長率も市場シェアも高く、大きな収益を得られる商品。
競争が激しいため、市場シェア維持のための投資は必要となる。
アップルのスマホがこの象限に該当する。

・金のなる木

市場成長率は低いが市場シェアは高い商品。
花形商品の市場の成長が止まると、金のなる木になる。
市場シェア維持のための投資は不要で安定した収益を得られるため、投資のための原資を得ることができる。
現在も製造を続けているガラケーがこの象限に該当する。

・負け犬

市場成長率も市場シェアも低い商品。
今も今後も収益を得られる見込みがないため、撤退の検討が必要になる。
撤退を決断したガラケーがこの象限に該当する。


いかがでしたでしょうか。

「プロダクトポートフォリオマネジメント」の考え方を用いると、自社のサービスを俯瞰して戦略を立てることができるようになります。
市場成長率が高い市場に進出して(問題児)、投資を強化してシェアを増やし(花形商品→金のなる木)、そこで得た収益を次の投資へ回す、というのが基本的な戦略になります。
花形商品は将来的には金のなる木になりますが、次第に市場自体が縮小し、収益が低下します。そうなる前に次の市場にチャレンジする必要があります。
IT業界で言うと、昔作ったシステムの保守・運用ばかりになってしまうと危険信号です。市場が縮小する前に、収益を元にして次の市場にチャレンジしないと、後々経営が悪化する可能性があります。

思考フレームワークの記事についてはこれで一区切りとし、次回からは別のネタを書いていこうと思います!