「こういうバグや問題を防ぎたい」から考えて検出方法を考える

拙著「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー」の初版が2013年に発行され、2023年に第3版が発行されました。第3版の「はじめに」「おわりに」を書くときに、この10年のソフトウェア開発や品質を振り返りました。このページでは、そのときの気づきを書きます。2024年3月19日のオンラインのイベント「バグ分類に合わせた品質評価 - エビデンスにもとづくシフトレフトとシフトライトテスティング」でお話する機会をいただきましたので、そこでもお話するつもりです。

この10年で「なるべく多くのバグ／問題を見つける」「とにかく早い段階で網羅的にバグ／問題を見つける」という考えだけでなく、「こういうバグ／問題は後から修正する」という考えも浸透してきたと思います。明確な理由なしにとにかく早く見つけるという考えは減ってきたのではないかと思います。つまり「こういうバグ／問題は手痛いので早いうちに防ぎたい」という合理的な理由があれば早い段階で見つける工夫をするというものです。拙著もそれを後押ししているのではないかと思っています。

ここでの「問題」はバグとはいえないけれど(明確な誤りではないけれど)、改善したほうがよい点を指します。たとえば使い勝手がよくない等です。

しかし、「こういうバグ」「こういう問題」という前提がなく、ぼんやりと「とにかく早く見つけて修正する」「後でもよければ後で探して修正する」となってしまうのはよくありません。「どういうバグ／問題」をどうやって見つけるかを決めてチームで合意するのがお勧めです。これをうまく決めることができれば、「こういうバグや問題」を見つけて修正するメリットと見つけられなかったときのリスクや損失を勘案して合理的な判断ができます。

ただし、特に意識しなくても普段どおりに見つけられているものは、わざわざ「こういうバグ／問題」と明示する必要はありません。明示しないと見つけにくいものが今回の対象です。

「こういうバグ／問題をこういう方法で見つける」を浸透する上での問題の一つは「こういうバグや問題は後から修正しても問題ない」という話を積極的にはしづらい、または否定されやすいという状況や環境はまだ多いことです。そうした場合でも「こういうバグや問題を防ぎたい」を明示しておくと、合理的に対処しやすくなります。最初はバグよりは問題のほうから考え始めるのがお勧めです。問題のほうが「使ってもらわないとわからない」ことが多く、後から修正することに合意してもらいやすいからです。

具体例を挙げて、後から修正しても問題ない問題を説明します。ソフトウェアによっては、使ってもらってから様子を見る／再考するのが適しているものがあります。典型例はA/Bテストのように「利用履歴をみてどちらがよりよくなるかを確かめる」「実際に使ってもらってからどちらがいいかを聞いてみる」といった判断をするものです。これは、「こういう問題」を実際に使ってもらってみないとわからないと判断しているからです。リリース後のA/Bテストもリリース前に限定されたユーザに評価してもらってもよいはずです。しかし、「実際に多くのユーザに使ってもらわないとわからない」「これらには甲乙つけがたいところがある」ということであれば、「使ってもらった上で必要があれば修正しよう」と合意がとれていると思います。

このとき、「こういう問題／バグ」を「こういう方法で見つける」という対にしておくとさらに合意が取りやすくなります。

これまで研究してきた「こういう問題／バグ」をどのように選べばよいかを説明したこちらのブログエントリを合わせて読んでいただくと、より明瞭に理解いただけます。