こんにちは！kintone 開発チームの Android エンジニア、トニオ（@tonionagauzzi）です。
本日は、私たちがモブプログラミング（以下、モブ）を活用して Android アプリの品質向上に取り組んだ話をします。
目次
はじめに
私たちのチームでは、モブを活用しています。モブは、複数の作業者が画面を共有しながらコードを書いたりテストしたりする開発スタイルです。
現在、開発者と品質保証担当者（以下、QA）が共同で全体の7割程度の作業をモブで実施（以下、共同モブ）しています。この共同モブは、チーム内のコミュニケーションや作業プロセスを改善すると同時に、プロダクトの品質向上にも繋がることがわかりました。
この記事では、
- 共同モブの実践例
- 共同モブで得た成果
- 今後の課題
に分けて、具体的にお伝えします。
1. 共同モブの実践例
共同モブの進め方
1つのプロダクトバックログアイテム（以下、PBI）において、以下の作業を共同モブしています。
- 実装プランニング
- タスク分割
- 実装、テスト仕様書作成
- コードレビュー、テスト仕様書レビュー
- 品質保証（テスト実施と修正）
- マージ
実装プランニング
実装プランニングでは、以下をドキュメントに書き出すことで、これからPBIの作業を始めるための認識を合わせます。
- 達成したいこと
- これまでにわかっていること
- 影響範囲・テストケース
タスク分割
実装に着手したら、具体的な作業をタスクに分けます。
開発者とQAがそれぞれどのタスクを進めているかを、ホワイトボードと色の異なる付箋を使って表現します。
実装、テスト仕様書作成
開発者は実装を開始し、QAはテスト仕様書の作成を開始します。
誰かが気づいたことがあれば逐一共有したり、QAが開発作業を眺めてテスト計画に反映したりします。
コードレビュー、テスト仕様書レビュー
実装が終わると、開発者同士でコードレビューを行います。
テスト仕様書の作成が終わると、開発者とQAの間でテスト仕様書レビューを行います。
タイミングはPBIによってまちまちで、コードレビューが先に行われることもあれば、テスト仕様書レビューが先のこともあります。
品質保証（テスト実施と修正）
QAはテストの実施とフィードバックを行い、開発者はコードレビューやフィードバックを元に修正を行います。
マージ
すべての検出事項に対応したら、コードベースにマージしてPBI作業を終えます。
共同モブを始めたきっかけ
元々、開発者とQAはテキストでやりとりしていました。また、PBIの完了の定義に品質保証は含まない開発フローでした。
具体的に言うと、PBIが完了してからQAがバグを見つけ、開発者に報告するのが普通でした。開発者はバグの報告を受けると、今仕掛かり中のPBIを中断して、前のPBIのバグに対応していました。
ここには、開発者とQAが、お互いにやりづらさを感じる問題が潜んでいました。
開発者のスイッチングコスト
開発者は、仕掛かり中のPBIを中断し、バグに対応することでスイッチングコストが発生していました。
QAから見た不透明さ
QAは、ふだん開発者が何をしているかわからず、話しかけると開発者の作業を中断させてしまうと思い、質問をしにくい状況でした。
バグの優先度が不明
バグを最優先で直すべきかどうかは内容によります。QA側には優先度の基準がありましたが、開発者がそれを知らない状態でした。開発者はバグの報告を受けたらなんとなく最優先で調べてしまっていました。
これらのやりづらさを解決するため、まず、開発者が何をしているのかをQAに共有しました。具体的には、デイリースクラムやプランニング、ふりかえりなど、様々なイベントにQAが参加するようになりました。そして、当初は開発者の間だけで行っていたモブに、QAも加わることになりました。
2. 共同モブで得た成果
シフトレフトテスト
共同モブの導入後、バグが見つかるタイミングが明確に変わりました。PBI完了後ではなく、PBIの実装段階で潜在的な問題に気づけるようになりました。さらに、スプリントプランニングにおけるPBIの設計段階でも、テストケースを共同で設計することで、設計段階で見落としや考慮不足が見つかるようになりました。これにより、次の効果が得られました。
レビューコストの削減
元々、自動テストが十分実装されているかどうかは、開発者がコードレビューで判断していました。また、QAが作成したテスト仕様書は、開発者が非同期でレビューしていました。レビューや修正に今よりも多くの時間をかけていました。
共同モブを始めてからは、プランニング時に開発者とQAが一緒に作成したテストケースをレビューに使うことで、レビューがとても楽になりました。QAが新たに思いついたケースも、開発者がリアルタイムで確認し、「このケースは分ける必要があるのか」「実装観点では共通部分だから1パターンで十分」などのフィードバックを即座に反映できるようになりました。
探索型テストの増加
元々、テストといえばテストケースに沿って行うものという認識でしたが、共同モブを始めてからはQAが開発者からの情報をもとに探索型テストを実施するようになり、即座に気づいた点を開発者と共有することで、より柔軟かつ深いテストが可能になりました。
バグ対応コストの削減
バグは早期に見つかるほど、対応コストが下がります。リリース後にバグが見つかると、多くの関係者が対応に巻き込まれますが、設計や実装段階で発見できれば、開発者やQAの負担だけで済みます。
元々、PBI完了後やリリース後にバグ対応していましたが、共同モブを始めてからは、PBIの開発中にバグが見つかることが増えました。
以上の効果で、共同モブを始めてからチームの作業が高効率化し、品質も向上したと感じています。
シフトライトテストも可能に
仮説をもとに実装する場合や、バグを手元で再現できなかった場合など、お試しでリリースしたいこともあります。実装やβ機能、ログなどを一旦リリースしてみて、ログやフィードバックを受けて改善したり次の施策を打つといった、シフトライトテストです。こういったテストも共同モブにより、やりやすくなりました。
定期的なリリース
元々、モバイルアプリは回帰テストや審査提出などのリリース準備が複雑で、PBI完了後にバグが見つかっていたり、全体的なリリース手順を1人しか把握していなかったのもあり、リリースできるタイミングを見つけるのが難しい状態でした。
共同モブを始めてからは、残作業なくPBIを終えるようになったことと、共同モブでリリース手順を開発者とQAが全員把握したことで、リリースできるタイミングが増え、当番制で2週間に1度のリリースサイクルを回せるようになりました。
リリース後の対応の強化
リリース後のトラブルに対処するための体制も整備されました。例えば、リリース後に予想外のバグが発生した場合、バグの優先順位の指標が言語化されており、その指標に基づいて迅速に対応できるようになりました。
このように、リリースへの抵抗感を下げたことで、積極的にリリースしてフィードバックを得つつ改善を重ねていく文化へと変わっていきました。
数字で見る実際の効果
共同モブの導入前後で、バグ検出のタイミングがどのように変わったのかを比較しました。以下は、2022年6月から2022年12月までと、2024年6月から2024年12月までの、リリース前後のバグ検出件数をまとめたものです。
2022年6月〜2022年12月（共同モブ未導入）
- リリース回数：2回
- PBI完了後に発覚したバグ：4件
- リリース後に発覚したバグ：3件
2024年6月〜2024年12月（共同モブ導入後）
- リリース回数：9回
- PBI完了後に発覚したバグ：0件
- リリース後に発覚したバグ：4件
2年前と比較して、PBI完了後に発覚したバグがなくなりました。これは、共同モブによりPBI内で見つけることができている、シフトレフトテストの効果です。
一方、リリース後に発覚したバグは1件増えましたが、これはリリース回数が増えたためと考えられます。リリース1回ごとのバグ発生率を計算すると、1.5件から0.44件に、3分の1未満へと減っています。また、バグが起きても次のリリースまで短期間なのですぐに修正版を提供できる体制が整っており、シフトライトテストのしやすさにも繋がっています。
共同モブがもたらす副次的なメリット
共同モブを実践する中で、バグの早期発見以外にもさまざまなメリットを感じました。
コミュニケーションの質の向上
リアルタイムでの対話が可能になるため、チーム内の認識のズレを防ぎやすくなりました。開発者がQAへ、QAが開発者へと話しかけやすくなっています。認識が揃った状態で作業できるため、雑談しながら手を動かすようなことも増えてきて、チームの一体感が高まりました。
学びの共有
QAが実装の技術的な背景を学びたい、開発者がテストの種類を学びたいといった、片方が持つスキルをもう片方が教えてもらったり自発的に学習する動機も生まれています。具体的には、QAがKotlinのコードを書く時間を設けたり、チーム全員でLEADING QUALITYの輪読会をしたりしています。
3. 今後の課題
共同モブには多くのメリットがある一方で、課題も残っています。
よりシフトレフトに
リファクタリングのように自動テストだけでカバーできるタスクでは、QAがどのように関与すべきかが明確ではありません。リファクタリングが終わるまで待ちになることもあります。
また、実装後にテストを始めることで、テストが長引くと開発者が次のPBIに着手してしまうこともあります。
さらに改善するため、開発中のアプリをいち早くQAが触れるようにデプロイのプロセスを改善していきたいです。
探索型テストの強化
依然として、テストケースに沿ったテストが多くの割合を占めています。一度作成したテストケースの実施をやめるには理由が必要で、足すは易し、引くは難しと感じました。今後は、探索型テストをより積極的に採用し、費用対効果の高い品質保証をしていきたいです。
適切な時間管理
モブは全員の時間を拘束するため、作業効率が落ちる場合があります。誰がやっても同じ結果になる作業であれば、1人1人が分担で行ったほうがリソース効率が良いといえます。
私たちはモブに参加していながら個人作業をすることも許容していますが、その個人作業は注目されにくく、後で認識を合わせるための会話コストが発生することもあります。リソース効率とフロー効率のバランスを模索しています。
他の職能とのコラボレーション
開発者とQA以外にも、EM、ライターなど様々な人々が開発に関わっています。全員でモブをすれば良いかというと、そうとは限りませんが、開発者とQAの間だけでなく、どのような職種の人もモブのメリットを受けられるようなチームになっていきたいと思います。
おわりに
開発者とQAとのモブは、私たちのチームに大きな利益をもたらしました。バグ検出のタイミングが早まり、品質が向上しただけでなく、仮説検証もしやすくなり、チーム全体の生産性や一体感も高まっています。
これからも、職能を超えたモブをさらに洗練させ、職能を超えたコラボレーションを追求していきたいと思います。同時に、新たな課題に取り組みながら、より良いプロダクトを提供できるチームを目指します。
皆さんのチームでは、どのように品質向上に取り組んでいますか？ぜひコメントやフィードバックをお寄せください！
