テスト工程で品質分析を行う際、テスト密度やバグ密度といった品質指標を活用している現場は多いのではないでしょうか。
大手SIerなどでは過去の実績データをもとにした品質指標の数値を持っており、今開発している案件の数値と比較することで品質に問題がないかどうかを判断することが多いです。
しかし、新規のSoE（Systems of Engagement）開発となると話は別です。「意味がない」「数字合わせをしているだけ」という批判的な声を聞くことも多いと思います。
実は、この品質分析手法が機能するかどうかは、プロジェクトの性質によって大きく変わります。では、どのような場合に有効で、どのような場合に機能しないのか。そして、新規開発では何を重視すべきなのか。現場で実践すべきアプローチを考えていきます。
過去実績データを活用した品質分析のアプローチ
テスト密度やバグ密度を使った品質分析は、大規模保守開発や基幹システムリプレイス、マルチベンダーの開発案件など、様々な現場で実施されているのを目にします。
このアプローチの基本的な考え方は、IPA（独立行政法人 情報処理推進機構）や自社の過去の開発実績から導き出した指標値と、現在進行中の案件で算出されるデータを比較し、問題を洗い出すことです。大手SIerなど、多様な種類のシステム開発案件の実績がある企業では、会社ごとの標準値を定めています。開発中の案件の数値がこの標準値から大きく外れていれば、特異的な品質問題を抱えている可能性があると判断できます。
特に効果を発揮するのが、保守フェーズにおける開発です。システム開発手法や開発言語、利用サービス、体制などが大きく変化しない環境では、保守における案件ごとに品質指標を比較分析することで、ある程度正確な特異値を見つけることができます。環境が安定しているからこそ、過去データとの比較が意味を持つのです。
新規開発で過去実績ベースの分析が機能しない理由
しかし、新規開発の現場では、この手法が品質向上に寄与しづらいという現実があります。
最も大きな問題は、前提条件が大きく異なることです。新規開発では、開発手法、開発言語、利用サービス、体制のすべてが、その案件のために一から検討・選定され構築されます。これらの要素がほぼ同じ前提の開発実績があれば当然意味はありますが、システム開発の現場はプロジェクト型で体制が構築される上に、新しいクラウドサービスやフレームワークがどんどん登場している昨今、同じような前提で行われる開発はほとんどありません。
そして、この前提の違いが数字合わせという問題を引き起こします。各密度を計算する分母となるSLOC（Source Lines of Code：ソースコード行数）の算出方法一つとっても、プロジェクトによって解釈が異なります。何を1行としてカウントするのか、コメント行を含めるのか、自動生成コードをどう扱うのか。これらの基準が統一されていなければ、比較自体に意味がなくなります。
さらに、形式的な分析に陥りやすいという問題もあります。「過去実績の上限値に収まっているから問題ない」という判断で終わってしまい、実際の不具合の内容や傾向を深く分析する機会を逃してしまうのです。指標値との比較に時間を費やす一方で、本来注力すべき「他に同様の問題は潜んでいないか」という視点が薄れてしまいます。
結局のところ、新規開発において過去実績ベースの品質分析を中心に据えると、数字を合わせることが目的化してしまい、品質向上という本来の目的を見失いがちになるのです。
新規SoE開発で実践すべき品質分析の方針
では、新規のSoE開発において、どのような品質分析のアプローチを取るべきでしょうか。
まず、SoE案件の特徴を理解する必要があります。SoE開発では、限られた予算の中で、できるだけ早く、ある程度の品質でまずリリースしたいというニーズが強いのが特徴です。つまり、問題なく利用されるレベルでいったんリリースし、そこからサービスを育てて行くのです。
このような前提において、私が推奨する方針は以下の3つです。
第一に、別案件の情報に基づく指標値での品質分析はしないことです。前述の通り、新規開発では前提条件が大きく異なるため、過去データとの比較は意味を持ちません。むしろ、その案件固有の品質傾向を見極めることに集中すべきです。
第二に、発生不具合をゼロにするよう対応することです。つまり、バグ消化を最優先にします。指標値との比較よりも、目の前にある不具合を確実に潰していくことが、SoE案件では品質向上への最短ルートです。
第三に、1件ずつ不具合を確認し、その内容をもとに横展開要否を個別に考えることです。これが最も重要なポイントです。各不具合から「同様の問題が他にも潜んでいないか」を考え、必要に応じて横展開することで、バグそのものから全体的な品質向上につなげることができます。
この方針を実現するために、バグチケット管理と体制面で重要なポイントが2つあります。
バグチケット管理では、バグ種別の分類はしっかり行うが、それ以上の分類までは行わないことです。もちろん、混入工程やすり抜け工程、それぞれの原因を記録することに意味がないとは言いませんが、バグチケット起票者がそれぞれを記載すると、どうしてもブレが発生して適切な分類ができないことが多いのです。そして、それらを入力するのに時間がかかり進捗に影響したり、入力してもらったとしても内容の確認に時間を要し、分析のための分析をすることに多くの工数を取られてしまいます。そうならないためにも、バグ種別の分類だけはしっかりやるという方針が効果的です。
体制面では、バグ分析専任担当を1名決めることです。そして、この1名であることが極めて重要です。この分析担当者は、全ての不具合とそのバグ種別を確認し、1件ずつ不具合の横展開が必要なのかを検討します。
1人で担当するからこそ、テスト序盤は「個別の事象だから横展開不要」と思っていた不具合も、徐々に似たケースがあったなと鼻が利くようになり、横展開の精度が上がってきます。複数人で分担すると、この感覚を養うことができません。
もちろん、この担当者の役割は大きなものですので、専任にしてあげることがとても大事です。そして、その担当が分析した1件ずつの横展開の考え方・観点をPMはしっかりレビューし認識合わせすることで、担当者の横展開の観点をコントロールしてあげることが重要です。
このように、横展開観点がしっかり管理されていれば、後続工程でバグが発生したとしても、観点レベルの抜け漏れかどうかを判断することでアクションもしやすくなります。そして、バグ分析から全体的な品質向上に寄与することができるのです。
実践する際に忘れてはいけない注意点
このアプローチを実践する上で、いくつか重要な注意点があります。
まず、発生するバグが多すぎる場合は、この手法はそもそも成立しません。1人では見切れないレベルの品質問題を抱えている場合、分析の前に全体としての品質向上施策を検討する必要があります。例えば、設計プロセスの見直しや、開発チームへの技術教育など、根本的な対策が先決です。
次に、バグ分析担当者の選定が極めて重要です。ある程度システム開発経験がある人でないと、この役割は意味を成しません。ただバグ分類を集計して多い少ないを報告するようなメンバーをアサインすると、横展開の観点が具体的にならないため効果が出ません。SEの経験があり、設計工程のレビュー経験がある方などが適任です。技術的な背景を理解し、「このバグはNULL・空白のハンドリングミスであるあるだ。他にもありそう」「この実装ミスは他のモジュールでも起こりうる」といった洞察ができる人材が必要です。
最後に、PMレビューは各論に入りすぎないことが大事です。PMは不具合事象や原因を細かく掘り下げるようなレビューではなく、分析担当者が報告する横展開の要否の判断軸と範囲にばらつきがないかを確認することに徹するべきだと思っています。
特にSE出身のPMの場合、経験があるがあまり、不具合事象や混入原因に必要以上に興味を持ってしまったり、経験ベースの（思い付きの）横展開を指示してしまうことも少なくありません。あるプロジェクトで、特殊文字の入力バリデーションの不具合が発見されたときに、有識者の人がその話を聞いて、色々気になってしまったようで、担当者に実装方法やアーキテクチャについて質問したり、なぜか権限周りを再度チェックするようにと指示したりと、思い付きベースの質問・指示をしているのを見かけました。私はこのシーンをみて、担当者がこの質問・指示に時間がとられて、本来行うべき分析が行えないのではないかと危惧を抱きました。必要最低限の指示は問題ありませんが、分析する軸を明確にし、分析担当者が工程を通じて、一貫性をもって、品質分析することの方が全体としての品質はあがると考えています。また、仮に後続工程で問題が発生した場合も、前の工程の品質分析の軸が明確なので、ここまでは大丈夫なはず、と、その問題の範囲や対応を局所的にすることができます。
案件の性質に合わせた品質分析を
テスト密度やバグ密度を使った品質分析は、保守案件のように開発をする前提が一定である現場では有効な手法です。過去実績との比較により、特異的な品質問題を早期に検知できます。
しかし、新規のSoE開発では、前提条件が大きく異なるため、この手法は数字合わせに終わってしまいがちです。これらの案件では、別案件の指標値に頼るのではなく、発生した不具合を1件ずつ分析し、横展開要否を個別に判断することが重要です。そのために、バグ種別の分類に絞ったチケット管理と、専任のバグ分析担当者1名を配置する体制が効果的です。
ただし、何でもかんでもこのアプローチが正解というわけではありません。バグが多すぎる場合は根本的な品質向上施策が必要ですし、分析担当者には一定の技術力が求められます。
完璧な正解はありませんが、どうしたら品質が向上するのか、そのために何をするべきかを、前例や慣習にとらわれずに考えて、実行することこそが、真の品質向上につながるのです。
