開発完了からリリースまでのリードタイム改善に挑戦した話

はじめに

これは Kyash Advent Calendar 2024 の13日目の記事です。12日目は おもたに@k_omotani の 「銀行振込設計で考えていること」です。

こんにちは、 Kyashでモバイルエンジニアをしているnitakanです。

金融業界のスタートアップであるKyashでは、品質を担保しつつ、より迅速に価値を提供できる開発フローを目指しています。

開発プロジェクトにおいて、「開発完了からリリースまでのリードタイムが長い」という課題に直面したことはありませんか?
Kyashでもこの問題が存在しており、その改善策としてQAチームをプロジェクトチームに早期から参加してもらうというトライを行いました。

この記事では、以下の取り組みを中心にご紹介します

  • プロジェクト初期段階からのQAチーム参加
  • チケットベースでの要件定義とテスト設計
  • スプリント内でのQA実施

これにより、開発完了からリリースまでのリードタイム短縮に一定の効果がありました。具体的な改善内容や成果について、ぜひ最後までご覧ください。

背景

KyashではQAチームが存在し、専門知識や経験を活かしてテスト観点の作成やテストケースの実施を行っています。

以下はKyashの従来の開発フローです。

このフローにはいくつかの課題がありましたが、この記事では特に「開発完了からリリースまでのリードタイム」にフォーカスします。

従来、QAチームは開発フェーズ後半に参加し、テスト観点やテストケースを作成していました。そして、開発が完了してから全体のテストを実施する形を取っていました。

課題の詳細

筆者が所属する事業部では、ユーザーの利用促進を目的とした施策を多く開発・検証しています。その中で、以下のような課題が見えてきました。

1. テスト観点・ケース作成のキャッチアップに時間がかかる

プロジェクト初期の段階でQAチームが参加せず、仕様が固まってからテストケースを作成していたため、キャッチアップに時間がかかり、手戻りが発生していました。また、要件がドキュメント化されていても、デザインに現れない仕様の確認不足が課題となっていました。

2. 不具合検出のタイミングが遅い

開発完了後にテストが開始されるため、不具合の発見と修正が遅れ、設計や仕様に大きな変更が必要になることがありました。これにより、リードタイムがさらに長引く結果となっていました。

3. QAチームの稼働状況にムラができる

プロジェクト後半にQAチームが集中して稼働する体制だったため、複数のプロジェクトが並行するとリソースが不足し、テスト期間の調整やリリースの遅延が発生していました。

これらの課題が原因で、開発からリリースまでに大きなタイムラグが生じ、迅速な仮説検証が困難になっていました。

トライしたこと

これらの課題を解決するために、以下の取り組みを実施しました。

1. 開発チームに専属のQAメンバーを常駐

プロジェクト初期段階からQAメンバーが参加する体制を構築しました。これにより、要件やデザインのキャッチアップがスムーズになり、仕様の理解が深まることでテスト設計時の効率化を図りました。朝会やプランニングを通じて、日常的なコミュニケーションも強化しました。

2. チケットベースの要件定義に変更

要件や技術仕様、デザインリンクを含めたチケットをユーザーストーリー単位で作成しました。これにより、要件が一元管理され、仕様の不明点が事前に解消される仕組みを導入しました。

3. チケットベースでのテスト設計と実施

開発完了を待たずに、チケット単位でのテスト設計と実施を開始しました。これにより、早期に不具合を検出し、修正範囲を限定化することができました。また、スプリントごとに分割してQAを行うことで、テストの分散化と効率化を実現しました。

4. シナリオテストの追加

チケットベースで実施したテストだけでなく、システム全体の正常系や異常系を確認するシナリオテストを導入しました。これにより、チケット間での仕様の不整合を早期に発見できるようになりました。

改善後のフロー図

改善後の開発スプリントでは、チケットの開発と同時にテスト設計を実施します。
スプリント1で作成したテスト設計は開発チームのレビューを経て、次のスプリントでテストを実施します。
テスト実施をパスするとチケットをクローズする運用としました。

結果

今回の取り組みによって、開発完了からリリースまでのリードタイムに改善が見られました。ここでは、具体的なデータを用いて成果を振り返ります。

定量的観点

プロジェクトA(改善前)とプロジェクトB(改善後)のリードタイムを比較しました。以下は、主要な項目を並べた比較表です。

項目 PJ-A PJ-B
テスト人数 4人 2人
機能テストケース数 214件 441件
シナリオテスト - 92件
回帰テストケース数 584件 100件
開発完了から回帰テスト開始までの営業日数 5日 3日
開発完了から回帰テスト完了までの営業日 8日 5日

回帰テストのテストケース数に違いがありますが、別途改善した結果なのでここでは触れません。

・リードタイムの短縮
開発完了から回帰テスト完了までの営業日数を8日から5日に短縮。全体のリリース時間を約2営業日短縮。

・リソースの効率化
QAメンバーを半減しながらも、より多くのテストケースを実施。

定性的観点

1. 不具合の早期発見

チケット単位でのテスト設計と実施により、不具合を早い段階で検出できました。これにより、修正の範囲が限定され、開発チームの手戻りが最小限に抑えられました。

2. QAチームの認知負荷軽減とスキル向上

QAメンバーがプロジェクト初期から参加することで、仕様や要件への理解が深まり、テスト設計時の手戻りや考慮漏れが減少しました。また、QAメンバーが一連のプロセスに積極的に関与することでスキルの向上にもつながりました。

3. チーム内コミュニケーションの活性化

チケットベースでの要件管理とQAメンバーの常駐により、開発チームとQAチーム間のコミュニケーションが密になりました。これにより、要件の不明点や不整合が早期に解消されるようになりました。

4. 品質向上

シナリオテストの導入により、単一のチケットだけでなく、チケット間の整合性を確認するテストを実施。これによりフロー全体の品質担保をしています。

課題と改善策

今回の取り組みでリードタイムの短縮や品質向上が実現できた一方で、新たに見えてきた課題や改善すべき点も明らかになりました。以下に具体的な課題と、それに対する改善策を紹介します。

1. QAメンバーへの負荷集中

プロジェクトに参加するQAメンバーが少なくなるにも関わらず、多くのテストタスクが集中することで、負荷が増大し、対応スピードやモチベーションの低下につながる懸念がありました。

[改善策]
・リソースの優先順位付け
プロジェクト間で優先順位を明確化し、QAメンバーのアサイン計画を適切に管理する。

・チーム全体で品質を担保
開発メンバーがテスト実施の一部を担当するなど、品質管理をチーム全体で共有する仕組みを導入する。

・外部リソースの活用
必要に応じて短期的に外部QAリソースを活用し、負荷を分散します。

2. 開発中に不具合修正が発生し、作業が並行する

開発スプリント内で前スプリントの不具合修正を行うケースが多く、通常の開発タスクと修正タスクが並行してしまうことがあります。これにより、集中力や生産性が低下する可能性があります。

[改善策]
・不具合のトリアージ
検出された不具合を優先度に基づいて分類し、軽微な問題は次のスプリント以降に回す。

・テスト自動化の強化
自動化テストのカバレッジを拡大し、特定の領域での不具合検出を効率化する。

・スプリントレビューの強化と開発品質の向上
チケットの開発時に開発メンバーによるクロスチェックを実施し、思い込みや見落としがないか確認する。スプリントレビューでチーム全員で開発したものを触り、改善点を挙げる。

3. 要件の記載不足や不明点の確認

チケットベースで要件を管理する方針に切り替えましたが、要件の記載が不十分であったり、曖昧な部分が残るケースが発生しました。この結果、テスト設計時に確認作業が発生し、リードタイムが延びることがあります。

[改善策]
・チケット作成のタイムボックス化
スプリント内にチケット作成の時間を設け、内容をチーム全体でレビューする仕組みを導入。

4. スプリント間でのテスト内容の重複や仕様変更の影響

スプリントごとにテストを進める開発手法では、テスト内容がスプリント間で重複する場合があり、後続のスプリントで仕様が変更されるとテスト設計に手戻りが発生することがあります。

[改善策]
・変更点の透明化
仕様変更が発生した場合、チケットやテストケースに明記し、早期にチーム全体に共有します。

・許容する運用
スプリント間での重複を許容し、テスト内容を柔軟に更新することで負担を最小化します。

これらの課題を許容しつつ、改善策を継続的に取り入れながら、開発フローの効率化をさらに進めていきます。課題を完全に排除するのではなく、適切に管理しながら改善を続けることで、より柔軟で効果的な開発フローを目指していきます。

おわりに

開発チームの運営は課題が多く改善できるところの塊です。

KyashのValueである「動いて風を知る。」 は、まさにアジャイルな考え方です。あれこれ考えるのも必要ですが、実際に試して結果を元に次の動き方を考える姿勢を推奨しています。
スタートアップならではのスピード感の中で、各メンバーが自分の役割に責任を持ちながらも、必要に応じて助け合う文化が根付いています。

「動いて風を知る。」に共感し、新しいお金の文化を一緒に創りたいと思う方、あるいは少しでも興味を持っていただけた方は、ぜひカジュアル面談で私たちとお話ししましょう!
プロダクトやチームの裏側、Kyashの挑戦について、ざっくばらんにお伝えします。

https://herp.careers/v1/kyash

私たちと一緒に、風を感じながら前に進みませんか?
お会いできるのを楽しみにしています。

それでは!