顧客の共感を構築する

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

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

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

顧客の共感を構築する方法

想定を定義することは、計画の基本部分です。 計画を多く立てるほど、優れたアイデアの基盤となる想定が増えます。 通常、想定は自己への共感から生まれます。 つまり、この立場にいたとしたら、何を望むか ということです。構築フェーズから開始すると、想定がソリューションに入り込む期間が最短になります。 また、このアプローチでは、実際の顧客とのフィードバック ループが加速され、早期に共感を学んで研ぎ澄ませる機会のきっかけになります。

注意事項

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

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

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

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

共感の構築とは、特定の顧客のニーズを示す定義済みの仮説に基づいてソリューションを作成することを意味します。 次の手順は、共感の構築を促進する仮説を立てることが目的です。

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

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

注意事項

目標は、顧客の共感を "計画" することではなく、顧客の共感を "構築" することです。 完璧な顧客の共感の提示を見つけるために、計画と調整の無限のサイクルに巻き込まれることはよくあります。 このような提示を作成しようとする前に、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 ソリューションを構築した後は、共感の値と規模の値を測定できます。 顧客への影響を測定する方法を学びます。