濃淡をつけたソフトウェア品質の向上にむけて
バグは実装上の誤りという狭い意味で使われていることがあるので、この記事ではバグではなく欠陥と呼びます。欠陥は実装上の集まり、仕様の漏れや曖昧さ、仕様の誤り、設計上の問題も含めています。
ソフトウェアの欠陥を濃淡をつけて見つけるのは大事です。この記事では、ソフトウェア開発全体を通じて濃淡をつけて見つけるためにはどうすればよいかを説明します。ドキュメントレビューで濃淡をつけて欠陥を見つける方法は拙著(「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー」amazon の書籍ページ)で説明しています。
どういうタイプの欠陥を優先して見つけるかを決めると濃淡の「濃」がわかります。欠陥タイプは欠陥の大まかな分類を指します。分類は同じような原因で混入される欠陥をグループ化したものです。同じような方法で検出できて、同じような欠陥と見なせる場合には欠陥タイプと呼びます。開発メンバーの間で「あそこでよくあるタイプのヤツ」と共通認識が持てるものであれば欠陥タイプにできます。たとえば、デフォルト値が設定されていない、ファイル、ネットワーク、データベース等のリソース競合が起きたときの調停処理がない、ある設定をしているときはこれが使えないはずだが、使えるようになっている、といったものです。実装上や仕様上で非常に細かい部分が原因になるときもありますし、複数箇所で整合性がとれていないといった広範囲な部分が原因になるときもあります。
この前提で、(a) ソフトウェア（プロダクト）にとって重要な部分にあると困る欠陥タイプ、(b) 開発チームや組織として未然防止(セルフチェック)できている欠陥タイプ、(c) 開発チームや組織として持っている知見や使っている検出方法で検出しやすい欠陥タイプの重なりを考えると効果を高めたり効率化できます。逆に、(a), (b)をあまり考えずに他の開発チームでの事例から(c)を活用しているような場合には効果が得られなかったり効率があがらなかったりします。(a), (b), (c)を図1のように考えると(a), (b)や(a), (c)の重なりが大きいほうが効果が高く効率もよくなると思います。
(a), (b), (c)がどういうものか一つずつ見ていきましょう。
(a)は開発対象のソフトウェアやプロダクトにとって利用者の価値が大きい部分にある(重要な部分にある)と困る欠陥タイプです。ここにバグがあるとソフトウェア／プロダクトが使う意味がなくなるものです。ソフトウェアやプロダクトによって違います。少し極端な例を挙げますと、文書作成ソフトウェアで保存したファイルが読めなくなる、テキスト送受信ソフトウェアで送信したテキストがなくなってしまう、届かない、といったものです。ソフトウェアやプロダクトによって違ってくる理由は、どう使われるかが違うからです。その例を説明します。閏年かどうかを判定する部分があるとします。これを銀行の勘定系システムで利子を計算する部分で使う場合には、判定結果の誤りにより利子の金額が変わります。この欠陥は勘定システムにとっては重大な欠陥です。一方で、買い物用のポイントカードとして使えるスマホアプリが閏年を判定して、2月29日にレアキャラを表示して「2月29日だよ。閏年だね」と通知してくれる場合(通知のみ)では同じ欠陥でも深刻さが違います。利子の計算の間違いは勘定系システムとしての価値は大きく毀損します。一方でポイントカードアプリとして閏年の2月29日の通知はそれに比べると損なう価値は小さいと言えます。ポイントカードアプリが2月29日にポイントが追加でつくようなポイントカードアプリとしての機能はないものとしています。
(b)は開発チームや組織の知見、開発プロセス、使っているツールや技術で未然防止できている欠陥タイプです。自分たちで開発すると欠陥が入ってしまうかもしれないけれど、特定のAPIやミドルウェアを使っていて欠陥がない場合もこれに含まれます。注意して普通にプログラムやドキュメント(成果物や中間成果物)を作成していれば、こうしたタイプの欠陥はそもそも混入しなかったり(未然防止できていたり)、セルフチェックで見つけられたりするものです。これは普段通りの活動でできているので認識しづらいのですが、こうした欠陥タイプを意識して、やり方、プロセス、メンバーの変更時や他での事例を聞くとき自身の開発と比較すると気づけることが多いです。たとえば、通販サイトでの送料やポイントの計算が複合的な条件で決まるような場合であっても、欠陥がほとんど混入しないというような場合です。ここでの複合的な条件は、3000円以上は送料無料、キャンペーン中は送料が半額、おすすめ商品を購入する場合や合わせ買いするときはポイントの割合が増える、会員ステータスや前月の購入金額によって送料やポイントが増えるといったものです。パラメータ設定できるような仕様として書いておいてパラメータの変更だけで反映できたり、典型的なテストケースを準備しておいてチェックが簡単にできるようにしているといった方法で未然防止できているのがこのタイプの欠陥になります。
(c)は持っている知見や使っている検出技法で検出できている欠陥タイプです。いったんはプログラムやドキュメント(成果物や中間成果物)に混入したとしても他の開発メンバー、手順、ツールを使うと検出できるような欠陥タイプです。これも(b)と同じように普通にできているので気づきにくいものではありますが、検出した記録があれば、そこから「こういうタイプの欠陥は検出できている」と気づけると思います。(b)で挙げた通販サイトでの送料やポイントの条件があるような場合、仕様やプログラムに誤りがあった場合でも、テスト(テスト担当やテストチーム)でのチェックで誤りが見つかる、別の方法で計算した結果との突き合せで誤りが見つかる、境界値分析や決定表のような手順で誤りが見つかるといった場合には、この欠陥タイプにあてはまります
まずは(a), (b), (c)に該当する欠陥タイプはどのようなものがあるかを把握する必要があります。限られたリソースの中で品質評価している方であれば、なんとなく感じていると思いますのでそれを明確にします。その上で、(b)と(c)の重なりが大きい、(a)と(c)の重なりは大きいけれど(b)はそうでもない、といった分析ができると品質向上に貢献します。その上で、(b)や(c)を増やすための方法とその実施コストやそれぞれの欠陥タイプの修正コストを勘案した上で、濃淡をつけることができれば、優先順位を下げられる欠陥タイプが明らかになり、効率化につながります。
(a), (b), (c)を意識できたら、次に重要なのは、認識できているものとそうでないものがありそれをいかに広げていくか、(b)や(c)を改善するために新たな方法を導入、活用しようとするときに要するコスト(手間)、といった点です。これは別の記事で紹介したいと思います。