はじめまして、アイキューブドシステムズにおける CLOMO の製品検証を担う部門、QA を担当している林田です。
私が QA に配属されて早2年半が経ちました。まだまだ多くの課題は残っているものの、少しずつプロセスや組織体制が確立されたと感じる、今日この頃。
ここらで一旦、QA という組織をどのように考えてきたか、どういう仕組みを整えてきたか、過去を振り返りつつ、備忘録として筆を取りたいと思います。
今後何回かに渡り、QA に関するブログを記載していきます。
組織を考えるにあたって
いきなり QA でやってきたことをつらつらと書き始めてもなんですので、まずは、どういう組織にしていくか、どういう事を考えていたかをお伝えしたいと思います。
最初に考えたのは、この組織において、また弊社製品において、どういった部分にフォーカスするべきか、そのために何を考えないといけないか、でした。
まず「ソフトウェアテスト」について、ありきたりに wiki で検索したところ、
- 規定した品質目標に到達すること
- 目標とした品質には、規定した試験項目にすべて合格すること
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることの確証
- 故意・欠陥の発見、それによる不十分なソフトウェア品質リスクレベルの低減
- 意思決定のための情報提供(テスト対象の品質レベル等)
など、様々な部分に「品質」という言葉が出てきました。そこでまず最初に考察したのは
「品質とは何か?」
「大事にすべき品質のポイントは何か?」
についてでした。
品質保証と品質管理
製品を作る立場の方々がこぞって大事だと言う「品質」という言葉。
この「品質」とはいったい何のことでしょう。
例えば、高級カフェで注文したサンドイッチが出てきたとしましょう。しかし、パンの一部が少し焦げているように見えました。顧客は料理の品質に不満を感じるかもしれません。
別の日、同じ顧客が通りで安いクレープを買いました。しかし、クレープの中に少し硬い部分があったとします。それでも、顧客はあまり気にせずに楽しんで食べたと思われます。
つまり、品質とは顧客が支払う「対価」に対する「価値」のことであり、「満足度」でもあります。したがって品質は相対的なものと考えることもできます。
※ ちなみに、タイトルの回収にもなりますが、ジェラルド・ワインバーグは著書「Quality Software Management, Volume 1」 で「品質とは誰かにとっての価値である」と書いています。
そして、品質は顧客が決定するもので、生産者が決めることはできません。
自分たちで決めることができないものを、しかし企業としてどこまで考えるべきなのでしょう。
ここで必要となるのが、品質保証や品質管理です。
私が所属する QA とは「quality assurance」、品質保証という意味です。
検索するとだいたい「Q&A」が出てきてしまい、「品質保証」としての在り方・考え方についての情報はあまり見つからなかったりするものです。
この QA とは、『顧客に対して製品の性能や機能を保証すること』を指す言葉です。ソフトウェア業界においてこの言葉は、テストの実施、所謂検証業務を実施し、不具合や問題が発生しないことに責任を負う部門として概ね認識されています。
品質を保証するためには、どの程度の品質なら合格かという基準も持たなければなりません。QA には合格基準を定義したり、どのような検査で合否判定するかというプロセスを決めることも含まれています。
しかし、あくまで、品質は判定しません。前述のとおり、品質を決めるのは顧客であるからです。
もうひとつ、QC という似た言葉もあり、これは「quality control」、品質管理という意味です。
QC は『製品やサービスの品質目標を設定し、それを実現するための取り組み』を指す言葉です。同時に、高品質な製品やサービスを効率よく低コストで製造・構築するための視点も求められます。
品質保証 | 品質管理 | |
---|---|---|
意味 | 製品の性能や機能を保証すること | 製品やサービスの品質目標を設定し、それを実現するための取り組み |
責任 | 製品の不具合や問題に対し | 顧客の満足度向上に対し |
時間軸 | 企画から販売後まで | 製品完成前まで |
範囲 | すべての製品・機能について | 顧客にとって重要な部分まで |
品質を保証する、品質を管理する。
似たような言葉ではありますが、品質保証は『製品を使う顧客に対して責任を負う』ことに対し、品質管理は『顧客の要求を満足させる品質をもった製品を作り出し提供する』ことと考えています。
ちなみに、私が QA に所属する前には、ここでいう「品質管理」の部門に属していました。
やっていたことは似たようなものなのですが、「顧客にとって大きな問題の起こらない製品改修、機能追加であるか」「顧客が分かりやすい、使いやすい UI/UX であるか」「改修箇所以外にも、顧客が良く利用する機能に問題は生じていないか」など、顧客にとって大事な要素のみ検査する部門でした。
QA に属するにあたっては、この品質管理でやってきた「品質は顧客に寄り添うこと」や、「顧客に品質が高いと思わせること」などを取り入れていくことが軸になると考えました。
当たり前品質と魅力的品質
品質を考える場合、もうひとつの軸として「当たり前品質」と「魅力的品質」があります。
当たり前品質とは、その名のとおり「あって当たり前」の品質のことです。例えばゲームにおいて操作どおりにスムーズに動作すること、不具合やバグでプレイが妨げられないことなど、当たり前に求められるものです。
対して、魅力的品質とは、高まることでユーザーの満足につながる一方、不十分でも不満に思われない品質のことです。こちらも同様にゲームで例えるなら、キャラクターの背景、グラフィック、素晴らしい BGM、他にもネームバリューのある声優や作家が関わっていることなどが挙げられます。魅力的品質は、なかったからといってすぐに不満に繋がることはありませんが、この品質が高まることによって、より一層の満足度向上が見込めることとなります。
参考:当たり前品質と魅力的品質は、東京理科大学の狩野名誉教授が1980年代に提唱した「狩野モデル」の一部である。狩野モデルでは魅力的品質と当たり前品質を含め、品質を以下の5種類に分類して定義している
当たり前品質
充足されても当たり前としか受け取られない反面、不充足であるとユーザーの不満につながる品質
魅力的品質
充足されるとユーザーの満足度を高められる反面、仮に不充足でもユーザーの不満にはつながらない品質
一元的品質
充足されるとユーザーの満足度を高められるが、不充足であると不満につながる品質
無関心品質
充足されても不充足でもユーザーの満足度に影響しない品質
逆品質 充足されるとかえってユーザーの満足度を下げ、ない方がユーザーの満足につながる品質
目指すべき品質目標
「不具合はゼロにはならない」
これは、かなり昔に読んだ文献に登場していた言葉で(文献は失念してしまいました・・)、とても印象に残っているものです。
私はこの言葉を「不具合をゼロにすることを目的としてはならない」という意味で解釈しています。
- 当たり前品質を向上させること
- 魅力的品質を向上させること
これらは当然のことですが、ただし、完璧を求めてはいけない。
何かしら定義を明確にし、より多くの顧客にとって、充足してかつ満足いただけるライン。まずはそこを目指していこうと考えました。
次回は、当たり前品質の向上について、どういう施策を考えてきたかお伝えしたいと思います。
新卒採用 www.i3-systems.com
キャリア採用 www.i3-systems.com