「品質」は誰が決めるもの?~改めて「品質」を考えてみる~

  • ソフトウェアテスト・品質保証
  • UI/UX

「品質」は誰が決めるもの?~改めて「品質」を考えてみる~

株式会社SHIFT マーケティンググループ
著者 株式会社SHIFT マーケティンググループ

お役立ち資料

Introduction

ショッピングサイトやスマホアプリのレビューには、「品質がいい」「品質が悪い」という言葉をよくみかける。
その商品を買うか買わないか、アプリをダウンロードするかしないかを決めるために、こうしたレビューを参考にしている人も多いのではないだろうか。

例えば、起動して5秒たっても開かないアプリケーションはみなさんも使いたくないだろう。なぜなら、私たちはアプリケーションの応答速度が速いことをもはや当たり前に感じているからだ。
ユーザーの期待と実際のアプリケーションのギャップがあると、「品質が悪い」という印象になり、一度でもこうした体験をすると ユーザーに見放されていってしまう。

ユーザーからのよい評価を得るために、アプリケーションを利用してもらうために、品質は誰が、どのような基準で決めていくべきなのだろうか。

ソフトウェアにおける品質とは、要件や仕様通りにソフトウェアが動き、必要な開発プロセスを踏んでいればよいのだろうか。プロダクトの不具合分析や、開発プロセスの改善などに取り組み、目標を定めているチームもあるだろう。
しかし、その取り組みがユーザーを満足させる結果になっているだろうか。答えはNoである。

目次

ソフトウェア品質に重要な3つの要素

スマホを見る人

私たちが考える「品質」には、「要件・仕様通りに動作すること(プロダクト品質)」「開発中のプロセス(プロセス品質)」「ユーザーの満足度(サービス品質)」それぞれ3つの要素がある。
まずは、それぞれの定義を説明したい。

 

品質 説明
プロダクト品質 プロダクトが要件・仕様通りに動作すること
プロセス品質 プロダクト品質の確保のために必要なプロセスを構築し、実行していること
サービス品質 ユーザーの要求、満足度を満たしていること。あるいはユーザーの期待を超える価値を提供すること

プロダクト品質

プロダクト品質に影響を与える要素として 、「設計書」「ソースコード」「テスト結果」などがある。例えば「設計書」は、設計内容の抜け漏れがないか、非機能要件が組み込まれているか。「ソースコード」は設計通りに実装されているかはもちろん、可読性や保守性があるか。「テスト」は必要十分なテストが行われているか、正常系だけではなく異常系もテストされているか。

プロダクト品質は、その良し悪しをレビューやテストを通して判断することになる。

プロセス品質

プロセス品質は、大きく「開発プロセス」と「管理プロセス」にわけられる。

「開発プロセス」は、ソフトウェア開発を行う作業手順であり、何をもってその作業を開始/終了するか、何をもってその成果物の良し悪しを判断するか、という基準や手順を明確にすることである。これにより、個人の解釈の違いや判断ミスを減らすことができる。

「管理プロセス」は、計画立案から実行、そして実行状況を監視し、計画からズレそうなら対策することで、計画を守るための作業であり、計画の立て方、レビューの仕方、実行状況を測るデータの特定と収集方法、計画との差異の測り方、差異があった時の対処の仕方などを指す。これにより、計画とのズレを早期に発見し、対処することができる。

プロセス品質を確保することで、計画したスケジュール通りに計画した品質のプロダクトができあがってくるかを予測することができる。

サービス品質

サービス品質は、「サービスの成果」と「サービスのプロセス」にわけられる。
「サービスの成果」は正確/迅速/好印象といったサービスの機能的な一面を指す。
「サービスのプロセス」は共感/柔軟/安心といったユーザー一人ひとりに寄り添ったプラスアルファの価値や体験を指す。カスタマーサポート、Webサイトやアプリのアップデート、個人向けにカスタマイズされた情報提供や画面に当てはめるとわかりやすいだろう。

プロダクト品質、プロセス品質と異なり、サービス品質は運用チームやカスタマーサポートとより緊密に協力してつくり上げていく必要があることにも注意したい。前者はチーム内、組織内の指標に基づいて評価できるが、後者はプロダクトをリリースしないとわからないからである。

現場における品質保証の話ではプロダクト品質、プロセス品質をよく問われるが、それぞれの品質を高めていくための弊害となる光景や課題が現場で垣間見える。その一部を見てみよう。

関連サービスについて

開発現場で起きる品質向上における課題

このような3つの品質を意識した開発を行うにあたり、実際の現場の状況はどうだろうか。
品質に大きく影響するプロセスやテスト、基準、組織など、開発現場における課題に触れていきたい。

品質の向上

通り一辺倒にテスト密度を重視してしまう

プロダクト品質を判断する指標には、単位規模あたりの数や時間などを表す密度がある。「レビュー密度(レビュー時間や指摘件数)」や「テスト密度(テストケース数)」、「バグ密度(バグ数)」などだ。これらが目標値の範囲内に収まっているかどうかが、品質を判断する一つの材料となる。
この「密度」は、開発規模に応じた指標 (レビュー時間、指摘件数、ケース数、バグ数など)、過去の統計に基づいた値を目標値として使用する。
(「バグ密度」の詳細はこちら:バグ密度とは?システム開発における品質可視化のための指標について解説)

しかし、開発プロジェクト(プロダクト)は二つとして同じものはない。
このような指標は品質を決める一つの目安にはなるかもしれないが、生産過程における評価をするためのものにすぎない。
プロダクトの特性や品質への要求によってどのようなテストを行うかを考慮すべきであり、プロダクト品質を判断する指標だけでは、テストをどれだけやればいいのかという必要十分な根拠にはならないことに注意すべきである。

テスト戦略や方針を決めないまま品質保証活動をしてしまう

ソフトウェア開発においては、単体テスト結合テスト総合テストなどさまざまなレベルのテストを行う。
それぞれのテストを行う前にテスト計画を策定し、それに基づいて実行することになるが、そもそも何を対象にいつどのような観点でテストを行うのか、テストの戦略とテスト全体の計画があるべきである。プロダクトや要求される品質の特性、そこから考えられるリスクや諸条件によってテスト戦略は変わってくる。

ところが実際には、前回プロジェクトのテスト方針をそのまま踏襲したり、残存不具合数などの指標をテストの終了条件にしてしまうことが少なくない。
テスト戦略がないままテストをはじめる、あるいは誤ったテスト戦略に基づいてテストをはじめると、結果として見当違いのテストをすることにもなりかねない。
(テスト戦略についてはこちら:テスト戦略~テスト計画プロセスにおけるテスト戦略の考え方~)

絶対的な品質基準を求める

プロダクトのリリース判定、あるいは工程完了判定において、品質基準を満たしているかを問われる。もちろんそれ自体は必要であるが、過去のプロダクト開発に適用してきた基準を、そのまま現在のプロダクト開発に当てはめてしまってはいないだろうか。

開発の条件は一つ一つ異なる。満たすべき品質基準も異なる。それにも関わらず「当社の基準はこうだ」と決めつけてはいないだろうか。
「当社の基準はこうだが、かくかくしかじかの理由でこうである」「このプロダクトはこのような特性があり、これをもって品質を満たしていると判断する」。
そういい切れる人がいなければ、うわべだけの品質管理になってしまう。

テストを最後にもってくることによる悪循環の発生

設計して、開発して、テストをする。たしかにプロセスとしては正しい。
しかし、何らかの不安があり、あるいはたくさんの不具合が表面化したことによって品質向上対策、いわゆる「強化テスト」をすることがある。これには多大な労力と時間が必要で、当初計画したコストや納期を脅かすものである。

ビジネス側(業務部門)は「どうなっているんだ、いつ終わるんだ」とピリピリし、システム側(開発部門や開発ベンダー)はシューティングのために残業を余儀なくされ、終わりのみえない闘いに挑みつづけ、やがては疲弊してしまう。明らかに悪循環である。

テストの自動化が目的となっている

アジャイル開発とともにCI/CDやDevOpsが広まり、テスト自動化も一般的になってきた。もちろん従来型の現場でもテスト自動化が進んでいる。いままで人手でやっていたことが自動化され、しかも人的ミスがなくなるのは素晴らしいことだ。

しかし、自動化することが目的になっていないだろうか。前述したとおり、テスト戦略に基づいたテストを行うべきであり、それをサポートするのがテストツールなのである。

関連サービスについて

チームメンバー間で情報に差異がある

最新の仕様がどこにあるかわからなかったり、情報の伝達がうまくいっていなかったりと、チームメンバーに認識の差異が生じていることはないだろうか。

会議に招集するメンバーが不十分だったり、喫煙所での個人間の決めごとがいつのまにか公の仕様になっていたりする、などという嘘のような本当の話があるとも聞く。
最新の情報を一元管理し全員がそこにアクセスできる状態をつくらないと、認識の齟齬がうまれ、実装やテストに大きな影響をおよぼしてしまう。

いくつ思い当たるところがあるだろうか。
上記の例は、いずれもプロダクト品質やプロセス品質の向上を目指している過程で起きることが多い課題だと考えている。
しかし、もう一つ大事なサービス品質が抜けていることに気づくだろう。
「このプロダクトやサービスは誰が使うのか。ユーザーが満足するにはどうなっていればいいのか」。
テスト戦略といった方向性 やユーザーが満足するための目標値がない、つまり、ビジネスとシステムが同じ方向を向いておらず、共通の目標達成に向かって寄り添っていないのである。

開発現場だけで品質を語るだけでは足りない

PCを見る男性

品質は誰のためのものだろうか。何をもって「品質がいい」といえるのだろうか。
いうまでもなくユーザーのためであり、どれだけユーザーが満足するかである。

これまで述べてきたように、現場の悩みや課題は、どうしてもプロダクト品質とプロセス品質に閉じてしまいやすい。
チームのなかにいると、技術的に実現できるのかであったり、メンテナンス性が高いかどうかであったりを気にしがちで、ユーザーからみえる品質に気づかないことがある。
しかし、ユーザーからみえる品質を考えることなく、売れるサービスをつくることはできない。

売れるサービスをつくるためには、ビジネスオーナーやカスタマーサポート、運用チームなどを巻き込んで、プロダクトだけではなく関連するユーザー体験を設計する必要がある。
ユーザー体験の良し悪し、すなわちサービス品質を考えていく必要が生じてくる。
このようなときに、以前からまったく変わらないプロダクト品質やプロセス品質の指標を用いていてはいけない。なぜだろうか? 一つ例をあげよう。

例えば、生活習慣病の予防に役立てる目的ではじまったメタボ健診。
2008年から導入されたものだが、定期的に評価基準の見直しがされている。
実際に保健指導になる対象者が適切か、本当は対象にすべき人が外れていないかなど、運用した結果をもとに専門家が議論して見直しを図っているのである。

プロダクトの品質についても、同じことがいえるはずだ。
あなたが入社したときからある残存不具合件数やバグ密度などの指標にいつまでも頼っていて本当によいだろうか。ユーザーに求められるプロダクトはすっかり変わってしまっているはずだ。

サービス品質を向上させていくためには、市場からのフィードバックを得ることを怠ってはいけない。同時に品質の基準も、ビジネスオーナー、開発チーム、運用チーム、カスタマーサポートを巻き込んでつねに見直していくべきである。QAはその専門性を活かして議論をリードすることが期待される。
プロダクトにかかわる人が一丸となってサービス品質を考え、改善を繰り返していくことこそが、売れるサービスをつくるために欠かせないのである。

アジャイル開発白書のダウンロード

近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。

近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。

ダウンロード

まとめ

本コラムでは 、品質を考えるにあたって「プロダクト品質」「プロセス品質」「サービス品質」の3つの考え方を紹介した。
さらに、品質の基準を以前からまったく変えずに今のプロダクトに当てはめてしまうのではなく、ユーザーからのフィードバックを得ることによって目指す品質も変わってくることを論じた。

プロダクトやサービスにおける品質とは何だろうか。
品質を満たすためにはどこまでやればいいのだろうか。
間違いなくいえることは、ユーザーが満足して私たちのサービスを使いつづけてくれることである。
これこそが「品質」の本質である。

本コラムが、プロダクト品質やプロセス品質だけでなく市場のフィードバック獲得と改善を繰り返すことでサービス品質を高める一助になれば幸いである。

資料ダウンロード

この記事を書いた人

株式会社SHIFT マーケティンググループ
著者 株式会社SHIFT マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト:https://service.shiftinc.jp/
コーポレートサイト:https://www.shiftinc.jp/
X(旧Twitter):https://twitter.com/SHIFT_cp

ご支援業種

  • 製造、金融(銀行・証券・保険・決済)、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

関連コラム

Top