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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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