こんにちは！飲食店システム開発部オーダーチームで食べログオーダーのWebサービス開発を担当している堀口です。 本記事では、品質改善と不具合対応コストの削減に向けた新たな取り組みについてお伝えします。
はじめに
プロジェクト品質と聞くと、何を思い浮かべますか？製品の品質だけを示すものと考えがちですが、実はそれだけではありません。開発プロセスの効率性、リリースのスムーズさ、チーム間のコミュニケーション、そして最終的な製品の品質。これら全てが、プロジェクト品質というひとつの大きな概念を形成します。その品質を更に向上させるための重要な手段、それが「不具合分析」なのです。
目次
なぜ「不具合分析」が必要なのか
品質改善と聞くと、一見すると大がかりな作業を想像するかもしれません。しかし、その根底にあるのは、皆が日々の業務の中で「自分の仕事で何が問題点で、どう改善すればよいのか」を深く考えることから始まります。そのためには、具体的な事例として目の前にある不具合を深堀りし、その中から見えてくる品質課題を分析することが重要です。
不具合対応コスト最小化と手戻りコストの法則
不具合対応コストを削減することは、資金面だけでなく、作業時間や精神的な負担を減らす重要な戦略です。不具合はその発生源が上流にあるほど、修正に必要なコスト（時間や労力）は少なくて済むためです。それゆえ、不具合対応コストを最小限に抑えることで、よりクリエイティブな仕事や、ユーザーに喜ばれる品質向上に注力できる環境が整うのです。
この戦略の中心には、「手戻りコストの法則」という考え方が存在します。これは、プロジェクトが進行するにつれて不具合の修正コストが急増するという一般的によく知られた法則です。初期の設計段階で発見・修正した不具合のコストと比較して、製品が完成してから発見・修正する不具合のコストは何十倍も高くなることが示されています。これは、製品完成後の修正にはテスト作業の再実施、ドキュメンテーションの更新、ユーザーサポート、修正版のリリースなど、多大な時間と労力が必要となるためです。だからこそ、不具合を早期に発見し、速やかに修正することで、不具合対応コストを最小限に抑えることが可能になります。
不具合検知〜分析・振り返りまでの流れ
では食べログオーダーで実行している不具合分析のスキームをご紹介させて頂きます。
不具合検知とチケット対応
開発完了後の結合テストのフェーズ以降で不具合が検出されたら、管理ツールに不具合チケットを登録していきます。
チケットには、システムの種別、バグレベル、不具合原因、検出すべきフェーズ、といった分析に用いるフィールドを用意します。
ここでは不具合原因にフォーカスして具体例を記載します。
- 不具合原因の例
- 要件定義での考慮漏れ
- 仕様書の記載ミス
- 実装の漏れ
- 影響範囲の考慮漏れ
- プログラミング誤り
- 外部要因
- 環境構築ミス
- その他
このフィールドはエンジニアが記載します。
各フィールドは分析に用いるため、振り返りを行う前に必ず記載する運用を徹底します。
以下は不具合チケットの例です。
振り返りと分析
次に、チケットに入力された不具合原因などのフィールドを元に、
その内訳をQAチームにてチェックし、検出不具合の解像度を上げていきます。
以下は不具合原因内訳の例です。
不具合の分類傾向を元に、分析に対する総評をQAチームが記載します。
総評の例
- 不具合の傾向
- プログラミング誤りが不具合全体の29%、影響範囲の考慮漏れが全体の25%を占めている
- 対策の草案
- プログラミング誤りについてはコードレビューの改善をお願いしたい
- 影響範囲の考慮漏れについては洗い出しの徹底をお願いしたい
定例ミーティング
月毎にプロジェクト全体で集まり、不具合分析の結果を共有する定例ミーティングを行います。
定例ミーティングでは、不具合分析の結果を受けて、良かったこと、改善したいこと、アイデア、次のアクションを皆で忌憚なく議論していきます。
次のアクションとして決まった内容は別途タスク化して進めていきます。
議論の例
- 良かったこと
- NG率を低くしようというモチベーションにも繋がる(エンジニア)
- 明確にポイントを決めて対策に取り組めそうなので効果が出そう(QA)
- 改善したいこと
- 結合テスト開始後に基本機能の不具合が検出される(QA)
- アイデア
- 結合テスト前に基本機能のプレテストを実施できるようにしたい(QA)
- 次のアクション
- 大きな機能追加案件ではプレテストを実施しよう
不具合検出率低減の取り組み
影響範囲のリスク洗い出し会
私たちは、新規の開発案件を開始する前にいわゆるキックオフミーティングを実施し、案件の概要やゴールを関係者で共有しています。 キックオフが終われば詳細設計、デザイン定義、テストケース作成といった各関係者の作業が進行します。 そして、工程のより上流でリスク洗い出し会を行うことにより、手戻りのコストが少なくなるという考えを元に、 開発案件のキックオフより前にリスク洗い出し会を実施しています。 リスク洗い出し会には、プロジェクト全体をスコープとして案件に関わる関係者以外にも有識者を集めてブリーフィングを行います。 以下は私たちのチームの開発フローです。
リスク洗い出しの一例として以下を挙げます。
- リスク事項
- クライアントからのリクエスト頻度が高そうなのでサーバー全体のパフォーマンスが落ちそう。リクエスト頻度は間引けるか？
- リスクへの備え
- クライアント上でキャッシュの期間を設けて、APIリクエストの回数を少なくする。
リスク事項に対し、対応状況、対応内容を記載し、全てのリスク事項への処置が完了したらチェックを行いリリースするという流れになります。
単体テストの補充
不具合分析から、開発プロセスである単体テストの段階では不具合を十分に検出できないことが明らかになりました。そのため、単体テストの精度とカバレッジを向上させることを目指しました。 まず、テストカバレッジを定量的に90%以上担保すること。さらに、定性的にも、影響範囲のリスク洗い出しで洗い出された内容をテストケースに追加し、潜在的な問題を見つけ出すように努めました。
コードに対するテストカバレッジの目標は、一見難易度が高いかもしれません。しかし、この目標を追求することで、私たちのコードはより堅牢で信頼性が高くなりました。また、テストカバレッジが高いということは、新しい機能を追加したり、既存のコードをリファクタリングしたりする際のリスクを軽減することにもつながります。
そして何より、リスク洗い出し会で議論した内容をテストケースに落とし込むことで、具体的な問題領域に対して明確な視点を持つことができました。これにより、各開発者は問題解決のための具体的なアクションを取りやすくなり、結果的に品質向上につながりました。
実践の結果、何が変わった？
不具合検出数の減少
不具合対応のための時間が大幅に減少し、その結果、開発者が新機能の開発や既存機能の改善により時間を費やせるようになりました。
リスク洗い出し会と単体テストの補充が効果を発揮した結果だと考えられます。特に、リスク洗い出し会によって事前に見える化した問題に対して対策を打つことができ、また単体テストの補充により、結合テスト前に多くの問題をキャッチできました。
不具合の可視化
不具合分析を始めたことで、特定の人しか把握できていなかったことや見過ごしていた問題をプロジェクト全体で把握できるようになりました。これは不具合に対する深い理解を持ち、その根本的な原因を把握し、それを解決するための具体的なステップを練れることを可能にしました。 さらに、私たちのそもそもの開発プロセス自体の弱点や問題点を明確に把握でき、開発プロセスを改善するための重要なフィードバックとなり、チーム全体の生産性と品質に大きく寄与しました。
品質意識の高揚
この取り組みを通じて、チーム全体の品質に対する意識が高まりました。私たちが行っている不具合分析や定例ミーティングは、開発者一人ひとりが自身の開発に対する意識を深め、自己改善を行う機会となりました。これが結果として製品の品質向上につながっていると思います。
さいごに
私たちの取り組みは、組織全体の文化を変えることから始まりました。開発者一人ひとりが品質に対する意識を持ち、それを日々の開発に活かす。そしてその一方で、組織としても手戻りコストを最小限に抑え、プロジェクト品質を向上させるための仕組みを整える。これらが双方向に働きかけることで、我々は「小さな手間で大きな成果」を出すことができました。
ただし、大切なのは成果を生み出すための手法を適切に整備することです。不具合分析はコストを掛ければいくらでも細かく実施することが可能ですが、メトリクス収集に必要以上に手間をかけると、実業務への負荷が増大し、運用自体が困難になる可能性もあります。それぞれの分析は目的ではなく、あくまで品質向上の一つの手段であり、継続的な運用が重要です。これを実現するためにも、最もコスト対効果の高いスキームを確立していくことが求められます。
私たちの目指すところは、さらに高い品質を持つ製品を提供し、それが顧客の満足につながることです。そのためには、今後も不具合分析やリスク洗い出し会などの活動を継続し、さらなる改善を進めていきます。我々の取り組みが、他の組織の皆さんにも何かの参考になれば幸いです。最後までお読みいただきありがとうございました。
私たちは食べログオーダーを共に開発いただける方を募集しています。
気になった方は是非下記の採用リンクをチェックしてみてください！
