自己紹介
hacomonoの運動スクール向けの機能開発チームでEMをしている藤谷(社内ではしゅんぺいと呼ばれています)です。
最近は柚子胡椒を自作したらかなり美味しくできたので、いろんなものを柚子胡椒味にして楽しんでいます。
話したいこと
hacomonoでは、2023年に運動スクール向けの機能をリリースしました。
まだまだ改善が始まったばかりではあるのですが、1→10フェーズの開発チームにおける品質向上の取り組み状況を共有できればと思います。
背景
2023年に運動スクール向けの機能をリリースし、SMBからエンタープライズへと導入を進める中で、要求品質とのギャップが顕在化してきました。
また、エンジニア組織も2年で 12人 → 76人と急拡大する中で、試行錯誤しつつ品質向上に取り組んでいます。
全体のアプローチ
1. PDCAの仕組み作り
品質向上に向けた取り組みは終わりはなく継続して改善し続けるため、PDCAを回す上での仕組みづくりが重要だと考えています。
- 定量化
- QA実施時やリリース後に検知した不具合について、発生箇所や発生原因の分類を行い、課題や改善状況が定量的に把握できるようにしています
- 検出された不具合が設計レベル か 実装レベルか、検出すべき工程はどこだったのか と言った観点で分類し、改善施策の効果想定を目的にしています
- テスト本の輪読会
- 本番障害に対する意識が高まる中で、より課題や手段を具体化し、世の中のベストプラックティスを知ったり、品質向上に対する意識醸成を行うことを目的にチームで輪読会を行いました
QAエンジニアからおすすめしてもらったソフトウェアテスト本を、チームで輪読会を行いました
テストケースのレビューはしているものの、実施がQAにお任せになっていたことに対する課題意識が強くなったり
- 振り返りでも品質に対する言及が多くなるなど、チーム全体での品質に対する意識面での効果や、スキル面でもテスト設計スキルの向上が見られるなど、改善を行う上での初期の取り組みとしては、費用対効果の高い取り組みだったと思います
2. 上流品質
- PRD(プロダクト要求仕様書)レビューの改善
- PdM、デザイナー、開発・QAエンジニアなど、プロダクト開発に関わる全員で、PRDの読み合わせ・レビューを行っています
- チーム全体の理解度を上げるために、細かな改善ではあるのですが、PRDを各自で事前に読み込んだ上でレビューを実施したり、質問をテキストで記載するなどを行っています
- 事前準備により人による経験やプロダクト知識に差異を埋めたり、QAをテキストで記載することで、議論が明確化、活性化するなどの効果がありました
- 開発ドキュメントの型化
- 検討や設計段階での不具合検知を進めることや、チーム内の議論促進などを目的に、開発ドキュメントのテンプレート化などを進めました
- 機能の振る舞いだけでなく、データ構造やクラス設計などをチームでレビュー・議論進めれるようになることを目論んでいます
- ユニットテストの拡充
- QA主体で機能テスト、シナリオテストを行い、エンジニアがテストコードを実装していますが、APIテストが主体でユニットテストが少ないのが現状です
- APIテストだけで必要なテストケースを網羅するのは難しく、また網羅されているか読み取るのも難しく、本来はユニットテストで検知したい不具合も多い状況でした
- 新規や既存機能の改修を行う際にはユニットテストを書くように改善を進めています
- 一方でユニットテストの網羅率も把握できていなかったりするので、まずは定量的に把握し、ユニットテストの拡充を進める必要がある
- また、フロントエンドはテストコード自体がなかったり、ロジックを持ってしまっているなどの問題があります
- Vue2のサポート切れを年末に控えていることもあり、Vue3への移行と合わせて進め、この辺りを一挙に改善できるように作戦を練っています
- モブプロ、ペアプロのお試し
- より前工程でのバグの作り込みを防ぐことや、ドメイン・プロダクト知識の向上を目的として、ペアプロ・モブプロなどを試しています
- 定性面では、開発に集中して取り組めたり、知識やスキルの移管が進むなどの効果がありました。
- また、弊社は完全フルリモートで業務を行っていることもあり、雑談が生まれるなどのコミュニケーション促進の面でも相性が良さそうだと思っています
- まだまだ目先のプロダクト改善を優先する必要もあり、全面導入には至っていないのですが、複雑な機能の開発など効果が大きいところで優先的に導入を進めていければと思っています
- しっかりとチームとして導入を進めていくためには、定量的な効果測定を進め、チーム内外で合意しながら進める必要がありそうです
- 定性面では、開発に集中して取り組めたり、知識やスキルの移管が進むなどの効果がありました。
- より前工程でのバグの作り込みを防ぐことや、ドメイン・プロダクト知識の向上を目的として、ペアプロ・モブプロなどを試しています
3. テストの実施
- テストケースレビュー
- テストケースについてもQA、開発エンジニアで認識合わせ・レビューを行っています
- また、開発ドキュメントの型化により、テストケースレビューのコミュニケーションが潤滑になったり、テスト本の輪読会によりレビューの質の向上などが見られました
- 探索型テストの追加
- 要求品質や仕様の複雑度、テストで検出したバグの傾向によって、探索型テストを追加しています
- 現状追加したテストと比較しバグの検出数はさほど多くないため、上流のレビュー強化に切り替えている
- より効果的にバグを検出できるような、テスト手法については改善の余地があると思っています
- 要求品質や仕様の複雑度、テストで検出したバグの傾向によって、探索型テストを追加しています
4. 既存機能の改善
運動スクール向け機能はスクールの業態や種目等によって業務やドメインの幅が広く、プロダクトの複雑性が高い傾向があります。
汎用化するところ、シンプルにするところの判断が難しく、仕様が複雑化してしまったところや顧客業務と仕様にギャップが出てしまったところもあります。
まだまだ機能追加や改善が必要なフェーズであり、今後も開発スピードを落とさず改善するためには、仕様や内部品質の改善も合わせて進めています。
- 仕様改善
- 仕様が複雑化し、改修コストが増大していたり不具合発生が多い機能については、仕様自体をシンプルに改善することを行っています
今後取り組みたいこと
パフォーマンス問題の改善
- hacomonoを導入してくださる顧客が増え、データ量やアクセス数も増える中で本番リリース後にパフォーマンス問題が発覚するケースも発生しています
- より検知を早める、リリース前にテストで不具合を洗い出すなど、まだまだ改善の余地がありそうだと思っています
品質リスクの高いコードの改善
- Hotspotsなどの品質リスク指標を元にコードを改善するなど、より前段階での品質向上も進められそうかなと思っています
株式会社hacomonoでは一緒に働く仲間を募集しています!
採用情報や採用ウィッシュリストも是非ご覧ください!