簡単リスクベーステスト

今度リリースする製品に大きな変更があると不安になる。
それはわれわれの組織が適切なメトリクスを計測していないこともあるのだけれど。

しかし、継続して計測していないとどうしようもなく、プロジェクト終盤にオロオロしてもどうしようもない。
なのでこの不安を払拭する方法を思いついた。

それが「どんな問題が起こるか聴いてみる」方法である。
次にリリースする製品が不安で仕方なければ、とりあえず隣の人にこう聴いてみよう。

「なあ、これリリース後にバグ出ると思う？」

きっと隣の人は「出る」と答えるだろう。
それは今までリリース後にバグが絶えなかった経験とか、現在のバグの発生具合から推測した答えだろう。
しかしそれは大体当たっている。自分もそう思っているから不安なのだろう。
「出ないよ」と言われたら別の人にも聴いてみよう。「出る」と言われたら次にこう聴いてみよう。

「どんな問題が出ると思う？」

そうすると、隣の人は過去に問題がおきた機能や、現在バグが頻出している機能をあげるだろう。
もし自分がそれらの問題に対して対策済みなら問題ないだろう。（バグが頻出しているのに対策済みという認識なら、それを改める必要があるが）
未対策であれば対応策を考えよう。今すぐつぶせない問題なら、それが発生した時の対応策を考えておき、管理しておけばいいだろう。

・・・てな具合にその辺の人にどこに問題が出るかを聞いて回って英知を結集するのだ。
なんだったらミーティングでもいいだろうし。とにかく問題になりそうなことはすべてあげるのだ。

ここまでやって対応策を組んでいけば、リリースした製品が大炎上することはないだろう。
良くも悪くも、いつも通りの品質まで上がっているのではないだろうか。
もしそれでも不安が払拭できなければ、いつでも前の状態に戻せるようにしておくことだ。
ここまでやれば、最悪の結果は起きない。

と、ヤバそうなプロジェクトにかかわっているさなか思いついた提案である。（よく考えたらデマルコの本かも）