今回は「実践してみてよかった」的な話ではなく、「こういう考え方でまとめてみたらいいのかもしれない」というアイディアベースの話です。「そうじゃないだろう」などツッコミが来ると嬉しいです。
よく、組織やチームの目標・ミッションなどに「品質の良いものをユーザーに届けよう！」といった内容を掲げたりします。これ自体はとても良いことだと思う一方で、「そこで言っている品質って何？」というのを具体化したくなります。
ワインバーグのことばを借りて「誰かにとっての価値である」と表現するのは簡単ですが、そうではなくて「自分たちが言う"品質が良い"とはつまりどういうことなのか」をチームで話し合って決めることそのものが大事だと考えています。
品質が良いとは？について考えるには
たとえば品質特性の話を持ち出してきて、「我々にとって品質が良いとは、＊＊性が高いことです！」と言うこともできそうです。ただ、もう一歩ほしいところ。＊＊性というワードは、品質というワードよりは一歩具体に近いかもしれませんが、それでもまだ抽象度が高いと思っています。
抽象度が高いと、同じワードを用いていてもAさんとBさんとで想定が違ってしまって、それではミッションや目標として掲げるには不十分です。
品質を掲げた際の弊害およびミッションとしての機能を満たすための具体性
ミッションや目標自体を具体化する必要は、おそらくありません。ある程度抽象的なほうがキャッチーだったりしますし、口をついて出るワードのほうがメンバーにも浸透しやすいはずです。
ですが、「具体的にはどういうこと？」が部内やチーム内のナレッジベースに明文化されていることは必要です。
「品質」のままの抽象度で語ってしまうと、先に書いたようにAさんが思う「品質が良い」とBさんが思う「品質が良い」が違ってしまいます。この状態で、たとえばなにかのプロジェクトで新規追加する機能の設計について議論しているときに、AさんとBさんとで「俺の案のほうが品質が良いだろう（なのになぜ反論するんだ）」という事態になりかねません。大人なので喧嘩はしないと思いますが。
といった具合で、ミッションやら目標が果たすべき「意思決定の指針・拠り所になる」という機能を果たすためには、ミッションの外でもいいのである程度具体化されている必要がある、と考えます。
品質が良い、を定めるには
本題のおさらいです。
チームや組織において「品質が良い」とはどういうことなのかをある程度具体化したい。というのがモチベーションでした。
決めるにあたっては「品質が良いとは、を定めるワークショップ」などを2,3時間集まってワイガヤすると定まってきそうですし、実際そのような過程を経て「QAチームのミッションを決めました！」というブログ記事も見かけます。
で、私自身もそういったこと（開発者と一緒に、開発チームにおける「品質が良いとは」を定めること）をやりたいなぁと思っていて、考える際の枠組み的なものを思いついてみました。ご意見ください。 が本題でした。
品質が良い、の先は 儲かる に行き着くのでは
品質が良いものを作ろう、というのに反対する人は居ないと思います。じゃあなんで品質が良いものを作るんだっけ？というと、その行き着く先は「儲けたいから」になるのかなと思います。
もちろんドメインなどにも依存するかもしれませんが、ソフトウェア開発というものが企業の営利活動として行われる以上、儲からなければ意味がありません。バグだらけでも儲かればいい、とはいいませんが、良いものを作った結果儲けたい、はずです。
ただ、品質が良いものを作ると儲かる、というのは直感的にはそうなのですが、この間というのはまさに「風が吹けば桶屋が儲かる」のと同様に距離がある・ふわっとしていることが多そうです。
ここの間がふわっとしたまま、「俺達は品質が良いものを作るぞ！」と掲げていても、空振り感があります。
品質が良い→儲かる、の間について合意すれば「我々にとって品質が良いとは？」が明確になるのでは
じゃあふわっとしているところを明確にしましょう、ということで「考え方」を考えてみました。
まず、
- 品質が良いということの候補
- 儲けるための方法の候補
を列挙します。
図の例で言うと、セキュアである・頻繁に機能が増える、などの「品質が良いとは」の候補と、新規ユーザー増・ユーザーが逃げない等の儲かる候補です。
そして、この間には品質が良い結果と儲かる理由にあたる要素が出てきます。
間の要素は1つとは限りませんが、「品質が良い」の要素と「儲かる」の要素をつなぐ経路が複数できるはずです。
この複数できた経路のうち、じゃあ自分たちの組織はどれをとくに狙っていくんだっけ？を考え、3つなり5つなり選び出したものが、自組織にとっての「品質が良いとは？」に対するアンサーになる。という考え方です。
上の図でオレンジにしている経路を選んだとすると、「我々はユーザーの離脱を減らしてユーザー数を増やし続けて儲ける。そのためには安心して使ってもらうことが大事で、そのための品質の良さとしてセキュアであることを重視する」ということになります。
ここで3つなり5つなり経路選択ができると、たとえばアーキテクチャについて考えているときなどに「どっちのほうがセキュアになるか」や「多少工数が増えてもセキュアになるほうを選択しよう」といった、意思決定の基準になるはずです。
「品質が良いものをユーザーに届けよう！」的なミッションだけで考えているときよりも、だいぶ有用なのでは・・・？どうでしょうか。
（Cursorによる）おわりに
今回提案した「品質が良い→儲かる」の間を埋めるアプローチは、以下のような利点があると考えています：
- 抽象的な「品質」という概念を、具体的なビジネス目標と結びつけることができる
- チーム内での意思決定の基準が明確になる
- 品質向上の取り組みが、ビジネス成果にどうつながるのかを可視化できる
もちろん、このアプローチがすべてのチームや組織に当てはまるわけではありません。しかし、品質とビジネス成果の関係性を可視化し、チームで共有するというプロセス自体が、組織の品質に対する理解を深める一助になれば幸いです。
この考え方について、ぜひ皆さんのご意見やご経験をお聞かせいただければと思います。