製品の定義と設計にテスタのフィードバックを活かすことは、ビジネスのための価値ある行動だ。組織のニーズに耳を傾け、ビジネスの目標を理解し、さまざまなスキルやプラクティスを駆使してテストプロセスをカスタマイズする作業は、プロダクトがまだ"机上の空論"である時からテスタが始められるひとつの方法である。
InfobipのシニアコントロールアナリストでチームリーダのIrja Straus氏は、ConTEST 2021での講演で、テスタが製品定義に貢献する方法について探求した。
"テストはプログラムを書く前から始まる"というのはよく言われることだが、正しく理解されているかどうかは定かではない、なぜなら、"すべてのための唯一のレシピ"が存在しないからだ — すべての組織には、さまざまな人たちが推進する独自の目標があるのだ、とStraus氏は言う。
よりよい製品を開発するには、製品定義における批判的思考が有用だ、と氏は言う。製品開発を成功させるということは、単にソフトウェア開発が成功することではない。
成功した製品とは、クライアントの問題を解決するものであり、それぞれの疑問を持ち、異なる感情や思考方法によって導かれた、さまざまな人たちで構成されたチームによって作り上げられるものなのです。
例えば、プロダクトマネージャは、カスタマにとって最も重要な問題は何なのかを自らに問うでしょう — これこそが、チームが解決したい、可能な限り早く解決したい問題だからです。
開発者や設計者も同じように、回答としてそれを解決する方法を探ることでしょう。それに対して私たちテスタは、"何がうまくいかないのか"を示すことで、製品が失敗する可能性について考えるのです。リスクを探し出し、それを軽減する方法を提案するのが私たちの役割です。
製品が提案されていない時点において、これらの疑問を提示できれば、対応して変更するための費用が低減できる、とStraus氏は言う。
開発の初期段階において批判的フィードバックを提供する方法について、氏は次のように説明する。
同僚をミーティングやペアリングセッションに誘えば、彼らが何をリスクと考えているか、基本的な品質特性は何か、などを、いつでも知ることができます。それに従って、有効なフィードバックを提供すればよいのです。そのようにして、一歩一歩、共同作業を確立するのです。重要なのは、早い段階で支援やメリットを届けるためには、情報が自分たちの手元に来るまで待っていてはいけない、ということです。
もちろん、それとは逆方向で、同僚(プロダクトマネージャ、設計者、開発者、...)の側にも、テスタを招き入れてフィードバックを受け取ろうという意思が必要です。最初は難しいかも知れません。テスタが自分たちの居場所から出て、最初の一歩踏み出す必要があるでしょう。ですが、早期コラボレーションの価値をひとつの例(小規模でも構いませんが、企業にとって価値のあるプロジェクト)で示すことができれば、その例を組織の他のメンバと共有することによって、きっかけを作ることができるのです。
"参加する"ための最も簡単な方法 — それは参加することだ、とStraus氏は言う。
もちろん、プロセスに"望まれずに参加"したいとは思いませんが、作業が始まって、私たちテスタが価値を提供することができるのならば、傍観者でいるということもまた、望ましいものではないはずです。
製品要件と設計のレビューに対して、テスタとその活動や技術が関与することについて、Irja Straus氏にインタビューした。
InfoQ: 講演では、テストはコードを書く前のプロダクトレビューから始めることができる、という話がありましたが、どうやって始めるのでしょうか?
Irja Straus: 企業はそれぞれ、作っている製品が違います。ですから、製品を構築するプロセスを理解し、ステークホルダと優先順位について知ることが最初の課題です。私は同じ会社のプロダクトマネージャでしたから、最初のステップは難しいものではありませんでしたが、協力する人々の間に理解が存在しない場合には、難しいものになるかも知れません。
理解のギャップを縮める上で、成功の立証されたアプローチは、"話す前に聞く"ことです。具体的には、ステークホルダ(プロダクトマネージャや設計者など)と会い、彼らのモチベーションや目標を知り、関係を築いてコラボレーションを成立させる — すなわちフィードバックループです。
その次には、プロダクトマネージャと会話する、業界関連の記事を読む、顧客データを分析するなどの方法で、クライアントのニーズとそのユーザのペルソナについて探る必要があります。ユーザのペルソナはそれぞれが異なる目標を持っているので、私たちの製品を使って、さまざまなタスクを完結できなくてはならないからです。設計やユーザエクスペリエンス、あるいは製品要件についてのフィードバックを提供する時、私にとって重要なのは、彼らの違いを理解して、それぞれにとって何が重要なのかを学び、特定の品質特性(データインテグリティ、コントロール、一貫性など)を目指すことです。このような情報を知ることで、私の気付きを報告する時にステークホルダの言葉を使うことが可能になって、フィードバックを彼らにとってより関連深いものにできるのです。
フィードバックループは、短ければ短いほど好都合です。そのために私は、プロジェクトがキックオフされて要件が固まるか、あるいは最初のプロトタイプが行われる時点から同席して、次に重要なものは何かを積極的に質問したり、さまざまなステークホルダをペアリングやコラボレーションに誘うことで、製品に関わる重要な情報の発見と共有をするようにしています。
InfoQ: 要件が議論されている間、テスタはどう関与できるのでしょう?
Straus: ビジネスのプロセスや責務は企業ごとにまったく違いますから、どうやってアプローチすればよいかを明確に答えることはできませんし、すべての企業とすべての状況に必要かどうかも分かりません。それでもビジネスプロセスや、そのために特に重要なものは何か、どのようなフィードバックが最も価値があるか、といったことに関して、プロダクトマネージャやビジネスアナリストといった仲間と交わすごく一般的な会話が、彼らのビジネスを支援する方法についてのヒントを与えてくれます。
彼らのビジネス上の目標が理解できれば、フィードバックを提供したり、彼らを脅かすリスクを分析したりすることで、彼らを支援することができるようになります。問題なのは、これらの目標が、ほとんどの場合において、要件には記載されていない、という点です。もうひとつの課題は、要件には正確な仕様が存在しない、という点です。そのためには、関係者との要件に関する議論(つまりミーティングの設定)が必要になります — 比較的簡単ではありますが、これも第3の課題と言えます。
InfoQ: 設計やUIの議論に対して、テスタはどのように貢献できるでしょうか?
Straus: 少し前に、"ステークホルダの言葉を話す"ことの重要性について述べました。議論に貢献するには、この、彼らの言葉を話すことが重要なのです。つまり、何が十分で何が不十分なのかを説明することを学んで、"うまく言えないが、気に入らない"以上のレベルに議論を高めることが重要です。テスタとしてこれを行う上で、設計やUIの専門家になることを勧めているのではありません。ですが、これらの議論に貢献するには、一般的なプラクティスやヒューリスティックに関する知識を持って、それを適用することが必要です。
まず最初は、Jakob Nielsenの"10 general principles for interaction design"を推奨します。そしてもちろん、設計者やユーザエクスペリエンス研究者に声を掛けて、フィードバックを提供してくれるように依頼しましょう。:)