ソフトウェアの欠陥予防 テストより確実な品質改善法
ある市営図書館でたまたま見つけて、ふと手に取ってた書籍です。
この書籍は日本語訳する時に一部がっつり省かれた章があるらしいです。日本語で読んでかなり資産としてよかったので、つい英語版をポチってしまった。届いたら再読しようと思います。ご興味のある方はどうぞ => The Practical Guide to Defect Prevention (Developer Best Practices)
読んでみて、この書籍はテストエンジニアや品質にかかわる人は読んだほうが良さそうです。が、それ以上にソフトウェアで製品を開発し、それによってユーザに価値をより効率的に提供したい開発者やディレクターの人ほど読むべきだと感じました。特に、第1、2章くらいを。経済的な話など含めて、欠陥予防への取り組みの価値を知ることができるので。(ちなみに、これを書かれた方はWindows Vistの開発に関わった方々です。)
例えば、欠陥予防の取り組みが、破壊的なイノベーションへの投資へ資源を回すことができる余力を作ることに如何に貢献するかなどが書いています。欠陥予防を中心に取り組んだ組織と事後対応中心に取り組んだ組織とでは、彼らの計測結果の中で新機能やサービス改善への生産性に対して約2倍の差があったそうです。つまり、欠陥予防へ取り組んだ組織は、そうでない組織に対して新機能/新しい価値を生み出すための挑戦が多く実施可能だそうです。
この背景は想像の世界ではなく、開発時にかけるコスト、その保守対応時のコスト、機会費用などを持ってきて、費用という側面からの議論のコンテキストの上で行っていることがこの書籍の素晴らしいと感じたところです。
例えば、機能を開発している時に発見された不具合を事後対応に回すほどに、リリース前に対応していた時に比べて修正するまでに費用がかかります。それは、リリース後にユーザサポートにかかるコストや、その修正を行ったあとに行われるテスト作業など含めて考えると直感にも反しないでしょう。これは事後対応中心の組織における開発では考えられないことも多く、例えば自身の変更がmasterにマージされるまでは考慮するが、それ以外のことは考慮しない、というような 限られたソフトウェアのライフサイクルしか考慮できていない ことも関係あるそうです。
ここでいう欠陥/不具合とは、それを利用した人が欠陥/不具合と判断したものです。そのため、Specの通りに実装できていないものだけを欠陥と言っているのではないです。誤って行った設計など、より上の工程に埋め込まれた欠陥、などへも言及しています。
Microsoftの人の言葉はなかなか強いですね。論文などもちゃんとしているぶん。
幾つか頭に残った項目を以下につらつら。
メトリクス
P133ページごろに書かれていたメトリクスの話。
例えばカバレッジなどのメトリクスに関して書いていました。よくあるソフトウェアテスト／品質関連の書籍同様、目指す計測可能な値の1つだと書かれてはいますが、それが銀の弾丸などではないとも書いています。コード変更量とかカバレッジの話で気構えるの、私の観測する範囲ではなんかテスト界隈の人よりも開発者が過剰に反応している環境の方が多いように見えるのですが、これは過去に何かあったのかな…その計測値が顧客への成果物になってたりする場所で働いて、それが絶対的だったりしたのかな。参考値としては多彩な情報を提供してくれますが、それだけをプロセス管理などの管理のために使うといった、誤った使い方は妥当ではないですね。
Microsoftのビジネス及び従業員のゴールは、SMARTを求められるそうな。
- 具体的 specific
- 計測可能 measurable
- 達成可能 achievable
- 結果重視 result oriented
- 期限付き time bound
そのための要素としてGQMが言われていて、
- Goal
- Question
- Metric
を使うそうな。優先付けの数値は、一般に粒度があまり密でないほうが良いらしい。なので、hight 9/medium 3/low 1くらいの点数付けでメトリクスやタスクを優先付けするそうです。その重み付けには、開始の容易さ・メンテナンスの容易さ・有用性、現在収集されているか、信頼レベルなどらしいです。それを元にヒートマップを作るみたい。ヒートマップを作るの良いな。(P.140くらい)
リスク分析
第8章ではリスク分析の話が書かれてました。リスク分析では、特性(characteristics)、量(amount)、インパクト(impact)、理由(reason)、オーナーシップ(ownership)でリスクレベルを判断するそう。コードの変更内容、変更量、変更による影響、変更理由、誰が変更しているか、だそうです。真っ当な感じですね。過去、現在から予測する。そこにフィードバックも入れる。
欠陥分類
第10章では欠陥分類法について言及してました。そこでは、以下の内容を前提に、欠陥を分類していく幾つかの実例を載せています。
- 変化には決まった種類がある: 人/文化/プロセスなど
- 人は過ちを犯す
- 欠陥はサイクルの後で見つかる
- 欠陥はそれが生まれたフェーズでは見逃される
- テストは常に安定しているとは限らない
- ツールやプロセスの能力をこえている可能性がある
- 後期になってから設計を修正する場合がある
少し話は脱線して、 私も業務である取り組みの欠陥分類を考えていた のですが、そのために使っていた2軸の設定は誤りではなかったみたいです。原因形成と、その対応、という2つの異なるステージを対象にしていたのですが。
根本原因分析(RCA)
根本原因分析(RCA)の役割で言及していた必要なスキル、おそらくテストエンジニアのような立ち位置に必要とされる能力が多分に関わっている気がしますね。私の現在と照らし合わせるとそんな感じしかしなかった。
この分析、本当はかなり頭使うし疲れるのですよね…
フィッシュボーンダイアグラムが使われてた。ここで使うとは。なるほど。
欠陥予防のためのプロセス
欠陥予防は、プロセス改善の側面ももちます。そこで
欠陥予防のための、プロセスの側面
Agileとかtraditionalなものは当然として、personal software process まで書かれていたことは少し驚きました。
欠陥を防ぐ最も良い方法の1つは、機械を使って人がエラーを起こしやすいタスクを自動化すること
~ my tech diary ~ 
3 Comments