はじめに
はじめまして！食べログシステム本部 品質管理室にて飲食店QCチームのマネージャーをしております、木川広基と申します。
今回は2022年6月にローンチし、現在着々と導入範囲を広げている食べログオーダーの開発チームにおいてチャレンジ中である品質改善指標の数値化と、それを用いての改善活動の歩みについてお伝えできればと思います。
目次
背景
食べログオーダーはローンチから約1年半を迎えた現在、プロダクトとして急成長を目掛けるフェーズへ突入しています。
これまではプロダクトとしての地盤を固めるべく、ローンチ初期から導入頂きパートナーシップを持ってご意見をいただける数店舗様と連携し、
飲食店の業務オペレーションにおいて汎用的に必須となるような機能を揃え、その安定的な運用と良質なUXの提供を実現してまいりました。
今後はより多くの店舗様に導入していただけるよう、多様な規模・業態の店舗様のニーズに対応したプロダクトを目指し、高品質を維持しつつ、爆速で機能エンハンスを進めていきたいフェーズが現在地点であると捉えています。
上記の実現の為、我々品質管理室としては、不具合の改修にかける工数を出来る限り抑えることで、
開発エンジニアが新たな機能開発を推し進める為の工数を最大化していきたいと考えています。
その為にも、シフトレフトの活動を加速させ、不具合の芽を検知可能な最上流で摘み取っていける仕組みづくりを目指しております。
不具合を起因とした手戻りのコストを最小化することの効果と、それに向けた食べログオーダーの取り組みについては、こちらの記事をご参照いただけますと幸いです。
→プロジェクト品質革新の鍵！『不具合分析』で開発プロセスを改革
今回の「品質改善指標のスコア化」につきましては、上述の取り組みを推進することで、どれだけ修正開発案件率を下げ、新たな機能開発に投入できる開発工数の増加に寄与できたのかを可視化することを目的としています。
案件スコアとは
案件スコアは「案件規模」と「案件の複雑度」を各3段階で表し、それを掛け合わせた数字を指します。
これにより各案件毎に「開発の重み」が１〜９までの値で示されることになります。
複数の因子を掛け合わせることでスコア化をする方式については、リスクベーステストの考え方から着想を得ています。
先述の図の赤枠内「QAとして」で示している、"リスクの見える化"という文脈において、リスクを因数分解することでより各案件の性質が見えやすくなると考えました。
※参考：リスクベーステストの実践的アプローチ
案件スコアは食べログ品質管理室にて定義している品質改善フレームワークの一部として組み込んでおり、不具合検出数及びQA工数見積もりに対し影響を与えます。
※品質改善フレームワークの詳細につきましては「JaSST'24 Tokyo」にて発表しております。下記発表資料ををご参照いただけますと幸いです。
→【JaSST'24 Tokyo】テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却
案件スコアで実現できること
不具合の発生傾向を分析する際に案件スコアごとにカテゴライズして品質評価を実施することにより、異なる性質を持つ案件同士の比較や、複数案件をサマリした傾向分析を同一指標の元で行なうことが可能になります。
例えば、前月の不具合検出数が100件、当月の不具合検出数が70件の場合であった場合、見かけの不具合数は減っているものの対応した案件の性質(規模感や開発難度)が異なる為、全体傾向の分析からは"品質レベルとしてはどちらがよかったか"の判断は悩ましいものになります。
この場合、「全体傾向としては不具合検出数は30%減だが、案件スコアが大きな重要案件においては重篤なバグが先月比120%検出できているから、シフトレフトとテスト強化の施策は効いていそうだね」という結論が、簡易的且つある程度納得感のあるものとして導くことができると考えております。
案件スコアを決める際の留意点
スコア付けの際の留意点としては、下記２つです。
スコアが正確なものであるかという部分には必要以上に拘らず、
時間をかけずに「ある程度妥当性のあるスコア」をつけていくことがポイントです。
スピーディに適当な数字を案件につけていくために「案件同士の相対比較」「複数担当者間での合意形成」を用いる工夫については、アジャイル開発における見積もり手法であるプランニングポーカーに倣っています。見積もりとは異なり、原則的に既に開発完了したものに対して付与していくものになる為、複数担当者間の合意形成についてもスムーズに行なわれています。
案件スコアの利用実例
◆案件スコアをカテゴリ分けし、不具合検出傾向を分析
２０２３年度２Qの状況把握
当該メトリクスの取得を開始した２０２３年７月〜９月までのリリースした案件の総スコアと、
対象案件のQAフェーズにおける不具合の検出数を把握します。
食べログオーダーでは不具合レベルをLv1(表示崩れなどの軽微なものetc.)とLv2(クリティカルな機能不備etc.)に分けて定義している為、こちらの検出内訳も確認します。この時、下記のように案件スコアの大きさとの掛け合わせにて分析を行なうことで案件の性質別に不具合検出傾向を測ることがでできます。
上記のデータを元に、次の四半期で目指す方針を下記のように策定しました。
└案件スコアの大きい重要案件のLv2の不具合検出数を上げていく
→①案件スコアの小さい案件のLv１の軽微なバグは上流にてキャッチアップする仕組みを徹底し、QAフェーズへの漏れ出しを防止
→②QAテストの質を向上することで、重篤な故障につながりやすい案件スコアの大きい重要案件のLv2の不具合検知を精度高く行なうことを目指す
２０２３年度3Qにやったこと
└不具合分析会
└単体テストの運用ルールの徹底
└リスク洗い出し会
取り組みとしては2Qまでと同じ(詳細はこちらを参照)ではあるものの、形骸化させないことをポイントにおきました。プロジェクトメンバ全体で意識して継続することで学び得ることが増え、取り組みの質が上がっていったと感じています。
シフトレフトの活動により軽微な不具合を上流にて効果的に摘み取ることができる為、QAテストにおいてLv1相当の不具合の対応工数(不具合起票・改修確認etc.)を削減することができます。
その工数を、リスクの高い外部システム結合周りのテストを強化することに充当していきます。(単機能で発生しうる不具合は開発フェーズまでで検知し、システム結合起因の不具合はQAが重点的に検知するような役割を目指すイメージです。)
外部システムとの繋ぎ込みが発生する案件は案件スコアが大きく(大規模または複雑に)なり、Lv2相当の重篤な障害が発生しやすい為、当該テストの強化が上述の四半期で目指す方針に寄与すると考えました。
具体的な施策として、QAフェーズとしてはプロダクト利用店舗における業務シナリオに基づいたテスト設計を目指す方針にシフトしました。
業務フローを図化することで実際のユーザーのプロダクト利用シナリオのパターンを可視化し、それをテストベースとしてユースケースシナリオテストのフォーマットに落とし込んでいきます。
モバイルオーダーというプロダクトの特性上、利用中の障害発生はその日の店舗営業をストップさせてしまうリスクを常に抱えています。こちらの取り組みにより、実際の利用店舗の業務オペレーションにおいてクリティカルな障害を未然に防ぐことで「当たり前品質」の死守を目指しました。
どうなったのか
上述の施策前後の比較にあたり、先ずは案件スコアを用いて対応案件の性質を見てみます。
２Qにおいては案件スコアの大きい(即ち規模が大きく、複雑な)案件が多かったのに対し、3Qにおいては比較的案件スコアの小さい(即ち規模が小さく、単純な)案件の開発が多かったことが見受けられます。
上記を前提として、QAフェーズにて検出された不具合数及び傾向を見ていきます。
不具合の総検出数は減少し、Lv2以上の不具合の検出数は増加するかたちとなりました。
総検出数の減少については、案件スコアの低い案件が2Qと比較して多い傾向であったことから、潜在的なバグの数が少なくなった可能性が考えられます。
実際、1案件あたりの不具合検出数を箱ひげ図で見てみると、中央値で4件から4.2件とほぼ横ばいの数字、第三四分位で12件から7.5件と減少していることがわかりました。
では、多く検出されたLv2の不具合については、どのような性質の案件から摘み取ることができたものだったのでしょうか。
以下の図は、案件スコア３以上の案件から検出することのできたLv2の不具合数を箱ひげ図で表したものになります。
案件スコア３以上の案件におけるLv2の不具合検出数が中央値で0件から2件へ、第三四分位で2件から6.5件に増加しています。
これらのことから2Qの施策であったQAテストの強化によって、特に案件スコアの大きな重要な案件で重篤な障害に繋がり得た不具合を摘み取ることができたことの裏付けが得られました。
このように全体の分析からは見えづらい部分を異なる性質の案件ごとにカテゴライズしたうえで相対的に比較することで、品質改善施策の効果をより精度高く分析できることが、案件スコアの魅力であると考えています。
今後の展望
今回、案件を規模と複雑度によってスコアリングすることで、案件の性質ごとにカテゴライズして不具合分析を行うことができるようになりました。これによって不具合レベルだけでなく案件の性質も考慮してシフトレフトのPDCAを回せるようになりました。
案件スコアの次のステップとして、生産性改善への活用を考えています。具体的には、案件スコアの高い案件のLv2不具合を見つけられるようなテストを優先的に自動化することなどが考えられます。
最後に
我々食べログ品質管理室は「テスト」ではなく「品質」を主語とし、開発プロセス全体に対して品質を作り込んでいくことを目指しています。
このようなビジョンに共感いただける仲間を絶賛大募集中です。
ご関心を持っていただけた方は、是非下記採用ページにつきましても是非ご一読いただけますと幸いです。
頼もしい仲間のJoinを、メンバ一同心からお待ちしております！
