これは何？
「品質に問題はない！」と言うのは信じてはいけないよ。
もし「品質に問題ない！」を多用してしまっているのであれば、それは組織上の問題かもしれないよ。という話を例え話をしながら長々と話している記事です。
品質には問題ありません！は本当？
開発したサービスやプロダクトに対して、またウォーターフォールであれば工程完了時などに
「品質に問題はありません！」
と言ったことはありませんか？
品質に問題がないってどういう意味でしょうか？
「バグはありません！」とか「このプロダクトは完璧です！」などと言った意味で使っていたのであれば、それは問題です。
なぜ問題なのでしょうか？
満場一致のパラドックス
統計学においては、全ての意見が一致すると逆にそのデータの信頼性が下がるということが知られています。
それは「満場一致のパラドックス」と言われます。
通常、人は多様な意見を持ったり、誤った判断をするものなので、自然な状態では満場一致は極めて発生しづらいのです。
例えば、とある犯罪の目撃者が10人いて
犯人の候補となる人を並べた上で「誰が犯人だとおもうか？」と質問をしたところで
10人全員がとある1人を指差すような場合、安易にその差された人が犯人であると考えるのは危険だということです。
人間の記憶は曖昧なものなので、上記のようなシチュエーションでも40%ほどの人が間違った人を指名してしまうことが知られています。
にもかかわらず、10人全員が1人の人を指すのはあからさまに不自然ですね。
このようなシチュエーションでは、目撃者に何らかのバイアスがかかっていることを疑うべきです。
例えば容疑者の中にあからさまに柄の悪い人がいるせいで、目撃者たちの判断が偏ってしまったのかもしれません。
ソフトウェアにはバグがつきものです。全てのバグが除去できるというのは幻想に過ぎません。
「バグがありません！」というのは信用できない状態と見るほうがよいでしょう。
DDP(Defect Detection Percentage)による評価
例えばこうしたパラドックスは、DDPという指標を使って品質評価をするとわかりやすくなります。
DDPは簡単にいうと評価対象のテストなどのプロセスの終了時の値を100%とした際に、すり抜けバグが発生すると徐々にパーセンテージが低下していく指標です。
この数値をモニタリングしていくことで、評価対象のプロセスの能力が発揮されていたか？が明確になります。
日に日に数値が低下するようであれば、どこかで評価対象のプロセス実行上に問題がなかったか疑い、改善することができます。
もし、この数値が100%にあると「満場一致のパラドックス」の通り不自然なので、もし100%に張り付いているようなプロセスがあれば、バグをバグとして報告できないような組織になってしまっているか、もしくは後の工程でまともにテストされていない、リリース後にユーザが全然機能を利用していないといったことを疑うべきです。
全会一致の幻想
バグをバグとして報告できないような組織や、いつもいつも「品質に問題ない」といってしまうチームは、全会一致の幻想に陥っている可能性もあります。
人間は集団の中で意思決定をする際に、できるだけ和を乱さないように動いてしまうそうです。
ソフトウェア開発はチームで進めるものですから、このプロダクトはリリースしてよいのか？次の工程に進んでよいのか？などと考えるときには、ついつい「問題ない」という判断をとりがちです。
人に迷惑をかけたくない、余計なお世話だって言われちゃうかも、自分の発言で遅延を産んでしまうかもしれない、これ言ったらあの人怒っちゃうかな…そう考えてしまうと、批判的な意見は中々言えませんよね。
ひょっとしたら１人１人インタビューをすると
「本当はxxの機能に不安があるんだよね…」
「実はセキュリティについてあんまり検討できていなくて…」
といった不安が出てくるかもしれません。
私達は、常にこうした全会一致の幻想に囚われていないか？満場一致のパラドックスに引っかかっていないか？と気を配る必要があります。
「悪魔の代弁者」を使え！
じゃあ、どうすればよいのでしょうか？
1つは心理的安全性を上げる。ということがあります。
組織文化に変革を促し、自由な発言ができる風土を醸成するのは重要なことです。
ただ、明日の会議でどうすればいいのか？と言われると困ってしまうとおもいます。
そんな時は悪魔の代弁者を使うのが有効です。
悪魔の代弁者とは、簡単に言ってしまうとサクラです。
議論を盛り上げるために、敢えて反対の意見を述べたり、批判をしたりする人を用意するのです。
1人が口火を切ることで、他の人の発言の障壁が下がることが期待できます。
自由な発言を促し、個々の開発者が品質に関する不安を口にできる状態になってこそ健全な品質管理だと言えるでしょう。
そうして、皆の意見を聞いた上でも「リリースできる」とか「いや、このリスクには対処しておこう」といったような合意が形成できると良いと思います。
品質を保証する。というのは対象となるプロダクトやサービスに対して責任を負う。ということにほかなりません。決してバグが存在しないということではないのです。
「品質に問題がない！」と宣言する事ありきでリリースを判断するのではなく、自由な議論ができる状態を作ることに努め、起こりうるリスクや、潜在するバグについて認識した上で、なにかあっても責任が取れる状態になったと判断できるのであれば、「品質を保証します！」と宣言してもよいでしょう。
まとめ
私がこの記事を通して伝えたかったことは以下の通りです。
リリース前の会議や、品質評価を行う際には常に肝に命じておきたいですね。
自戒の念も込めて、改めてまとめてみました。
- 「品質には問題ありません！」を信じてはいけない。
- 必ずバグは残存している。バグが見つからないのは不自然な状態で逆に怪しいと思おう。
- 満場一致、全会一致、バグ0件は心理的安全性の無さが生み出しているかもしれない。
- 時には「悪魔の代弁者」を使って、チームの壁を取り払おう。
- バグはある。プロセスの不備もある。という前提のもと評価を行おう。