はじめに
はじめまして！
株式会社SUPERSTUDIOでエンジニアをしています、@SuperLazyDog と申します。
弊社では「ecforce」というAIコマースプラットフォームを提供しています。
私の所属するチームでは、新規API基盤の本番提供に向けて、開発・試験・リリース等の体制の整備を進めています。
前回は@nakaearthがAPI基盤の開発背景について紹介しましたが、今回は新規API基盤の設計・開発・QA・リリースフローの改善に関するお話です。
前提として、新規API基盤はまだファーストリリースから次のリリースに移行する期間にあります。また、メンバーの増減があり、チームとしてフレキシブルな開発プロセスを再構築する必要がありました。
従来のリリースプロセスでは、デプロイ作業やコミュニケーションなどが改善できる余地があり、開発効率の低下やヒューマンエラーのリスクが懸念されていました。
本記事では、その改善の経緯と具体的な施策についてご紹介します。
本題
目次
1. 改善の背景
新規API基盤は現在開発段階にあり、まだ本番提供には至っていません。しかし、将来的な本番運用を見据えて、設計・開発・QA・リリースの一貫したフローを確立することが急務となっていました。
本番運用に向けた課題
1. リリースフローの整理
現在の開発プロセスでは、デプロイの頻度やタイミングが明確に定まっておらず、リリース準備を含めた作業フローが確立されていませんでした。また、リリース作業が特定のメンバーに依存する属人化の問題も発生しており、スケーラブルな運用体制の構築が課題となっていました。
2. 品質管理
テスト漏れのリスクや、開発やQAが完了していない機能が意図せずにリリースされるリスクが存在していました。これらの問題は、本番環境での予期しない動作やバグの発生につながる可能性があり、顧客体験に直接的な影響を与える課題でした。
3. 仕様漏れが発生しないような設計フローを確立する
設計の段階で考慮漏れが発生するリスクがあり、開発途中やリリース後に仕様の見直しが必要になるケースが散見されていました。このような手戻りは開発効率を大幅に低下させ、チーム全体の生産性に影響を与えていました。
4. QAと開発で共通認識を持てるようにフローを確立する
QAと開発チームの間で認識の齟齬が発生し、QA失敗による手戻りが発生していました。この問題は、単純な作業の重複だけでなく、チーム間のコミュニケーションコストの増大や、プロジェクト全体のスケジュール遅延にもつながっていました。
上に列挙した点を解決することで本番で安定した運用が出来るようになると判断し、様々な取り組みを開始することにしました。
2. 従来のフローの課題と施策
まず、改善前の従来のリリースフローを確認してみましょう。以下の図は、私たちが以前に使用していたリリースフローと、各段階で発生していた課題を示しています。
1. 開発プロセスの共通理解
背景
- 改善前は主にエンドポイント開発の完成がメインで、設計・開発・QA・リリースの一連の流れについて明確な共通認識が形成されていませんでした
- 各自の理解のままで進めていたため、責任の所在が曖昧で作業の順番が異なるなど、様々な課題が発生していました
- 開発段階であり本番運用がないため先延ばしにされていた側面もありますが、作業効率化の観点からもチーム全体で共通認識を持つべきと考えました
施策
- 現状フローの整理：設計・開発・QA・リリース流れを整理し、チームMTGで認識合わせを実施
- 課題の抽出：フローの各フェーズの課題を抽出し、各メンバーと一緒に考える機会を設ける
- 共通認識の形成：課題の存在及び改善の必要性について共通認識を形成
結果
- 共通認識の確立：明文化されていなかったフローについてチーム全員が共通認識を持つようになりました
- 改善基盤の整備：現状フローの改善への土台が整いました
2. 見積もり精度の向上
背景
- プランニングはタスク着手前の工数予測作業で、個別リリースのスケジュール策定やチーム全体のロードマップ策定、定量的なチーム成長測定のために必要不可欠だと感じていました
- 課題1：機能開発は定型のストーリーポイント（以下、SP）の付け方がある一方、機能以外の個別タスクでは各メンバーによるばらつきが発生
- 課題2：AI活用により習熟度によってタスクボリュームが変動し、SPが流動的になってベロシティ計測が困難になっていました
施策
- 共通基準の確立：SPのボリュームについてチーム内で共通認識を形成（AI活用を前提としないやり方を基準に設定）
- 柔軟な見積もり方式：複雑なタスクは調査段階のみプランニングポーカーでSP付け、残りは各メンバーの裁量に委ねてベロシティで妥当性をチェック
- 継続的改善：運用しながら改善を重ね、チーム全体でSPに関する共通基準を確立
結果
- 効率化の可視化：AI活用による効率化を完了SP数で測定可能になりました
- チーム成長の実感：前期を通じてベロシティが4倍弱に増加し、チームの成長を実感しました
- 計画精度の向上：開発計画・スケジュール策定にベロシティを活用できるようになりました
3. 仕様漏れを防ぐための取り組み
背景
- 設計フェーズはPDM要求を実現するための仕様設計と詳細設計で、実装の前提となる重要な段階です
- 課題1：PDM要求は概要レベルで、エンジニア側の判断部分が大きく、認識の齟齬が発生し、あるべき設計になっていないリスクが存在していました
- 課題2：設計レビューを通じても課題が残るケースが実際に発生していました
- 課題3：QA側には仕様に必要な動作レベルの知見が蓄積されているにも関わらず、開発に十分に取り入れられていない状況でした
施策
- QA連携の強化：設計とPDMレビューの間にQAと連携して試験観点を事前作成し、それを基に設計を改善
- セキュリティ観点の追加：試験観点にセキュリティ観点を加え、設計段階でPDM・エンジニアに加えQAも関与
結果
- 要件の明確化：設計段階で実際の機能が満たすべき機能要件やセキュリティ要件を明確化し、考慮漏れのリスクを軽減
4. リリースまでのプロセスに効率的なQAを実施
背景
- 新規API基盤はまだ本番提供に至っていないため、リリース可否の観点が強く意識されておらず、以下の課題が発生していました
- 課題1：未完成機能の一部やQA未実施機能が次回リリース予定のブランチにマージされるケースが散見されていました
- 課題2：本番提供を見据えた品質担保のため、開発完了機能のマージ条件及びリリース条件の整備が課題でした
施策
- 未完成機能のマージ防止：依存関係のあるタスクについてベースとなる親ブランチを設け、子タスクを全て完成しないとマージできない条件を設定
- QA未完了機能のリリース防止：QA依頼タスクの一覧表を設けてチェックボックス運用を導入
詳細は下図をご確認ください。
- QA未完了機能のリリース防止に関しては、開発時にQAの試験観点を含めるで後述しますが、QA依頼タスクの一覧表を設けてチェックボックス運用にしました
結果
- 意図しないマージの防止：ブランチ運用の改善により意図しないマージを防止
- 品質保証の徹底：QA完了を個別機能リリースの必須条件としたことで、意図しないリリースを防止
- 品質向上の実現：意図しないマージやリリースを防ぐことで、機能の品質向上を実現
5. 開発時にQAの試験観点を含める
背景
- AI活用によるQA自動化の進展により、従来できなかった効率化が実現し、QAチームに余力が発生していました
- 従来のQA依頼方式：エンジニアが機能単位で開発完了後、個別にQAに試験依頼をしていました
- 課題：QAの試験観点が開発段階で考慮されず、本来防げる不具合がQA段階で発覚し、手戻りが発生していました
施策
- 設計段階での品質向上：QAの試験観点とセキュリティ観点を設計段階で取り入れ、考慮不足を事前に防止
- 依頼方式の改善：個別依頼からスプリント毎の一括QA依頼に変更
- タスク管理の一元化：QA依頼のタスク管理を一元化し、チェックボックス運用を導入
- 担当者の明確化：スプリント毎にQA担当者を決定し、ローテーション制を導入
結果
- 手戻り削減：設計段階でのQA観点取り入れにより、QA失敗による手戻り作業を大幅削減
- 効率化達成：スプリント毎の一括QA依頼により、試験環境のデプロイ作業が激減し、QAとエンジニアの重複作業を削減。前期ベロシティ3桁達成に大きく貢献
- 品質保証の徹底：チェックボックス運用により試験状況が可視化され、QA未完了タスクのリリースを完全に防止
6. 属人化によるリスク
背景
- 新規API基盤は管理画面側でecforceを利用しているため、リリース作業にはecforceのリリースも一部必要となっていました
- リリース準備作業が複雑で、個別手順は存在するものの一連の流れがまとまっておらず、チーム内部で属人化していました
- 本番提供を見据え、リリース準備とリリース作業の両方の属人化解消が急務。ブラックボックス化によるセキュリティリスクの解消も必要でした
施策
- マニュアル化：リリース作業の一連の流れをマニュアル化し、作業のハードルを低下
- 自動化の推進：AI活用によりQA試験依頼と内部リリースノート作成を全自動化
- 全員参加の仕組み：リリース頻度を固定し、エンジニア・QA全員が同席する体制を構築
- 輪番制の導入：一連の作業を輪番制で回し、属人化を解消
結果
- 作業の明確化：リリース関連作業の流れを明確化し、自動化による負荷軽減で作業効率を向上
- 属人化の完全解消：輪番制の導入により属人化を完全に解消し、チーム全体での知識共有を実現
3. 新しいフロー
改善施策の一覧
上記の図は、改善後のリリースフローと各段階で実施した改善施策の全体像を示しています。
フローの特徴
- 7段階の明確なプロセス：リファインメントからリリースまで、各段階の役割と責任が明確化
- 品質保証の強化：設計段階でのQA試験観点の活用と、QA完了の必須化
- フィードバックループ：設計レビューでの再設計、QAでの修正など、品質向上のための循環構造
改善施策の体系化
- 6つの主要課題を特定し、それぞれに対応する具体的な改善施策を実施
- 課題と対策の可視化：各段階で発生する課題とその対策を明確にマッピング
- 継続的改善：運用を通じて改善を重ね、チーム全体での知識共有を実現
4. 導入後の効果と今後の展望
導入後の効果
定量的な成果
- ベロシティの向上：前期を通じてベロシティが4倍弱に増加し、チームの成長を実感しました
- 効率化の可視化：AI活用による効率化を完了SP数で測定可能になりました
- 品質向上：QA失敗による手戻り作業を大幅削減し、意図しないマージやリリースを完全に防止できました
定性的な成果
- 共通認識の確立：チーム全員がフローと課題について共通認識を持つようになりました
- 属人化の解消：リリース作業の属人化を解消し、チーム全体での知識共有が実現できました
- 作業効率の向上：スプリント毎の一括QA依頼により、試験環境のデプロイ作業が激減し、重複作業を削減できました
チーム文化の変化
- 協働の促進：PDMとQAとエンジニアの連携が強化され、設計段階から品質を意識した開発が定着しました
- 継続的改善：運用を通じて改善を重ねる文化が根付き、チーム全体での知識共有が活発化しました
- 責任の明確化：各段階での役割と責任が明確になり、チーム全体での品質意識が向上しました
今後の展望
- 本番提供への準備：現在の改善されたフローを本番環境での運用に適用
- 自動化の拡張：AI活用をさらに強化し、作業の効率化および最適化
- メトリクスの充実：品質指標や効率指標をより詳細に測定し、継続的改善の基盤を強化
5. まとめ
新規API基盤チームにおけるリリースフローの改善を通じて、本番運用に向けて大きく前進しました。
主要な成果
1. プロセスの体系化
- 7段階の明確なリリースフローを確立し、各段階での役割と責任を明確化
- 6つの主要課題を特定し、それぞれに対応する具体的な改善施策を実施
- 課題と対策の可視化により、継続的改善の基盤を構築
2. 品質保証の強化
- 設計段階でのQA試験観点の活用により、考慮漏れのリスクを大幅に軽減
- QA完了をリリースの必須条件とし、意図しないリリースを完全に防止
- ブランチ運用の改善により、未完成機能のマージを防止
3. 効率化の実現
- ベロシティが4倍弱に増加し、チームの成長を実感
- スプリント毎の一括QA依頼により、重複作業を削減し、効率を大幅に向上
- AI活用による自動化により、人的ミスのリスクを最小化
4. チーム文化の変革
- プロセス理解の不足を解消し、チーム全員が共通認識を保有
- リリース作業の属人化を完全に解消し、チーム全体での知識共有を実現
- 継続的改善の文化が根付き、品質を第一に考える意識が向上
学んだこと
課題解決のアプローチ
- 表面的な問題ではなく、根本原因を特定することの重要性
- チーム全体での共通認識形成が、効果的な改善の前提条件であること
- 継続的な改善と運用を通じた学習が、持続可能な変革の鍵であること
チーム運営のポイント
- 自律型組織の構築を通じて、各メンバーが自ら課題を発見し解決策を実行できる環境を整備することの重要性
- 各メンバーの役割と責任を明確にし、協働を促進することの重要性
- 自動化とマニュアル化のバランスを取り、属人化を防ぐことの必要性
今後の展開
リリースフローの改善は単なる作業効率化ではなく、チームの協働文化を育み、持続可能な開発体制を構築するための基盤となる取り組みでした。この経験を活かし、さらなる改善と成長を続けていきたいと思います。
SUPER STUDIOの採用について
SUPER STUDIOでは、エンジニアを採用しています。
少しでも興味がありましたら、以下をご覧ください。
下記の記事は、SUPER STUDIOのキックオフイベントで表彰されたエンジニアのインタビュー記事です。
SUPER STUDIOのエンジニア組織をより理解できる内容となっておりますので、ご一読ください。
Discussion