1.はじめに
みなさま、こんにちは。
昨年は以下の記事で、開発チームの実装遅延を改善するため、QAとして私が行った立ち回りについてご紹介しました。
現在担当しているスマホゲームの運営タイトルでも、開発チームの実装遅延や職種間の連携漏れによって障害が発生しており、日々障害削減に取り組んでおります。
今回も品質改善のためにどんな打ち手をとったのかを簡単にご紹介したいと思います。
2.担当プロダクトの状況
前回記事を執筆した際に担当していたタイトルと比較して、現在担当しているタイトルは開発チームの規模や組織成熟度、事業フェーズが異なっています。
- 運用期間：リリースから間もない
- 組織規模：前回担当タイトルの4倍
- 施策規模：新規仕様の施策リリース・機能アップデートが頻繁に行われる
品質面での違いは、新規機能実装・機能改修を行ったことによる既存仕様への考慮漏れで障害が多く発生している点です。
特に、仕様決定＆作業依頼タイミングが開発規模に対して遅延しており、職種間での連携・レビューの時間が十分に取られていないことが課題になっています。
#3.改善のためのアクション
打ち手の方向性としては以下2つです。
- 開発タスクを漏れなく進行したこと（特に「職種間と連携・レビューしたこと」）のエビデンス残し
- 進行予定の開発スケジュールと、開発規模から逆算した本来望ましいスケジュールとの差分を可視化し、実行予定スケジュールを見直さなければいけないのか・そのままの進行でいいのかの明確化
具体的には、施策毎に以下のような開発フローチェックシートを導入しました。
実行の際のポイントとしては以下3つです。
- 経営層への事前コミュニケーション
- 専用チームの編成
- 経過観測
チェックシートの導入＆運用には開発チーム全体を巻き込む必要があったため、最初に部長・本部長へ、現状の品質状況を定量的に提示し、改善に向けた取り組み内容を握りました。
その際に、開発チームでも「品質改善大臣」という立て付けで、導入推進担当のプランナー・エンジニアを立ててもらうよう依頼し、開発チームの担当者とQAのチームを編成しました。
チェックシートの導入にあたっては、QAからいきなり開発全体に周知＆導入するのではなく、事前にプランナー班・エンジニア班それぞれで概要説明を行ってもらい、段階的に導入をしていきました。
チェックシート導入後も、毎週品質改善大臣MTGを実施し、チェックシート運用状況の観測をしています。
チェックシートの進行が滞っているものは施策担当者へ状況を確認し、開発進捗が遅れているものはプロジェクトリスクとして各職種のリーダー陣へ周知する流れで運用しています。
4.チェックシート導入による効果
まだ運用に乗り始めてから1ヶ月ほどですが、現状で出ている効果としては2つです。
1つ目は、開発チームの組織課題が可視化され、体制強化に繋がった点です。
導入後、機能アップデート施策でのチェックシートの運用が毎回滞っており、機能アップデートの頻度・規模に対して、アップデート担当のプランナー班の工数が不足している状況が顕在化しました。
事業計画に対して適切な開発体制になるようにプロデューサーへアラートし、来年から体制変更予定となっています。
2つ目は、クライアントの更新はせず、サーバーデータ更新のみを行う施策での「仕様考慮漏れ」による障害が減ったことです。
チェックシート導入以前は、既存の機能のみで仕様の実現が可能と判断された施策で本番障害が発生し、実は追加実装・機能改修が必要だったことが判明するケースがありました。
サーバーデータ更新系の施策を担当している班ではチェックシートの運用が比較的適切に行われており、図の#4にて「プランナー判断ではクライアントの更新が必要ない施策でも、エンジニアの仕様確認を通す」フローも設けたことで、いまのところ上記のような障害は発生しておりません。
5.まとめ
今回の取り組みで実感したことは以下2つです。
- 開発チーム全体を巻き込む際は、品質に対して意識の高いキーパーソンと密に連携できる座組みを最初の段階でを構築し、段階的に巻き込んでいく
- 開発チームの組織課題に対しては、最終的に開発チームの責任者へ改善を依頼する必要があるが、その際に納得してもらうためのエビデンスを準備することが重要
少しでも、同様な課題に直面されている方の参考になりましたら幸いです。