世界で大企業～小さな企業がたくさんあります。今日の大企業がビジネスの始まる時きっと小さな企業でした。時間及び提供された商品の継続で今の大企業に変わりました。この成長の力と言えばそちらで業務を進んで来た社員たちです。これはお互いの協力ものです。
世の中の企業の中で、一部の製品は私たちの心に強い印象を残します。これらの企業の製品を手に入れたいという欲求を抱く人々が多くいます。その理由は、最終的には製品の品質にあります。
有名な企業様の例ですが、上記にリストアップされた企業について紹介する必要は全くありません。これ以外にもたくさんの企業が存在しますが、これらの企業は提供している製品の品質レベルが非常に高いため、一般のお客様から自然にトップ評価されていると思われます。これらの企業は研究能力、技術能力、品質能力の組み合わせによって成り立っており、そのために今もなお成長し続けています。一方で、この3つの要素のうちどれかが欠けていれば、希望通りの製品は生み出せないでしょう。したがって、特に「品質能力」は非常に重要であり、理解を深めた上で実現していくことで、どんな企業でもお客様の心に長く残ることでしょう。
商品向け品質とサービス向け品質
テストの色んな種類があります。業務上開発の段階及び状況によってそれぞれのテストを実施されます。同じく”検証”業務も深い意味で考えて分けられます。例えば、
A。商品向け検証
B。サービス向け検証
何が違うかというと、商品向けの検証は主に商品に対して丸ごと考えた上で検証業務を実施する事です。ある商品の品質を高める為に必要なQAプロセスを導入する。一方で、サービス検証は割と広い範囲で考えて実施する物です。検証の立場で、商品は商品だけとして考えないで、企業のイメージを持つ、商品を利用際に商品というより企業名をよく考える、商品に満足があれば直接企業として表現する。例えば、現時代の主ないくつか種類のスマホのことでお話しますと、あくまで「Apple」と「Google」もしくは「Samsung」企業名が先に来てしまうのです。色んな型番でスマホを提供していても、結局サービス企業の名前で該当スマホのことをみんなが表現してしまいます。これはサービス品質の意味です。一言でいえば、商品の品質はもちろん素晴らしい状態にする目的の上、お客様の心の中にその商品を提供された企業名に関して深い印象を作る目標がサービス品質です。
本記事には、サービス品質を目指して商品向けどのような品質改善プロセスを導入したら、それは結局サービス品質向上に繋がれるか見てみます。
【本題】
- 品質とは⇒重要さ⇒もし足りなければ
- 品質改善プロセスの紹介
- 未来のQAプロセス
まずはQAとTestに関して少しお話しします。
【テスティングについて】
テストとは、単純に開発された商品に対して要件と参照しながら不具合、異なる点の見つかり、又は商品の安定感の判定をチェックするのが目的です。テスト種類*も色々あり、段階によって色んなテスト業務を行えれば製品の中にある何かしら不具合、問題点などが見つかれます。テストすればするほどものなので、区切りは全然ありません。なので、ある程度の安定状態まで持って行ける事が出来てればテストの目的な達成します。
※テスト種類などに関しては、ここに記載しません
【品質保証について】
一方で品質保証は大規模な業務であり、その中でテストは重要な要素です。ただし、品質保証は単なるテストだけでは完全に担保できません。商品は一度で終わるものではなく、その寿命中にしっかりと品質を維持する必要があります。そのため、テストだけでなく、他のさまざまな業務も適切に行うことが理想的です。この記事では、私がこれまで経験してきた品質保証の改善方法をいくつかご紹介します。
Quality means to Japan
Japan became a prosperous country in the decades after World War II by importing raw materials and making them into finished products for export. China has used its cheap labor costs to attract manufacturers and transform the country into the "factory of the world," but Japanese goods have remained competitive because of their excellent quality.
「毎日新聞の記事から」
つまり、日本は最初から品質担保をしっかりと行っていたため、世界一の品質印象を持たれており、今でも人々は「日本製なら品質に心配はない」と感じています。信頼性と一貫性の素晴らしい組み合わせが、日本品質の特徴ですね。
■ 品質とは！！
ある製品又は機能に対して開発して、要件通り出来上がれば一旦、商品自体が完成と言われます。開発立場としては、物が出来ている表現も出来るのです。但し、開発の完成した状態で早速商品を市場に出しても良いでしょうか？ ここで企業様の中で差が生まれるのです。「品質第一」と「売上第一」のどちらが優先されるかによって、企業の未来が形作られます。
商品の一貫性
どんな商品であっても、品質の担保を継続することは非常に重要です。どんな状況においても、品質を最優先に考えて進めれば、商品の一貫性が確立されることでしょう。実は、お客様の心の中で一番求められているのは、商品の一貫性なのです。
商品の信頼性
商品だけでなく、どんなものでも信頼性は非常に重要です。この言葉には深い意味が含まれています。お客様の中で信頼性を築り、育てることができることは、商品の成長につながります。
顧客の満足
商品が良ければ良く程顧客満足度も上がるものです。お客様から良い印象を取ってもらうのは大きなチャンレンジでありますが、良い品質の商品を手に上げれば大きく乗り越えること出来るのです
■ 重要さ！！
品質の重要性については、もちろん皆さんが理解していることだと思いますが、それでも世の中ではさまざまな事件が起きています。その中には品質不足が原因となった事例もあります。もう少し昔の例ですが、あくまで品質不足が原因であった事例なのでご紹介させて下さい。
▲ Takata Corporation (2017)：車部品の大企業であるのですが、車両のエアバッグ品質担保が出来ず結局命を失うまで発生。今まで自動車企業の中で最も大きな損害を持たせた企業でした。会社は負債と数十億ドルに踊らされた。タカタ製エアバッグの大失敗は、品質不足でした。
▲ Samsung Galaxy Note 7 (2016)：この前Samsungのこの機種が充電オーバーの原因で端末に火事が発生問題が出て、Samsung社がそれによってbillions of dollarsの大幅な損害が受けた。背景は品質不足でした。
■ もし品質が足りなければ。。
品質は時間をかけて状況を把握するものです。ぱっと見た感じで不具合が解決されているかもしれませんが、商品には見えない問題が残っていることがあり、結局はお客様がそれを発見することもあります。
今の時代では、情報の流れが速いので、商品の品質不備がさっさと流れてしまい、担保出来る前に客の方で悪い印象を作ってしまう恐れも考えられます、場合によって事実です。一度でもお客様が悪い印象を持ってしまうと、二度ともその商品が使いにならないパターンが割と多い、長い目で結果的に業績に影響が与えてしまうのです！！！
■ 品質改善プロセスの紹介
企業のビジネス種類によって色々品質方式があるかと思いますが、特にIT企業に対して以下の改善プロセスが良い結果を返してくれるのではないかと思います。
本プロセスの導入は大作業の上、時間をかけて守れるべき物です。基本のアイデアは品質の専門者Mr. Joseph M Juran から参照しまして、さらに必要な個所などをどんどん導入してある程度完璧な品質改善プロセスが作られました。
一先ずMr. Juranさんのポリシー的に、主に三つ大単語です。
⇒ 要件定義
⇒ 開発測定
⇒ 向上継続
How it Works?
企業によって色々開発メソッドが使われています。現在のIT企業ですと、アジャイル式が人気です。ビジネス及び開発観点的にメリット点がそこそこありまして、よくかつ用されています。なので、今回の品質改善プロセスはアジャイル形式の開発を始め普段の開発プロセスにも役に立つと思います。
■ 一先ずビジネス「要件定義」：
物のサイズさえ分かれば、必要な清算は楽です。同様にリリース候補内容が重要です。きちんと内容が分かれば、それに対して検証行動も正しく計算が出来て漏れが少なくなります。
商品の品質は一回で完璧にできることは不可能です。繰り返して業務を行い、少しずつ改善していくのは当たり前です。そこで大事なのは、毎回のリリース時に、何を提供していくのか、何を出すべきなのか、またはどこまで開発するのかを明確にすることです。理由として、リリース候補の内容が大きければ大きいほど、テスト関連の業務も増加します。したがって、最初にリリース内容を明確に決める必要があります。それによって、関係する箇所で検証業務の準備を行うことができます。そうすることで、検証範囲が正しく決まり、無駄な作業時間も減らせます（以前お伝えした通り、テストはするほど完璧にはならないこともあります）。
商品の品質は、継続的な努力と戦略的な判断によって向上します。一度でもお客様に悪い印象を与えることなく、最高の品質を提供するために、リリース戦略を慎重に考えましょう。
■ 開発された物の「測定」
どんな製品を作ろうとも、最終的にはプロダクトオーナーに受け入れられなければならない。 この最初の納品段階では、製品がどのような状態なのか、どのように開発されているのかが何となく分かれます。
範囲内で実装がきちんとできているか！そして、出来た商品の品質担保ができているかは、この辺で測定します。上の画像に指定されている通りですが、一般的なテストプロセスを実施します。（こちらはちょっと深くて複雑なプロセスですが、細かくは書きません）要件定義通りにテスト計画を立てて、必要な工数やリソース、テスト設計などをきちんと準備して進めるのです。何度も繰り返して作業が発生するのは当然ですが、要件通り該当範囲まで品質を担保できていればリリース判定になります。
ところで、このテストプロセスを実施する際に、いくつか大切なことを作業チームの心に留めておいていただきたいです。
・Ownershipの考え方
・ビジネス影響なしの前提でリリース
・Resilience（回復力）
テスト業務は、見た目で簡単と思われますが、実は責任感が山ほどあります。商品が開発され、リリースの前段階であるテストを行う立場として、テスト実施者は責任を持たなければなりません。いくら頑張ってテスト業務を行っても、お客様の方で一つの不具合が出たら、その責任の一部はテスト実施者や関係チームにも及びます。ですから、テスト業務を行う際には「Test Ownership（テストの責任）」の気持ちを持つことが大切です。
次は、不具合なしの前提で業務を進めるべきです。100%のテスト完了は不可能であっても、テスト実施者自身で判断することが重要です。どのタイミングで区切りをつけるか、自分らしいテスト業務によって判断できるのではないかと思われます。経験による判断が楽な場合もありますが、経験が浅い場合はチームと相談してから区切りをつけるのが一般的な考え方です。
人は誰にでも間違いがあります。いくら注意しても、ミスを起こしてしまう場合があります。完璧な人でも時々ミスなど起こしてしまうのです。ここで大切なのは、業務で間違い、漏れなどが発生された場合早速の対応。どのスピードで対応が出来て回復準備して、問題をさらに広げるを避けられるのか！関係チームとともにテスト関係者も同様心の準備を持たなければなりません。
■ 品質向上の継続
ここがメインポイントです。徐々に品質状態を改善して行く為色々方法があると思います。今回はいくつか重要な改善ポイントをご紹介します。
・改善度測定 ： Measureing of Improvement
・不具合の分析 ： Analysis of Defects
・顧客の洞察 ： Customer Insights
・影響範囲の認知 ： Acknowledged of Impact Ranges
・自動化 ： Automation of Systems
・品質KPI ： KPI of Quality Improvement
品質とは、常に測りながら順調な状態を保つ必要があります。製品の進化作業を進めながら、品質向上の業務も並行して行うものです。
改善度測定
とても重要な項目でありますが、正しく測る為に必要なデータを参照して行きましょう。企業によって色々データ収集方法ありますが、品質にかかわる基本的なデータを分析で測れる結果がもらえます。例えば、
不具合の比較：比較的にどのほど問題が上がっているかを測定する。一先ず、現行版と直前のリリース関連データで、具体的に言うと、
・発生率 = 現行版での発生数/前回の版で発生数
※こちらの収集に対して重要なのは、主に新規実装の影響で発生されたバグとなる。平均的な値をもらうには、過去複数リリースの情報をまとめるのは理想です。もし、過去の１０個リリースに対してデータを収集されてある場合、
・平均的に不具合の発生値 ＝ 不具合の総数/１０個リリース
それで、この値があればある程度判断に使えます。これによって値の変化どれほど変わっているか！もしくは平均値と同じか/少なくなっているかにより改善度に関して少しでも測れます。
不具合の分析
直前の不具合とこちらの不具合を一先ず別物として分かっておいて下さい。ここで分析したいとは、あくまで品質保証を通った上で発生された不具合率、つまりエンドユーザーより上がって来たclaim率などの収集のことです。毎日/毎月又は過去三か月でどれほど
→ 不具合報告があったか
→ SNSなどで不具合情報上がったか
→ ユーザーレビューなどで
このデータを収集し、発生する原因の分析が重要です。テストが完璧であるのに、お客様の方で報告されている現象にはさまざまな条件が含まれていることがあります。テストは100%完璧にはできないため、クレームが入ってくるのは普通です。それらの不具合を分析して、根本的な原因を見つけることが重要です。関係者と協力して問題を解決するのです。開発側の視点では、想定されている不具合なのかを確認し、予測外の問題なのかを調査の上QAの視点では、テスト関連の漏れや必要条件の欠如、実行の不備などを確認を合わせて分析結果をまとめる必要があります。そして定期的なデータ分析によって改善の度合いを把握できます。
分析結果を測るためにさまざまなメトリックがありますので、参照してください。
顧客の洞察
とても重要な改善ポイントです。直接品質改善というより少し離れるかもしれませんが、全体のサービス品質の向上に大きく繋がる項目となります。品質改善の立場でよく把握するべき物です。
どんなサービスでも、主な目的は、お客様にそのサービスを提供することです。そのユーザーが商品を利用してどんな思いを感じているかをfeedbackとして受けとならないと、今後の改善にも足りない、足りていない物が出てしまう事が考えられます。
それは、製品に対してかもしれません、品質に関して不満の事かもしれません！上の記載がありましたが、一度お客様が悪い印象を受けてしまうと、中々その商品に向き合いたくない可能性があります。結局それは、業績に影響が出てしまいます。ですので、その辺りをケアの上定期的に収集データを分析し、今後の改善に必要な行動するべきです。
影響範囲の把握
商品の実装には大勢のチームメンバーが関わっています。その中で、知識と能力のレベルは人それぞれ異なると思われます。良い意味で言いますと、実装の際に該当する機能またはサービスについて深く知識を持っていれば、実装された物の安全性が高まりますね。一方で、割と知識がまだ十分でない方の実装箇所から見ると、目的の実装部分が完璧に出来ているかもしれませんが、どこに影響を与えてしまうのか！あまり分からないもしくは把握されていない場合が多いです。
なので、可能であればUXとAPI、または各機能の連携されたマトリックスを準備しておけば、ある程度の保証ができるのではないかと思います。毎回のリリースやどんな時でも、開発者および検証者が可能な影響範囲について簡単に把握できるため、大幅な改善ができるでしょう。
色々方式があるかと思いますが、一先ずどなたでもわかりやすい＋メンテしやすいの形でマトリックスが作れます。以下の例を見てみましょう、
※BAL＝バックエンドAPIレベル
※CA＝クライアントAPI
※SF＝サービス機能
こちらのマトリックス表では、どのAPI、CA、SFがどれとかかわっているか、何とか分かれるようになっています。こんな表が簡単に作れるわけではないと思いますが、関係者と協力ながらサービスに新規API,又はサービスが追加された時点で少しずつ更新して行くと楽です。
自動化
自動化はテスト業務の中で一つ重要な項目です。これによって時間の大幅な改善が出来ます。現在は、案件の流れが激しい企業もたくさんあると思い、リソース不足的な問題を解決する為自動化のメリットが測れ切れないです。但し、UX的な自動化テストに対しては、いくつかの条件を守っていかないと単純なテスト実施となり、効果が見えなくなります。つまり、ROI（Return on Invest）を重要することです。例えば、
→ ビジネス的なクリティカルパターンを必ず網羅し、必ず回帰で回せるように準備しておく
→ 頻繁に変われるもしくは挙動の変動がある機能の自動化を避けて良い
→ 自動化テストでは、”多分問題ない”と感じて普段実施から外れている項目を網羅しておく
→ 時間を優先して、あまりカバーできない条件を付けるパターンを網羅しておく
→ クロスプラットフォーム的な項目を網羅しておく
→ 割と条件の複雑さがあるパターンを出来れば網羅しておく
→ 自動化テストでは、出来る限りUI確認的なパターンを避けるようにしておく
→ 自動テストの実施率、効果率及び更新頻度のKPIを監視するようにする
→ 出来るだけUX向けの自動テストと手動テストの重複を減らせる方式で調整して行く
テスト自動化の効果をしっかり受け取る為に、出来すだけ関連個所で改善しながら活用すると、良い物になります。
品質KPI
KPI（Key Performance Indicator）とは、どんな作業に対して用意する物です。きちんとKPIの確認が取れれば、必要な改善点が見えて来ますかつ進め方の違和感があれば発見も出来るようになります。品質状態が「良い/良くない」か！ぱっと見判断する物ではありませんので、大分時間がかかる場合もあります。案件及び企業が大きければ、大きいほど分析も幅広くしないと正しいKPI結果が難しいです。
よく質問するとして、なぜ品質保証にKPIが必要でしょうか？
答えがたくさん有っても一言で言いますと、高水準の品質を維持する為です。品質チームの責任は、商品の品質を担保する事なので、そもそもチームの方々の品質状態に関して、深く把握していないと向上は難しいと思います。現状態及び定期的にどう変わって来ているかを具体的な数字で出して比較して改善業務を進化する事が出来るのです。
企業種類によって、QAでまとめるKPI方式が異なるのは当然ですが、自分の経験では以下のデータでQA用KPIが出来ると思います。
→ 要件の不備
→ 設計的な間違い
→ 実装的な間違い
→ 仕様又はサービス機能の理解不足
→ コーディングミス
→ デグレード
→ 環境的問題
→ テスト観点不備
→ テスト項目不足
→ テスト実行から漏れた
→ 影響範囲の考慮漏れ
→ その他
■ 未来のQAプロセス
「懸念」of the Future
Observers have said that the roots of the recent rash of illicit practices lie in Japan's labor shortage and prioritizing meeting deadlines above all else, causing sloppy quality management. Intensifying international competition is also pushing Japanese companies to cut costs, and we wonder if the pressure to save, save, save has been shifted primarily to the factory floor.
「毎日新聞の記事より」
どうすれば良いでしょう？
を繰り返しながら、方式を出来るだけ進化して進めれば何とか良い結果が出るのではないかと思われます。
しかし、QA業務と同時に品質分析など行えるならば、改善必要な弱い箇所の判明が早速出来て、その辺りで改善などを実施されます。一気に全般的に全力を入れるより、割と必要な点からで業務して進めると、時間＋リソースの大きな管理もできます。
※未来の品質改善向けのツールイメージ
■ 最後に
QA活動は企業トップの意思決定にかかっている。チームが様々なタスクを設計する一方で、適切な権限の承認を得ることは極めて重要である。幅広い活動には協力と支援が必要である。トップマネジメントのコミットメントがなければ、これらの目標を達成することは困難になる。このように、QAは組織の意思決定に大きな影響を与える。
数多くの改善プロセスを設計することができるが、その実施は重要である。時間と労力の投資を考慮し、企業はそれらを取り入れるかどうかを決定しなければならない。したがって、経営トップはQAを徹底的に理解すべきである。そうでなければ、成果を上げることは難しいかもしれない。品質そのものがブランディング材料となり、達成されればビジネスの成長に貢献する。
※本記事は個人的な経験及び知識を書いた物なのです。©2024 Roman Ahmed e-Mail: fruswlo@icloud.com