LEADING QUALITY読書会から始まる品質改善活動

※この記事は 2024年04月08日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。

2023年11月にリリースされた『LEADING QUALITY』という書籍は、QAエンジニアだけでなく、CTOやEMといったマネジメント層からも大きな注目を集めました。

私はQAエンジニアとして、この本から得られる知識の共有と影響力をより発揮するため、『LEADING QUALITY』の講演会／読書会を企画、実施しました。この記事では、その背景と本書籍を活用した今後の改善活動についてお話しします。品質改善活動の進め方に困っているQAエンジニアの方々の活動の一助になれば幸いです。

Tebikiの品質課題

約1年間開発チームを支援し、QAエンジニアである私は現在、以下の課題を持っています。

・スクラムチームは、中長期的な品質課題に関心が向きにくい

スクラムチームは、事業を加速させる価値をユーザーに提供することを目的として活動しており、その活動を阻害する品質課題には対処します。重大な不具合の修正や単体テストの拡充などをスプリントで実施する場合があります。しかしながら、「重要だが、緊急ではない品質課題」に対して、先回りして、対処できていません。緊急ではないため、現状のプロセスにおいて大きな課題がなければ、それらの改善の優先度が低くなるからです。

例えば、「Tebiki社では、プロダクト品質目標が定義されていない」という課題は中長期的な課題だといえます。

これによって、品質の解釈が個人によって異なり、インクリメント（成果物）にムラやムダが発生するリスクがあります。しかし、積極的にステークホルダーとコミュニケーションをとることで、そのリスクの発生を最小限に抑えています。短期的にみると、積極的なコミュニケーションで解決できる問題ですが、中長期的な視点で捉えると、チームがスケールし、関わる人が増えることでコミュニケーションミスが発生する確率は上がります。

よって、この課題は「重要だが、緊急ではない品質課題」であると言えます。この課題は先の通り、現状のプロセスにおいて大きな問題に発展していないため、対処が先送りになっていました。

・QAエンジニアだけでは、中長期的な品質課題に取り組めない

スクラムチームが中長期的な品質課題に取り組めないのであれば、QAエンジニアが主体となって、それらに取り組めば良いのではないかと考えるのではないでしょうか。

QAエンジニアだけでは、この品質課題に取り組めないと考えた理由は、品質課題に対する施策を実行するのはスクラムチームだからです。QAエンジニアが感じている課題をスクラムチームが認識し、様々な改善施策に納得感を持って実行してもらわなければ、すぐに形骸化してしまいます。

LEADING QUALITYとの出会い

このような品質課題を抱えて、心がモヤモヤしていた時に、私は『LEADING QUALITY』に出会いました。

”品質を管理し、推進し、もたらすにはどうしたらいいか、経験と実例に基づいたアドバイスを提供してくれる資料だ。”

出典：LEADING QUALITY まえがき

”プロダクトの課題である品質がどうしてビジネスにとって重要なのか、またそれをどのように経営陣に伝え、組織の品質への取り組みを変えていくのかが記されている。”

出典：LEADING QUALITY 訳者まえがき

『LEADING QUALITY』をスクラムチームメンバーと読むことで、QAエンジニアが感じている品質課題を自分事として認識するようになるのではないか。その結果、QAエンジニアは、スクラムチームと一緒に中長期的な品質課題に取り組めるのではないかと考えました。

読書会の様子

以下の流れで読書会を行いました。

・読書会は、合計5回開催する。・読書会は、1回あたり30分〜1時間の枠で行う。・読書会の頻度は週に1〜2回。・参加者が章を読み終えるごとに質問や意見を付箋に書き出し、参加者間で意見交換したい付箋を司会者がピックアップして、対話を行う。・章ごとに個人ワークを実施し、個人ワークで出た意見について、参加者同士で話し合う。

読書会の対象とした章は以下3つの章です。

・第5章プロダクトの成熟度と品質・第9章ローカルペルソナ・第10章品質戦略のリード

その中でも読書会の中で意見交換が一番盛り上がった章は、「第9章ローカルペルソナ」の章でした。tebikiはデスクレスワーカー向けのプロダクトであるため、開発環境とユーザーが実際に使用している環境が異なることが往々としてあります。このような開発環境とユーザーの利用環境の差異について、参加者の方々も検証方法やユーザーを深く知るための接点が十分ではない点について課題を持っていることが分かりました。

また、「現在の品質ナラティブを知ろう」というテーマでワークを行った際には、スクラムチームとQAエンジニア間でテストナラティブの実態に乖離があることが分かりました。具体的にいうと、QAエンジニアは適切なテスト技法を使って、効果的なテストケース作成をするような会話が、スクラムチーム内で行われていないと感じていますが、スクラムチームからはそのような意見があがってきませんでした。このような役割間でのナラティブの差がワークを通じて明らかになった点は非常に良かったです。

ワークシート「現在の品質ナラティブを知ろう」

読書会で組織が得たもの

下記は読書会参加者の感想です。

・品質について深く知れた・参加者間でも品質に対する価値観のベースラインは揃いつつある・POとエンジニアで品質について会話できた・品質が、開発優先順位の決定や、ソリューションを選択する際に、1つの評価軸になるというのが感覚として理解できた・品質の技術的な品質と、プロダクト価値の品質的な話があるよな〜と思っていた部分を3つのナラティブという共通の認識で会話できるようになった

これらの感想から、スクラムチームは以下の3つを得ました。

・品質に関する理解・品質文化という共通の考え方・POとエンジニアのコラボレーションの向上

これらによって、スクラムチームは、品質に関わるあらゆることについて、QAエンジニアと協力して、現状を認識し、品質課題に取り組める状況になったと考えています。

例えば、リグレッションが頻発している状況を改善するために、あるエンジニアは、リグレッションが与えるユーザー影響を具体的に考える会を開き、安定した品質を提供する重要性をチームに理解してもらう取り組みを始めました。