DevOpsのチームのQAエンジニアの取り組み

こんにちは、QA（品質保証）エンジニアの矢引です。今回はDevOpsのチームのQAエンジニアが本番環境のログを定期的にチェックすることでプロダクトの品質向上を行っている事例を紹介します。

Claraとは

今回の取り組みを行っているClara開発チームを簡単に紹介します。

Claraとは、オンラインストアと販売管理システムを開発・運用するプロジェクトです。オンラインストアというのは弊社のクラウドサービスであるKintoneやその他関連サービスを、顧客（Kintoneのユーザー）が購入するためのシステムです。もう一方の販売管理システムとは、クラウドサービスの売り手として受注・見積・請求などを弊社のオペレーターが行うためのシステムです。いずれもグローバル市場向けに開発されています。 Claraの2つのシステム：オンラインストアと販売管理システム

運用データを製品開発に活かす取り組み

DevOpsでは、運用データを高速かつ継続的に開発にフィードバックして製品開発に活かすことが重要です。

Claraチームでは、アクセスログから機能の利用状況を把握したり、各種メトリクスをモニタリングして障害の予兆や発生を検知したりしていますが、QAエンジニアが主体的に行っている活動として本番環境のエラーログの定期的な確認作業があります。

今回はその取り組みによる効果や得た学びについて詳しくご紹介します。

何をやっているの？

毎日、対象のサービスのアプリケーションが出力したエラーログをQAエンジニアがチェックしています。

エラーログを目視で確認し、怪しいログがあればトレースID等を使って一連のリクエストを調べ、エラーの詳しい内容や原因を探ります。

また、調査をする際はそのエラーが仕様動作であるかどうかの判断のみではなく、最終的にユーザーがどのような体験をしたかも調べます。例えば、ユーザーが目にしたエラーメッセージはどういったものだったか、エラーに遭遇したユーザーが同じ操作を再試行したかどうかといったことです。そしてユーザーに必要なフォローがあるかどうかを検討し、必要に応じて営業部門など関係部署にエスカレーションしています。

ちなみに、これとは別にモニタリング・アラートの仕組みがあり、即時対応が必要なエラー（障害など）はその仕組みで対応しています。そのため、この取り組みで検出・対応しているエラーはそれ以外のものが対象です。

効果

この取り組みによって得ている効果は主に3つあります。

プロダクト改善の種を見つけられる
働きかけが必要な顧客を見つけられる
考慮漏れによる不具合を早期に見つけられる

効果のサマリ

ここからは、それぞれの具体例を紹介します。

効果① プロダクト改善の種を見つけられる

例：契約に関する注意喚起をするための機能追加

オンラインストアでは契約中のサブスクリプションを解約することができますが、本番環境のログをチェックすると、「未払いの状態でユーザーが解約操作を行おうとしてエラーとなった」というケースが頻繁に発生していることが分かりました。

ユーザーが初めて購入操作を行うフローの中で、購入初月の支払いが完了しないと解約できないという仕様(注意書き)を提示していますが、このエラーが頻繁に発生しているということは、この注意書きがユーザーに十分に伝わっていないことが推測できます。

そこでプロダクトオーナーと開発チームで相談し、初回の購入操作を行うフローに新たに「注意事項に同意する/しない」のチェックボックスを追加することにしました。これによって、ユーザーはチェックボックスにチェックを入れて明示的に同意しないと購入操作を進めることができないようになり、注意事項をユーザーに確実に伝えることができるようになりました。

この機能を追加した結果、該当のエラーの発生が減少しました。

例：オペレーターの入力ミスを防ぐためのUI改善

社内のオペレーターが利用する販売管理システムには、顧客情報を検索する機能があります。本番環境のログをチェックすると、検索で404エラーが発生するケースが多いことが分かりました。詳しく調査すると、検索の入力画面にはデータの種類に応じた複数の入力欄があるのですが、入力欄の取り違え（分かりやすく例えると"電話番号"の入力欄に"メールアドレス"を誤って入力するなど）が多いことが分かりました。

これを受けてプロダクトオーナーと開発チームが社内のオペレーターにヒアリングするなどの調査を行い、「入力フォームの表示サイズを大きくする」「検索窓のプレースホルダに入力例を表示する」といった入力ミスを防ぐためのUIの改善をすることになりました。

その結果、入力ミスによるエラーが減少しました。

効果② 働きかけが必要な顧客を見つけられる

ユーザーがオンラインストアの機能制限に遭遇した際のエラーが記録されることもあります。例えば、契約プランの上限値を超えるユーザー数で購入しようとしたり、オンラインストアへのアクセスを制限している地域からアクセスしようとしたりしてエラーになるケースです。

これらはプロダクトの改善のみで解決することが難しいのですが、営業部門など弊社の別の部署がフォローすることによって、別の解決策を提示できたりユーザー体験を向上させられたりする可能性があります。そのため、上記のようなエラーに遭遇してユーザーが意図した操作を行えなかったことを社内の関係部署にエスカレーションしています。

その結果、顧客からの問い合わせを待つのではなく、カスタマーサクセスの一環として、弊社からの働きかけが必要そうな顧客を早期に見つけることができるようになりました。

効果③ 考慮漏れによる不具合を早期に見つけられる

Claraチームでは利用者を開発チームの一員に引き込むといったシフトレフトの品質保証の取り組みも行っているのですが、考慮漏れによる不具合が流出してしまう場合があります。

例えば、連携している外部サービスが禁止している文字をオンラインストア側で適切にバリデーションできていなかったために、外部サービスと連携している箇所でエラーが発生してしまったことがありました。

そういった考慮漏れによる不具合が本番環境に流出してしまった場合も、エラーログを定期的にチェックすることで、ユーザーからの問い合わせを待たずに早期に気づくことができました。

実践する中での気づきと学び

チーム全体の協力が不可欠

この取り組みを進めるためにはチーム全体の協力が不可欠だと感じています。

まず、ログの内容が不十分な場合はチームで相談してログの出力内容を改善しています。例えば複数の種類のエラーに対して同一のエラーメッセージを出していたため、ログの内容のみでは原因の調査が難しいことがありました。そこでチームで相談し、エラーの種類ごとに別のエラーメッセージを出力する改善を行いました。

また、本番環境で出たエラーへの対応方針はチームでリスクを考慮した上で相談して決めています。例えばあるエラーに対して、「設定したログレベルが適切かどうか」や「ログをフィルタで確認対象から除外しても良いかどうか」、「そもそも他の手段(アラート)で即時に気付けるようにした方が良いか」など、対応方針はそのエラーのリスク（発生頻度や影響度）によって異なります。そのため、QAのみで決めるのではなく、プロダクトオーナーと開発チームで相談して決めています。リスクは運用する中でも変化していくため、これらのルールは一度決めたら終わりではなくチームで継続的に見直していくことも大事だと感じています。

得た知見をリリース前の試験に活かせる

エラーログを確認する作業自体はQAエンジニア以外の職能のメンバーでもできることですが、QAエンジニアがやるからこそ得られるメリットについて最後に紹介したいと思います。

まず本番環境で起きてしまった不具合を参考にしてリリース前のテストの試験観点をアップデートすることで、似たような不具合を別の箇所で再度作り込まないようにしています。

また、本番環境でのユーザー操作や挿入されたデータをログで目にする機会が増えたため、それを参考に探索的テストでも「こういった操作をするとどうなるかな？」と試してみる機会が増えたと感じています。

一般的に、リリース前のテストは「事前に予想できる欠陥」を見つけることに適しており、リリース後の監視やモニタリングは「予想していなかった欠陥」を見つけることに役立つ*1と言われています。この取り組みによってリリース後に見つかる「予想していなかった欠陥」をリリース前のテストにフィードバックすることで「予想できる欠陥」の種類を増やしてリリース前に取り除き、品質向上に繋げられることは、QAエンジニアがこの取り組みを行うメリットだと感じています。