リリース判定基準・残存バグから電話申告の件数を推定する（その２）
残存バグで１か月に何件コールセンターに電話が入るか推定します
前の記事とこの次の記事では残存バグがもとでサポートセンターに電話申告が発生する件数を推定計算する方法を紹介しています。これは、ソフトのリリース判定の時に残存バグがあっても、ソフトの目的に沿ったサービス提供への影響が少なけれソフトのリリースを承認する、というグータラ親父の考え方かたです。では、前の記事に続いて計算式の中身を順番に説明していきましょう。
A1に続いて延べ稼働台数 A2 を計算します
この (A2) の1ヶ月あたりの延べ稼働台数は、市場での稼働台数 Ｘ 30日で計算する程度で充分です。 この項目に限らず、あくまでも推定計算ですので、どの項目もそれほど精度は必要ありません。 どれかの項目が精度が高くでも、他の推定項目の精度が荒いので、掛け算する事で結局は荒い精度に落ち着いてしまいます。
次に（B)の問題事象の影響度毎の申告率を考えます
ここまでで (A) １ヶ月あたりの問題事象の推定発生件数 （回/月） が計算できたので、次は (B) 影響度毎の申告率です。 影響度とは何でしょう？ 問題事象がサービス提供にどれだけ影響するかの度合、と考えて貰う判り易いです。
例えばオンラインゲームを例に考えてみましょう。 ゲームのスタートボタンを押せないという問題事象は影響度大ですね。 ゲームソフトの目的がゲームを楽しむといサービスの提供ですので、そのサービスの提供が全くできない状態になってしまうので、サービスの提供への影響度大です。
では、ゲーム内で何か特定のアイテムを拾おうとした時にそのアイテムがうまく拾えない、という問題事象はどうでしょう？ そのアイテムの大切さにもよりますが、あまり大切でないアイテムなら、例えそのアイテムが拾えなくてもゲームを続けて楽しむ事はできそうです。 この場合、ゲームを楽しむというサービスの提供には大きな影響は与えていません。
ゲームのスタートボタンを押せない、という問題事象を経験した人は、おそらく２人に１人はゲームメーカのサポートセンターに申告の電話を掛けるのではないでしょうか？ では、ゲーム内で特定のアイテムを拾えなかったという問題事象を経験した人はどうでしょうか？ 100人に１人くらいは、サポートセンターに申告の電話をするかも知れませんね。
このように、問題事象の影響度合いが大きいとサポートセンターへの申告電話を掛ける確立は高くなり、影響度合いが低いと申告電話を掛ける確立は下がります。これを表すのが (B) 影響度毎の申告率 です。これは、計算式で算出するのは難しいので、グータラ親父は表を作って影響度毎に値をエイヤッで決めていました。
このエイヤッで決めて作る影響度毎の申告率は、全てのソフトに共通な物は考えにくいので、ソフトが利用される市場毎に準備する事となります。 先ほどの記事で使った例で考えると判り易いですが、銀行のオンライン決済用のソフトとオンラインゲームのソフトとでは、サポートセンターへ申告電話を掛けるかどうかの判断も、かなり変わります。ですので、ソフトが使われる市場毎に作ったほうが、実際の運法で便利になります。
例えばこんな表になります
ＸＸＸＸ市場向け申告電話の発生確率表
| 影響度合い | ユーザの申告率 | 説明 |
サポートセンターに通知済み時の申告率（＊１） |
| 重大 | １．０ | 1人に１人（全員） | １．０ |
| 重要 | ０．５ | ２人に１人 | ０．０５ |
| 通常 | ０．０１ | １００人に１人 | ０．０ |
| 軽微 | ０．０００１ | １００００人に１人 | ０．０ |
注１：不具合について客先の承認が得られている場合には、客先承認時の率を採用する
表の縦方向は、問題事象がエンドユーザへのサービス提供にどの程度影響するかの影響度合いを、重大から軽微までの４段階に分けて書いてあります。 各々の影響度合いの問題事象が起きた時に、何人に１人がサービスセンターに申告電話を掛けるかを、ユーザの申告率の欄に書いてあります。 例えば、影響度合いが重要な問題事象が発生した場合には、２人に１人が申告電話を掛けると推定して、申告率として 1/2 = 0.5 としてあります。
オンラインゲームで影響度合いの具体例を考えると、例えば以下のようになります。
- 影響度＝重大 ： ゲームのスタートボタンが押せない （ゲームができませんね、即申告電話です）
- 影響度＝重要 ： ゲームへのログインが２回に１回失敗する （まあゲームはできるのですが、イラつきますね）
- 影響度＝通常 ： ゲームの中で重要では無いアイテムが拾えない （それほど気にならないですね）
- 影響度＝軽微 ： ゲームの背景の画像が一部崩れている （気が付かなければオッケー）
また、表の一番右端の欄には、サポートセンターに通知済み時の申告率という欄があります。 これは、問題事象を事前に客先のサポートセンターまで連絡してあり、電話申告を受けたオペレータが適切な回答を返す事でエンドユーザへのサービス提供の影響を回避できる場合は、この値を使って計算する、という意味の欄です。
言い換えると、エンドユーザから申告電話を受けたが、重要度がそれほど高くなく、オペレータが適切な対応を返した結果サービスの提供に影響が無くなるなら、ノーカウントでいいでしょう。 という意味です。
この表の値の設定値には、特に理論も経験値もありません。 まったくのエイヤッの気合で決めた値です。 でも、例え気合で決めた値であっても、決まっている事によって毎回のソフトリリースの判定基準のフラツキを減らす事ができるので、エイヤッであっても決めておく方がよいと思います。
国別の調整係数って何でしょう？
判り難い表現で済みません。 同じ市場であっても国によって要求される品質が異なるので、市場で何か障害が有った時にサービスセンターに申告電話を掛ける人の割合も変るだろうから、そこを調整するために一定の係数を掛け算しているのです。
例えば、日本市場の要求品質を 1.0 としましょう。 日本は品質に対してかなり意識が高い系の国です。 買った製品は、いつどんな状況でもちゃんと動く事が、当然の事と考えています。それに対して、例えば東南アジアの小国ではどうでしょうか？
かなりインフラが整備されてきたとはいえ、まだ停電が起きる事も珍しくない状況です。停電による電子機器のサービス停止が、月に何回か発生するようなイオンフラの環境です。そのような、停電によるサービス停止に慣れてしまっているユーザは、少々の製品の不具合では、わざわざ製品ベンダのサポート窓口に電話をしないだろうと推定されます。
例えば、日本人なら １０人に２人はサポート窓口に申告電話を掛けるような障害であっても、東南アジアの小国では、１０人に1人程度しか申告電話を掛けないでしょう。この違いをサポートセンターへの申告電話の件数の計算に取り込むために、国別の調整計数という値を使っています。
言葉は難しそうでえすが、例えば、日本を 1.0 としたら東南アジアの小国向けには 0.5 という値を最後に掛け算する、というだけの事です。国によって、 0.7 とか 0.5 とか 0.3 とか値を決めておきます。 もちろん、この値もエイヤッで決めているだけです。
やっと計算式が完成しました
これでやっと、リリースするソフトに１つのバグが残っていた時に、サポートセンターに１ヶ月あたり何件の申告電話が掛かってくるのか、という申告件数を推定計算する事ができました。ここまで読んで下さった皆さん、ご苦労様でした。
と、安心するのはまだ少し早いです。もうひとつ、考えておかなければいけない事があるので、次の記事で紹介します。