アジャイルプロダクト開発における「バリュー」を定義することは、あらゆる規模の組織にとって課題です。その定義は、オンタイムデリバリー、生産性、予測可能性などの測定基準に焦点を当てた、運用の観点から組み立てられて回答されることが多いでしょう。また、企業は、財務的利益、ユーザー満足度、プロダクトスコープの実現に焦点を当てた結果の観点からもバリューを定義します。
これらの観点からバリューを定義する場合、数多くの課題が発生します。運用の観点からバリューを見ると、ビジネスバリューやユーザーバリューを実際に実現することなく、指標を最適化することが可能です。成果の観点では、測定基準が互いにどのように関連しているのかが必ずしも明らかでなく、相互目的であることさえあります。さらに、プロセスや結果に優先順位をつけたり改善したりするために、異なる値をどのように組み合わせればよいのかが不明確な場合も多いのです。
IBM Garageは、ビジネスとユーザーのバリューを一致させるための一連のステップと多用途のツールを開発し、これをバリューオーケストレーションと呼んでいます。そして、バリューオーケストレーションを使用して、プロダクトのUX戦略とエクスペリエンスの変革を導き、アジャイル環境で継続的にバリューを提供します。この方法論は、複数の業界とフォーチュン500のクライアントで展開され、改良されてきました。以下に、その方法と知見を詳述します。
ステップ1:ユーザー行動からビジネスバリューを理解する
バリューオーケストレーションは、ビジネスバリューがユーザーの行動に根ざしていることを理解することから始まります。ユーザーとは、プロセスやツールの内部または外部のエンドユーザーと定義します。ビジネス・オーナーは、ユーザーが特定の行動をとることでバリューを実感します。例えば、eコマースサイトを運営している場合、ユーザー(新規または既存顧客)がサイトを訪問し、商品を購入し、広告に反応することでバリューを認識します。また、職場環境最適化ツールを開発する場合、従業員が仕事を完了し、素早く、ミスをしないことにバリューを見出すことができるかもしれません。
上記の場合、サイトを訪問すること、広告を見ること、タスクを完了すること、あるいはミスをすることのビジネスバリューを理解するのは簡単です。また、これらの行動の変化をどのように測定し、そのバリューを定量化するかについても、同様に簡単に想像することができます。
そして、このプロセスは、プロダクトのステークホルダーに、ユーザーの行動をどのように変化させたいかについて尋ねることから始まります。ある経営者は、「カートのまま購入に至らないユーザーを減らしたい」と言うかもしれません。ショッピングデータを検証し、カート放棄率を75%から50%に下げるという目標を設定することができます。
目標と成功の尺度を持つことで、取り組みにいくつかの利点が生まれます。それは、3つの本質的な問いに答えることができ、それに対して個人やチームが何人であっても連携できることです。
- 何を達成しようとしているのか:例えば、カートの放棄率を75%から50%に減少させる。
- 自分たちのソリューションがうまくいっているかどうか、どのようにして知ることができるのか:カート放棄率が低下したとき。
- いつ完了するのか:カート放棄率が50パーセントになったとき。
目標に到達したら、次にやるべきことは、"なぜ、ユーザーは75パーセントもカートを放棄しているのか?"に答えることです。
ステップ2:バリューモデルの作成
目標の行動と尺度が特定できたら、行動の変化を金銭的な影響に結びつけるバリューモデルを構築します。これらの計算式は、ユーザー行動の指標を入力とし、暗黙のうちに財務的影響を生み出します。この財務的インパクトにより、チームはユーザー行動の変化のバリューを互いに比較することができるようになります。また、このバリューモデルによって、プロダクトオーナーは一貫した利益計算を確立することができ、これを通じて将来のソリューションのROIを評価することができるようになります。
ステップ3:根本原因の特定
ステップ3では、変えようとしているユーザーの行動の要因を特定します。このような行動のドライバーを「根本原因」と呼びます。
カート放棄の例では、インタビューや既存データのレビューを通じて、お客様がカートを放棄する理由を特定するための調査を行うことから始めます。その結果、重要度の差こそあれ、多くのペインポイントを発見することができるでしょう。そのため、根本的な原因を優先順位の高い順に並べ替えて、調査・分析のプロトコルを設計します。この例では、ユーザーは注文の編集、「チェックアウト」ページへのアクセス、支払い情報の入力に苦労している可能性があります。このように、カート放棄への影響という観点からこれらの問題点に優先順位をつけることで、次のステップで解決すべき根本的な原因に優先順位をつけることができるのです。
クリックすると、優先順位をつけた根本原因を見ることができます。
ステップ4:解決策を考える
ステップ4では、優先順位をつけた根本原因に対する解決策を検討します。この段階で、設計チームは設計概要書を受け取ります。
チームは、最も容易に解決できると思われる根本原因を選択し、その根本原因に対する解決策を考案します。この例では、注文の編集にまつわるユーザーの悩みを検討し、より簡単、迅速、直感的に編集できるように作り直すかもしれません。
デザイン案ができたら、次は検証です。
ステップ5:ユーザーテスト
プロセスの5つ目のステップは、ユーザーによるソリューションのテストです。まずテストプロトコルを作成し、ユーザーにオリジナルのペインポイントを提示し、そのペインポイントを定量的に説明し評価してもらいます。次に、新しいエクスペリエンスを歩きながら、使いやすさ、スピード、直感性など、私たちの目標に関連する行動を評価するための質問をします。そして最後に、その問題が解決されたかどうかを定量的に評価してもらいます。ユーザーテストの結果、解決度が高ければ、開発の優先順位をつけることができます。
以下に、Frito-LayとのIBM Garageワークで実施された使用テストの詳細を示します。
クリックするとユーザーテストの結果を見ることができます
ステップ6:開発
この段階では、開発者は優先順位付けされた設計の悪影響に目を光らせることになる。ソリューションの文書には、ビジネスゴール、ユーザーへの影響、ソリューションがどのようにユーザーの行動に影響を与えるか、が含まれます。例えば、ビジネス目標はカートの放棄を25%減らすことであり、ソリューションは注文編集の簡素化により5%の削減を意図しています。開発したソリューションが、ロード時間が遅いなど、意図したユーザーの行動に悪影響を与える可能性がある体験をもたらす場合、開発者はプロダクトオーナーとデザインチームを巻き込む権限を与えられます。
ステップ7:影響を監視する
最後のステップは、成功の尺度を用いて、ユーザーの行動に予想される影響をモニタリングすることです。現実のデータをバリューモデルに組み込み、目標への進捗を評価することで、これまでに実現したバリューの増分を素早く算出し、残りの根本原因に対処することで期待されるバリューを見積もることができます。
アジャイルバリュー手法がもたらす実世界でのメリット
バリューオーケストレーションの特徴は、ユーザーバリューとビジネスバリューが直接結びついていることです。ビジネスバリューはユーザーの行動の関数であり、ユーザーバリューはその行動を変化させる手段です。上記のプロセスを通じて示したように、ユーザーの行動を推定、翻訳、測定することで、ビジネスバリューを算出、予測することが可能になります。
このアプローチは、プロダクト開発のライフサイクルにバリュー評価を取り入れることで、アジャイルデリバリーに直接的に適合しています。ユーザー行動の変化として表現された目標があれば、すぐにでも始めることができます。また、ユーザー行動の根本原因を分析することで、プロダクトチームは、同じビジネス目標に向かって作業しながら、新しいユーザーのペインポイントをバックログに取り込むことができます。これにより、エクスペリエンスの向上がビジネスの利益につながるというフィードバックループが可能になり、バリュー実現までの時間が短縮されます。
「体験とデザイン、スタートアップについて」の更新情報は、ぜひこちらのアカウント(@hrism2)をフォローしてください!
— いしまるはるき (@hrism2) 2022年5月30日