品質管理部の体制変化の1年間:リリースに対しての戦略と今後の展望

品質管理部のtarappoです。

早いもので2023年度となりました。 私が10Xに入社して、そろそろ1年がたちます。

この1年間の間にいろいろとあったので、その内容について話していきたいと思います。

ただ、すべてを話すには1回の記事では足りないのでいくつかに分けて話していきます。 本記事では、この1年における「体制の変化とその理由」ということにフォーカスしていきます。

はじめに

品質管理部は、プロダクトの品質という点にフォーカスしてさまざまな課題に取り組んできました。 直面する課題は多岐にわたり、それらを解決するためにさまざまな取り組みが求められました。

その中で、この1年間でおこなってきたことを大きく分けると次のようなことがあります。

  • 問題の特定と改善の取り組み
  • テストプロセスの改善
  • プロダクトの品質を守るためのテストの強化
  • 全員品質に向けたQAオンボーディング
  • 体制面の変化

この1年間でQAチーム、そして品質管理部と組織が変化し、その中で体制も大きくかわりました。 そこで、本記事では「体制面の変化」についてフォーカスして話していきたいと思います。

目次

初期の体制と最初におこなったこと

私が入社した2022年4月時点では、私と外部検証会社の方々という体制でした。 その中で、最初におこなったこととしては、次の方針を元に進めていきました。

「限られた時間の中で本当に大事なことにフォーカスしていくために、そのフォーカスすべきものがなにかを定量的に分かるようにする」

その中でまず進めていたのは主に次の2つです。

  • 定量的に分かるようにするための土台の構築(例:不具合分析やコスト判断など)
  • テストプロセスの改善

入社から2か月の間についての話は次のブログ記事に書いてあります。

これらの初期の交通整理を整えていく中で、考えるべきこととして次がありました。

「どのように、どこまでリリースに関わっていくか」

この点が、今回話す体制の変化に強く関係していきます。 そのためこのことについて次以降に説明をしていきたいと思います。

2つのリリースに対するアプローチと体制検討

我々のリリースは大きく分けて次の2種類があります。

  1. 新しいパートナーのローンチ
  2. Stailerの機能追加や改修

前者と後者では考えるべきことや行うべきことは異なります。 メンバーのスキルや人数、そしてそれぞれのリリースにおいて必要なことは何かを元に次のような戦略をとることとしました。

  • 1への戦略:専任メンバーをアサインし型化を進めていく
  • 2への戦略:リリースする案件の多くに関わっていく

この2つを進めるためにメンバーが1人増えた入社2か月後での体制図は次のとおりです。

2つのリリースについての歩みについて次に1つ1つ説明をしていきます。

1. 新しいパートナーのローンチ

パートナーのローンチは今後も続くことが想定されていることもあり、QAプロセスの見直しは重要でした。 そのため、どこをどのように守っていくようにするか、それに対してどのように進めていくかという点については、根本的に見直しをする必要がありました。

そこで、専任としてメンバーを1人アサインしました。 このメンバーにリードしてもらい型化を進めてもらいました。

それにより、型化が進むだけでなく併せてローンチの中で多くの機能に携わるという側面から、潜在している問題を発見し適切な改善フローに乗せることまでできました。

この「新しいパートナーのローンチ」においては、1年前と比べると型化が進み最適化されたことでかかる工数は大幅に削減しています。 この1年間で、大枠のプロセスは整備できたので、今年度は運用を続ける中で発生する課題や改善点を見つけるための測定や可視化にフォーカスをしていきます。

少ない行数でさらっと書いていますが、おこなった内容についてはいろいろとあったため、その詳細については別の記事で紹介できればと思います。

2. Stailerの機能追加や改修のリリース

機能追加や改修におけるリリースにおいてどのように関わっていくかを検討した結果、1つのチームに深く関わるというスタイルではなく、リリースする案件について関わる範囲を広げていくこととしました。

こうした理由としては、次があります。

  • Stailerは複雑な作りであり、チーム単位で明確に分かれているわけではなく、全体的に考慮するべき点が多い
  • 現時点で潜在バグがいろいろな箇所にある状態である

特定のチームのみに関わった場合、関わっていないところの品質がわるい状態になると、全体に影響するバグが生まれてしまうことがあります。 そして、場合によっては見つからずに新たな潜在バグを生み出してしまうおそれがあります。

早い段階から作り込みをしていきたいという思いは強くあるものの、まずそこに強くコミットするのではなく「全体的に守っていく」というスタイルをとることとしました。

当然ですが、このやり方についてはデメリットがあります。

  • 1つ1つの案件に早く関わることがむずかしい
  • 案件をスケジューリングするためにすべての案件の中身を知る必要がありその判断にコストがかかる

したがって、この体制を続けることは「我々の目指すQAの姿」から離れやすいというのがあります。

そのため、長くこの体制のままでいくというのもよくないと考えていました。 しかし、メンバー数や現行メンバーのスキルを考慮した上でこの時点ではこの体制を選択しました。

この体制の方向性を元に進めていった上での関わる案件数の変化については次のとおりです。

Phase0:現状把握

最初の段階で私たちがどの程度関われているかを可視化したものが次です。

色についての情報は次のとおりです。

当初は開発者確認というものはなく、すべてにおいて関わっていた案件のみでした。 開発者確認においては、すべてを任せるというわけではなくて、「何を見るべきかの共有」や「テストケース作成」など関わり方に濃淡があります。

Phase1:定量化

現状の私たちがどこまで対応できるかを把握するためにリリースする案件すべてに関わることを宣言しました。 これと併せて主にどこに時間がかかっているかをJIRAチケットにデータを入れることで可視化もおこないました。

この時点での対応できている案件数は次のとおりです。 ここから関わり方の濃淡をつけて「開発者確認」というパターンを用意しました。

ここで分かった課題としては次がありました。

  • リリースする案件の優先順位が分からない
  • 上記により全体的なスケジューリングをすることがむずかしい
  • テスト資産の積み上げがあまりないことにより、新規にテスト設計をすることによる工数がかかっている
  • 検証環境が完全に独立して存在していない、デバッグ機能が少ないことによってテスト実施に一定のコストがかかっている

Phase2:専任メンバーのアサイン

上述した課題を解決するためには、ここにコミットするメンバーが必要でした。

そこで新たなメンバーが入社した段階で、案件の全体把握をするために専任メンバーをアサインし、全体のスケジュール調整や関わり方の濃淡をつけるようにしました。

この時点での体制は次のとおりです。

この体制になってから「リリースのスケジューリングの最適化」や「案件への関わり方の濃淡」、そしてSWEと連携してのデバッグ機能の実装などを進めてきました。

その結果として、関わった案件数については次のように右肩上がりになっています。

テスト資産の積み上げについては、まだ十分ではないものの一部において進んでいます。 その点については、別の記事で紹介できればと思います。

新たな体制への変化

当初の想定どおりに関わる案件数は増えており、1年の成果として次のようになっています。

しかし、今のやり方における当初想定していたデメリットが徐々に課題として見えてきました。

  • これ以上関わる案件数を増やすことの限界さ
    • 窓口となるメンバーの負荷が高まってきている状態
  • 早く、深く案件にかかわることのむずかしさ

そこで、新メンバーの入社タイミングが見えてきた段階で次の体制について検討をはじめました。

専任メンバー制のトライアル

4人目のメンバーが入社した時点で特定チームにおける専任メンバーとしてアサインすることとしました。 このやり方でうまくいくかどうか、そして他でもうまく進められるかについて検討していきました。

専任メンバーを作ることで、より早く案件に関われますし、より深く関わることができます。 これにより「仕様を一緒に作る」というレベルで早く関わることができるようになります。 また、その対象の機能に対して深く知ることができることで、より細かくチェックできるようになります。

新体制の導入と今後の展望

今年度から、品質管理部としては各チームに対して1人ずつ専任メンバーを固定化しています。 現時点では次の体制となっています。

各チームの窓口としてメンバーを固定化しています。 そのメンバーがチームに加わってSprint Planningから入っていくようにしています。

今回の新体制における展望として、この体制になったことによって次が進むと考えています。

  • より早くみつける
  • より深くみつける
  • まだ見つかっていないバグを解体する

しかし、まだ次のような課題も現時点ではあります。

  • まだ人数不足があり流動的に動くことが一定あるためチームに完全専念とはいかない
  • 結果として1人で複数アサインの箇所がある

上記の課題を解決していくためにも、採用については今年度もまだ強化中です。

今後の体制についても検討しており、どういったスキルをもつメンバーが今後必要かについても考えています。 別の記事に書きますが、最近ではSETスキルが強いメンバーも募集しています。

まとめ

品質管理部はこの1年で「広く案件に関わってリリースを守っていく」というスタイルから「専任メンバーをアサインすることでプロダクトに早く、深く、広く関わり価値を守っていく」スタイルと、それを実現するチーム体制へと変化し始めました

この体制へと変わるまでに1年かかりました。 当初の想定より時間はかかってしまったものの、この先も状況にあわせながらよりよい体制に変化させていくつもりです。

今回は体制面の変化について話しましたが、他にもいろいろな課題に対して取り組んでいます。 さまざまな取り組みを通して、品質管理部はプロダクトの品質を向上させるために、日々進化し続けていくと思っています。

興味がある方は是非とも話をしましょう。 お待ちしています。