2020/03/22 プロダクトの品質とは何か

プロダクトマネージャーは、ビジネス上の要件から開発する機能を選んだりするのも仕事だけれど、品質を担保し続けるためにどのくらいの工数をそこに割いていくか、どうやって担保し続けるか、というのも意思決定するべきこと、あるいは意思決定者との合意を取るべきことの範疇に入ってくる。

これがすげー難しいんですよね。いくらでも時間をかけられるし、「それって意味あるの？」「そのぐらいだと焼け石に水では？」との兼ね合いの中で判断しないといけないし。しかも開発者が考える品質と、ユーザーが考える品質はけっこうずれるのでコンセンサスが取りづらい。

そもそも品質ってなんなんだ、というところが不明瞭だと、1ヶ月間ずっとリファクタリングしてました！ コードが綺麗になりました！ ってエンジニアから報告が上がってきて、「え？ それなんの意味があるの？」「開発速度が上がるんですよ」「でも先月からリリースした機能の量、減ってない？」みたいな虚しいバトルが始まってしまったりする。

ので、品質とは何か、というこを言語化して見ようという取り組み。

ユーザー目線の品質は、だいたい以下の要素に分解できる。

・パフォーマンス
・安定性
・期待と動作の一致
・なんとなくの印象

パフォーマンスは言わずもがな。多くの場合、表示や処理は早ければ早いほどいい。

安定性はサービスがダウンしてないとか、そういうやつ。

期待と動作の一致は、例えばユーザーのプロフィール知りたかったらユーザーの名前欄とかアイコンクリックしたらそこにいけるでしょとか、エラーメッセージ出てなかったら送信ボタン押したら処理完了するでしょとかそういうやつ。これは想定するユーザー層のリテラシーや、コンテキストによって正解が大きく変わる。Googleがモバイル版のリンクから下線を外すようになった話は有名だ。わざわざそんなもの入れなくてもリンクだとユーザーが認識せるようになって初めて、その下線は外せるようなったんだ、というような話。

なんとなくの印象、は意外とバカにならない。プロダクトの品質は、エラーに遭遇する頻度や、プロダクトの直感的な使いやすさによって判断されたりする。前項３つが正常に動作してる状態で、デザインが綺麗(見やすい)、みたいなのがトドメの理由になったりする。挙動としては正しいがLoadingが不親切とか、UXライティングが不十分で正しいメンタルモデルが形成できないまま機能を使ってしまい、なんだこれ使えねーな、って思われるとか、そういうこともよくある。

対して、ソフトウェアエンジニアが言う品質というと、パフォーマンスや安定性もそうだが、その前段の話になることが多い。これは非機能要件と呼ばれるものもあって、別途整理したいなーと思っているんだけど、ざっくり思いつく範囲だと以下のようなものがある。

・コードの見通しの良さ・エンバグしづらさ
・CI/CDの整備
・バグの検知体制が十分であるか
・テストカバレッジまたはその導入
・ドキュメントの整備などによる仕様の明確化

これらを整えることの意味は、売上などを追求する組織においてはなかなか浸透しない。なぜなら間接的な効果のものが多く、機能実装などと比べてビジネスメリットが明確に説明しづらいから。ユーザー向けの品質の分脈に乗せてうまく織り込むのが、リアルにやりやすいところかなと最近は思う。

ちなみに、組織体が小さくて意思決定者がエンジニアと直にやりとりするようなケースで、意思決定者がここを軽んじると半年以内くらいの短いスパンでエンジニアが辞めるって言い出す十分な理由になるので、そういうリスクは理解しておくといいと思う。

てなわけでなんとなくの目次出しで本日は切り上げます。非機能要件の話は自分なりに分解しきってそのうちちゃんと書きたいなあ