はじめに
こんにちは、助太刀 iOSチームリーダーの喜多です！
今回は、iOSチームの不具合修正率を52%から99.06%(開発部全体としては97.69%)まで向上させた取り組みについてお話しします。約3年間の地道な改善活動を通じて、チームの品質向上と開発効率化を実現できたので、その過程と学びを共有したいと思います。
不具合修正率の推移
前提
該当Sprintで出た不具合かつユーザ影響が大きくあるものについては、そのSprint期間で修正しています。
また本番アプリで発生した不具合については基本的に迅速に対応し修正でき次第リリースしています。
3年前の不具合修正率
不具合修正率とは以下の式で表すことにしています。
2022年7月時点で、iOSチームのバックログに蓄積された不具合の修正率は52%という状況でした。新機能開発に注力する中で、不具合修正が後回しになりがちで、バックログがどんどん蓄積されていく悪循環に陥っていました。
当時は不具合の優先度や分類が曖昧で、どの不具合から手をつけていいかわからない状況が続いてそうです。そのため日々、QAチームからの不具合報告が増える一方で、品質面での課題が深刻化していました。
課題の根本原因を分析
不具合起票を詳しく分析してみると、いくつかの問題が見えてきました。
- 要望や仕様確認の混在: 不具合起票の中にQAチームからの要望や仕様確認(質問含む)が混在していた
- 過去機能の残存: 過去機能や廃止予定機能の不具合が残存していた
- 責任範囲の曖昧さ: アプリ側とサーバー側の不具合が混在していた
- OS間のレイアウト差異: OS間で微妙にレイアウトが違う点も不具合として扱われていた
これらは本来不具合ではないにも関わらず、同じバックログに蓄積され、修正率を下げる要因となっていました。
改善策の実施
問題を明確にしたところで、段階的に改善施策を実施していきました。
まず取り組んだのは、不具合の精査と分類です。
1. 不具合の精査と分類
不具合以外のクローズ作業
新機能開発中の合間を見て不具合起票を1つ1つ確認し、以下の内容を進めました。
- 要望起票であるもの：内容を精査し、必要があればPMチームに連携、取り下げ可能なものはクローズ
- 仕様に関する起票であるもの：仕様が曖昧であるものについてはPM/エンジニアで協議して改めて仕様を策定
- 過去機能に関する起票であるもの：存在しない機能についてはクローズ
不要機能の削除
不具合として上がっている内容の中には、技術負債となっていて修正が困難となっている機能についての不具合も数多く存在していました。
我々はまずその機能が本当にユーザーに使われているのかを調査/検討しました。
調査としては下記を行いました。
- サービス内で該当機能が使われているのか調査
- CSや営業でその機能をお客様に案内しているのか、または商材として売り物になっていないのかの調査
上記2点を調査し、ユーザにも使われていない、かつ、CSや営業もお客様に案内をしていないとなっている機能については、法務の確認を通したうえで機能削除の段取りを進めてしました。
以下は削除に至った機能の1例です。
グループメッセージ削除のお知らせ
不要機能を削除することで結果として不具合起票をクローズし、開発生産性を上げることができました。
2. カテゴリの最適化
デザインシステムの統一
弊社ではデザインシステムを構築して現在アプリに反映を進めています。そのため、OS間で微妙にレイアウトが違う点については、デザインシステム反映後に統一されているため、不具合として扱わないことにしました。
これにより、今後修正されるレイアウト周りのOS間差分の不具合を排除することとしました。
不具合の適切なカテゴリー分類
当初はiOSチーム不具合として計上されているものでも、中身をよく見るとサーバーサイド/フロントエンド起因の不具合であったりするものもありました。
不具合の原因を特定し、該当チームに引き継ぐことでカテゴリを変更し、責任範囲を明確化しました。
これにより、どのチームが対応するべき不具合なのかを明確にすることができました。
3. 残存不具合の全力修正
施策の合間での継続的修正
ここまで来たら残ってる不具合は真の不具合です。そのため全力で修正するだけです。
新機能開発の合間に少しずつ不具合を修正する体制を構築しました。具体的な取り組みは以下の通りです。
- 施策の合間を活用した修正時間の確保
- チームメンバー全員での修正作業の分担
冒頭のグラフでも分かる通り、継続的な改善活動を実施することで、着実に修正率を向上させていきました。
成果
数値での成果
約3年間の地道な取り組みの結果、2025年8月時点で不具合修正率を99.06%まで向上させることができました。52%から99.06%への約47%向上は、単純に不具合を修正しただけでなく、不具合の精査不要機能の削除、分類/カテゴリの最適化を通じて実現できた成果です。
施策の合間を活用した継続的改善により、新機能開発と不具合修正のバランスを取りながら、着実に品質向上を図ることができました。
※ちなみに執筆時点でiOSチームが修正するべき不具合は0件となっています🎉
品質向上の効果
バックログの整理及び不要機能削除により開発効率が大幅に向上しました。具体的な効果は以下の通りです
- 対応の迅速化: 不具合の分類が明確になり、対応すべき不具合が一目でわかるように
- 開発効率の向上: 技術負債となっている不要機能削除により、開発チームの開発生産性が向上
- 品質意識の向上: チーム全体で品質を意識した開発が行われるように
特に新規不具合が発生した際にはこれ以上不具合修正率を下げないようにという気持ちが湧き、何が何でも修正する意識になっており、この意識改革はとても素晴らしいことだと思います。
学びと今後の展望
得られた学び
この取り組みを通じて、以下の学びを得ることができました。
- 精査と分類の重要性: 単純に不具合を修正するだけでなく、まず「本当に不具合なのか」を精査することで、効率的な改善が可能になる
- 継続的改善の効果: 一度に大きな改善を目指すのではなく、小さな改善を継続することで、大きな成果を得ることができる
- チーム全体での取り組み: 個人の努力だけでは限界があり、チーム全体で品質向上に取り組むことで、持続可能な改善が実現できる
- プロセスの重要性: 適切なプロセスを構築することで、効率的かつ継続的な改善が可能になる
特に、不具合の精査と分類がいかに重要かを実感しました。当初は「とりあえず修正すればいい」と考えていましたが、まず不具合かどうかを判断すること、更にその不具合を修正する以外の解決方法はないのかを考えることの重要性を学びました。
今後の取り組み
今後も品質を高水準で保つために、以下の取り組みを継続していきます
- 継続的監視体制の構築: 99.06%の修正率を維持し、新規不具合の早期発見と迅速な対応
- プロセスの改善: 不具合発生を抑制する開発プロセスの継続的な改善
- チーム全体での品質意識の維持: 新規不具合発生時の迅速な修正意識を継続
またiOSチームの直近１ヶ月の未クラッシュ率は99.99%のため、こちらも同様に高水準の数値を保つようにしていきたいと思います。
直近１ヶ月の未クラッシュ率
また、この取り組みを継続し、組織全体の品質向上に貢献していきたいと考えています。
まとめ
iOSチームの不具合修正率を52%から99.06%まで向上させることができました。
この成果は、単純に不具合を修正しただけでなく、不具合の精査と分類、不要機能削除、カテゴリの最適化、継続的な改善活動を通じて実現できました。
品質向上は一朝一夕では実現できませんが、地道な取り組みを継続することで、大きな成果を得ることができることを実感しています。今後もこの取り組みを継続し、さらに高い品質を目指していきたいと思います。
最後までお読みいただき、ありがとうございました！
採用情報
助太刀では一緒に開発してくれるメンバを募集してます！
少しでもご興味を持っていただけたら下記よりお気軽にご連絡ください！
Discussion