1. はじめに
2019/3/6にDeNA QA Night #2に参加しました。
第二部はJaSST'17東京の招待講演の奈良さんの資料「ソフトウェアの品質保証の本質～技法の変遷から学ぶ～」をベースに、奈良さん、西さん、河野さんのパネルディスカッションを通して今でも使い物になりそうなもの、基礎知識として必要なもの、忘れても良さそうなものという視点でQAの考え方、技術、プラクティスを整理するという内容でした。
ここで取り上げられた技法のひとつに品質管理図がありますが、品質管理図を使っている人という質問に対してあまり手が挙がらず意外だったのでこの機会に振り返ってみたいと思います。
2. 品質管理図
奈良さんの資料より品質管理図を引用します。これはウォーターフォール開発のシステムテストの予実管理に使うものでテストや不具合修正の進捗を一枚のグラフで見られるようにしたものです。目標と実績の乖離をモニタリングし対策を打ったり着地点を予想したりするためのチャートです。
このグラフには下記の5つのアイテムが描かれています。
- 不良摘出予想線
- テスト消化予想線
- 不良摘出実績線
- テスト消化実績線
- 未解決不良件数曲線
不良摘出実績線とテスト消化実績線は実績をプロットします。未解決不良件数曲線は起票された不良の数から摘出済みとなった不良の数を引き算してプロットします。
3. 予想線≠予測線
奈良さんの資料によると品質予測と評価にあたり信頼性成長曲線モデルに基づいたバグ件数の予測や探針を行っていたそうですが、モデルに現実1を反映させるのは難しそうに思いました。
ところで予想線のS字の説明に登場するゴンペルツ曲線は信頼性成長曲線モデルにも出てくるので何らかの仮説やモデルに基づく予測をしていると思うかもしれませんが、筆者がゴンペルツ曲線を使って予想線を描くのはExcelでいい感じにS字を描けるからというだけです。筆者が品質管理図を作ることになった当初、参考にさせていただいた「山浦恒央の“くみこみ”な話（16）：テスト消化曲線とバグ発生曲線の7パターン診断」ではS字の書き方を以下のように説明しています。
図1を見ると、線を引くのが大変そうですが、実際の開発現場では、「テスト項目の総数」と「テストに割り当てた日数」から適当に曲線を引いている場合がほとんどです。S字に曲げた針金の端を「テスト開始日＋テスト項目総数」に置き、もう一方の端を「テスト終了日＋テスト項目が0件」に置いて、針金を伸ばして決めるマネージャもいます。この後に述べる理由により、Gompertz Curveでの品質制御では、正確性や厳密性を求めませんので（すなわち、きちんと曲線を引いても意味がないので）、テキトーで構いません。
ただしテキトーと言ってもまったくのあてずっぽうで予実管理と呼ぶのはちょっとアレです。例えば上の記事では不具合の発生件数を過去の類似プロジェクトのバグ密度(KLOCあたりの不具合の発生数)と今回の開発ステップ数から見積もる方法が紹介されています。
実際にはバグ密度で推測したバグ件数は何もないよりはマシという程度ですし2テストの消化スピードにしても常に一定ということはなく日によって速い遅いが発生するのでそう正確なものではありません。とはいえ正確さを上げるのに工数を投入するよりもざっくり把握できればOKと割り切ってその工数を例えば予実の乖離の分析に振る方が良いです。
また、予想線はマネージャの意思表示でもあります。ゴンペルツ曲線でS字を引くのは筆者のようなSQAやPMOでもできますが目標に沿って進められるよう段取りや順番を工夫したり日々発生する課題をつぶさなければ(=マネージャの意思がなければ)絵に描いた餅でしかありません。
4. これ一枚
システムテストの進捗がこれ一枚でざっくり俯瞰できます。
偉い人と話すときは話のゴールをまず伝え、大枠から話して相手が興味を持ったところを細かく話しますよね？品質管理図はこれ一枚というには物足りなさがありますがいろいろ引き算してマネージャが大枠を把握するのに必要な項目だけが載っていると考えると良いように思います。上に挙がっている5項目に項目を足したり層別して二枚、三枚と増えることもありますが、あまり増えると見づらくなるので一枚目になくて構わないものは二枚目に回したり、一番の読み手であるマネージャと相談して決めたりすると良いでしょう。
なお、これ一枚といっても品質管理図だけ見ても例えばどのテストが終わって、仕掛中のテストが何で、予定していた順番が入れ替わったテストはどれといったことはわからないのでそういう資料も別途用意します。
5. たいして手間がかからない
いちどExcelでひな型を作ってしまえばあとは1日1回などあらかじめ決めた周期でBTS(Bug Tracking System)からデータをエクスポートしてExcelに貼ったりテストの進捗を記入すればよく、あまり手間をかけずに作れるのはメリットです。たいして正確なものでもないので手間をかけても仕方ないとも言えますが。
6. おわりに
パネルディスカッションのオープニング資料「DeNA QA Night #2 presentation QAの過去から現在・現在から未来」で水中に沈む古代都市(諸説あり)として描かれている'70～'80の技法をもうすぐ'20という今の時代で使うならちょっと昔(プロジェクト時代：'90～'00)のCHAPDなやり方よりも上手に使いたいところです。
改めて品質管理図を振り返ってみて、あまり手間をかけずに目標と実績の乖離が視覚的にわかるメリットがありウォーターフォール開発においてマネージャが押さえておくべき資料の一つと思いました。ただ、予想線に実績が乗っていることにこだわるのではなく判断材料の一つと位置付け、ほかの情報源も加え、予想線から外れていても理由が分かっていること、対策を打てていること、コントロールできていること、そのことがチームで共有できていることが大事と思います。見積もりをどうするという課題はあるもののこれは品質管理図に固有の課題ではないため別途取り組むテーマと思います。