リリース判定基準・残存バグはサービス提供への影響で判断する
残存バグがあっても良いかはソフトの目的と影響度で決める
残存バグが残っていてもソフトをリリースする場合、残存バグの何をもとにしてリリースの可否を判定すれば良いのでしょうか？ グータラ親父は、そのソフトの目的であるサービス提供への影響度を使って判定していましたので、この記事で紹介していきます。
ところでソフトの目的ってな何でしょう？ いきなり話題が変わってしまいましたが、まあもう少しお付き合い下さい。例えば、コーヒーカップの目的ってなんでしょう？ これは判り易いですね、人間がコーヒーを気持ち良く飲むために、中にコーヒーを溜めておく事がコーヒーカップの目的です。サイフォンの口から直接コーヒーを飲むのは、さすがに辛そうですよね。
では銀行のCD機(キャッシュディスペンサー）の目的って何でしょう？ 自分の銀行口座からお金を引きだりお金を預けたりする事がCD機の目的ですね。CD機は中に大量のお札を保管していて、これをユーザからの要求に従って出したり預かったりしてくれます。実際にお札を保管したりユーザに渡したりしているのは、CD機のハードウエアですので、CD機のハードウエアの目的は、安全にお札を保管しユーザとの間でお札の出し入れをする事、と言えます。
それでは、CD機のソフトの目的は何でしょう？ ソフトは直接お札を扱っているのではありません。ソフトが実行してるのは、ユーザは誰でその人の口座に残金がいくらあるかを確認して、今回は何万円の引き出しの指示があったからCD機が保管しているお札から必要な枚数を決めてユーザに渡す、という指示をCD機のハードウエアに出すという事を実行しています。
CD機のソフトはこのように情報を処理する事で、CD機というハードウエアを使って提供される、銀行口座からの現金の出し入れというサービスを提供しているのです。つまり、情報を処理する事でサービスを提供するというのが、CD機のソフトの目的です。
ソフトの目的をサービスの提供と考えると判り易い
サービスの提供をソフトの目的と考えると、ソフトという物が理解しやすくなります。CD機のソフトは口座からの現金の引き出しや預金というサービスを提供しています。オンライゲームのソフトは、リモコンやゲーム画面を通してゲームの世界を楽しむというサービスを提供しています。車の自動運転のソフトは、ドライバーの替りに車を運転するというサービスを提供します。
サービスの提供をソフトの目的と考えると、何が判り易くなるのでしょうか？ サービスを受ける私たちエンドユーザが、ソフトに何を求めているかが判り易くなります。私たちは、サービスを受けたい時に、その時その場面で必要な品質でサービスを受ける事を望みます。
必要な品質でサービスを提供できるのがリリース条件
ＣＤ機でお金を引き出す時には、自分の口座から間違いなくお金を引き出せるサービスを望みます。オンラインゲームで遊ぶ時には、遊びたいと思ったその時に楽しめるゲームサービスを望みます。
そして、エンドユーザが望む品質でサービスを提供する事ができるか？ というのがソフトのリリース判定で見極める必要のある事になります。いや～、やっと話題がリリース判定に戻ってきました良かったです。
その残存バグはサービス提供に影響しますか？
ちょっと回り道をしたのですが、リリース判定の時に残存しているバグがある場合には、その残存バグがエンドユーザへのサービス提供に影響するかどうかを基に判定するというのが、グータラ親父の方法です。
でも、これだけだとまだ漠然としていてリリース可否の判定には使い難いですね。サービス提供に影響するかどうかという事をもう少し具体的にして、できれば数値化してリリース判定に使いたいところです。では、エンドユーザがサービスの提供に満足をしなかったら、どうするでしょうか？
例えば、ＣＤ機が引き出しを指定したお札の枚数を間違えたり、ゲームで対戦相手に勝ったのに、自分が負けという結果が表示されたら皆さんはどうしますか？ たいていの人はサポートセンターに電話して苦情を言いますね。サポートセンターへの苦情が多ければ、それは多くのエンドユーザがサービスの提供に満足していないという事です。
その残存バグは月に何件サポートセンターへの申告を起こしますか？
グータラ親父は、リリース時の残存バグに関して、その残存バグが残っている状態のソフトが市場で使われた時に、そのバグが原因で発生する問題について、サポートセンターに1ヶ月あたり何件の申告電話が掛かってくるか、という申告件数を推定して、ソフトのリリース可否の判定に使っていました。要するに、サポートセンターにたくさん申告の電話が掛かってくる可能異性があるなら、リリースを止めるという事です。
サポートセンターへの申告電話の件数を推定する事なんて、できるのでしょうか？ まあ、いろいろな仮定を置く事になりますが、１ヶ月あたりのサポートセンターへの申告電話の件数を推定する計算式を作る事はできます。
ユーザがサポートセンターに申告電話を掛けるかどうかは、色々な条件で変わってきます。バグが原因で発生する問題は、どんな条件が成立すると発生するのかとか、その発生条件はどんな確率で揃うのかとか、問題が起きるとサービス提供がどの程度影響を受けるのかとか、様々な事が申告電話の件数に関係します。
少し無理目でも定量的な方法があったほうが良さげです
この残存バグによるサービスセンターへの申告電話の件数を、こんな感じならオッケーというように定性的に判断するのはちょっと難しいので、少し無理はありますが、定量的に計算する方法を考えておく必要があります。でも、数学の定理のような立派な物でもないので、どかの教科書に載っているという物でもありません。仕方が無いので、エイヤッで自分で作ってしまい、運用するしかありません。
という事で、グータラ親父は自分の経験から、エイヤッで計算式を作って、残存バグから１ヶ月あたりのサポートセンターへの申告電話の件数を推定検査して、その件数をリリース可否の判定に使っていました。推定の具体的な方法について、次の記事で少し詳しく紹介していきます。