品質という言葉について考える

「品質に不安がある」
「品質を安定させたい」
「品質をもっと良くしたい」
「品質は特に問題ない」

品質という言葉を文章にすると、こんな内容が飛び交う場面がある。
そんな時、僕の中でいつも浮かぶ疑問がある。

この人の頭でイメージしている品質ってどんな意味なんだろう？

っと。

言葉としては、品質という単語で共通しているが、頭でイメージしている内容に齟齬があった場合、後々その認識ずれにより、大きな問題に発展する危険性があるからだ。

僕の中の品質という言葉のイメージは大きく分けて4つある

• サービス品質

• プロジェクト品質

• ソフトウェア品質

• リリース品質

これを重要な順番に並び替えると

1. サービス品質

2. リリース品質

3. プロジェクト品質

4. ソフトウェア品質

となる。

これは、あくまでも僕個人の考えだ。

なぜこの4つか？

品質 という言葉では、判断出来ない場面が多いと感じたからだ。

実体験ベースに例えると
リリース直前まで、不具合がずっと検出されているとする。
不具合が出ているのだから、ソフトウェア品質としては良くない状況だ。

では、リリースすることは出来ないのか？？

僕はそうは考えない。
結論、不具合の内容による。

リリースする上で、以下の2つを満たしていたらリリース品質はクリアしていると定義する

• リリース対象の新機能が要件通り動作していること

• 既存の機能に重篤な影響が出ていないこと

そして、リリース直前で検出されている不具合の多くが既存機能の不具合だったとする。

その場合、サービス提供に支障が出てしまうような内容の不具合でない場合は、リリース品質にも、サービス品質にも影響はないと判断する。

また、検出した不具合は、次回Sprint以降に計画的に改修出来るよう、バックログなり、タスクなりにして、流れないように管理出来ているとする。

ここまで出来ている場合、

結果的に
サービス品質 クリア
リリース品質 クリア
プロジェクト品質 クリア
ソフトウェア品質 申し送り事項あり

というようになり、リリースOKと判断した。

このように、品質という言葉だけで判断しようとすると、基本はソフトウェア品質的な感覚に引っ張られて、基本リリースNGという判断にするしか無かったのだ。
だからこそ、何に影響がある事象なのかを整理する必要があった。

つづく。