こんにちは！マネーフォワードのHR領域でQAエンジニアをしている森田です。
前回以来の半年ぶりのエンジニアブログ投稿になります。
不具合分析の取り組みを導入してから1年ほど試行錯誤してきましたが、同じような悩みや課題感を抱えて、不具合分析に取り組んでいる方もいらっしゃるのではないか思います。
そこで、導入編、運用試行錯誤編に分けて 何を考えて何を行ったのかと、その結果についてお話していきます。
導入編の今回は、不具合分析の取り組みをどう開始したのか、どう開発チームに取り入れていったのかについてお話します。
（次回の運用試行錯誤編では、どんな切り口で分析しているか、分析結果をどう開発チームに持ち帰っているのかについてお話する予定です！）
不具合分析の運用の概要
プロダクトによって運用方法が異なるところもありますが、大体下記の流れで運用しています。
- （随時）開発エンジニアは、不具合issue/チケットにラベルをつける
- （日次）GASで、不具合issue/チケット情報がスプレッドシートに出力される
- （日次）Googleデータポータルに、不具合件数などが反映される
- （週次）開発エンジニア＋QAエンジニアで、不具合の分類づけ会を実施
- （月次〜四半期毎）QAエンジニア主体で、不具合の傾向を分析
※内容の詳細については次回です！
不具合分析を通して何を成し遂げたいかを明らかにし、WHYを理解・共感してもらうことが一番大切
不具合分析はあくまで手段です。
まずは不具合分析を通して、何を成し遂げたいのかを文章化しました。
HR全体で、不具合件数を可視化することによって、
- まずは、現状の不具合件数を把握したい（現状が分からないと議論もできない）
- 次に、不具合の件数を減らしていくための施策を考えて実施する。
- そして、不安や不満の要素になるものをゼロに近づけていく
当時は「不具合分析」ではなく、「不具合件数の可視化」という言葉を使っていました。
ダイエットするにも、まずは体重を測定しないことには、今どのくらい太っているのか、体重は変化しているのか、改善しているのかが分からないですよね？
それと同じで、ユーザーの不安や不満の要素をゼロに近づけていくためには、まずは不具合を可視化することが必要だと考えました。
しかし、目的を定めるだけでは不十分です。
開発チームの外側にいる私（QAエンジニア）が、開発チームで何か新しいことを始めるのに際して、一番重要なことがWHYを伝えること、WHYに共感してもらうことだと考えています。
日々、たくさんのタスクに追われている中で、これやりましょう！と言っても、その重要性を理解し、共感してもらえないと、なかなかアクションに移すことはできません。
幸い、マネーフォワードでは、まずやってみようという考え方が主流なので、すんなりとトライアル運用を開始することができました。
運用定着のためには、開発チームがオーナーシップを持てるようにするのも結構大事
トライアル運用を開始しても、継続・定着しなければ意味がありません。（もちろん、やっていることに意義があることが前提で、問題箇所があれば随時改善・アップデートしていきます）
1から10まですべてQAの方でやるのでは、やりたいこと（ユーザーの不安や不満の要素をゼロに近づけていくためには、まずは不具合を可視化することが必要）は開発チームになかなか浸透しません。
また、その開発チームでどのような運用にするのが一番良いかは、その開発チームの皆さんが一番わかっています。
そこで、開発チームのリーダーに相談して、開発チームの中で品質担当の方をアサインしてもらいました。（最初はメンバーの自発性、厚意に甘えて取り組みを進めていたのですが、他の業務との兼ね合いで進まなくなった...）
目的ややりたいことを個別に説明し、「こういうことをやりたいんだけど、どういうやり方だったらこのチームだと上手く回りますかね？」と問いかけながら、一緒に進めていきました。
週次の分類づけの会の進行も品質担当の方に行っていただき、私は強力なサポート役として活動しました。
一つ気をつけていたのは、やらされ仕事にならないように、必要性を理解してもらうことです。説明だけだとイメージが伝わらないこともあったので、「まずは3ヶ月やってみませんか？」「今日やってみて、どうでした？」とか密にコミュニケーションをとるようにしました。
結果
開発チームに新しいメンバーが入った時、運用の中でそもそも何でこれやっているんだっけ？という雰囲気になったときなど、ことあるごとに、目的について繰り返しお話しました。
その結果、1年近く経って開発チームにやりたいことが浸透していると感じました。（嬉しい）
というのも、新しいメンバーが開発チームにジョインした時に、最初は私から目的ややりたいことを説明していたのですが、いつの間にか品質担当の方自身が資料などを見なくても目的・やりたいことを説明していたのを目撃したのです。（一人で感動していました）
さらに嬉しかったのは、運用を6ヶ月ほど続けた頃に、この不具合の分類づけや分析をやってみてどうかを聞いてみたところ、「自分の案件以外の不具合の内容や原因がわかって、チーム全体での知見共有になっていて良い」というポジティブなフィードバックをもらったことです。
メリットを実感してもらえれば、私が深く関わらなくても改善は進みます。（しめしめ）
複数プロダクトだからこそのお悩み
マネーフォワードクラウドのHR領域には6つのプロダクトがあり、ファーストローンチの時期・プロダクトの成熟度も異なります。
また、それぞれのプロダクトで最適の方法で開発を進めているため、開発の進め方やスタイルも異なります。
6プロダクトにどう導入していくかが最初の悩み
いきなり6プロダクトで不具合分析の運用を開始するにはパワーも足りなかったですし、自分の頭の中で考えていることが正しいのかの自信も、正直あまりなかったです。
何より、スモールスタートで改善のサイクルを回していきたいという思いもありました。
そこで、最初は2プロダクトで開始することに。
ファーストローンチからある程度期間が経っているプロダクトから2つ選びました。より運用フェーズに近いプロダクトの方が、不具合分析の結果から運用改善しやすいのでは、と考えたからです。
また、各開発グループのリーダーとも話をして、不具合分析の運用をする余力や要望がどのくらいあるかも確認しました。
プロダクトによって用語も課題感も異なるので、分析の中身は揃えないことにした
どう6プロダクトに導入するかの次に悩んだことが、「分析の切り口は揃えるのか」という点です。
ベースとして、「対象機能」「混入したフェーズ」などの分析の切り口と想定選択肢はQAの方で用意しました。
しかし、いざ分類づけしてみると、ふさわしい選択肢がない、選択肢の名称が理解しづらいから変更したい、という話になりました。
例えば、「混入したフェーズ」では、左側の4つの選択肢を用意しましたが、分類づけ行う中で、右側のように変化しました。
他のプロダクトではそもそも混入したフェーズという項目自体が不要という話になり、項目自体を削除しました。
フェーズの呼び方だったり、課題感も異なるので、どう分析するのかは、プロダクト間で統一しないことに決めました。
結果
トライアル的に運用を開始した当初は、各プロダクトで納得できる、わかりやすい内容で行うことが重要だと判断し、柔軟に分類項目や項目の選択肢を追加・削除しました。
開発チームの納得度が高いので運用定着という意味ではよかったと考えています。
一方で1年ほど経って、HR全体として、不具合の傾向はどうなっているんだっけ？と見たくなってきました。
分析結果をGoogleデータポータルに載せようとした際に、分類項目が違ったり、フェーズの捉え方が違ったり、起票対象の不具合の範囲が微妙に違ったりと、作業に苦労しました。
元々、プロダクト間の横比較は不要（プロダクトの成熟度が異なるので、横比較は意味がない）と考えていたのですが、ここになって、とはいえ、最低限ラインは守れているよね、をプロダクト横串で同じ基準で確認していく必要性が出てきました。
不具合件数だったり、不具合の内容が見えて来たからこそ、これは大丈夫なんだっけという新しい観点が出てくるのだ！と前向きに捉えて、引き続き改善していきます！
余談
そもそもの「不具合」の定義についても、人によって認識が異なっていそうだったので、図を使って定義しました。
不具合についての図は、Qiitaでも公開しています。 不具合（バグ）とは？ を視覚的に表現。
おわりに
繰り返し目的を伝え、WHYに共感してもらうことに気をつけたことで、不具合分析の運用は波に乗って来ました。
次回は、どんな切り口で分析したのか、分類づけ会や不具合分析、データポータルでどのように不具合を可視化しているのかについてお話します。
お楽しみに！
もっと踏み込んだ話を聞きたい方、不具合分析についてお話したい方はぜひカジュアル面談しましょう！
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点（大阪/京都）
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers
