テストプロセス改善の具体例
それでは、具体例の説明に移りましょう。設定として、あなたはソフトウェア品質のコンサルタントで、金融会社のXYZソフトウェア（架空の会社）の社長より、「市場バグが多発しているので何とかしてほしい」と相談を受けたとします（ここでは、このような設定にしていますが、大きな流れは同じなので、適宜読者の置かれている状況に合わせて読み替えてください）。この状況を、IDEAL改善プログラムに沿って対応していきましょう。
開始工程（Initiating）
開始工程では、プロセス改善の成功にむけて、初期の改善体制を構築します。また、組織としてのゴールを設定し、利害の異なる関係者の貢献および期待結果を定義します。
変化への刺激
開始工程の最初は、「変化への刺激」です。「変化への刺激」は、今回、テストプロセスを改善しなければならなくなった「きっかけ」を明らかにします。今回の例でいうと、「市場バグが多発している」という状況になります。さらに踏み込むと、「市場バグが原因で、ユーザーからの信用を失っている。バグ修正に追われ、コストも増加している。それにより、会社の存続が危うくなっている」となります。
活動背景の確認
開始工程の2つ目は、「活動背景の確認」です。「活動背景の確認」は、テストプロセス改善の「ゴール」を明らかにします。今回の例でいうと、「一刻も早く市場バグを削減する」になります。
スポンサーシップの確立
開始工程の3つ目は、「スポンサーシップの確立」です。「スポンサーシップの確立」は、テストプロセス改善をしていく上で、ステークホルダーの「支援の約束」を取り付けることです。
今回の例でいうと、XYZソフトウェアの社長に、テストプロセス改善の全面的な支援を約束してもらい、各部署の責任者やリーダーに最大限の協力をするように要請してもらいます。ここでは、社長の協力を得られましたが、社長が難しい場合は、なるべく上位の役職の人の協力を仰ぎましょう。役職が高い人の後ろ盾があれば、改善活動がぐっと楽になります。逆に、ここで協力が取り付けられないと、今後の改善活動がスムーズに運びませんので、ここはしっかりやりたいところです。
活動体制の構築
開始工程の4つ目は、「活動体制の構築」になります。「活動体制の構築」は、その名の通り体制の構築です。今回で言うと、外部コンサルタントと内部の責任者（通常業務と兼任）で体制を構築することになります。プロジェクトの体制図などを作って承認してもらうと良いでしょう。できるだけ、社長直轄になるようにしてください。それが難しい場合は、なるべく高い役職の人の直轄になるように交渉してください。
診断工程（Diagnosing）
診断工程では、現状の把握と改善の機会を確認します。その際、テストプロセス改善モデルなどで診断することもあります。それらは、提案書にまとめられ、プロジェクトスポンサーやステークホルダーの承認を得ます。
現状と理想像の記述
診断工程の1つ目は、「現状と理想像の記述」です。「現状と理想像の記述」は、現状把握し、あるべき姿とのギャップを明確にします。筆者は、ここが最も重要なプログラムだと考えています。そこで、この部分については特に丁寧に解説していきます。
現状把握とあるべき姿の明確化には、前提として「仮説思考」が必要になります。テストプロセス改善をするときに、情報を完璧に収集できることも稀ですし、時間も非常に限られています。その中で答えを出さなければなりません。元マッキンゼー・アンド・カンパニー経営コンサルタントの斎藤嘉則氏が、著書『問題解決プロフェッショナル「思考と技術」』（ダイヤモンド社）内で以下のように述べています。
＜仮説思考＞とは、限られた時間、限られた情報しかなくとも、必ずその時点での結論を持ち、実行に移すということである。とにかく早く結論を出して、早く実行に移す。そして、その結果を早く検証して次のステップにつなげて行く。刻々と変化する現代においては、このスピードが命運を分ける。時間をかけて緻密な分析によって精度を高めようとするよりも、ざっくりでもいいから短時間であるレベルの結論を出し、アクションに結びつけることが重要なのだ。ベター・ソリューションでかまわない。なぜなら変化の激しい現代では、検討を重ねているうちに前提条件が180度転換するようなことはいくらでもあるからだ。そうした事態に陥らないために、この＜仮説思考＞が必要なのだ。
＜仮説思考＞のポイントは、
- アクションに結びつく結論を常に持つ ―― 結論の仮説
- 結論に導く背後の理由やメカニズムを考える ―― 理由の仮説
- 「ベスト」を考えるよりも「ベター」を実行する ―― スピード重視
である。
今回の例でいうと、「結論の仮説」は「市場バグが多発しているということは、開発時にバグを多く混入して、テストでバグの検出ができていないのだろう。一刻も早く市場バグを減らさなければならないとなると、まずはテストの強化が必要です。それも、リリース前のシステムテストから改善していくのが、最も費用対効果が良い可能性が高いでしょう。（第2回の「1．市場バグを削減できる」章を参照）」になります。「理由の仮説」は、システムテストでは、「プロセス」「人」「技術」の三要素が不足している可能性が高い（第1回「はじめに」章を参照）。
「『プロセス』は、テスト計画やテスト設計、バグ管理などが整備されていない。『人』はテストスキルや経験が不足している。『技術』はバグ管理ツール（BTS）、プロジェクト管理などが機能していない。などが考えられる」となります。
それでは、「現状把握」に進みます。「現状把握」ですが、HBA 品質コンサルタントである安達 賢二氏の著書『ソフトウェアプロセス改善手法 SaPID入門』（日科技連）の「現状把握」手法が参考になります。安達氏は著書の中で、「現状把握」には、以下の3STEPが必要と述べています。
STEP 1: 問題の洗い出し・引き出し
STEP 2: 事実確認・要素精査
STEP 3: 問題分析・構造化
筆者は、この3STEPがとても有効であると感じているので、ここでは仮説思考と一緒に使っていきます。
STEP 1: 問題の洗い出し・引き出し
このSTEPでは、関係者が把握している問題や課題などを、付箋やブレーンストーミングを利用して、洗い出します。安達氏によると、問題や課題の総数は、20件前後を目安にすると良いとしています。20件を下回ると抜け漏れが多く、20件を大きく超えると因果関係分析に時間がかかってしまうとされています。筆者の経験からも、20件前後がバランス的に良いと感じています。一度に対応できる数は限られていますし、刻一刻と状況は変わるので、あまり厳密さにこだわるよりも、スピード重視で結論を出すことが大切です。
SaPIDでは、関係者が全員参画して課題や問題を明らかにすることを求めていますが、現実的に難しい場合もあります。そのような場合は、重要な関係者にヒアリングして代用します。ここでは、XYZソフトウェアの社長と現場責任者、リーダーにヒアリングします。
ヒアリングでは、仮説思考で立てた仮説がカバーされるようします。例えば、「何が問題や課題でしょうか？」「なぜ市場バグが多く起こっていると思いますか？」「システムテストはどうでしょうか？」「テストプロセスで問題はありますか？」「メンバーのスキルはどうでしょうか？」「ツールやマネジメント技術は適切に使えていますか？」などと聞いています。ヒアリングの結果、仮説が間違っていることが判明することも多々あります。そのため、仮説に固執しすぎず、都度修正していきましょう。場合によっては、事前に用意した質問を全く使わないで、関係者の説明を聞くだけになることもあります。
ヒアリングは、「非常に多くの市場バグが発生していて、毎週何かしらのバグが出ています。エンドユーザーからその都度、クレームがきており、週次で会議しているのですが、毎回、詰められています。その上、毎回説明に窮してしまって、謝るしかない状態です。単純なバグも多くあり、テストが機能していないようです。開発とテストの業務がうまく連携できていなくて、効果的なテストが実施できていないようです。なんとか、この状況を改善しないと、次の案件をもらえないかもしれません。それに、メンバーが残業続きで疲弊しており……」のような形で収集されます。
このままだと、分析できないので、重要な項目を20件前後ピックアップしていきます。この際、付箋に書き出していくのが、オススメです。付箋ですと、スペースが限られているので、ちょうど良い文字数に分割できます。今回のヒアリング結果は、図2のようになりました。
STEP 2: 事実確認・要素精査
STEP 2は、STEP 1で洗い出した問題や課題の事実確認・要素精査になります。まずは事実確認です。STEP 1の洗い出しでは、思い込みや個人的な感情、事実誤認などが入っている可能性があります。それらを排除するために、なるべく記録やドキュメントを確認して、客観データによって裏づけをしていきます。
ただし、「テストプロセスが存在していない」や「テスト知識やスキルが不足している」などは、「ある・なし」というよりも「程度」の問題です。そのような場合は、テストプロセス診断やテスト技術者の実力テストなどを実施して、程度を計測することもあります。また、記録などの客観データがない場合や、客観データをそろえるのに時間がかかりすぎてしまう場合もあります。そんな時には、推量・推定などを用いたり、複数人に追加ヒアリングしたりして判断することになります。
例えば、客観データを今回の例でいうと、市場バグは93件／年、顧客クレームは48件／年、休出や残業が多い時は平均4回／月の休出、平均60時間／月の残業、最高100時間／月の残業と、具体的な数字にしていきます（ここであげた数値は架空の数値です ）｡
程度の計測では、テストプロセス診断やテスト技術者の実力テストなどを実施します。テストプロセス診断では、TPI NEXTやTMMi、ISO/IEC 33063など標準的なプロセス診断を使っても良いですし、独自の診断手法を用いても構いません。今回は比較的診断しやすいTPI NEXTで診断していきます（第1回の「テストプロセス改善モデル（Test Process Improvement Models）」章を参照 ）。TPI NEXTは診断ツールが用意されており、その診断ツールのチェックポイントに回答していくことで診断することができます（図3）。
診断ツールのチェックポイントに全て回答すると、図4のような結果が得られます。緑色の部分ができているところで、赤色の部分ができていないところです。今回の例では、関係者が「テストプロセスが存在していない」と言うだけあり、ほとんどプロセスが存在していないことが分かります。このように、テストプロセス診断の良いところは、できている所とできていない所が、明確になることです。
最後に、追加ヒアリングについてです。追加ヒアリングは、客観データの収集および計測が困難な時に効果的です。例えば、「無責任なやつがいる」という問題・課題については、「なぜ無責任と感じたのか？」「その時の状況はどうだったのか？」などをヒアリングして、裏をとっていきます。
ヒアリングすると、無責任と感じたのは、「バグ修正後の確認テストをしないから」と分かりました。状況を確認すると、「故意に確認テストをやらなかったのではなく、バグ修正完了の連絡が特定メンバーに届いていなかった」ことが分かりました。その結果、「無責任なやつがいる」という問題・課題については、取り下げとなりました。
次に、「開発者へのフィードバックができていない」について見ていきます。状況を確認すると、現在のテスト担当者は、開発でパフォーマンスを発揮できなかった人が担当することが分かりました。つまり、降格のようなイメージで、開発担当からテスト担当に役割変更となっていました。そのようなこともあり、開発担当者はテスト担当者のことを下に見ており、一方のテスト担当者は開発担当者に引け目を感じていました。そのため、テスト担当者がバグを見つけても強く言えず、無視されることもあり、その結果「開発者へのフィードバックができていない」につながりました。このようにヒアリングで、客観データや計測では分からない隙間を埋めていきます。
要素精査では、問題や課題の粒度を合わせたり、漏れや重複がないか確認したりしていきます。今回の例では、ヒアリングの結果、「効果的なテストができていない」は「テストに抜け漏れが発生している」の言い直しであることが分かったので、2つを統合しました。
事実確認・要素精査をした結果は、図5のようになりました。
STEP 3: 問題分析・構造化
STEP 3では、STEP 1とSTEP 2で抽出した課題と問題を連結・構造化していきます。ここで役立つのが、「新QC七つ道具」の「連関図」と「系統図」です（SaPIDでは、構造化に「連関図」は使用していますが「系統図」は使用していません）。
「連関図」は、「原因」と「結果」の関係を論理的につないでいき、問題を解明する方法です。問題の構図をつかむのに適しています。その特徴から、複数人で議論したり全体像を把握したりするには向いていますが、情報を整理するのには向いていません。「系統図」は、問題を徐々に詳細化しながら展開し、課題解決の方策を考案する方法です。問題を整理したり抜け漏れをチェックしたりするのに適しています。その特徴から、情報を整理するには向いていますが、複数人で議論したり全体像を把握したりするのには向いていません。
流れとしては「連関図」を使って問題の全体像をつかみます。可能なら、作成した「連関図」を、関係者と議論して内容をリファイン（洗練化）します。次に、「系統図」を使って、情報を整理して抜け漏れをチェックします。情報が整理されているので、スポンサーやステークホルダーへの報告は「系統図」を使用するのが良いと考えます。
「連関図」の例を図6に示します。「連関図」を作成する時は、テストプロセス改善のきっかけになった「市場バグが多発している」を起点にします（黄色の網掛け）。
次に、「市場バグが多発している」ことが原因で、「顧客クレームが多発している」「残業や休日出勤が多い」という結果になっているので、それらを矢印でつなぎます。「残業や休日出勤が多い」ことが原因で、「プロジェクトが赤字である」「モチベーションが低い」という結果になります。このようにして、次々に原因と結果の関係で連結していきます。
連結していくと、これ以上連結が難しい状況になることがあります。その場合は、起点にこだわらず、連結しやすい箇所がないか確認し、連結しやすい要素同士を連結します。また、原因と結果が結びつきそうなのに、論理が飛躍していると感じる時があります。その場合は、要素が足りない可能性があります。本例で言うと、「開発者へのフィードバックができない」の原因として、「開発者と対等な立場を築けていない」と「フィードバックの機会がない」という2つの要素を追加しました（紫字の要素）。
課題や問題を構造化できたら、対処すべき問題の核を決定します。問題の核は、そこが解決すると全体が波及的に改善される部分を選びます。多くの原因になっている部分（矢印が多く出ているところ）や原因の大元（矢印が出るだけで入ってこない要因）を問題の核として選ぶ場合が多いです。本例（図6）で言うと、青色で網掛けしている「テストプロセスが存在していない」「テスト知識やスキルが不足している」「ツールがきちんと適用されていない」の3つを選びました。
第2回（「テスト作業が増加する」を低減するヒントの章）で述べた通り、問題の核は3～5個を目安とします。この点は重要です。というのも、問題が見えてくるとあれもこれも解決したくなり、6個以上選びがちだからです。ここで、もう1つ参考資料を紹介します。
デミング博士のセミナー助手を勤め、米国連邦政府などにコンサルタントをしたカリフォルニア州立大学名誉教授の吉田耕作博士の著書『経営のための 直感的統計学』です。吉田博士も、以下のように、「吉田の片手の法則」として、問題を5つに集中することを強調しています。
戦略とは何が何より大事か、何が何より効果があるか、等に関して優先順位をつけ、その順序に応じて精力を集中することである。従って、パレート図では上位5つだけの項目を挙げ、そこに精力を集中する。そして6位以下は「その他」としてまとめて挙げる。上位5つの内1つが解決されると第6位の項目が上位5つに入ってくる。これを吉田の片手の法則という。
出典：経営のための 直感的統計学（吉田耕作, 日経BP） P25
「連関図」作成のコツとしては、あまり悩みすぎずに、取りあえず作ってみることです。作ってから、それをたたき台にして見直したり、皆で議論したりしてリファインしていきます。また、仮説思考で述べましたが、完璧を目指しすぎないことです。時間も限られていますし、やってみないと分からないこともあるので、ある程度の納得感が出たところで次に進みましょう。
次は、「系統図」の例を図7に示します。「系統図」もテストプロセス改善のきっかけである「市場バグが多発している」を起点に展開していきます。基本的には、「連関図」の通りに展開していくことになりますが、そのまま展開すると各階層の粒度がそろわない時があります。
その場合は、要素をまとめたり省略したりします。また、「連関図」作成段階で、抜け漏れに気づくときもあるので、必要に応じて要素を追加してください。「系統図」では、最終的に課題解決の方策を考案するので、問題の核の部分で展開をやめます。いくつか要素が余ることもありますが、無理に含めようとしないで大丈夫です。「系統図」までできたら「現状把握」の3STEPは完了です。
「現状把握」ができたので、「あるべき姿」に移ります。「あるべき姿」は、テストプロセス改善のゴールでもある「市場バグが少ない状態」です。そのために、システムテストがしっかり実施されている必要があります。ただし、この「あるべき姿」は、方向性は示されますが具体性に欠けるため、スポンサーやステークホルダーの理解を得るのが難しい場合があります。
よって、「あるべき姿」のゴールは、なるべくSMART基準という基準を満たしているようにしましょう。SMART基準は、S（Specific：具体的）、M（Measurable：測定可能）、A（Achiveble：達成可能）、R（Realistic：現実的な）、T（Time-Related：期限のある）の5つからなります。
ここで問題になるのは、市場バグが少ない状況とは具体的に何件に設定すれば良いかということです。もちろんゼロになるのが理想でしょうが、年間93件もバグを出している企業が最初に目指すゴールとしては非現実的すぎます。ここで参考になるのが、元IBMでソフトウェア開発の定量化手法の専門家であるCapers Jones氏が、ソフトウェアテスト技術者向けイベント「JaSST '08 Tokyo」の基調講演で話した内容です。
Jones氏は講演の中で、「調査の結果、点検をおろそかにしている企業では、不具合を発見できる確率が30～50％である。それに対し、適切に点検をしている企業ではこの値が70～90％にまで上がる。さらに、CMMI（能力成熟度モデル統合：Capability Maturity Model Integration）などの開発プロセスを評価するガイドラインを導入し、きちんとテストをする企業では最高で99.99％にまでなる」と述べています （出典：日経xTECH）。
今回は、Jones氏の調査結果を活用して、SMART基準のゴールを設定します。XYZソフトウェア社は、市場バグが多発している状況なので、点検（テスト）をおろそかにしている企業に分類されるでしょう。さらに、年間93件と非常に多い水準なので、協議の結果、最低の30%しか不具合（バグ）を検出していないと推定しました。ここから適切に点検（テスト）している企業になり、バグ検出率が70～90%になることを目指します。
具体的には、93件が30%のバグを取り除いた後のバグ数なので、0.7で割ると、元々の全体バグ数の推定値133件が得られます（93件が30％取り除いた後の数値なので、93件の割合は100％－30％＝70％になります。つまり、93件は70％なので、0.7で割れば、30％を取り除く前の数値を得られます）。そこから、70～90%のバグを取り除くと13〜40件になります。
XYZソフトウェア社では翌年も同程度の開発を予定しているので、13～40件／年のバグ数が目標になります。幅があると分かりにくいので、ここでは、最低限の目標を40件／年、通常の目標を27件／年（13～40の平均値）、努力目標を13件／年と、3つの目標を設定することにしました。これで、「あるべき姿」のSMART基準のゴールの設定ができました。
勧告の策定
診断工程の2つ目は、「勧告の策定」です。「勧告の策定」では、これまでの情報を整理して、ハイレベルの提案書（勧告）を作成します。提案書には、問題分析に対する方策やハイレベルのタイムラインを含めます。提案書は、テストプロセス改善のスポンサー（場合によってはステークホルダー）に提案し、承認を得る必要があります。筆者は、提案内容を図8のように1枚にまとめ、詳細内容は付録にすることが多いです。
今回は、「一刻も早く市場バグを削減する」というゴールがあるので、一からプロセスを作っている暇はありません。そこで、コンテンツベースドモデルであるバルテスのテストプロセス「QUINTEE」をカスタマイズして適用します。
また、テスト人材を育成するのにも時間がかかるので、訓練および経験を積んでいる弊社のテストエンジニアをアサインします。XYZソフトウェア社のテスト担当者には、業務知識のレクチャーおよび成果物のレビューをしてもらいます。ツールには、バグトラッキングツールのRedmineを活用します。それらの準備を1カ月で完了させ、1週間のPoC（Proof of Concept：試験実施）期間を経て、本番運用に入ります。その後は四半期ごとに振り返りを実施し、リファインしていく計画としました。
以上で診断工程の全てのプログラムは終了です。筆者は、この診断工程がテストプロセス改善の肝であると考えています。ここまで、具体例を用いて詳細に解説しました。読者が実際にテストプロセスを改善するときに、各図表の内容を参考にしていただければと思います。
