君は「バグ減らし」と「魅力的なソフトウェアの開発」のどちらに関心がある？：「狩野モデル」の狩野先生からソフトウェア技術者に質問

ソフトウェア品質やレビューについて研究している、名古屋大学 大学院情報学研究科 情報システム学専攻 准教授の森崎修司氏が、「狩野モデル」（Kano Model）で有名な狩野紀昭先生にインタビュー。狩野先生が今、ソフトウェア技術者に聞きたい3つのことについてのアンケート結果を基に所感を頂いた。

[森崎修司，＠IT]

　アジャイル開発の原則の一つに「顧客満足を優先し、ユーザーに価値を素早く届ける」があります。このユーザーの価値を説明するときによく使われるのが、「狩野モデル」（Kano Model）の「魅力的品質」「当たり前品質」「一元的品質」です。

魅力的品質要素	充足されれば満足を与えるが、不充足であってもしかたないと受けとられる品質要素。「魅力的品質」とも呼ぶ
一元的品質要素	充足されれば満足、不充足であれば不満を引起こす品質要素。一元的品質とも呼ぶ
当り前品質要素	充足されれば当り前と受けとられるが、不充足であれば不満を引起こす品質要素。当り前品質とも呼ぶ
狩野モデルでの代表的な品質の区分（出典：「魅力的品質と当り前品質」品質 14巻 2号 p.147〜156、1984年、狩野紀昭、瀬楽信彦、高橋文夫、辻新一）

　アジャイル開発が米国から輸入されたこともあり、狩野モデルが狩野紀昭先生によって1980年代に提案されたことや、当初は日本の工業製品の品質管理や商品企画において活用されてきたことを知らないソフトウェア技術者もいると思います。

　そこで筆者は、改めて狩野先生からの狩野モデルの解説を聞く機会を設けました。筆者を含め19人の産学の委員で企画する「ソフトウェア品質シンポジウム2023」（2023年9月7〜8日、オンライン配信で開催）の基調講演です。タイトルは「狩野モデルから品質について学ぶ！」で、そのアブストラクトはこちらです（狩野先生のご経歴なども掲載）。

　アブストラクトにある通り、狩野先生からシンポジウム参加者（ソフトウェア技術者）に向けた3つの質問があります。これを事前にソフトウェア技術者の方に回答してもらい、狩野先生と回答結果を共有して所感を頂きました。本稿ではその内容を報告します。

アンケートの結果はオンライン会議で狩野先生と共有。左側が狩野先生、右側が筆者

　狩野先生からの質問を見てみましょう。アブストラクトの質問とは順番を入れ替えており、質問内容を少し補足しています。

1. ご自身の関心は「バグを減らす」「魅力的なソフトウェアの開発」のどちらですか？
2. 狩野モデルを当てはめる対象は「1つの品質要素」「品質要素の体系」のどちらですか？
3. ソフトウェアに「品種」という概念はあると思いますか？

　この質問への回答をシンポジウム公式のSNS、筆者個人のSNS、日本科学技術連盟のメーリングリストを使って募集しました。3つの質問に対して52人分の回答を頂きました。

回答者プロフィール

　質問についての対話を紹介する前に、回答者プロフィールを示しておきます。回答者の方には、この場をお借りしてお礼申し上げます。

質問A：狩野モデルをご存じですか？

• 選択肢A-a：知っていて活用している
• 選択肢A-b：書籍や記事で読んで知っている

　「活用している」と「知っている」が26人ずつで同数でした。

質問B：ご自身の開発ドメイン（最も近いものを1つお選びください）

• 選択肢B-a：自社ネットサービス（コンシューマー向け）
• 選択肢B-b：自社ネットサービス（エンタープライズ向け）
• 選択肢B-c：組織内システムの開発・保守
• 選択肢B-d：システムインテグレーション
• 選択肢B-e：製品組み込みソフトウェア開発
• 選択肢B-f：ソフトウェアハウス
• 選択肢B-g：その他

　製品組み込みソフトウェア（選択肢B-e）が最多で19人、自社ネットサービス（B-aとB-bの合計）が17人でした。

質問C：ご自身の立場（最も近いものを1つお選びください）

• 選択肢C-a：開発者（プログラミング、設計）
• 選択肢C-b：品質保証（QAエンジニア、検証担当、SETを含む）
• 選択肢C-c：自社製品／サービスのプロダクトオーナー
• 選択肢C-d：開発支援／開発管理（プロジェクトマネジャー、スクラムマスターを含む）
• 選択肢C-e：その他

　品質保証が28人で最多、開発支援／開発管理が14人で次に多かったです。

　以降、狩野先生からの質問への回答と、それに関する対話です。

質問1：ご自身の関心は「バグを減らす」「魅力的なソフトウェアを作ること」のどちらですか？

• 選択肢1-a：バグを減らす
• 選択肢1-b：魅力的なソフトウェア
• 選択肢1-c：両方ともだが、どちらかというとバグを減らす方が優先順位が高い
• 選択肢1-d：両方ともだが、どちらかというと魅力的なソフトウェアを作る方が優先順位が高い
• 選択肢1-e その他

森崎　「バグを減らす」「魅力的なソフトウェアを作ること」がおおよそ半分ずつという結果になりました。

狩野　「バグ減らし」「魅力的なソフトウェアの開発」がほぼ半数ずつというのは、大変面白いと思っています。

　この回答結果から生まれてくる私の仮説は、組み込みソフトウェアの開発を含む大きなソフトウェア開発プロジェクトで、一括して企画、計画した上でさまざまなバグを想定し、それらに対応する業務を担っているQA担当者の「バグ減らし」活動が浮かんで来ます。

　これと対照的に、短い期間で少しずつ機能を追加する少人数での開発に従事され、商品企画から品質保証に至るまで全てのフェーズに対応する必要があるプロジェクトでは、まず「魅力的なソフトウェアの開発」の商品企画から始めなければならないので、後者に関心が向かうと思います。この点については、アンケート調査の回答者のプロフィールとクロス集計すると分かるのではないでしょうか。

森崎　プロフィールに自動車の組み込みソフトウェア開発に携わっている回答者の方が複数いるので、その傾向が出ていると思います。

質問2：狩野モデルを当てはめる対象は「1つの品質要素」「品質要素の体系」のどちらですか？

• 選択肢2-a：単体
• 選択肢2-b：体系
• 選択肢2-c：分からない

森崎　半数近くが「分からない」という回答でした。体系が全体の4割強、単体が1割程度でした。また、単体、体系のどちらかを回答した方には、自由記述の回答としてそれが何かを質問しています。その回答を抜粋したのが次のリストです。

• 「単体」と回答した方の品質要素
  • 処理速度（使用性）
  • 機能品質（バグの少なさや利便性）
• 「体系」と回答した方の品質要素
  • 「ソフトウェア全体」「付加価値」：6件
  • 利用者や開発関係者のグループごとに考える：3件
  • 機能安全：3件

狩野　古典的なQC（Quality Control：品質統制）では、石川馨先生の「消費者の満足」のように今日の顧客満足概念の先駆となる主張も現れていましたが、製造現場で、個々の品質特性についての適合状況が、「良品」「不良品」の名の下で議論されていました。ところが、1970年代前半に出現した品質表（後にQFD：Quality Function Deploymentの名称の下で普及）の提案によって、「顧客の要求と製品特性は、異なる言語だ」と認識し、両者の翻訳を品質表で行うことに始まり、顧客の要求を把握する必要が生じてきました。

　特に、魅力品質理論のように、品質要素別で顧客の声を調査した結果から品質要素を分類する手法の適用に当たっては、従来の技術者のみが理解できる品質特性ではなく、顧客も理解できるように品質要素を記述しなければならなくなってきました。

　一般に、品質を分類しようとすると、詳しい要素に分解する必要から、技術の介在が必要となり、顧客にとって難解なものになりがちです。従って、魅力品質理論での魅力品質や当たり前品質などを区分するには、開発側の担当者のみが理解できる用語ではなく、顧客も理解できる用語を用いる必要があります。

　B2B（企業向け）の方が品質要素は細かく分類されたり、専門特化のものになったりするはずです。企業向けでは顧客にも仕様や品質に詳しい担当者が存在することが多いからです。B2C（一般消費者向け）の場合には、詳しい顧客もいますがその数は少なく、多くの顧客は抽象的に（ぼんやりと）品質を捉えていることが多くなります。いずれの場合でも、顧客やユーザーも理解できる用語レベルで品質要素を考えることが大事です。

　狩野モデルは、個々の品質要素を対象にして「魅力品質」「当たり前品質」「一元品質」「無関心品質」「逆品質」などの分類を提案しています。製品全体に対する満足度について、直接評価しているわけではありません。この辺りを意識すると、より本格的に活用できると思います。

　前置きが長くなりましたが、森崎先生の調査結果を見て驚いたことは、「分からない」という回答が回答者の半数近くを占めていることです。これは設問に問題があります。それでも、「分からない」という回答が得られているので、対応が可能となりました。この選択肢を挿入した森崎先生に感謝します。もし、私の作成した「全体」or「単体」の二者択一の質問だったらもっと理解に苦しむ結果になったと思います。

　講演ではこの点について聴衆の皆さんが理解できるようにインプットします。

　次に、「単体」「体系」への回答総数28人の方を「有効回答者」とし、その全員に対する「単体」「体系」回答者の割合を求めると、それぞれ約20％、約80％となりました。この結果は、設問者の私の予想とはかなり違ったものでした。

　設問者としては、1問目で「魅力的なソフトウェアの開発」と回答した方は、網羅的にリストアップした品質要素というよりも、自分が考えていた魅力品質の候補となる、単体の品質要素の幾つかに対する狩野モデルの調査結果にのみ関心があると考えていました。しかし、この調査結果を見る限り、そういう方も、取り上げた品質要素全般についての顧客の反応を見た上で、魅力品質への回答が多かった要素に注目していると推測します。

　これに対して「バグ探し」と1問目で回答した方は、2問目は「体系」と回答して「当たり前品質」「一元品質」といった要素に注目し、その不充足状況に目を光らせてバグ対策を考えるという仮説を抱いていました。しかし、この回答結果からは、この仮説を積極的に肯定する結果は得られませんでした。

　ところで、有効回答者について、上のような仮説を立てて推論できるかどうかは、「設計された質問表で取り上げた品質要素が、どのように設定されたか」に大きく依存します。

　私が過去に拝見した実例を見ると、現行の製品についての品質要素をリストアップして調査用紙が設計されているケースを多く見掛けます。このような調査では、魅力品質を発見するのはかなり困難だと思います。というのは、狩野モデルを適用しようと考えている現場では、「これは」と思うアイデアを反映した品質要素について試したが成果が得られなかった場合に狩野モデルを持ち込んだとしても、既に魅力品質が見つかるケースは少ないからです。

　その点をどうしたらいいのかについては、私の講演でお話しする「魅力品質創造」に期待してください。

森崎　回答者のプロフィールの「コンシューマー向け」とそれ以外とを比較して確認しましたが、企業向けの方が詳細に回答している印象です。顧客に使う用語についての話も整合していると思います。

質問3：ソフトウェアに「品種」という概念はあると思いますか？

• 選択肢3-a：ある
• 選択肢3-b：ない
• 選択肢3-c：分からない

森崎　75％の方が「ある」という回答でした。IT、ソフトウェアで「品種」という言葉を使うことが少ない印象だったので、「ハードウェアの機種のようなバリエーションを想定してください」と補足しています。

狩野　品種自体が理解や定義が難しい言葉にもかかわらず、「分からない」という回答が少ないのはすばらしいですね。

　私たちの「魅力的品質と当たり前品質」の論文が日本品質管理学会の学会誌『品質』に掲載され、世に出たのは、実は、品質と品種についての関係について明確にできたからなのです。お恥ずかしい話ですが、私たちの最初に投稿した論文は、レフェリーから「本論文は、品質の本質的な部分についての提案を含んでいるが、文献研究が品質管理の分野に限定されているので、もっと広い立場から行う必要がある」という査読結果とともに「却下」のスタンプが押されて、戻って来ました。私たちは典型的な工学人間で、哲学や経済など文系についての文献を調べる能力もなく、途方に暮れていました。

　結果的には、講演で触れますが、素晴らしい方との出会いがあり、アリストテレスの著書に品質の記載があることを知り、彼の品質論の下で新たなる理論を構築でき、再投稿して掲載されました。その理論は、「品質とは、種差のことだ」というものでした。言い換えれば、2つの品種のあるところで初めて品質を問題にすることができ、そこでの品質とは、2つの品種の違いだ」というものでした。狩野モデルでは、「品種があって、それに対して品質がある」という考え方をしているので、品種の定義自体も品質に影響します。この点についても、講演でお話しします。

森崎　ここで「ある」と回答した方には、何を「品種」と捉えているかを自由記述で回答してもらっています。それを抜粋したのが次のリストです。

• 記載なし（空欄）：5件
• 機能のカスタマイズ：2件
• 機能性とセキュリティ（金融システム、B2B）：2件
• バグ修正の速さ
• 応答時間
• PC版とスマホ版
• 費用によって機能制限が適切にかかっているか

狩野　まず、回答が空欄になっているのも品種の定義は難しいので納得できます。そうした中で、回答を書いているのはすばらしいと思います。品種は「品質をどのように捉えているか」が表れたものでもあります。

　最後に付け加えておきたいのは、「ある時期に魅力品質と評価されたものも、時間の経過とともに、一元品質となり、当たり前品質になる」というように変化することです。この点については、「品質のライフサイクル」ということで講演の中で紹介します。

まとめ

　狩野先生からのコメントを通じて、製品の品質とソフトウェアの品質には共通点が多いと感じました。また、B2B、B2Cといった区分にも共通点が多く、それらの間では品質要素の粒度が異なる点も共通しています。

　顧客やユーザーと合意できる最小単位を品質要素と捉えることもソフトウェアや製品の品質でも同様に捉えられます。商品企画やマーケティングのような部門の有無といったコンテキストによって捉え方が異なることも、そうした部門や顧客とのコミュニケーションを円滑にする際に参考になると思います。