さいきんXで「品質とはや保証とはを議論しても意味なさそう」的なツイートを見かけました。

たしかに言葉の定義をぐるぐると議論したとで現場の何かが良くはならないよなーと思う部分もあります。また、実際に私も開発者向けに話をするなかで「品質保証と言っても保証する品質を厳密に定義するのはWebサービスにはなじまないので、品質を向上させる取り組みをするくらいのつもりでいいと思う」的なことを言ったりします。

ただ一方で「品質とは」を考えることに一定の意味もある、というのが私の考えです。（ちょうど今所属している組織内で「品質とはなにかみんなで考えようぜ」という活動をしていたりもします）

品質とは、を考える意味

ざっくり言うと、

  • 考える過程に意味がある
  • 「大事にしたい」品質とは、を考えることに意味がある

の2つです。

考える過程に意味がある

品質とはなにか、を議論しても皆が納得するような結論や定義は出てこないだろう、と思います。

一方で、QAエンジニア同士やQA・開発者間で「品質とは」を議論していて得られるものとして、「認識が違っているという事実」があります。

ちょうど社内で「品質について考えるワーク」をやろうとしていて、以下の記事を参考にすべく何度も見返しています。

両記事に共通しているのは、「品質に対する認識や、意味しているものに違いがあることをまず知ることが大事」という点です。これは私もそうだなと思っています。「品質」というワードってかなり抽象的ですし、それを議論したとて「これだ！」と決まることが無いというのはそうなのですが、人によって意味しているものが違うという前提を共有するのは必要なことです。でないと認識のズレを自覚しないまま物事が進んでしまうおそれもあります。

立場によって「品質」に関する捉え方がいろいろある、ということを各々が自覚するためには、「品質とは」を議論する過程に意味があると思います。結論を出すためではなく思いを共有するための議論、ですね。

「大事にしたい」品質とは、を考えることに意味がある

品質に対する捉え方がいろいろある一方で、ある程度のすり合わせはできるはず、というのが私の考えです。そのうちの一つの切り口が「大事にしたい品質は何か」というものです。

ISO/IEC 25010の品質特性でも「＊＊性」と名前のついた品質の要素がたくさんあるわけですが、そのうち「とくに自分たちが大事にしたい品質とは」を組織内で話し合い、方針をすり合わせるのも大事です。さいきんでは「質」と「スピード」はトレードオフでない、という認識が広まっていると思いますが、一方で品質の要素はトレードオフになる部分もあるように思います。

限られたリソースや時間の中でできるだけ価値を提供しよう、と思ったときに「＊＊性と＊＊性、どちらをより重視する？」といった判断は発生します。（保守性を犠牲にしてスピードを重視しよう、は無いよというのが質とスピードの考え方ですが。）

上記のような対立構造は多くないにせよ、たとえばアーキテクチャの検討や設計方針を決める際などに、どのような品質をとくに重視するのかは各種意思決定の判断材料になるはずです。このときに「品質とは」がふわっとしたままだと判断がブレます。雑な例ですが「我々は保守性を第一に考えるぞ！」といった方針が決まっていれば、それに応じた筋の通った選択が可能になるのではないでしょうか。

まとめ

ここで述べたような話を考えると、「品質とはなにか」を机上でぐるぐると議論していても無駄である一方で、組織の中で「品質とは」に対する認識ズレの存在を理解したうえで、自分たちがどのような品質を大事にするのかの共通認識を持つことは、それはそれで意味のあることなのでは、と思います。

正直自分も「ふわっとそう思っているんですよね」というレベルなので、どこかで非同期に議論できると嬉しいです。