はじめに
現在Voicyで開発責任者をやっています @yamagenii です
みなさんはプロダクトにおける品質担保やクオリティコントロールと聞いて何を思い浮かべるでしょうか。 一番最初に思いつくのはバグ修正やテスト、QAといった項目かもしれないですね。 しかしそれはほんの一部でしかありません。
高い品質でプロダクトを提供し続けることは重要と認識はされている反面、 品質面においてのリソースを投下されずに、後戻りができない状況になり、大きな損失をしたと言う話はよく聞く話でもあります。 これはまさにVoicyが直面した課題でした。
その原因は、新規機能開発など事業にポジティブな影響を及ぼす開発は組織全体でもマインドシェアが大きくなるのに対して ネガティブなインパクトは確率的なために、問題が表面化するまでは気づかず、リソース投下の意思決定が遅れてしまうことにあると考えています。
そんな失敗もあり、Voicyでも明確に品質改善への投資の意思決定をして事前にケアをしていく必要がありました。 今回はその時の意思決定のプロセスを紹介したいと思います
話の大枠の流れは
- 品質の定義をして品質に対する解像度を上げて、
- エンジニアチームがケアするべき品質項目を洗い出して、
- 注力ポイントを決めて、
- チームを作って解決をする
という流れになっています。 同じ悩みを抱えてる方の参考になれば幸いです
品質の解像度をあげる
実は品質の定義は必ずこれ！というものはありません。以下に例を挙げます。
- 本来備わっている特性の集まりが要求事項を満たす程度（ISO9000）
- 明示された状況下で利用するとき、明示的ニーズ又は暗黙的ニーズを満たすためのソフトウェア製品の能力(ISO/IEC 25000 : 2014)
- 誰かにとっての価値である(Weinberg 1994)
Voicyでは品質は「誰かにとってのプロダクトの価値である」という方向性から始めています。
余談ですが、最近Voicyでは品質についての理解を定めるために「品質とは何か？」をワークショップ形式で解像度を高める活動をしました。 以下の記事に詳細が載っているので、気になる方はチェックしてください
品質のカテゴライズ
品質をより理解するために世の中で一般的に言われている方法で品質を分解して理解してみましょう。 主に意思決定に利用したのは品質特性と狩野モデルです。
品質特性
ISO/IEC 9126では品質の性質を「品質特性」で分解しています。 細かい話は参考文献がたくさんあるのでそちらを参考にして欲しいのですが、 それぞれの性質をVoicyに当てはめると以下となると考えています
狩野モデル
品質のカテゴライズの方法は品質特性だけでなく、狩野モデルによる分解もされます。 細かい話は参考文献がたくさんあるのでそちらを参考にして欲しいのですが、品質を3つ(正確にはユーザにマイナスな品質を含めると5つ)で分解をしています。
それぞれの品質は以下のように説明されて、Voicyのプロダクトにも当てはめることができます
- 魅力的品質 : 充足されてなくても問題ないが、充足されてる満足度が上がる。Voicyならパーソナリティさんと繋がれる
- 一元品質 : 上がれば上がるほど、満足に繋がり、下がれば不満に繋がる。Voicyなら読み込み速度が早い
- 当たり前品質 : 充足されていないと不満に繋がる。Voicyなら音声が再生できない
開発組織が注力するべき品質とは？
品質に関する理解が深まったところで Voicyの開発組織が注力するべき項目について説明します
エンジニアとプロダクトマネージャ+デザイナーの役割を明確にすることで開発注力ポイントを決める
Voicyのプロダクト開発組織ではエンジニアとデザイナーとプロダクトマネージャがいます。 プロダクトマネージャ+デザイナーとエンジニアの役割をさっくり言語化すると以下です。
- プロダクトマネージャ+デザイナー : Voicyのユーザ体験を最大化する機能を意思決定する
- エンジニア : 不具合のない状態でスピード感早くリリースをする
上記の方針の元、エンジニアが注力するべき品質項目のポイントを狩野モデル×品質特性のテーブルを使って整理をしました ※あくまでVoicyにおけるマッピングになっています、ぜひ組織でディスカッションしてみてください
品質注力ポイントの決定 : フェーズとイシューの大きさによる分析
ここまでで注力したい品質がわかりました。ではそれは全て改善できるのか、で言うと答えはNoです。 リソースを適切に分配するために選択と集中が必要で注力ポイントを絞る必要があります。 今回は「フェーズ」と「イシューの大きさ」を定性的に分析することで、今注力するべき事項を決めました
フェーズ
フェーズはサービスのリリースからの期間になっています。 Voicyはプロダクトもリリースしてから6年経ち、初期リリースから今までで、お客様に求められる品質レベルの度合いは形式的にも暗黙的にも変化がありました。 例えば、シード期のプロダクトは多少のバグがあっても許容できる場合があります。しかしプロダクトが成熟するにあたり一つのバグがもたらす事業インパクトも大きくなり、担保するべき品質レベルが変わります。また形式的にもアグリーメントをお客様と結ぶことで担保するべき品質が明確になることも考えれます。
求められる品質レベルは時間で変化をしていくため、フェーズを言語化する必要があります。
期間の分け方は経営の目指したい方向性に強く依存するため、経営メンバーとのコミュニケーションをとりながら進める必要があります Voicyのフェーズは経営情報にも直結するので割愛します
イシューの洗い出し
フェーズを分けたらそれぞれのイシューの大きさを見積もりましょう。
まずはフェーズごとにイシューを洗い出します。 フェーズごとのイシューは例えば「今、重要度の高い不具合がある」もそうですし、「今、スパゲッティコードで開発者の生産性が低い」等、「将来(フェーズC)、ユーザ数に耐えられる基盤を作成する」もそうです
その後イシューにビジネスにおける重要度のレベルづけをします。イシューが解決されないとどんなリスクがあるか、または解決するとどんな価値につながるかを考えて、ポイントをつけます。
フェーズとイシューで注力ポイントの決定
イシュー大きさを「重要度が高さ」と「数」で見積もります。 ざっくりにしか見積もれないと思いますが、ざっくりで良いので見積もります。 例えばフェーズBの現在で以下のようなマッピングになったとします。
こうすることで今、解決するべき問題は「機能性 : 不具合が発生しやすい」「信頼性 : ユーザの信頼を落とさない」「保守性 : より良いソフトウェアにする」ことであることがわかります。
実際は定性的に違和感がないかなど経営を含めた複数人でディスカッションする必要があります
チームの作成
注力ポイントが決まったらリソースを投資して解決をします。
Voicyでは実際に初めに分析したときは「機能品質」「信頼品質」「効率品質」に問題があることが判明したので、まずはそこの投資からしました。 具体的には機能品質はQAチーム、信頼品質/効率品質はSRE、Quality(CRE)チームにコミットをしてもらう設計にしました。
端的にいうとエラーバジェットの管理をする文化がなくて未成熟だったため、各チームがやるべきファンクションを定義しました。
- QA : 新規開発時の不具合埋め込みを管理して、許容ラインを決めて、修正をする
- CRE : ユーザ様からの問い合わせを管理して、許容ラインを決めて、修正をする
- SRE : アラートから出てくるエラーの管理して、許容ラインを決めて、修正をする
現在では「機能品質」「信頼品質」「効率品質」のイシューは明確に減っていき、今では安定してきていると捉えています。
これらはDevOpsでは開発チームができるべき開発文化とも捉えているので、QAとSREチームでは各チームが実践できるようにEmbeddedチームとしての活動もしています。
今後の注力ポイント
将来の品質注力ポイントの仕込みは今から進めています。 また半年前に分析した現在のイシューと今分析するイシューとでは異なる場合があるのでアップデートをしていくことが重要です。
Voicyで今後の品質注力ポイントはズバリ「保守品質」です。
長らく運用されて、機能を増やしていったVoicyのサービスは負債もどんどん溜まってきていて、それらのコントロールをすることで開発効率を上げながらも、その他の品質面でもポジティブな影響を及ぼすことができると考えています。 具体的な施策についてはまた別途紹介をできたらと思います。
まとめ
エンジニアチームにおいて品質のコントロールはMustで必要になる事項の中で、実際にどのように分析してリソースを投下の意思決定をするかはあまり世の中のTIpsがないように思います。
自分自身意思決定をするときに悩むことが多かったため、誰かの指針となれば幸いです！
