PM向けのバグトリアージプロセス
今日の記事は、今月経産省を卒業された、元デジタル化推進マネージャーの稲垣さんに、経産省に残してくださった足跡とその重要性について語っていただきました。
2019年7月より2021年8月までの約2年間、情報プロジェクト室でデジタル化推進マネージャーとして勤務していました稲垣です。
本稿では、携わった開発事業においてプロダクト品質を高めるために導入したプロセスについて、簡単ではありますがこの場を借りて紹介したいと思います。プロジェクトに関わる皆さん（特にPM/PMOポジションの方）にとって、今後の活動の一助になれば幸いです。
経産省で何を導入したか
バグトリアージと呼ばれるプロセスを本格的に導入しました。これは、テストで検出された不具合（厳密にはイシューとの区別がありますが、ここではざっくりとバグと呼ぶことにします）に対して優先度を判断（トリアージ）し、リリースまでに本当に必要な対応だけを行う、という考え方です。
トリアージはもともと医療現場で傷病者の緊急度に応じて治療や搬送の優先度判断に使うもので、医療ドラマでもたまに見かけることがあります（ひと昔前だとコードブルー、最近だとTOKYO_MER〜走る緊急救命室〜とか）。トリアージで大事なことの一つは分類化（仕分け）で、傷病の緊急度に応じて対応優先度を判断して仕分けを行います。
優先度を判断し仕分けする際は以下の4状態でタグ付けし、それぞれに適切な処置を行います。
[タグ]
赤色： 生命の危機に瀕し即時の対応が必要な状態
黄色： 数時間であれば治療を遅らせても悪化しない状態
緑色： 最後に治療を行ったとしても生命や機能に問題ない状態
黒色： 治療を行っても生存の可能性がない状態
これをバグトリアージに置き換えてみると、以下のようになります。
[対応優先度]
P0（即時）： テストブロッカーになるなど即時の対応が必要な状態
P1（必須）： リリースまでに対応が必須な状態
P2（必要）： リリースまでに対応が必要だが、回避策がある状態
P3（任意）： リリースまでには対応しなくて問題ない状態
もちろん、医療トリアージとバグトリアージには分野（扱う領域）や時間軸の捉え方など違いはありますが、時間制約がある中で目の前にある問題に対して明確な判断軸をベースにある程度機械的に対応優先度をつけていく、という部分においては共通であり、これができることで品質コントロールが可能となります。
なぜ必要なのか
品質低下、ひいてはリリース遅延を招くリリースブロッカーの多くが制御不能な事象（イシュー）であり、その原因の一つに潜在的な欠陥（ポテンシャルバグ）があります。そしてテストフェーズでポテンシャルバグを生み出すのは欠陥改修（バグフィックス）です。そこで、バグフィックスを不必要に行わず、バグを適切にコントロールするために有効な手法がバグトリアージです。
もしテストで検知したバグに対してトリアージを行わず、検知した順に一律に改修していくようなやり方だと、想定以上に大量のバグが見つかった場合には計画通りリリースすることは相当困難になります。なぜなら、程度はあれど改修１つ１つには時間がかかる、また改修したことで新たなバグを埋め込んでしまうことから、雪だるま式にコストやリスクが膨れ上がってコントロールできなくなるからです。
なお、開発事業（プロジェクト）のPM/PMOを担っている方で、テストを開発事業者にほぼお任せの場合は、当該プロセスを導入して、テスト期間全般を通じて日に1回でも自身がトリアージすることで、時間や手間はかかりますがテスト終盤に品質コントロール不能な状態に陥るリスクを大幅に低減することができますので、ぜひ検討してみてください。
重要な考え方
まず、バグトリアージを効果的・効率的に行うためには、以下3つの重要な考え方があります。
1. 要件や仕様が明確化されてなければバグではない
2. リリースまでにバグを0にする必要はない
3. できるだけ早くトリアージを始める
1. 要件や仕様が明確化されてなければバグではない
バグ（と思われる動作）に対して「こういう仕様です(ｷﾘｯ」と真顔で言われても、「いやいやこれはバグでしょう」と思ったりするなど、各々の立場や捉え方によって意見の食い違いが起き平行線を辿る、という状況が生まれることがあります。この「ステークホルダー間で認識が取れていないこと」の問題は、暗に「要件や仕様が存在しないこと」を示しており、結果的には「仕様通りでもバグでもない」のです。
バグとは「期待されている動作」と「実際の動作」の差分のことでしかなく、期待されている動作にあたる要件や仕様がない限りはバグとは言えないのです。ちなみに、上流で議論された結論がステークホルダー間で合意されていれば要件や仕様としては成り立つとは言えますが、複雑な要件や仕様があったり、抜け漏れがあったり、また人の記憶は曖昧であったりするので、後から誰もが把握・理解できた上でバグかどうかを容易に評価できるようにドキュメント化されているべきと思います。
2. リリースまでにバグを0にする必要はない
多くの人がリリースするプロダクトの品質に対して完璧（ゼロバグ）を求めがちですが、実は世の中の多くのプロダクトはバグを内包したままリリースしています。これが可能となっているのは、バグがユーザーにとって問題ではないと分かっていることと、バグがコントロールできる管理下にあること、が実現できているからです。
また、リリースまでの時間制約がある中では検知した全てのバグフィックスは難しく、前述の通りバグフィックス自体が新たなポテンシャルバグを生み出すリスクとなります。費用対効果の面から言っても得策ではありません。そこで、前述の対応優先度（P0-P3）を元に対応しなくて良いバグを明らかにし、リリース後にしっかりと時間を確保して対応していく計画を立てれば良いのです。
3. できるだけ早くトリアージを始める
トリアージの開始が遅くなるほどに、リリースまでの残期間が少なくなります。その分だけ対応優先度が高いバグをフィックスする期間が少なくなるというリスクが生じます。できればテスト初日から日次でトリアージする時間枠を確保しておくことをお勧めします。
これら3つを念頭に置いておくと、よりスムーズで実効的なトリアージを行うことができます。
具体的にどうやるのか
まず、バグトリアージ用のチケットボードを用意します（JIRAやBacklog、Redmineなどのチケット駆動型ツールが望ましい）。次に検知したバグが遷移すべきステータスを配置していきます。その際には、テストフェーズに登場するアクター（主にTesterやPM/PMO、Developer）がどのステータスで活動するかを意識しておくと管理しやすくなります。
バグトリアージボードのサンプルと、ステータスに即したアクターの連携図を下図に示しておきます。ボードに作成するチケットはISSUEからスタートし左から右に遷移していき、最終的にはDONEもしくはWON'T FIXのどちらかで完了となります。実際にはもう少し細かいステータスが必要になりますが、ここでは最低限のステータスを記載しておきます。
[ステータス]
ISSUE： テスターが検知したバグをチケットとして新規起票した状態
IN TRIAGE： PM/PMOがチケットをトリアージしている状態
WAITING FIX： トリアージ後、チケットへの対応が必要で待ちの状態
IN FIX： 開発者がチケットを対応（改修）している状態
WAITING TEST： 対応後、チケットへのテストが必要で待ちの状態
IN TEST： テスターがチケットをテストしている状態
DONE： チケットへの対応が完了した状態（FIX）
WON'T FIX： トリアージ後、チケットへの対応が不要で完了した状態
ここで、IN TRIAGE（トリアージ中）で対応優先度を決定する要素には大きく、「ユーザー影響度」と「発生頻度」の2パラメータがあります。そして、これら2つの組み合わせを用いて対応優先度を表現します。
ユーザー影響度： バグによってユーザーが受ける影響の度合い
発生頻度： ユーザーがバグに遭遇する度合い
対応優先度 ＝ ユーザー影響度 ＊ 発生頻度
ユーザー影響度と発生頻度の度合い（P1-P3）を便宜上HighとLowの2つとした上で、x軸を発生頻度、y軸をユーザー影響度として４象限に分けると以下の図のように表すことができます。
例えば、x軸がHighでy軸がHighの場合は、ユーザーへの影響が大きくその発生頻度も高いため、対応優先度は状況に応じてP0（即時）またはP1（必須）となります。このトリアージの結果を受けて、リリースまでに対応すべきバグとして、DONE（FIX）となるまでステータスを進めていきます。
一方で、x軸がLowでy軸がLowの場合は、ユーザーへの影響が小さくその発生頻度も低いため、対応優先度はP3（任意）となります。このトリアージの結果を受けて、リリースまでに対応する必要のないバグとして、WON'T FIXにステータスを移動して完了となります（十分な余裕があるなら対応に回しても良い）。
それ以外で、x軸とy軸の組み合わせがHighとLowで混在する場合は、対応優先度はP1（必須）またはP2（必要）となります。P1の場合は、先述の通りリリースまでに対応すべきバグとして、DONE（FIX）となるまでステータスを進めていきます。P2の場合は、PM/PMOと開発者（テスター）の間で協議し、他の対応優先度高のチケット状況や技術的な対応難易度、運用での回避策の有無などを考慮して、WAITING FIXとするかWON'T FIXとするかを決定します。基本的にはリリース品質を優先し、WON'T FIXにすることをお勧めしますが、その後のリソース体制や対応期間などに余裕がないなどの事情があれば念頭に置いた上で、トリアージの軸を設定してみてください。
本稿でのご紹介はここまでとしますが、バグトリアージ手法の目的は先に述べた通り、ある程度機械的に対応優先度をつけていくことで対応すべきかどうかを素早く判断し、不必要な対応をしないところにあります。そのためには起票するバグチケットの内容を読むだけでトリアージが行えるよう、チケットの情報粒度や項目立てをしっかりと決めておくことも大事です。
さらには、プロダクトのVISION共有やPRD（Product Requirements Document）といったドキュメント、バックログ（ユーザーストーリー）への優先度付け、などを事前に整備しておくことで、トリアージをより効率的・効果的に実施できるようになります。
この辺りは情報プロジェクト室が公開しているプレイブックのテスト章でも一部紹介していますので、興味ある方はぜひ読んでみてください。
最後に
約2年間、情報プロジェクト室の多くの方々と仕事をご一緒させてもらう中で、誰もが仕事に対して真摯に向き合い、様々な問題課題に対しても真っ向から取り組み、解決していく姿を見てきましたし、私自身も助けてもらうことが多々ありました（感謝）。本当に素晴らしいメンバーが揃っていたんだなぁと実感しています（本音）。
それでも目の前の案件やタスクの量は膨大なもので、個人個人で対処し切るのは時間的にもなかなか難しい現実が垣間見えたりしました。これからは今まで以上にワンチームとして仕組み化が必要になってくると思いますので、情報プロジェクト室メンバー、それからプロジェクト関わる皆さんがバグトリアージを導入されて、少しでもお役に立てるプロセスとなれば嬉しい限りです。