【イベントレポート】クオリティ（品質）視点から考えるプロダクト開発やデザイン、新規事業とは？

2021年4月21日にオンラインイベント "Build.Lunch Session" - クオリティ（品質）視点から考えるプロダクト開発やデザイン、新規事業とは？- を開催しました。

"Build Lunch Session"とは
DXの概念論や理想論ではなく、現実的に課題を解決するためのノウハウ、メソッドや国内事例に注目し、国内リーディング企業とともにDXの実現に欠かせないポイントについて対話するランチトークセッションです。

【登壇者】

神原 宏行（CTC Buildサービス推進チーム長）
2003年入社。大手の電機メーカーをSEとして担当し、その後、様々なソリューションやサービスの開発に携わる。昨年度から、Buildサービス推進チームの責任者を務める。

日野杉 賢祥（CTC Buildサービス推進チーム / QE（クオリティエンジニア））
2020年入社。前職のSaasベンダーにて、テスターからプログラマー、品質管理、QA（Quality Assurance）、QC（Quality Control）と、品質に関わる様々なキャリアを積む。2020年11月にCTC Buildサービス推進チームに転職後、QEとして従事。得意分野は、テスト自動化、品質管理、品質保証。

伊澤 和宏氏　（㈱グッドパッチ／デザインストラテジスト）
ハードウェアのデザイナーとしてメーカーとコンサルティング会社に従事後、グッドパッチに入社。
現在は、デザインストラテジストとして、ビジネスとデザインを繋ぐ役割の仕事をしている。主に新規事業開発や、既存事業の改革支援協力を担当。

「品質」は後回しになりがち？

神原：
本日のBuild Lunchセッションでは、ついつい後回しになりがちなクオリティ＝品質について深掘っていきます。最新のソフトウェアプロダクト開発の品質管理は、これまでの品質管理とは何が違うのか、という観点を交えながらご紹介していきたいと思います。
伊澤さん、やはりハードウェアのプロダクト開発において、品質は後回しになりがちになってしまうのしょうか？

伊澤：
そうですね。一般的に、機能や細部を詰めるステージでは、品質は後回しになりがちです。開発が全て終わった後で、品質管理の担当者がテストをすることはよくあります。
一方で、デザイナーとしての観点では、品質という言葉は「顧客に価値が伝わるかどうか」という意味で使うので、早々に品質を突き詰めることは多いと思います。さらに私たちは、「愛され続けるものになるかどうか」を重要視しているので、品質を先に考えることは多いです。
よくある例えで「空腹限界の人にキャットフードを食べさせれば、空腹は満たされる」。そのため、「MVP（Minimum Viable Product:実用最小限のプロダクト）」の観点では、「キャットフードでも良い」ということになります。しかし、「食べらればいい」のではなく「食べ続けたいか」という観点では、キャットフードは食べ続けたくはないはずなので、我々は「空腹を満たしつつも、ちゃんと愛されてもらえるものなのか」ということを大切にしています。そのため、MVPではなく「MLP（Minimum Lovable Product）」を先に作り上げることが多いです。

神原：
物理的（ハードウェア）プロダクトは、最後のゲートとして品質をテストするのが一般的ということですね。
では、これまでの一般的なソフトウェア開発でも、品質は後回しになりがちなのでしょうか？

日野杉：
そうですね。これまでの一般的なソフトウェア開発の現場では、スピードを求められる機会が多く、納品が優先になり、品質は後回しにされがちという認識があります。

神原：
ただ、品質を後回しにすると、困ることも実際にありますよね？

日野杉：
はい。サービスの品質が悪いと、個人向けサービスであれば、解約に至るケースや、類似サービスに乗り換えるケースもありますし、売上が悪ければそのプロダクト自体が破棄されることもあると思います。

神原：
一般的なソフトウェア開発では、まだまだウォーターフォールで進めることが多く、要件を決めて、作り込んでからテストをすることになります。先ほど日野杉が言ったように、まずはスピード重視で世に出すことが優先されると、品質は後回しにされがちなのかなと思います。

スピードと品質のバランスとは

神原：
ただ、品質とスピードのバランスを考えなければいけません。
品質はセキュリティに似ていて、時間とコストをかければどこまでも追及していくことができます。一方で、際限なく品質を求めすぎると動きにくくになってしまうので、品質とスピードのバランスをとっていくことは非常に重要なのかなと思います。
では、スピードと品質のバランスはどのように考えていけば良いのでしょうか？

伊澤：
機能的な品質という意味では、我々デザイナーは細部まで拘りたくなるので、お金をかけられる限りとことん突き詰めてしまいがちです。
しかしそれをやっていたらキリがないが無いので、事前に、プロダクトの段階を鑑みて「このステップではこの粒度まで突き詰める」というプランニングを徹底的に行うのが重要になってくると思います。

日野杉：

そうですね。（個人的な理想は時間をかけ品質を作り込むことなのですが、）プロジェクトマネージャーやプロダクトオーナーと事前に相談し、推奨ラインを握っておくことが必要だと考えます。

神原：
加えて、製品やサービスであれば、それを使うお客様を事前にリサーチするということも重要ですね。

従来の「プロジェクト開発」と最新の「プロダクト開発」の違い

神原：
ここからは、従来通りのウォーターフォール主導で作り込んでいく「プロジェクト」の品質と、最新の「プロダクト」としての品質。
2つの違いについて、クオリティエンジニアの日野杉からお話させていただきます。

日野杉：
まず、従来通りのウォーターフォール主導でのプロジェクト開発を行う場合、上図のような流れで品質管理が行われます。一般的には単体テスト、結合テストまでをSoftware Engineerが担当し、システムテスト、受入テストまでを
Quality Assuarance(QA)が責任を持ちます。

QEとは

日野杉：
ちなみに、私が思い当たるだけでも品質関連の職種はこれだけあります。(上図)

日野杉：
私が担うクオリティエンジニア（QE）は、各職種の要素を全て含めたテスト自動化エンジニアと考えていただけると理解がしやすいかと思います。
QAは、よく「第三者の視点でテストする役割」と言われており、エンジニアとは別のチームでテストすることが多いです。一方QEは「エンジニアのチームの一員として品質向上を進めていく役割」であり、必然的に、エンジニア＋QAのスキル・経験を求められるため、少し難しい職種かなと思います。

日野杉：
最新の「プロダクト」の中でQEの役割は、「テスト戦略や自動化といった品質への焦点をアジャイルに適宜組み込む役割」になります。
要は、既存の「プロジェクト開発」におけるQAの役割は、実装が終わってから展開したりレビューしますが、QEは実装が始まる前の準備段階から行動していくということです。

日野杉：
一番の違いは、実装完了後に品質に対して責任を持っていくのではなく、実装開始と同時に品質に責任をもって行動していく点だと思います。
もちろんウォーターフォール型の開発のように実装後にテストを行う役割は必須です。しかしスピードが求められるプロダクト開発においては、同様の立ち回りでは、バックログの新規実装チケットが「QA完了待ち」になり、「QAが完了していないのでリリースできません」と言われたりします。
そうようなことを防ぐために、QEという役割を置き、実装が開始されたと同時に行動していきます。その方が継続的にに活動できるし、結果的にスピード感をもって品質を上げていくことができると思っています。

神原：
要は、変化に追従するプロダクト開発においても「品質を作りこんでいける」ということですね。

QEの品質活動

神原：
では、最初から作りこんでいくというのは、具体的にはどのようにやっているのでしょうか？

日野杉：
QEの品質活動についてご説明します。従来のQAであれば、図の「Ready for Test」の段階から、設計や実装されているものを動作・仕様などを確認しながらテストをしていきます。
しかしQEは「Ready for Development」、要は開発の準備段階から行動していきます。そして開発途中から、単体テストの実装、API/UIテストの実装、コードレビュー、受け入れ基準の検証などを進めていきます。「Ready for test」から後は、従来のQAがやっている流れと変わりません。
さらに、「Definition of Done」（完了）の部分の定義に「全ての自動化が完了」というのをおいています。自動化をしない選択肢を取る場合もありますが、自動化することを「Ready for Development」の段階で決めたからには、この完了の定義に「全ての自動化の完了」をもってくるのが大事なポイントとなっています。

神原：
準備段階から品質活動は始まっていて、完了は「チェックができた」ではなく「自動化が完了している」というのがポイントですね。

日野杉：
また、アジャイルでのプロダクト開発が基本となるため、アジャイルセレモニーにおけるQEとしての役割も果たします。補足すると、スクラム開発のガイドラインには、スクラムマスター、プロダクトオーナー、開発者のような役割ごとにセレモニー(＝打ち合わせ)でのスタンスと実行するべき内容が記載してあります。しかし、QEの立ち回りについては記載していないので、独自に作ったものが上図の「アジャイルセレモニーにおけるQEの役割」になります。

神原：
アジャイルの進め方のフレームワーク自体はあるけれど、加えて、品質を司るQEが「どんな会議でどんな立ち振る舞いをすべきかを定義した図」ということですね。

伊澤：
QEは、開発の業務プロセスから変革させる役割という印象を受けたのですが、QEが必要だと判断されるのはどのようなタイミングでしょうか？

日野杉：
基本的にプロダクト開発で品質を固めたい場合は、（QEという名前では無くても）最初から、開発が初期段階から品質に対して責任を持つ人物は必要だと思っています。

神原：
「動く」ということだけにフォーカスすると少し後回しでもいいかなとなるのですが、それを最初から横で見ながらコントロールするのがという役割です。

神原：
こちらのQEのテスト内容はかなり細かいですね。テストというと、ユーザーに触ってもらう前に、自分がユーザーのつもりになって検証して、不具合を事前にチェックし省いておく、という観点が思い浮かびます。
そもそもなぜ細かく分かれているのでしょうか？

日野杉：
細かく分かれている理由は、「テスト対象を明確にする」という意味合いが大きいと思います。既存のQAの役割にも「システムテスト」がありますが、実施すべきタイミングが定義されている場合とそうでない場合があるので、我々はこのようにわかりやすく定義し分類しています。
この中で一番大事なポイントは「Component/APIテスト」です。ここはチームの各ロールと関りながら進めていくので、コミュニケーションと実装能力の両方が求められます。且つ、レビューもしなければならないので、かなり難しい部分だと思います。

神原：
特に作り手(エンジニア)と一緒に作りこんでいく部分であり、アジャイルセレモニーで一緒にレビューしたり、振り返りを実施したりしていると理解しました。

テスト自動化について

日野杉：
「テスト自動化」についても触れさせていただきます。
まず、先ほどのスライド「QEのテスト内容について」の区分は、手動も含まれます。自動化する、しないの戦略を立てる際には、図のようなテストピラミッドのセオリーを用います。自動化への投資はコストが高いので、何を重点に置き、どれくらいの粒度でやっていくか、この図に基づいて考えていきます。
QEは、Component/APIがE2E UIよりも大幅に多くのテストを実施する必要があるので、ここにフォーカスして自動化します。もちろんE2E UIテストも自動化しますが、Component/APIテストを自動化し土台をしっかりさせた上で、E2E UIテストを自動化しないと、意味のないことになってしまいます。

神原：
（デザイナーの観点では）お客様と接するインターフェースの部分を重点的にテストするかと思いきや、逆に土台のところなんですね。

伊澤：
ユーザーテストには、ユーザーが価値を感じる設計かどうか、「定性情報」の積み重ねであるため自動化できない、というジレンマがあります。
テスト自動化をすると、フィードバックの量が尋常ではないことを想像しますが、自動化したことでフィードバックが有効的に働いたケースはどのようなものがありますか？

日野杉：
テスト自動化をすることで結果は膨大になりますが、注目する部分はシンプルで、NGが出た部分です。NGが出た場合は、プロダクトに関わるメンバー全員に共有し、NGが出なければ常に仕様通りに動いているという安心感につながります。品質に担保しよう、という動機づけができるのは大きい効果なのかなと思います。

神原：
定性的なフィードバックをもらいながら作り上げていくのは、定性面の改善につながり、テスト自動化は定量的に見える化できるということですね。

日野杉：
そうですね、安心度を提供しているイメージです。

日野杉：
そして何故、テスト自動化が必要なのかについてです。
この図は、自動化した場合の時間に対する費用対効果を示しています。下がコスト効率が低く、上が高い、という見方になります。手動チェックは逆の図になります。
自動化のためにコストをかけるので、やはり始めはコストがかかってしまいますが、中長期で見るとコストが下がりコスト効率が上がっていくので、自動化が必要であると感じます。

日野杉：
例えば、スプリント（アジャイル開発における2週間毎の開発期間）が9つあるプロダクトで、スプリントごとにストーリー（新規機能）が追加される場合を考えてみます。例えば、スプリントごとに毎回平均1～2個のストーリーが追加される場合、スプリント9になると、テストの内容は90％前後がリグレッションテスト（新規機能を追加したことによって既存機能は壊れずに正常に動いているか）になります。そのため、スプリント9までの中長期で見ると、同じテストを繰り返すことになり、自動化するメリットは大きくなります。
逆に、スプリント2まで、ユーザーが1社しかない場合などは、手動テストの方が効果的になると思います。
したがって、対象者と期間によって、テスト自動化の有無の議論は重要であると感じます。

神原：
アジャイル開発およびプロダクトの開発で、お客様にフィードバックをもらいながら要件や新機能なども変化する前提においては、前段階で作ったものが正常に動くのか、毎回検証しているということですね。

日野杉：
そうです。毎回検証をすることを考えたら、始めにコストをかけて自動化をした方が効率的であり、他の部分の品質向上に注力できるメリットがあると考えております。

神原：
品質を作りこんでいく＝変化適応型の新規ビジネスに踏み込んでいくためには、テスト自動化は必須ですね。
プロダクションで将来を見据えると、自動化しないと難しいと感じます。

日野杉：
そうですね。ウォーターフォールでもテスト自動化は有効だと思うのですが、アジャイルだとより如実に費用対効果が出続けてくると思います。

まとめ

日野杉：
テスト自動化はアジャイル開発において非常に重要な要素だと思います。しかしテスト自動化をしても、メンテナンスコストや誰が管理をするかが決まっていないままスタートしてしまった為、結局無駄になってしまうケースもよく目にします。
そのため、テスト自動化の実行可能性を高めるためのベストプラクティスを、このように書かせていただいております。
テスト自動化は削減対象ではなく、開発そのものだという認識をもっていただきたいと思います。もちろんスピードとコストのバランスも重要です。またテスト自動化をする場合は、プロダクト開発の完了の定義の一部として扱うべきだと考えます。
最後に、テスト自動化をする場合は、過剰な投資にならないよう手動でやるという選択肢も鑑みながら、テストピラミッドに基づいて進めていく、ということになります。あくまで、テストをするのは、品質を測定して維持する、という役割しか持たないので、テストの結果で不具合が発生して、それを修正してアップロードして品質を上げていくという展開が必要となります。
テストはあくまで測定機能しか持たないので、それを認識した上で、どのように品質を上げていくかの意識を持つことが重要であると考えております。

伊澤：
ユーザー体験設計をしている我々デザイナーの立場からすると、アジャイルは泥臭く、今できる手段を用いて人海戦術的にスピーディーに価値検証を回すもので、根性論的なものがテストと捉えがちでした。
しかし今日の話を聞いて自動化は開発の一部だということに納得をし、中長期のテストが見込まれるケースでは、ソフトウェア開発の中で品質を上げるためのアジャイル手法の一部と捉えテストを自動化するべきだと思い、勉強になりました。

神原：
普段開発に関わりのない皆様にも、最新の品質の作りこみはどのように進めているのか、どれだけ重要なのかがお伝えできていれば幸いです。

※現在、Buildサービス推進チームでは、下記ポジションを募集中です。ご興味のある方は、ぜひこちらもご覧ください。
・ソフトウェア開発エンジニア
・ソリューションオーナー
・ソリューションアーキテクト
・クオリティエンジニア