これは何？
QCDのQを「顧客満足度」として捉えることで、より深く開発方針が検討できるんじゃないかなという提案記事です。
単にQを「品質」として捉えていると、テストを増やす/減らすということや、バグを少なくするといった形で考えがちになっちゃいます。
Qを「顧客満足度」とすることで、「障害からの復旧時間が多少長くても我慢してもらおう」とか「ここで不具合を出すと顧客満足度に著しい影響があるからトレードできない」とか、より深く考えられていいかもね。という話です。
QCDとは？
QCDは製造業で生まれた開発に関する指標です。
一般的には
- Q : 品質
- C : コスト
- D : デリバリー（納期）
を表していて、QCDのいずれかに手をいれると、他の2つに影響しますよ。という関係性を示しています。
例えば品質を上げるためには、コストを増やしたり、納期を伸ばしたりしないといけませんよ。という感じですね。
F(Flexibility)を加えてQCDFとしたり、S(Scope)、S(Safety)を加えてQCDSとすることもあるようです。
QCDは本当にトレードオフなのか？
QCDの関係はソフトウェア開発において通用するのか？という議論はよくされてきました。
私個人の考え方としては、基本的に通用しないものだと思っています。
@t_wadaさんの「質とスピード」で語られていることに、同意します。
出典：質とスピード（2022春版、質疑応答用資料付き）/和田卓人様
このように、こと内部品質に関して言えば、原則としては品質は制御変数ではないと思えます。
内部品質に閉じない世界で考えたとしても、バグの多い少ないはコントロールできないので、QCDにおいてQを操作するときは
「テストを増やす/減らす」というふうに捉えられがちです。
これではQのトレードオフではなく、テストにかける工数のトレードオフですね。
そもそも「品質」とは多角的なものであり、バグの有無だけで考えるのは無理があります。
なので、「品質」という曖昧な言葉を使うのはやめたほうがよいでしょう。
Qを顧客満足度とすると？
じゃあどうすればいいんだよ？って話ですが
個人的には「品質」ではなくて「顧客満足度」としてあげれば、ある程度品質の多様性に対応できるのではないかと思います。
「顧客満足度」が上がったり下がったりする要因を考えてみましょう。
- 障害の発生頻度
- 障害によるビジネス影響
- 障害からの回復スピード
- UI/UXの成熟度
- 口コミの質/数
- などなど…
どうでしょう？
Qを「顧客満足度」として考えてあげるだけで、少し幅広く品質について考えることができませんか？
これであれば多少はトレードオフできるところを探せませんか？
もしくは「品質」をトレードオフにすることの重みを実感できませんか？
「障害からの回復スピード」を多少下げてでも、コストを節約したい。と考えて自動テストの実装を抑えたり（それでいいのかは別として）
「障害によるビジネス影響」を下げるために、納期を伸ばしたり。とか考える事ができると思います。
まぁQCDを考えるときって大体開発がにっちもさっちもいかない時だと思うので
削れる場所捜索ツールみたいになってるかもしれませんが、簡単に「品質」や「テスト」を削ろうと言わせないだけの重みは出ると（個人的には）思います。
というわけで、「QCDのQ」は「顧客満足度」にする。というアイデア。
ぜひ使ってください。