QA組織として過去と未来についての話

医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで介護事業者向け経営支援サービス『カイポケ』でQA組織の管理者をしている清水です。2019年1月に入社し、QA組織の管理者として組織づくりや体制強化を進めてきました。

本記事は入社した当時の状況から現在にいたるまでの組織強化の過程、QA組織としてこれからの展望をまとめたものです。

カイポケQA組織の歴史

カイポケはサービスを開始してからありがたいことに介護業界でのニーズが高く、サービスの拡大を追う形で開発組織形成をしている歴史があります。

QA組織はできてからの歴史が浅く、元々QAのメンバーはカイポケの機能チーム毎に開発の一部としてテストを実施するメンバーで配属されていました。2017年頃より品質を独立した組織で担っていくことをミッションとし、機能チームに特化せず独立したQA組織をつくりはじめました。

QA組織をつくりはじめたものの、カイポケの成長スピードの速さとサービスとしての複雑さもあって、安定した品質を実現することのできる組織の構築には時間がかかっていました。そうした状況下で、業務委託メンバー中心であったQA組織に、最初の社員として入社したのが私でした。品質保証の精度を上げるための取り組みを、スピード感をもって進めることが主な使命でした。

入社当時のQA組織の状況とこれまで

前述の経緯で縁があり2019年1月に入社しましたが、QA組織に加わった時の印象はよく覚えています。「やることがいっぱいだ」と。

当時、QA組織としては、リリース前の品質に対して防波堤以上の役割で価値貢献がほとんどできていませんでした。そのため、エンジニア側の期待感との温度差があったり、検証業務以上の関わりができないためQAメンバーがキャリアパスを描けずに組織を離れたりと、入社してすぐに様々な課題が目につきました。

また、俯瞰した目線でQA組織としてあるべき姿、求められている姿からと乖離があったとしても、最低限の検証業務自体はできているため、かえって状態の健全・不健全さが一見すると分かりにくい状態でした。そのため、危機意識や課題感があまり強く持たれておらず、取り組むべき課題の整理に苦労しました。

その上で大なり小なり取り組んだ課題は多いのですが、主に以下3つをまとめましたので各取り組みに関して掘り下げて紹介します。

  1. QA組織として目指すべき指標の設定
  2. テスト観点の妥当性考慮不足への取り組み
  3. 課題解決を担えるQA組織のメンバーの採用・育成

課題について詳しく書く前に、あらかじめ断っておくと、入社時は(確かに課題は多かったものの)ネガティブな印象だけではなく、ポジティブな印象も数多くありました(そしてそれは現在でも変わっていません)。

まず、QA組織のメンバーはサービスへ向き合う姿勢はしっかりと持っており、一緒に取り組んでいきたいなという気持ちが強く持てました。

またエンジニアに関しても、過去経験してきた現場ではQA組織の発言権が弱く対等に話ができない場面も数多く遭遇してきましたが、エス・エム・エスではエンジニアとQAが対等に業務に取り組める環境です。またエンジニアはスキル感や成長意欲の高いメンバーが多いため、働きやすいという印象は今も変わっていません。

環境に関しても上司は品質への意識が高いため、試行錯誤で失敗したり、芽が出るのが数年スパンの施策でも取り組む際に積極的に後押しをしてくれました。このことがが、後述するように苦労した点は多かったものの、モチベーションが下がらずやれた要因であったのではないかと思います。

QA組織として目指すべき指標の設定

一般的なQA業務は検証だけに留まらず非常に幅が広いため、現場によって役割が大きく違ってきます。

エス・エム・エスでは、QA組織ができてからは機能仕様が固まった段階から参画することが多く、リリース前の防波堤の役割に注力しており、検証業務がメインとなっていました。

また、プロセスが決まっておらず人により成果の差が激しかったほか、案件がワンショットで終わっているため、問題が起きた際の課題解決への取り組みも積極的に行われず、品質保証としては非常に不安定な状態でした。

さらに、解決に向けて難易度を上げている要因として、あるべき論の理想からチームに反映させようとするとハレーションが起きやすいこともありました。カイポケには機能チームが当時4つあり、各々のチームで独自の開発スタイルを持っているため、QA組織として取り組むべき課題と各チーム毎で取り組むべき課題とで分かれていたことが理由の一つです。また、QA組織の設立からの歴史は浅くても、検証業務自体は歴史があり、業務スタイルが一定文化としてあったため、抜本的に変えようとして大きく失敗した経緯もありました。

そこで、まず検証業務プロセスのフローやフォーマットを策定し、各チームでの不足分の明確化やプロセス導入への障壁を下げることを試みました。

f:id:bm-sms-product-dev-saiyo-pr:20211102112209p:plain
図:キックオフ以後リリースまでの流れのフロー

また、QAの役割についての意識を合わせることにも努めました。QAは、品質を担保・向上を担う役割として、検証業務以外にも要件定義から参入し、検証業務の中で培った操作に関する知見や、顧客要望の分析の成果を活かしながら、関係者と仕様を決めたりと、開発プロセス全体に関わっていくべきだと私は考えています。この点を繰り返しミーティングなどの機会で伝えるようにしました。

一方で、べき論だけでは具体的な行動に結びつきづらいこともあるので、プロセスの中に行うべき作業や、作成すべき成果物を定義し、運用をしていくなかで、徐々に身につけていけるように工夫しました。

自身で何が必要かを考えること、業務を行うなかで自然と意識付けられていることの両面で取り組んだことで、まだ取り組むべき課題はありますが検証業務以外にも意識は向けられるようになってきており、メンバーから取り組みたい施策の要請があるなど、成果を感じています。

テスト観点の妥当性考慮不足への取り組み

検証業務に際しては、テスト観点を作成しますが、従来作成していたテスト観点には妥当性を欠いている部分が多々ありました。つまり、本来であればテストをしなければならない観点が脱落してしまっていたり、逆にテストが必要ではない(修正の影響範囲外の)観点が入っていたりしました。限られた人員・時間で検証を行うためには、テスト観点の妥当性を向上させることが不可欠です。

妥当性を欠く主な要因としては、大きく以下の2つが挙げられます。

1:カイポケの構成が複雑で影響範囲の把握が難しいこと

カイポケは本記事冒頭でも記載した通り、サービスの急成長に長期的な運用を考慮した構成が追いついておらず、影響ないと思われた機能で不具合が発生することもあります。機能追加や変更時にエンジニアと影響調査を確認しますが、現状では明確に範囲の線引きができるには至っていないことがあります。

QAの職責として、「不安なので検証を行おう」という姿勢でよしとせず、影響範囲に絞って検証を行うことを目指していますが、今のところは、「影響しないであろう」といった場合でも影響がないと根拠をもって言えない場合は、回帰テストのボリュームを減らせずに実施しています。

2:検証条件の組み合わせの検討不足

カイポケ自体の仕様として組み合わせが非常に多い機能であり、粒度を粗くすると特定の組み合わせの不具合を見逃してしまいやすく、逆に細かくすると途端に工数が膨大になってしまうため、バランスを考慮しながら観点を作成する必要があります。しかし、まだまだ過分な組み合わせを実施していたり、条件の考慮不足から本番環境での不具合に繋がったりもしています。

課題を一掃できる銀の弾丸は存在しませんが、QA組織の内部に限定せず、エンジニアと一緒に「何ができるか」を考え、様々な施策を試しながら妥当性の向上を図ることを通じて、本番環境での不具合の減少や、品質を維持したままでの検証工数の削減が少しずつできるようになってきています。以下は取り組みの例です。

  • エンジニアとのコミュニケーション・シフトレフトへの取り組み
    • 影響範囲を双方案件の早い段階から意識徹底
  • 案件の振り返りで特記事項を関係者で共有
    • 各案件での検証を通じた知見をQAチームとして次回以降に繋げる
  • テスト結果の分析
    • ポストモーテム開催等で不具合発生傾向を分析し次回以降に繋げる
  • 定期的な関係者間でのコミュニケーション
    • Dailyでの朝会や昼会
  • プロダクトへの理解向上
    • カイポケを学ぶ時間を増やしたり、知見者から使われ方を学ぶことでユーザーストーリーを意識し観点作成精度を高める

課題解決を担えるQA組織のメンバーの採用・育成

入社当時は、検証ボリュームに対してQA組織のリソースでは足らず、開発や事業部など関係者にも手伝ってもらうほどでした。そのような状況の中では、検証だけで満足せずに、不具合を作りこませないなどといった課題に取り組むことは到底できませんでした。

このような状態からのスタートでしたので、もちろん、まずは検証業務を十分に実施できるようにすることが最初の一歩ではありました。しかし、検証業務ができるというのはあくまで通過点です。目指していたのは、当初から課題解決に取り組めるようなQA組織の構築でした。そこで、検証業務に特化せず俯瞰したチーム運営の経験や、課題解決能力が高いというスキル、当事者意識をQAエンジニアが持てるように、採用や育成、価値観の共有に取り組みました。

採用に関してはスキルセットを時間をかけ精度高く作成しミスマッチを極力防ぐようにし、リソースは不足しているものの妥協せず人選し定着率を上げることで、結果として長期で課題に取り組む際の交代引き継ぎのコスト削減に繋がりました。

また、育成に関してはメンバーがやりたいことや学びたいことを優先しながらチームに還元できる事を話し合うことを重視しました。必ずしも直近の課題解決に繋がらなくても取り入れることで、モチベーション高く取り組むことができました。そして直接的に繋がらなくても何かのタイミングで役に立つことがあったり、モチベーションが高く維持できることで他の施策にも意欲的に取り組めたりしました。

結果2年ほどでQA組織も大幅に拡大し、検証ボリュームに対しQA内でこなせる体制にはなりました。今では、チーム内で課題を出し解決に向けて対応を行ったり、防波堤としての役割から関係者と共に早い段階からQAとして指摘を仕様に反映させるなどの取り組みができる体制になってきています。

これからQA組織として目指していきたい姿

ここまで、入社時に感じた課題への取り組みを書いてきました。最近では、(もちろん課題は全て解消できているわけではありませんが)「QA組織としてのあるべき姿」を意識して、その実現に向けた取り組みにも手をつけられるようになってきました。

私が考えるQA組織として目指したい姿は、「ユーザーに人に教えたいと思えるようなサービスを、品質という観点から手助けできる組織作り」です。すべてはここが原点であり、目指す姿だと思っています。

人に教えたいと思わせるには、基本的な機能や品質が充足していることに加え、使用していて「使いやすい、便利!」と思ってもらえることが必要になります。

基本的な機能や品質が充足するには、前述で書いた品質を安定的に担保できる仕組みの構築と運用を行う必要があります。また、「使いやすい、便利!」と思われるにはユーザーの使い勝手や求めているものを正確に分析し、素早くリリースできる体制が必要だと思います。

このような考え方に立脚して、「では、そのような仕組みや分析を実現するにはどうすればいいのか」、というように、目指す姿から逆算して現在の位置を把握し、どんな課題を解決する必要があるかを考え、取り組んでいます。もちろん、これはQA組織だけではなく、カイポケに携わる開発者やプロダクトマネージャーを含む様々な関係者と一緒に行うことです。

その上で直近では以下の内容の取り組みに特に力を入れています。

  • テスト自動化
  • 属人化せず連続性のある品質保証
  • 検証だけでなくサービスを運営する上で全ての品質に関わる

テスト自動化

テスト自動化に関してはまずE2Eテストに注力しています。マニュアルでの検証や、テストシナリオの運用工数を極力減らし、自動化できない観点、たとえば探索的テストなどに、よりQAエンジニアが注力できるようにしていきます。今後はエンジニアと協働し、単体・結合といった各フェーズでもどういった取り組みができるかを考えていきたいと思っております。

属人化せず連続性のある品質保証

属人化しない、連続性のある品質保証を行うには、検証業務プロセス整備の強化・知見の共有強化を通じて、どのメンバーであっても安定したパフォーマンスをだせるようにします。

現場の状況を加味し、都度チューニングしながらチームとしての最適な体制とは何か、どういったアプローチで理想に近づけるかを関係者と一緒に考えています。

また、カイポケ、介護業界、ユーザーによる使われ方など、検証する上で必要な知識が属人化しないよう定期的なミーティングや社内資料の作成に力を入れています。

検証だけでなくサービスを運営する上で全ての品質に関わる

QA組織は検証業務にフォーカスされがちですが、仕様策定段階からサービス運用時全てでQAの組織が関わっていくべきと思っており、品質を向上させる上でQA視点でどういった施策が取れるかを考える必要があると思っています。

特にQAとしての役割は近年品質を保証することから管理することに意識が向けられています。品質の管理とは、不具合を作りこませないために何ができるかという事を考え、対処、改善する時にリードしていくことだと思っており、私自身そういった組織を作りたいと思っています。

f:id:bm-sms-product-dev-saiyo-pr:20211102112352p:plain
図:QAの関わり方イメージ

取り組みとしては長期的で戦略・人材が欠かせず、現在は賛同してもらえる関係者を少しずつ巻き込みながら育てています。

さいごに

本記事では、カイポケにおけるQA組織とその活動について書いてきました。本文でも紹介したように、課題はまだまだありますが、より良い状態に対して日々取り組んでいます。課題への取り組みに際しては、開発者や上長の協力も受けやすく、「これをやってみたい」と思えば実際に取り組むことのできる組織です。自分で課題を見つけて、それに対して解決を試みるような動きはしやすい環境なので、QAエンジニアとして自身のやってきたことから更に1つ上のステップに挑戦してみたい方が合う環境だと思います。

カイポケでもまだまだやりたいことが数多くありますし、カイポケ以外のエス・エム・エスのプロダクト(たくさんあります!)にもQAの活動範囲を広げていきたいとも思っていますので、興味を持ってもらえた方がいらっしゃれば、ぜひお気軽にご連絡ください。

f:id:bm-sms-product-dev-saiyo-pr:20211102112408p:plain
図:私が思うQAエンジニアとしてのキャリアアップのイメージ