この記事は、ソフトウェアテストの小ネタ Advent Calendar 2022 17 日目の記事です。
自己紹介
初めまして。
私は、テスト業界歴３年目のテストマネージャです。
前職は、某メジャーレーベルに所属していた無名バンドのフロントマンでした。
自分勝手なんですが、安定した将来が欲しくなりバンドを解散し、３年前にご縁がありテスト業界に飛び込みました。
業界歴が浅く、日々わからないことが沢山ありますが、この業界がとても楽しく日々奮闘しています！
はじめに
今回は「元ミュージシャンが転職しODC分析を活用してみた件」というタイトルで記事を書きます。
元ミュージシャンとタイトルで記述していますが、この記事では、業界歴が浅い私がODC分析を使いプロジェクトの課題を抽出し、改善を進めている話をします。
また、それによって得られた副次効果についても話をします。
ほんの少しでも同じような境遇の方のお力になれれば嬉しいです。
また、ODC分析の有識者の方で、もし私が書いていることに間違いやアドバイスなどあればいただけますと大変嬉しいです。
ここでお話しする内容は、杉崎眞弘・佐々木方規 著 「ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する」を読み実践した内容を記述します。
参照： ソフトウェア不具合改善手法 ODC分析
1. ODC分析とは
ソフトウェア品質体系ガイド P.224 より抜粋
https://amzn.asia/d/5MeTJtOODC（直行欠陥分類：Orthogonal Defect Classification）とは、障害の含有要素を分類し分析することにより、そこから示唆される障害混入要因をプロセス改善に結びつける手法である。
【目的】開発プロセスの持つ期待と現状のギャップを可視化し、そこから示唆される改善を行うことにより、今後予想される障害の混在化を「抑制」できるようにする。
ODC分析では、プロセスシグネチャーという核心となるものがあります。
プロセスシグネチャーでは、そのプロジェクトの"プロセスの期待"と"プロセスの現状"を比較した際の差から、問題を見つけていきます。
プロセスシグネチャーについて（動画 11:35 から）
2. 前提
私が所属しているチームは、 開発部署とは異なる独立したテストチームです。
私が担当しているプロジェクトでは、特にテストチームのみ関係者との分断が生まれていた状況でした。
そのプロジェクトのテスト環境はネイティブアプリです。
3名程度のプランナーと十数名の開発者(フロントエンド・バックエンド込み)、十数名のテスターからなるプロジェクトです。
案件の規模にもよりますが、一連のプロセスはざっくりですが、添付イメージのように進行します。テストの周期は２週間に１プロジェクトのテストを実施しています。
3. ODC分析を導入した背景
当時、私が担当しているプロジェクトで以下の問題に悩んでいました。
- 新規機能実装時、私たちが担当するシステムテスト開始時に、テスト対象の主要機能が使えず、テストが止まることがあった
- 検出される不具合が多いことから、テスト期間の延長を行うことも多かった
- 中でも振る舞いに関わる不具合が多かった
- 市場不具合の件数が増加傾向にあった
振る舞いに関わる不具合が多かったことから、単純に各テストレベルの質が悪いのか、要件を決める段階で不具合が混入しているのかがわかりませんでした。
開発プロセスの質や、その不具合の要因などを定量的に数値として出せる方法がないかを探していました。
そんな時に出会ったのが ODC分析になります。
4. ODC分析の取り入れ方
私が担当しているプロジェクトでは、"ODC分析とは"の項目で説明したプロセスシグネチャーを用いて、予測を立てたり、プロセス固有の質の可視化についてはできていません。
理由は、各プロセスで発生した欠陥についてはチケット管理を行っておらず、数値化するための手段が現状ないことや、
そのプロセスを導入することでの費用対効果が未知数だったため、私たちが行える範囲内でできることをまずは取り入れようと決めたためです。
ですが、私たちが担当しているシステムテスト領域で登録された不具合のみを対象としても、ODC分析の部分的な利用でも効果を出せるかもと考えました。その理由は、以下のような方法が存在するからです。
- どの工程で検出されることが期待されているか（欠陥のパターン例を元にした分析の考え方[*1]）
- 不具合が、要件などの"漏れ"によって発生しているか、または"誤り"によって発生しているかを表すタグ[*2]
- その他 ODC 分析で存在している属性を用いた分析[*3]
私自身、未経験で何もわからないため、正直今でもODC分析を正しく利用できているか分かりません。
ただ、私は、ODC分析を正しく使うことが目的ではなく、課題を見つけ解決することが目的でした。
そのため、（紆余曲折ありましたが）振り返り時に、「こういった結果があるんですけど、悩みとか、より良く開発プロセスを進めるために改善したいことなど何かありますか？」のようなことを訊ね、課題と感じていることなどを全員で考えられるきっかけを作り、そして、課題解決を行う体制を作れると感じました。
*1：欠陥のパターン例を元にした分析の考え方
*2：不具合タイプが漏れなのか、誤りなのかを示唆するタグ（Missing/Incorrect）
*3：その他 ODC 分析で存在している属性を用いた分析
同じような機能に関する修正によって、ソースの状態の中の書き直しというタグが誤りとして登録される場合に、内部品質からリファクタリングしたいという希望がないかを確認するなどを行うなど、ODC分析の属性から得られるヒントがありそうだと思いました。
5. ODC 分析を取り入れて
分析結果から気になったことをこちらでまとめた上で、実際どうなのかとそれに対して困ったことがなかったかなどヒアリングを通して、解決案を考えていくような流れで利用しています。
具体的には、以下のような結果からヒアリングを通して、対策案を考えていくような流れです。
地道ですが、対策を行うことで、以下のような結果になりました。
- システムテスト領域登録されている不具合の件数自体は、以前に比べ30~40%は削減している（同じようなプロジェクト同士の比較ができていないので感覚値も含まれます）
- テスト期間延長の回数の削減
また、以下のような副次効果も出て、以前よりは良い状態が生まれていると感じています。
- 関係者で振り返りを行うサイクルも生まれ、プロジェクトの課題改善の時間が増えた
- 関係者それぞれの悩みなどを全員が気づくことで、コラボレーションが産まれるようになった（例えば、テストチームのテスト容易性を高めるために開発者がデバッグを開発してもらったり、モックではなく実データが必要な場合はテストチームがテストデータを用意するなど）
- 改善に向けてチャレンジを行える環境（実例マッピングの導入や開発者に協力いただく上でのノーコーディングの自動テストツールの導入など）
- リファクタリングの相談、リグレッションテストの対応の関係性の構築
私は、副次効果が生まれたことによって、今の結果に結びついたのだと感じています。
副次効果が生まれた理由は、振り返りの材料が感覚値や記憶ではなく、定量的に出されたデータをもとにしているからだと感じており、そういった意味でもODC分析を利用できて良かったなと感じています。
ODC分析を取り入れる際の注意点
私が取り入れている範囲でも、このODC分析を取り入れる際に注意が必要だと感じた点が以下になります。
- 登録された不具合を基に定量的なデータが出ることで他者はその数値を信頼しバイアスがかかることが多いため、使い方を誤ると全く改善に繋げられない場合がある
- 特定のデータのみを見て「誰」に対する課題の解決を促すと、特定の人に対しタスクが増えるため、その後なかなか進まない
また、私の失敗体験ですが、振り返りに利用するという方法を取るまでには色々と失敗してきました。
定量的にでた結果から示唆される問題を伝えて終わり、改善はそれぞれ担当の方に依頼するといったことをしていました。
（例えば、単体テストでの不具合が多く発生しているようです、ここの改善をお願いします的なことです）
なぜできないのか、どういったことが理由で今のような状態にあるのか、ここを全く考えていませんでした。
関係者の皆さんをリスペクトしていたものの、発生した原因は誰かにあるというバイアスがかかっていたと思います。
なのでそれだと改善まで至らず、私自身の信頼も落ちるような行動をとっていたと今振り返って痛感してます。
6. まとめ
まだまだ、課題はあり、改善の最中ではあります。
ですが、業界未経験での入社で右も左もわからない状態で、ただ、目の前のことに一生懸命に向き合うと、色々と経験ができると言うことがわかりました。
私は、今回ODC分析取り入れることで、以下のことを学びました。
- 行動すると、現況が変わる、逆に、行動しないと、現況は変わらない
- 貢献したいという求心力が自身の成長サイクルを回す
ODC分析を導入することで、本来気づけなかった関係者の悩みやそれぞれが感じている課題を知ることができました。
そして、その課題が個人のものではなく、プロジェクトやプロダクトの課題となる、このODC分析の取り組みを行ってよかったと振り返っても思います。