自社サPdMの実業務紹介(品質改善編)
※ボリューム多いので時間ない人は本編の「実際の改善活動」以下だけ読んでも良いかと思います。
都内の某企業で、toB向けSaaSのPdMをしているbullと言います。
PdMをしていると、「プロダクトの品質をあげないとマズイ」と思うフェーズは必ずやってくると思います。
筆者が実際に取り組んだ内容を振り返りも兼ねて言語化してみました。
前提共有
対象読者
PdM全員
自社プロダクトの品質をなんとかしてあげないといけない人々
想定しない読者
1人でプロダクト開発をしている人
プロダクトにまだ顧客がいない人
私の環境
当時の環境を簡単にまとめるとこんな感じでした。
SaaS運営体制としては、お世辞にも良いとは言えない状態だったと思います。
プロダクトフェーズ
ローンチは約5年前で既に有料顧客を有しておりPMF後である
開発規模は、PdM5名ほど・ENG30名ほどといった具合
品質課題
お客様からバグを指摘いただくことが多々あり、それが理由でチャーンしたこともあるため、品質に対して組織内でふんわり課題感がある
品質をあげたいというが、十分な予算もQA担当もいない
必要最低限の開発ルールはあるが、品質担保の目線から言うと機能していない点も多い
ボトルネック
技術的負債がそれなりにある
当然、新規開発を止めるわけにもいかない
「品質」とは
まず、本題に入る前に本ページにおける「品質」とは何かを定義します。
これについては、人や事業形態・フェーズなどによって千差万別かと思いますが、本noteでは「バグの数」にフォーカスします。
一般的には、品質というとUXもその一部で、改善時にはNPSなどを使って定量化してみたりとありますが、ここでは省きます。
本編
キックオフから予算取りまで
まずは組織にとって潜在的である「プロダクト品質」という課題を顕在化させ、具体的な施策・プロジェクトとして予算を獲得する必要がありました。
そのための大まかなステップはこんなイメージです。
バグ発生の原因究明
スコープ決め(解決する課題と解決しない課題を決める)
予算確保
<1. バグ発生の原因究明>
まず、CTOやテックリードなどマネジメントレイヤーに加え、現場で動くエンジニアやPdM、CS、時には営業さんにもヒアリングをしました。
気をつけるべきは、この段階で現場の方に理想を押し付けないことでした。
あくまで「ヒアリング」を目的として各メンバーの時間を貰っているため、改善を要求したり、原因を決めつけないよう注意しました。
課題を認識しつつも、日々の業務に追われ改善できないという実態はひとえに批判できるものではないからです。
加えて、書籍を読んだりして知識をつけて、課題を整理しました。
結果として、開発プロセス全体に課題が散らばっていることが分かりました。同時に、解決は1年以上かかると直感しました。
例えると、これまで木造で建築していたものを明日以降は鉄筋コンへ刷新する程度の改革が必要でした。
<2. スコープ決め>
バグ発生速度>>>バグ改修速度と表せるような状態だったため、バグの数を闇雲に減らすことよりも、バグが生まれにくい盤石な開発体制を早期に築くべきと考えました。(上図の赤字部分)
そのため、テスト体制強化といったようなアドオン型の改善ではなく、「要件定義」や「テスト設計」といった既存業務の改善を優先するべきと判断しました。
<3. 予算取り>
ここが最も困難でした。
困難と言える所以は、こういった既存業務改善活動はROIを示しづらい領域であるからです。
特に、開発プロセス改善においてはその必要性を理解するために一定の知見が求められます。
極論、業務改善をせずともとも運良く重大なバグが起きなれば、本活動のROIは最悪という見方もできます。
これに対して、バグ発生によるリスクの大きさを訴えることで予算を獲得しました。下記に示します。
売上低下
プロダクトへの信頼性低下によるチャーン
エンジニアがバグ対応に取られ、新機能開発のスケジュール遅延・市場参入速度遅延
その他
バグ対応へかけるコスト
重大バグによる事業存続リスク
最終的に、上記のリスクを掲げた上で、改善策や必要なコスト、評価指標などを資料にまとめ予算を確保できました。
実際の改善活動
上述したように、課題は要件定義を中心とする上流工程にありました。
そこで下記の改善策を進めました。
1. 要件定義段階でテストケースを作ってしまう
要件定義の成果物を厳密に定めました。
「デザイン」と「ディシジョンテーブル(以降:DT)」です。
DTは、2つの目的を持った成果物であり、テストケースとしてのみではなく、プロダクトの仕様書としても機能しました。
DTにある内容は、後述する作業でエンジニアによりテストコードが記述され、CICDで走るようになります。
DTの詳細については、ボリューミーなので下記の記事をご覧ください。
googleスプレッドシートで管理していました。
弊社の場合はDTをカスタマイズしたオリジナルの書式を導入し運用していました。オリジナル書式は時間ある時に記事化します。
2. 要件定義成果物のレビュー会をする
開発チケット毎に、要件定義や設計に関して議論する場を設けました。
時間は1時間で目的と参加者は以下の通りです。
本活動の周知強度を高める狙いもありました。
実装とコードレビューの質向上
主担当エンジニア
コードレビュー担当エンジニア
テックリード
要件・ユーザービリティ設計の確認
要件定義者
デザイナー
私(PdM)
テストケース(DT)のチェック
テスター
私(PdM)
アジェンダは、下記の2つで質疑応答を挟みながら進めます。
1. 開発概要・デザイン・要件の連携
2. DTの確認
工夫した点として、開発概要の連携を要件定義者ではなくエンジニアへお願いすることにより、双方向で理解を促進するよう進めました。
ある程度コストがかかってしまう事を承知の上で開催することにより、エンジニアの主体性向上など副次効果もありました。
3. Seleniumでテストコードを記述し管理
DTにあるテストケースを全てSeleniumを使いテストコードとして記述し、E2Eテストを自動化しました。
コストをかけて作ったDTを最大限活用できる運用がこの形と考えています。
デグレを防ぐことができるため、重宝しました。
一方で、UIの僅かなズレなどは検出が難しく目視で確認する運用となっています。
4. 運用周知徹底
例えば、DTでは下記するような課題が発生し、運用周知徹底に時間をかける必要がありました。
探索性
課題：機能毎・機能内ページ毎に対応するDTがどれであるか分かりづらい
解決策：機能毎に対応するDTのリンクを貼るnotionページを用意し、毎度の要件定義レビュー会(上述2番の施策)で記載漏れを確認した
可読性と抜け漏れ
課題：DTの書き方が属人化してしまい、第三者がレビューできないため精度が落ちる
解決策：DTの書き方を全てドキュメント化し、チーム毎に勉強会を開催し周知した上で要件定義レビュー会(上述2番の施策)で表記揺れを指摘
改善活動の評価
本活動の目的は、業務改善により「バグを生みづらい開発体制を築くこと」にあります。
バグが生まれにくくなっていることを定量的に計測するため、月毎に発生したバグ件数をカウントすると同時に二分化しました。
新規バグ：本活動以降の開発で生まれたバグ
既存バグ：本活動以前の開発で埋め込んでいたバグが顕在化した場合
本活動以前の開発で埋め込まれていたバグが顕在化した場合は「悪」と識別しないことにより、目的に沿った評価をしています。
ちなみに、二分化の方法はバグ発生箇所のコミット履歴を遡り、本活動で定めた要件定義成果物が残っているか否かを地道にチェックしています。
おわりに
読んでいただいてありがとうございました！
相当ハードな業務だったと思っており、願わくば同じことはもうしたくないです。
なので、自社プロダクトにおいては、PMF直後あたりから専門のQAさんをアサインして、恒久的にバグが生まれづらい体制をアップデートし続ける必要があると強く強く感じます。
この記事が気に入ったらサポートをしてみませんか？