こんにちは。フィックスポイントの冨です。

プロダクトの品質を担保していくかという問題。開発プロセスに於いてのソフトウェアの「品質」はバグやデグレーションが無いという事ですが、広く解釈するとプロダクトの機能や使い易さも含まれますし、開発者目線ではコードの読みやすさ、保守の容易さなども含まれます。

また、品質強化の順番や優先度の考え方は、プロダクトの置かれている状況やフェーズなどにも依存していて、線引が難しいところでもあります。
私の場合、Webアクセス解析ツールのQAマネージャをやった経験があるのですが、データ取得のモジュールのQAでは、想定し得るありとあらゆるブラウザで動作不良を起こすこと無く、かつ問題無いスピード感で動作し、正確にデータ取得が出来る事という目標がありました。「集計処理の不具合はやり直せるが、データ取得でバグったら会社が傾く」と脅かされ、設計／実装のレビューから、膨大な数のテストケースの消化までを指揮してバグ０まで持っていったわけです。逆にレポート画面の方は新しい機能・指標の実装の方を優先して、多少の不具合は許容してリリース優先といった方針で進められました。

この辺りのバランスの見極めは言語化が難しいのですが、品質のハードルは事業領域やプロダクト、また市場に投入しているステージによっても高さが変わってきます。コンシューマー向けのアプリであれば、多少動きに怪しいところがあっても、便利な機能を提供していれば支持されるだろうと、開発スピード優先に舵を切る判断もありますし、金融・医療のように、不具合が許されない事業ドメインもあります。開発当初はスピード優先で市場拡大を優先し、大手に導入するステージになってきたら高いレベルで品質を担保する必要が生まれてくるといった、場面によっても方針を変える必要が出てきます。

特に大手では独自に出荷基準を持っているところがほとんどで、高いレベルで品質確保出来ていないと、そもそもリリース出来ないと思います。その一方で、特に新規事業においては、プロダクトが置かれている状況によって品質レベルの高低のコントロールが必要になります。もちろん製品の不具合は少ない方が良いわけなのですが、「バグ０が絶対正義」という考えを取らない局面もありえますし、品質レベルに関しては、開発・運用・サポート担当間で意識合わせが必要になってきます。

この辺りの読みを間違えると利用者の支持を失うといった事態が起こりえるので、本当に難しいのですが、PM、営業、CS、開発間でコンセンサスを取れるように調整していってください。