顧客の共感を構築する

[アーティクル]
04/03/2023

"必要は発明の母"。このことわざは、人間の不屈の精神と発明への自然な衝動をとらえたものです。オックスフォード英語辞典で説明されているように、"何かに対するニーズが不可避になると、それを入手または達成する方法を何としても見つける必要があります"。発明に関するこうした普遍的な真実を否定する人はほとんどいません。しかし、「デジタル経済のイノベーション」の記事で説明されているように、クラウドのイノベーションでは発明と採用の間のバランスが求められます。

この比喩をさらに続けると、イノベーションはより広範な家族から生まれます。 顧客の共感はイノベーションを誇りに思う親です。 イノベーションを推進する顧客の共感ソリューションを作成するには、重要な課題を解決するために顧客に継続的に戻ってきてもらえるよう、確固たる顧客のニーズが必要になります。このようなソリューションは、顧客の望みや気まぐれではなく、ニーズに基づいています。顧客の真のニーズを見つけるために、まずは共感して、顧客のエクスペリエンスを深く理解することから始めます。共感は、多くのエンジニア、製品マネージャー、さらにはビジネスリーダーであってもあまり開発されていないスキルです。幸いなことに、クラウドアーキテクトの役割におけるさまざまな相互作用と急速なペースによって、このスキルが養われます。

共感はどのように構築すればよいでしょうか。また、なぜ顧客の共感がそれほど重要なのでしょうか。顧客の共感は、顧客のエクスペリエンスを理解し、共有するのに役立ちます。実用最小限の製品 (MVP) の最初のリリースから、市場グレードのソリューションの一般提供まで、顧客の共感は、より良いソリューションの構築に役立ちます。さらに重要なことは、共感することで、チームが導入を促進するソリューションを考案しやすくなるということです。デジタル経済では、顧客のニーズに最も迅速に共感できる製品チームが、市場を再定義し、リードする優れたツールで明るい未来を築くことができます。

顧客の共感を構築するための前提条件を定義する

想定を定義することは、計画の基本部分です。計画を立てれば立てるほど、素晴らしいアイデアの土台に思い込みが明らかにじわじわと広がってゆきます。通常、想定は自己への共感から生まれます。つまり、"自分がこの立場だったら、何を望むか" というものです。構築フェーズから開始することで、思い込みがソリューションに影響する期間を最小限に抑えることができます。また、このアプローチでは、実際の顧客とのフィードバックループが加速され、早期に共感を学んで研ぎ澄ませる機会のきっかけになります。

注意事項

構築対象を適切に定義することは難しい場合があるため、何らかの演習が必要です。あまりにも短時間で構築すると、顧客のニーズが反映されない可能性があります。初期の顧客のニーズとソリューションの要件を理解するために時間がかかりすぎると、何かを構築する機会を得る前に、市場によってそれらが満たされてしまうおそれがあります。いずれのシナリオでも、学ぶ機会は大幅に遅れるか、減る可能性があります。場合によっては、データが破損する可能性もあります。

歴史上最も革新的なソリューションは、直感的な信念から始まりました。その直感は、既存の専門知識と直接観察の両方から得られます。構築フェーズから始めるのは、その直感を迅速に試すことができるためです。そこから、より深い理解と、より明確な共感を育むことができます。ソリューションのイテレーションまたはリリースのたびに、顧客の共感を示す MVP を構築することでバランスが生まれます。

このバランスを着実に取るために、次の 2 つのセクションでは、共感を構築する方法と MVP を定義する方法の概念について説明します。

顧客重視の仮説を定義する

共感の構築とは、特定の顧客のニーズを示す定義済みの仮説に基づいてソリューションを作成することを意味します。以下のステップでは、共感の構築を促進する仮説を策定します。

共感を構築するときは、常に顧客が中心です。この意図は多くの形を取ることができます。解決する問題の中で、顧客の原型、特定のペルソナ、さらには顧客の写真を参照する場合があります。そして、顧客は内部 (従業員またはパートナー) または外部 (消費者またはビジネス顧客) の場合があることに留意してください。 "この特定の顧客を助けることができるか" という定義が、検証すべき最初の仮説です。
顧客の経験を理解します。共感を構築するということは、顧客の経験に共感し、顧客の課題を理解することを意味します。この思考様式は、テストされる次の仮説を示しています。このような対処可能な課題を抱えているこの特定の顧客を助けることはできるでしょうか。
1 つの課題に対して明確なソリューションを定義します。人、プロセス、各分野の専門家の専門知識に頼ると、ソリューションを導き出すことができる可能性があります。検証すべき完全な仮説は、"提案したソリューションを通して、このような対処可能な課題を抱えるこの特定の顧客を助けることができるか" というものです。
価値の提示に到達します。このような顧客にどのような長期的な価値を提示したいでしょうか。この質問への答えによって、ご自身の完全な仮説が成立します。提案したソリューションを使用して、このような対処可能な課題に取り組むことで、これらの顧客の生活はどのように改善されるでしょうか。

この最後の手順は、顧客の共感に基づく仮説の頂点です。これによって対象ユーザー、問題、ソリューション、改善の基準となる指標を定義します。これらはすべて顧客中心です。測定と学習のフェーズでは、それぞれの仮説を検証する必要があります。チームが対処可能な顧客ベースへの共感を深めるにつれて、顧客、問題提起、またはソリューションが変化することが予想されます。

注意事項

目標は、顧客の共感を "計画" することではなく、顧客の共感を "構築" することです。完璧な顧客の共感の提示を見つけるために、計画と調整の無限のサイクルに巻き込まれることはよくあります。このような提示を作成しようとする前に、MVP の定義と構築に関する次のセクションを確認してください。

中心となる仮説を証明したら、その後のイテレーションでは、共感テストに加えて成長テストに焦点を当てます。共感の構築、テスト、検証が完了すると、大規模に対処可能な市場がわかるようになります。前述した標準的な仮説の公式を拡張することで、対処可能な市場をより深く理解できます。その後、使用可能なデータに基づいて、市場全体の規模 (潜在顧客数) を推定します。

そこから、市場全体のうち、同様の課題が発生し、対象のソリューションに関心を持つ可能性がある割合を推定します。これにより、対処可能な市場が決定します。次に検証すべき仮説は、"提案したソリューションを使用してこの対処可能な課題を解決することで、顧客の生活の x% がどのように改善するか" というものです。顧客のわずかなサンプリングにより、関係する顧客のプールへの影響の割合を示す先行指標が明らかになります。

仮説をテストするソリューションを定義する

構築 - 測定 - 学習のフィードバックループの各イテレーションで、共感を構築する試みは、MVP で定義されます。

MVP とは、"顧客と共に" 学ぶことができる十分なソリューションを作成するために必要な最小の作業単位 (発明、エンジニアリング、アプリケーション開発、またはデータアーキテクチャ) です。すべての MVP の目標は、以前の仮説の一部またはすべてをテストし、顧客から直接フィードバックを受け取ることです。この結果は、業界を変えるために必要なすべての機能を備えた美しいアプリケーションではありません。各イテレーションの目的とされた結果から、学習機会が得られます。つまり、仮説をより詳細にテストする機会になります。

"タイムボックス化" とは、製品の無駄をなくすための標準的な方法です。たとえば、迅速なテストを可能にするために、開発チームは、1 回のイテレーションでソリューションを作成できると考えていることを確認します。速度、イテレーション、リリースを使用して最小限の意味を定義する方法の詳細については、速度、イテレーション、リリース、およびイテレーションパスの計画に関する記事を参照してください。

複雑さを軽減し、技術的なスパイクを遅らせる

イノベーションの方法論内の発明の規範には、成熟したイノベーションまたはスケール対応の MVP ソリューションを提供するために必要とされることが多い機能が説明されています。こうした規範は、機能を含めるための長期的なガイドとして使用します。同様に、ソリューションの顧客の価値と共感を早期にテストする際の注意ガイドとして使用します。

機能の幅と発明のさまざまな規範を一度にすべて作成することはできません。複雑な複数の規範を含めるには、複数回の MVP ソリューションのリリースが必要な場合があります。開発への投資によっては、複数の仮説をテストするために、異なる規範で作業する複数の並行チームが存在する場合があります。このようなチーム間でアーキテクチャの整合性を維持することは賢明ですが、価値の仮説を検証するまでは、複雑な統合ソリューションの構築を試みることは賢明ではありません。

複雑さは、"技術的なスパイク" の頻度または量によく見られます。技術的なスパイクは、顧客と簡単にテストできない技術ソリューションを作成する作業です。顧客価値や顧客共感が未検証の場合、技術的なスパイクはイノベーションのリスクとなるため、最小限に抑える必要があります。移行作業で見つかった成熟したテスト済みソリューションの種類については、導入全体を通して技術的なスパイクは一般的な場合があります。ただし、イノベーションの取り組みでは仮説の検証が遅れるため、可能な場合は常に延期するようにします。

MVP の定義には、たゆまない単純化アプローチが役立ちます。このアプローチは、仮説を検証する能力を助長しないものはすべて取り除くことを意味します。複雑さを最小限に抑えるには、仮説のテストに必要のない統合と機能の数を減らします。

MVP の構築

各イテレーションでは、MVP ソリューションはさまざまな形を取る可能性があります。一般的な要件は、結果が仮説の測定とテストを可能にすることだけです。このシンプルな要件によって科学的プロセスが始まり、チームは共感を構築できるようになります。この顧客第一の焦点を実現するために、最初の MVP では発明の規範の 1 つのみを利用することがあります。

場合によっては、クラウド導入チームが仮説が正確に検証されたと確信するまで、このような規範を一時的に完全に回避することが、イノベーションへの最短経路となります。 Microsoft のようなテクノロジ企業によるこのようなガイダンスは、直感に反するように聞こえるかもしれません。しかし、これは、MVP ソリューションでは、特定の技術的な決定ではなく顧客のニーズが最優先事項であることを強調するものです。

一般に、MVP ソリューションは、最小限の機能と限定的な改良が加えられたアプリケーションまたはデータソリューションで構成されます。プロフェッショナルな開発の専門知識を持つ組織にとって、多くの場合、このパスは学習とイテレーションへの最速のものです。次に、チームが MVP を構築するために利用できるその他のアプローチをいくつか紹介します。

99% の時間は間違っているが、特定の望ましい結果を示す予測アルゴリズム。
運用規模で安全に通信することはできないが、プロセス内のほぼリアルタイムのデータの価値を実証する IoT デバイス。
仮説をテストしたり、小規模なニーズを満たしたりすることができる、市民開発者によって作成されたアプリケーション。
従うべきアプリケーションの利点を再現する手動プロセス。
顧客が十分にやり取りすることができる詳細なワイヤーフレームまたはビデオ。

MVP の開発には、多額の開発投資は必要ありません。一度に検証する仮説の数を最小限に抑えるために、可能な限り投資を抑制することをお勧めします。その後の各イテレーションと各リリースで、発明の複数の規範を表すスケール対応ソリューションへとソリューションを意図的に改善します。

MVP 開発を加速する

イノベーションを成功させるには、市場投入までの時間が非常に重要です。より速いリリースは、より速い学習につながります。より速い学習は、より迅速にスケールできる製品につながります。従来のアプリケーション開発サイクルでは、このプロセスに時間がかかる可能性があります。多くの場合、イノベーションは利用可能な専門知識の制限によって制約されます。予算、人員数、スタッフの稼働率はすべて、チームが処理できる新しいイノベーションの数に制限を生じさせる可能性があります。

人員配置の制約と、共感を構築したいという願いから、市民開発者というトレンドが急速に生まれました。このような開発者は、組織のプロフェッショナルな開発コミュニティ内のリスクを軽減し、スケールを提供します。市民開発者は、カスタマーエクスペリエンスにおける領域の専門家ですが、エンジニアとしてトレーニングされてはいません。このような個人は、プロの開発者なら眉をひそめる可能性があるプロトタイピングツールや軽量の開発ツールを使用します。これらのビジネス志向の開発者は、MVP ソリューションとテスト理論を作成します。このプロセスがうまくかみ合えば価値を提供する運用ソリューションを作成できますが、十分に効果的な規模の仮説は立証できません。また、チームは、スケーリングの取り組みを始める前に、このソリューションを使用してプロトタイプを検証することができます。

イノベーション計画には、クラウド導入チームがポートフォリオを多様化し、市民開発者の作業を含める必要があります。開発作業をスケーリングすることで、少ない投資でより多くの仮説を形成し、検証することができます。仮説を検証し、対処可能な市場を特定すると、プロの開発者は最新の開発ツールを使用してソリューションを強化およびスケールできます。

最終的なビルドゲート:顧客の痛み

顧客の共感が強ければ、明確に存在する問題を簡単に特定できるはずです。また、顧客の痛みは明らかなはずです。構築中、クラウド導入チームは、顧客の問題点に基づいて仮説を検証するソリューションに取り組みます。仮説が明確に定義されていても問題点が定義されていない場合、そのソリューションは真の意味で顧客の共感に基づいているとは言えません。このシナリオでは、構築は適切な出発点ではありません。代わりに、最初に共感を構築し、実際の顧客から学ぶことに投資します。共感を構築し、問題点を検証するための最良のアプローチは単純明快です。顧客の声に耳を傾けることです。頻繁に発生する痛点を特定できるようになるまで、顧客と会って観察することに時間をかけます。問題点をよく理解したら、その問題点に対処するための仮説ソリューションを検証できます。

このアプローチを適用しない場合

多くの法律、コンプライアンス、業界の要件では、代替のアプローチが必要になる可能性があります。このアプローチは、以下のような開発中のソリューションの公開リリースには適していない可能性があります。

特許のタイミング、知的財産保護、または顧客データの漏洩などのリスクがある
確立されたコンプライアンス要件に違反する

このようなリスクが考えられる場合は、リリース管理のガイド付きアプローチを導入する前に、弁護士に相談してください。

References

この記事の概念の一部は、Eric Ries 氏の書籍『The Lean Startup』で説明されているアイデアに基づいています。

次のステップ

MVP ソリューションを構築した後は、共感の値と規模の値を測定できます。顧客への影響を測定する方法を学びます。

顧客への影響を測定する