どういう方針でバグや問題を分類すればよいか

こちらの記事で分類の必要性を説明していますので、お時間あれば合わせてご覧ください。

拙著「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー 第3版」の「はじめに」と「おわりに」にそれぞれ書きましたが、第1版執筆時から10年で開発の形態はだいぶ変わってきて、アジャイル開発のようなイテレーティブな開発の割合が増えました。イテレーティブな開発では設計レビューと名称がついたまとまった活動は見た目上減ったように見えますが、該当する活動がなくなるかというとそうではありません。様々な活動に分散します。そうすると、これまで以上に「こういうタイプのバグや問題(欠陥)が混入してしまうので、こういうふうに未然防止します／見つけます」という考え方を持たないとライトウェイトな品質評価や品質向上はできません。

私の研究と拙著では分類の方針は下図のように4パターンあると思っています。本書は基本的には初級者向けの内容になっていますが、これを説明している部分は例外で、ベテランの方にも気づきを得ていただけます。具体的には「こういうタイプのバグや問題が入り込むので」をどうやって見つけるかについて、説明しています。初版にはこの部分はなく、改訂版で追加し第3版でさらに整理しました。改訂版、第３版ともに4パターンそれぞれの事例を紹介しています。本書の事例4つはレビューがうまくいっている異なる組織の15人から聞いたものから機密情報を除いたものをもとに分類しており、実践でも通用します。

図の4パターン(D-1, D-2, I-1, I-2)を説明します。

(D-1)はもっとも典型的なパターンです。「以前のバージョンで見たことがある」「このソフトウェアで典型的なもの」という感じで設定します。たくさんのレビュー経験を積み上げると見つけられる問題や欠陥が増えていくのはこのパターンで増えていくからです。

(D-2)は(D-1)をもう少し発展、一般化したものです。(D-2), (I-1), (I-2)のパターンを積極的に考えていくとレビューで検出できる問題や欠陥のバリエーションが増えていきます。

(D-2)は類似のアーキテクチャ、類似の開発体制、類似の要素技術で混入していそうな問題や欠陥を検出するパターンです。以下はそれぞれの例です。

• 類似のアーキテクチャの例: 過去にレイヤーアーキテクチャで、レイヤーの制約を守るために十分な性能がでなかったのと同じような問題や欠陥がレイヤーアーキテクチャを使っている今回のレビュー対象にあてはめて考える。

• 類似の開発体制の例: 過去に設計の一部を委託したときに、委託していない設計の部分との整合性がとれていなかったとき。今回のレビュー対象でも同じように設計の一部を委託しているときに、同じような整合性の問題や欠陥がないかをあてはめて考える。

• 類似の要素技術の例: 過去に無線ネットワークを使っているときに、ノイズを受けて通信速度が下がって性能要求を満たせないときがあったとき。今回のレビュー対象でも同様の要求とノイズを受ける可能性がある無線ネットワークを使うとき

(D-1), (D-2)はバグや問題そのものが明確で、こういうバグや問題を見つけると指すことができます。いっぽう(I-1), (I-2)は、バグや問題は明らかではないけれど、ユーザにとっての価値が損なわれていたり損なわれそうになる原因を見つけます。I-1の場合はすでに価値が損なわれている原因となっているバグや問題を見つけます。I-2の場合は現時点では明らかになっていないけれど、留意していないと損なわれる可能性がある原因となっているバグや問題を見つけます。I-1は明らかになっているので、I-2よりは簡単ですが、I-1, I-2とも直接の原因はわからないので、D-1よりは難しくなります。場合によってはD-2よりも難しくなります。

では、具体的に(I-1), (I-2)を見ていきましょう。(I-1)は問題の原因や解消方法は明らかになっていないけれど、具体的に価値が損なわれているものや課題が明らかになっている問題で、そのことをユーザも感じている場合が該当します。以下はその例です。

• 特定条件でレスポンス低下によるユーザの利便性が低下している。

• 特定条件下でデータ損失が起こり、ユーザがデータを再登録しなければならなかった。

(I-2)は、現時点では明らかになっていないけれど、将来ユーザの価値を低減するかもしれない問題で問題がまだ起きていないかまだ気づかれていない場合が該当します。問題が顕在化すると(I-1)で、潜在していると(I-2)になります。ですので、(I-1)の例を「ユーザの価値が損なわれるかもしれない」とすれば、(I-2)の例になります。また、(I-2)の例を「ユーザの価値が損なわれている」とすれば(I-1)の例になります。以下は、最初の2つは(I-1)と同じ例を、その後の2つは(I-1)とは違う例です。

• ユーザの利便性が下がるようなレスポンス低下の原因となる問題(実現方法)

• データ損失が起こってしまうような問題(データ損失を防げない問題)場当たり的な仕様追加や仕様変更が重なると、保守性が悪くなり新機能追加やバグ修正のサイクルが遅くなったりコストがかかるようになる(保守性を考慮していない仕様追加や仕様変更)。

• 必要以上の可用性を求めると、運用コストが高くなる(適切な可用性を設定できない問題)。

これらの詳細は拙著で説明しています。