はじめに
初めまして。CQO室の東藤(@def_todo)です。
2025年3月27日(木)、28日(金)に開催されたJaSST'25 Tokyoに角田さん(@imtnd)と登壇しました。 JaSST(ジャスト)はJapan Symposium on Software Testingの略称で、JaSST Tokyoは日本国内で最大のシンポジウムとして知られています。 「保守性向上のためのユニットテストカバレッジの有効性評価」というタイトルで登壇しました。
この記事を通して、初登壇までの過程や自分の学びを共有します。
JaSST'25 Tokyo登壇のきっかけ
CQO室として全社横断的にメトリクスを取得していることから、このテーマを持ちかけていただき、論文作成を進めることとなりました。
ありがたくも登壇の話をいただいた際に、前職では社外発表を行う文化がなかったため、大勢の前で登壇することに対して高いハードルを感じていました。 しかし、これまでの経験を振り返ると、今まで2つの選択肢があった際に、挑戦を選んできた自分を思い出しました。なぜそうしてきたかというと、チャレンジすることで何かしら学びを得ることができ、自身だけでなく周りにも影響を与えられると思っているからです。 楽なほうを選んで後悔する自分が思い浮かんだため、今回も挑戦することを決意しました。
改めてこのような機会を提供していただける環境に、心から感謝しています。
論文作成
テーマの概要
CQO室は横断的にプロダクトの品質を把握するためにメトリクスを収集しています。その中でもコードカバレッジは取得しやすい指標の一つですが、有効なカバレッジ率の妥当性についてはさまざまな議論があります。
そこで、DORA(DevOps Research and Assessment)が提唱しているソフトウェア開発チームのパフォーマンスを測る4つの指標のうち、"サービス復元時間"に着目することにしました。 4つの指標とは以下を指します。
- デプロイ頻度
- 変更のリードタイム
- 変更失敗率
- サービス復元時間
サービス復元時間とコードカバレッジとの相関が見られるかを研究し、コードカバレッジの有効性について評価することにしました。 コードカバレッジと障害の数においては、研究データ内では相関が見られないことが先行研究でわかっていたため、それ以外の指標でカバレッジがどのように寄与するかを調査しました。
意識したところ
データ収集周りについて、人の手によって入力されたデータを元とするため信頼性のあるデータかどうかに着目しました。 そのため、障害の検知時間や復旧時間を、障害報告書やSlackをたどりながらチェックを行いました。
また、本を読んで統計分析の基礎を学習しました。どのような目的でどのような分析手法を用いるのかなど基礎的な知識があることでより進めやすくなったと思います。
良かったところ
- 先行研究を読んで事例を知ったこと
- 社内不具合の現状を知ったこと
先行研究を読むことで、過去にどのような調査が行われてきたかを知ることができました。英語の論文を読む機会はあまりなかったため、AIや翻訳を用いつつ読むことができ、とても興味深かったです。
また、社内の不具合を分析することで、ソースコードの欠陥だけでなく、インフラ障害や設定のミスなど、その根本原因は多岐にわたることを再認識しました。 QAエンジニアは「テスト」のイメージがあると思いますが、網を潜り抜けてしまう不具合を減らすための取り組みとしてはそれだけでは足りません。開発フロー・リリースプロセスの改善など、QAエンジニア以外の人たちと協力しなければ不具合を検知できないと感じています。
反省点
- 論文の構成をまとめた資料を作っておらず、レビューがしにくかったこと
- プロット形式で内容を構造化することで、自身もレビュー側も全体を把握が容易になる
- 最初は統計の知識が乏しく、用いるべき指標の定義やデータの母集団の定義などが曖昧な状態で分析を進めてしまっていたこと
- 事前にリサーチを行い、足りない知識を学習する
- 集めやすい・分析しやすい形でデータが存在していなかったこと
- 入力側が負担にならないようなフィールドの数を設定する
- アドオンやスクリプト、メトリクスツールを用いて自動で欲しい情報がとってこれる状態にする
特にデータ収集や前処理に時間がかかりました。 分析作業において、本来必要な分析や考察よりも前処理にかかった時間の割合が高かったです。今後も続けていくためには、一度きりの分析にならないような工夫が必要だと感じました。
発表資料作り・発表練習
どのように情報を整理し、伝えるか？
いざ発表資料を作成しようとしたものの、どのような構成でどう伝えれば良いか悩む部分が多くありました。
- 発表を聞いてくれる方にどのようなことを持ち帰ってほしいのか
- どのように説明すれば内容を理解してもらえるか
- 得られた結果から何を伝えたいのか
いざ聞く人の立場になったとき、論文の内容で分かったことに加えて追加の調査を行ったほうがより学びや議論が生まれるのではないかと考えました。 そのため、自分なりに疑問に思った箇所の分析を行い、それに対する考察を複数加えました。
追加調査によって、何を分析するかだけでなく、分析の結果から何を伝えるかなどを考える必要があり、新たなデータ分析と資料作りに時間がかかりました。
レビュー
角田さんに資料を見ていただきましたが、構成や論理性などたくさんの指摘をいただきました。一人で作業すると長時間悩んでしまう癖があるため非常に助かりました。
- 聞く人にとって流れがわかりやすいか
- 話の内容が飛んでいないか
- 仮説と結論は一致しているか
- 事実と考察が混ざっていないか、自身のバイアスがかかっていないか
発表練習
自分の傾向(緊張した時に早口になるのか/頭が真っ白になって話せなくなるのかなど)を把握し、それに沿った形の対処法を考え、直前まで練習を行いました。
いざ声に出して読んでみると、自分の言葉で説明するのが難しい箇所や、何気なく使っていた言葉の定義に違和感を覚えるなどさまざまな発見がありました。
JaSST当日
いざ発表
当日は席が満員で立ち見になるほどお越しいただき非常に驚きました！オンラインでの参加者も大勢いて、改めてこのような場を設けていただいたことに感謝します。
研究では復旧時間に着目しましたが、「他のメトリクスではどうなるのだろう」という会話や「こうしたほうがより良い結果が出るのではないか？」などさまざまな議論が飛び交いました。このようなきっかけを作れる場を提供できたことを嬉しく思います。
懇親会での感想
今回はデータ分析に対する発表だったこともあり、懇親会で「データアナリストではなく、QAエンジニアですか？」と言われるほどデータ分析を学習したことに対して感心していただきました。 着目した仮説がわかりやすく、面白かったと言っていただいて嬉しかったです。
仮説とは逆の結果になった部分を正直に伝えたことで、分析の難しさや試行錯誤をリアルに伝えることができたと感じます。
まとめ：登壇までの道のりを振り返って
初めての経験で途中で投げ出しそうになることもありましたが、無事に発表を終えることができてホッとしています。
今回の研究ではデータ数が少なく結果が出せなかった部分もあるため、データ数を増やし分析を続けられるよう今後もメトリクス収集を続けていきたいです。
また、この事例を含めて、"マネーフォワードのCultureを全社の模範になるレベルで体現している人"として、カルチャーヒーローのEvolutionに選んでいただきました。JaSST Tokyo登壇に向けて意識したことを全社朝会で共有することができました。
改めて、このような機会をいただきありがとうございました！
最後に、マネーフォワードではQAエンジニア、SDETエンジニアポジションの採用を積極的に行っています！もし興味を持たれた方がいらっしゃいましたらこちらからご覧ください。
