サイゼントの技術ブログ

コンティンジェンシープランとは、想定外の事態が起きた時に備えて事前に定めておく対応策のことです。
この記事では、プログラムのリリース時に定めておくべきコンティンジェンシープランについて、具体的に述べていきます。

---

プログラムのリリース作業は、事前に定められた一定の時間内に、プログラムを入れ替えて稼働確認を行う、という作業です。
例えば、特定の日の22:00-24:00をメンテナンス時間として事前に通知し、メンテナンス時間中はシステムの開放を止めてプログラム入れ替えと稼働確認を行う、というような作業を指します。

リリース作業時における主な想定外の事態は、稼働確認での不具合の発見です。
不具合を発見した時に備えて、以下のようなコンティンジェンシープランを事前に用意しておくべきです。

１．切り戻し作業の手順の用意と実施

新しくリリースしたプログラムに不具合が存在していたとしても、リリース時間内に元のプログラムに戻して稼働可能な状態に戻せば、利用者にはリリース前と変わらない機能を提供することができます。
リリースによるサービス水準の低下を防ぐという意味では、最も確実な対応策となります。
ただし、切り戻し作業自体にリスクが存在する（切り戻し作業を失敗し、戻せなかったり、より自体が悪化したりする可能性がある）ため、切り戻し作業を行う可能性があるのであれば、作業手順を事前に確立させる必要があります。
データの移行を伴う場合は、データの事前のバックアップとその戻しも必要になるので、特に注意が必要です。

２．サービス水準の低下を許容する方針の検討

切り戻し作業を行うのが最も確実ではあるのですが、発見された不具合が軽微なものであれば、その不具合を許容した上で戻さずにリリース作業を完了させる手もあります。
また、法律改正への対応のような、外部の変更に応じた対応の場合は切り戻し作業の実施自体が難しくなる（自社の判断だけでは切り戻し作業ができなくなる）ため、この場合も不具合を許容、最悪の場合は機能制限を加えた上でリリース作業完了させる必要が出てくることが多いです。

不具合を許容するかどうかの判断はその時々で柔軟に判断する必要がありますが、それを誰が判断するのか（作業時の責任者は誰なのか）は事前に決めておくべきです。
また、機能制限のような作業を行う可能性があるのであれば、その作業手順も事前に確認・確立させる必要があります。

３．切り戻し等の作業を開始するタイミングの確認

稼働確認で不具合が発見されたとしても、リリース時間内に修正できるのであれば、修正するに越したことはありません。
また、切り戻しを行うのかサービス水準の低下を許容するのかの判断が必要になる可能性もあります。

このように、不具合が発見されたとしても、切り戻しの行わない、という判断をすることがあります。
しかし、切り戻し作業にも時間が必要なので、その判断をいつまでに行うのか、ということは事前に決める必要があります。

例えば、24:00までにサービスを再開する必要があり、切り戻し作業に（余裕を見て）30分かかる場合、切り戻しを行うかどうかの判断は23:30までに行う必要があります。
23:30までに修正が完了しなかったり、サービス水準低下の許容の判断ができなかったりするのであれば、安全側に倒すために23:30を迎えた瞬間に切り戻し作業を開始するべきです。

---

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

今回は、後輩に指導したことを記事として残しました。
記事に書いたことは、保守作業に携わるエンジニアであれば意識するべきことです。
大規模なシステムでは書類の形でプランを作る必要がありますし、小規模なシステムであっても関係者間で事前に認識を共有しておくべきです。

指導した内容はこれからも記事として残すようにしていこうと思います！

ゲーム理論については、前回の記事と前々回の記事で解説しました。

ゲーム理論は話だけ聞くと簡単そうに見えますが、実際に適用しようとするとある壁にぶつかります。
その壁とは、「適用対象をゲームとして正しく認識することが困難」という壁です。
ゲームとしての認識が誤っていると、ゲーム木や利得表を正しく書くこともできなくなり、そこから導き出される分析結果も誤ったものになってしまいます。

今回の記事では、この問題について例を挙げて説明し、どのような落とし穴があるのかを詳しく書いていきます。

【ゲーム理論の３つの前提条件】

ゲーム理論で分析を行うためには、以下の３つの前提条件が必要になります。
「適用対象をゲームとして正しく認識する」を具体的に言うと、「以下の３つの前提条件を正しく設定する」ということになります。

・利害関係のあるプレイヤーの洗い出し

ゲーム理論とは、自分が選んだ選択肢と相手が選んだ選択肢の組み合わせで結果がどのように分岐するのかを分析する理論である。
そのため、まずは結果に影響を与えるような利害関係のあるプレイヤーを洗い出す必要がある。

・各プレイヤーが持つ選択肢

前述の通り、ゲーム理論とは選択肢を選んだ結果を分析する理論であるため、その「選択肢」を洗い出す必要もある。

・選択肢を選んだ結果得られる利得

ゲーム理論における「結果」は「利得」と呼ばれているが、その利得の大小も定義する必要もある。

【前提条件を設定する難しさ】

上記の前提条件は、ゲーム理論の例題では自明です。
しかし、現実世界の問題では前提条件は自分で設定する必要があります。
（スポーツ・ボードゲーム・コンピューターゲーム等のような実際に遊ばれているゲームに対してゲーム理論で厳密に分析する場合にも、前提条件を疑う必要があります）

これらの前提条件を設定するのは意外と難しいです。
以下では、ゲーム理論の代表的な例題である囚人のジレンマでの例を挙げて説明します。

・利害関係のあるプレイヤーの洗い出し

一見利害関係がありそうなプレイヤーは実は利害関係がなかったり、逆に意外なプレイヤーと利害関係があったりします。
囚人のジレンマの例では、相手の囚人の行動が自分の量刑に影響しないのであれば、相手の囚人をプレイヤーとして仮定するのは不適です。
また、被害者の気分で量刑が変わるのであれば、被害者をプレイヤーとして見立てるべきです。

・各プレイヤーが持つ選択肢

発想を膨らませると、選択肢も色々なものが想定できます。
囚人のジレンマの例では「黙秘」「自白」のみが選択肢として与えられていますが、囚人の能力や状況次第では「賄賂支払」「脱走」といった選択肢も想定する必要があります。

・選択肢を選んだ結果得られる利得

各プレイヤーの目的や価値観、心理的バイアス、外部から与えられた要素等によって、実際に感じる利得は変化します。
例えば、囚人のジレンマにおいては、プレイヤーには「刑を免れる」以外の目的はないことが前提として置かれています。
しかし、現実世界では「正義の主張」という目的が潜んでいる可能性があります。
この場合、自白をすることで「正義の主張」という目的を果たすことができ、それがプレイヤーの主観的な利得に影響を与え、そのプレイヤーにとっては自白一択になる可能性があります。

【ゲーム理論を現実世界で用いる上での心構え】

ここまでで述べたように、ゲーム理論の前提条件の設定には難しさがあります。

ゲーム理論を現実世界で用いるためには、現在のゲームがどのようなゲームなのか、メタ的な目線で分析することが欠かせません。
囚人の量刑を決める場面で常に囚人のジレンマが発生するとは限りません。
先入観に捉われず、現在の状況をゲームに置き換えるとどうなるのか、というのをその場その場で考える必要があります。

その上で、ゲームを作り変える、という視点があるとより有効にゲーム理論を活用することができます。
例えば、囚人のジレンマの例で言うと、予め財を成しておけば、「賄賂支払」という選択肢が選択肢が生まれ、相手の選択肢に関わらず無実を勝ち取れるゲームを作り出すことができます。
どのようにゲームを作り変えれば良いのか、を考える上でも、ゲーム理論の現状分析は役に立つと思います。

---

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

長くなりましたが、ゲーム理論に関する一連の記事は以上になります。

ゲーム理論は情報処理技術者試験のような試験で勉強する内容ですが、せっかくであれば試験対策だけでなく実際に活かした方が良いと思っています。
今回の記事では、実際に活かすにあたって注意するべきことを挙げてみました。

これからも、実践に即した記事を書いていきたいと思います！

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

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

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

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

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

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

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

【混合戦略の求め方】

１．連立方程式を解く方法

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

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

２．微分方程式を解く方法

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

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

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

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

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

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

【検算】

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

・ナッシュ均衡

お互いに最適戦略（相手が選ぶ選択肢によらず、必ず他の選択肢よりも高い利得を得られる選択肢）が存在する場合に、お互いに最適戦略を採用する状態のことを指す。
この状態の時は、お互いに他の戦略を選択する動機が生まれず、状況が硬直化する。
例１ではお互いに最適戦略が存在するため、ナッシュ均衡の状態になる。
プレイヤー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を選び続ける純粋戦略である。

・ラプラス原理

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

・期待値原理

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

・混合戦略

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

・マクシミン原理

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

・マクシマックス原理

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

---

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

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

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

経験が浅い技術者は、システムを構築する際、ユーザーの目から見える機能（機能要件）を満たすことのみを考えがちです。
しかし、システムが価値を生み出すためには、システムが安定的に運用される必要があります。
システムの安定運用を実現するための要件を、「非機能要件」と呼びます。

要件は、国際規格ISO/IEC 9126(JIS X 0129)においては、「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の６つの特性に分類できます。
この内、「機能性」を除いた５つの特性が「非機能要件」とみなすことができる特性です。
これらの分類を詳しく書くと以下の通りです。

---

この国際規格は、情報処理技術者試験で出題されます。
試験対策としては、６つの特性とその概要さえ覚えておけば十分です。

また、実務に従事する上では、６つの特性とその概要を理解した上で、副特性に書かれている観点を網羅的に見て非機能要件を洗い出すことが重要です。
現場に要件定義書のテンプレートがあるのであれば、その現場のテンプレートに従って非機能要件を記述すれば良いのですが、テンプレートが無い場合はこの国際規格をベースに要件定義を進めるのが良いでしょう。

なお、要件定義の後の基本設計でも、非機能要件をベースとした非機能設計が必要になります。
非機能設計についても非機能要件と同じことが言えます。

---

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

今回は、見逃されがちな非機能要件について触れました。
特に、新規のシステムの上流工程に携わるのであれば絶対に知っておきたい知識なので、携わる予定があるのであればどのような特性があるのか今一度眺めてみると良いでしょう。

これからも役に立つ技術の解説を書いていこうと思います！