パレート分析とは
パレート分析を活用すると、問題を分類し、数値化することで、対策をすることで大きな効果が見込めるポイントを見つけることができます。軽めの工数で分析が完了するので、比較的扱いやすい方法です。
パレート図の作り方
パレート図の作り方自体は、Excelでの動画なども豊富に公開されていますので、簡単にご紹介します。なお、パレート図を作るために、BTSなどで不具合が管理されており、不具合の記録が残っていることが、始めるにあたっての最低限の条件になります。
分類項目の作り方
分析項目は、製品の特性から考えて作るのがよいでしょう。たとえば、オンプレで運用している場合と、SaaSで運用している場合とでは、インフラなどで見るポイントが変わります。Webアプリのみを対象にする場合も、また問題の傾向が変わってきます。ですので、自社製品の特長や、洗い出したい課題などを挙げるとよいでしょう。
参考までに、私がつかっている指標としては、以下のものになります。
1. Function (機能)
2. Spec (仕様)
3. Privacy Breaches (プライバシー違反)
4. Performance
5. Combination (組み合わせ)
6. Temporal Issues (時間的問題)
7. Data (データ)
8. Environment (環境)
9. External Factors (外部要因)
10. Cosmetics (見た目)
実際に振り分けを行う際には、分類の判断には一定の熟練度が求められます。また、開発に深く関与しているメンバーが担当することで、本当の原因を把握しやすくなり、正確な状況を反映できるでしょう。
グラフの書き方
では、分析に使うパレート図の作り方です。
パレート図は、棒グラフと折れ線グラフを使います。
棒グラフの書き方
左側に、一番問題の多い棒をもってきて、右に行くにしたがって少ない問題を順番に並べます。
折れ線グラフ（積み上げグラフ）の書き方
これは、棒グラフを積み上げた数字を書いていきます。最後は、不具合の全数になります。
分類が終わって、件数を数字にし、グラフを書くと、この形になります。
パレート図で何がわかるか
こうしてできたパレート図をつかって、分析を進めていきます。
私の経験からいうと、概ねの企業で、３割ほどが上流工程の問題、４割～６割が組み合わせの問題、残りはそれ以外で、経営戦略に関わるものだったり、単純な実装ミスだったりです。面白いのが、同じ会社においては、違う部署であってもこの割合がだいたい同じになる傾向があります。会社の文化が品質に影響を与えている例でしょうか。
もちろん、この上流の問題は、単純にエンジニアリングだけの問題ではなく、複合的な要因があることが多いので（予算がなくて適切な設備が買えない、など）、深堀する際には、魚の骨を使ったり、プロセス改善を行うなど、次の手を打つ必要があります。
ここで注意が必要なのは、単純に製品や環境が違う場合、数字だけを比べても分析はできない、という点です。なぜなら、「テストは条件しだい」とも言われるように、製品の開発難易度やエンジニアの習熟度、リソース、いろいろな要素がプロジェクト開発には絡んでくるものであり、一様ではないからです。最低限、同じ指標を使って、一定の傾向を分析していくことになります。このため、私が行う場合は、単純に数字だけを見るのではなく、問題全数に対する割合も、参考にしています。
パレート分析の頻度
パレート分析の頻度は、３か月から半年ぐらいがよいでしょう。また、問題に対策することで数字の割合が減ったら、（問題が減ったと実感できたら）分類項目を見直しすることも必要になってくるでしょう。
まとめ
パレート分析は、開発体制の、「健康診断」とも言えます。なかなか品質を数字化するのは難しいですが、これは数字化できるのと、傾向が量で見られるので説明がしやすいです。また、分析に多大な時間を要しないため、軽く始めやすいのも特徴です。
用語解説
BTS
よく、アーティストと間違われやすいのですが、「バグ・トラッキング・システム」の略で、不具合を登録し、修正状況などが追跡できるようになったものです。
魚の骨
イシカワダイアグラム、フィッシュボーンチャートなど、いろいろな呼び方がありますが、魚の形のモデリングをすることで、因果関係を明白にしたり、作りたいもののゴールシークなどを行ったりします。