はじめに
先日、日本語版が発売されて話題になっている本、LEADING QUALITY を読みました。
以前、品質チームを兼任するエンジニアとして働いていた経験がある自分にとって、非常に興味深い内容で、当時の悩みを解決する大きなヒントを得ることができました。
面白すぎて睡眠時間を削って一気に読み切った程です。今この記事を書きながら 2 週目を読んでいます。
リーダーはいかにして高品質のソフトウェアを提供し、成長を加速させるか
「品質とは何か」「品質をどう測るか」を説明した書籍は山積しているのに「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説したものは皆無である。本書は、それらを解説した画期的な書籍である。
品質チーム運営での悩みポイント
品質チームの一員として活動していたころは以下のような悩みを抱えていました。
- そもそも品質チームとは何をするチームなのだろうか？
- 今の我々の品質は良いのか？悪いのか？
- どのように品質チームの目標を設定すれば良いのか？
それぞれについての詳細と、LEADING QUALITY から得られたヒントを紹介します。
そもそも品質チームとは何をするチームなのだろうか？
課題
当時、我々の品質チームは、リリース物の品質の最低ラインを守りつつ、開発速度を向上するための活動を中心に行っていました。
例えば以下のようなものです。
- 全プロダクトチームが守るべき開発フローの設計
- フェーズごとのレビュー（設計レビュー/開発レビュー/リリース判定 等）
- メトリクスの計測（開発速度 / リードタイム / バグ発生数 等）
これらの取り組みによって、ある程度の開発速度を維持しつつ、バグ発生数は抑えられていたとは思います。
一方で、メトリクスは上下を繰り返し横ばいで、改善施策との相関も不明瞭な状況が続いていました。
また施策自体も、
- レビュー内容の改善
- 新しいメトリクスの可視化
など、間接的なものが多く、品質向上にに貢献している、という実感が無いのも悩みの１つでした。
示唆
LEADING QUALITY p20 では品質チームを下記のように定義していました。
自律的なクロスファンクショナル（機能横断的）チーム
本書では様々な実例を交えながら、品質チームがどのように品質をリードしていくか、ということが書かれています。
読み終える頃には、品質チームとは下記のようなチームである、と認識を改めました。
- 実際のプロダクトのテスト戦略や開発フローの改善を計画・実行する
- 時にはステークホルダーを説得して改革を主導する
- 会社が目指す方向と目線を合わせ、品質に関わる全ての活動をそこに集中させる
ふりかえり
当時は自分たちが持っている（と思っている）権限の範囲で活動することに精一杯になってしまっていました。
開発フローやメトリクスでしか品質の向上に関与できないと思いこんでいました。
プロダクトには直接関与できないと思いこんでいました。
実際にやるべきだったのは、会社が成長するためにどういう品質活動ができるかを考え、実行していくことでした。
あるいは、プロダクトごとに品質担当者を決め、一緒に具体的な改善案を考え、実施していくのも良かったかもしれません。
LEADING QUALITY を読むことで、品質チームのやるべきことを知り、視野が広がりました。
今の我々の品質は良いのか？悪いのか？
課題
現在自分たちの品質がどこに位置しているのかがよく分かっていませんでした。
当然どこに向かって改善していいけば良いのか分かりませんでした。
そのような状態で品質チームの活動内容を決めようとして、しっくりこないまま短期的な施策を行うということを繰り返していました。
示唆
本書ではナラティブという概念を用い、現在の状態と理想の状態を言語化することを提唱しています。
ナラティブは「語られ方」という意味で、次の３つがあるとされています。
- 責任ナラティブ
- 「誰が品質に責任を持つか」がどう語られているか
- テストナラティブ
- 「品質向上に有効な技術は何か」がどう語られているか
- 価値ナラティブ
- 「品質がどう価値につながるか」がどう語られているか
これらを使えば、現状と理想が例えば次のように定義できるのではないか、と解釈しました。
現状
- 責任ナラティブ
- QA チームが品質に全責任を持つ
- テストナラティブ
- バックエンドはリクエストスペックの正常系を最低限書く
- フロントエンドは E2E をパスすれば QA に確認を依頼する
- 価値ナラティブ
- そもそも会社が生む価値と品質の関係を見いだせていない
理想
- 責任ナラティブ
- 開発に関わる全ての人が品質に責任を持つ
- デザイナーは特に UX を向上させることに責任を持つ
- 開発者は特に自動テストの設計と開発速度の向上に責任を持つ
- 品質チームは品質目標の設定と文化醸成に責任を持つ
- など
- テストナラティブ
- バックエンドとフロントエンドの担当者で相談しながら OpenAPI を定義する
- OpenAPI をもとにテストコードを自動生成する
- フロントエンドは Storybook を用いたスモークテストを最低条件とする
- など
- 価値ナラティブ
- デリバリーを平均X日短くすることで月の収益を XX 万円増加させることができる
- テスト工程を自動化することで 1 機能の開発に関わる費用を XX 万円削減することが出来る
あくまでこれは例ではありますが、実際に書き出してみることで 「ナラティブ」が現実と目指すべき理想を言語化するために非常に有効なフレームワークであると感じました。
どのように品質チームの目標を設定すれば良いのか？
課題
品質チームにいたころは、目標設定に OKR を利用していました。OKR では測定可能な値を KR (Key Result) として設定する必要があります。
当時は、まず使えそうなメトリクスを探し、その中から開発速度向上やバグ発生数抑制につながりそうなものを選ぶ、というプロセスを取っていました。
今思うと、数値化に執着しすぎて視野が狭くなっていたと感じます。
示唆
LEADING QUALITY では、まず会社の成長指標として有効なものを特定し、あらゆる品質活動をその指標に集中すると良い、としています。
成長指標は事業内容によって適しているものが異なり、主に下記の 3 タイプに分類されるとしています。
- BtoC 事業
- プラットフォーム上でユーザがどれだけの時間を費やしたかに着目したアテンションベースの成長指標が適している
- E コマース / プラットフォーム
- ユーザがどれだけ取引をしたかに着目したトランザクションベースの成長指標が適している
- BtoB 事業
- ユーザがどれだけ素早くタスクをこなせるようになったかを示すプロダクティビティベースの成長指標が適している
ふりかえり
当時所属していた会社の事業は BtoB でした。
今振り返ってみると、開発速度やバグ数に集中してしまい、顧客の体験向上に焦点を当てられていませんでした。
開発速度やバグ数に注目しすぎていたのは、性質やフェーズの異なる 5 つのプロダクトに共通する品質目標を立てようとしていたという背景がありました。
今当時に戻れるなら、プロダクトごとに会社の目標から逆算した品質目標を立て、プロダクトチームと協力しながら目標達成を目指してみたいです。
その他のおすすめポイント
- 訳注が丁寧で分かりやすい
- インラインで書かれているのでページの行き来無く読めます
- 非エンジニアでも分かるように丁寧に解説されています
- 自然な和訳
- 訳書だと感じない自然な文章で読みやすいと感じました
- 読みやすいボリューム感
- 質的なボリューム感は非常にありますが、本の厚さは 1cm に満たないくらいで、読みやすいボリュームだと感じました
さいごに
LEADING QUALITY を読み、品質チームのやるべきことを知り、視野が広がりました。
というか、品質ってもはや開発そのものじゃね？ ぐらいの感覚です。
出来ることは広すぎて、逆に困ってしまうくらいです。
実際に何をやるか、は現在のチームとともに議論して、実践していきたいと思います。
以前の品質チームでは悩ましいこともたくさんありましたが、地道な取り組みにより開発フローを標準化し、バグの発生を抑制できていたと思います。
LEADING QUALITY で学んだことを活用しながら、当時できなかったことにもチャレンジしていきたいです。