顧客の共感を構築するBuild with customer empathy

"必要は発明の母"。"Necessity is the mother of invention." このことわざは、人間の精神の不滅と発明への自然な意欲をとらえたものです。This proverb captures the indelibility of the human spirit and our natural drive to invent. オックスフォード英語辞典で説明されているように、"何かに対するニーズが不可避になると、それを入手または達成する方法を何としても見つける必要があります"。As explained in the Oxford English Dictionary, "When the need for something becomes imperative, you're forced to find ways of getting or achieving it." 発明に関するこうした普遍的な真実を否定する人はほとんどいません。Few would deny these universal truths about invention. ただし、「デジタル経済のイノベーション」で説明されているように、イノベーションでは発明と採用の間のバランスが求められます。However, as described in Innovation in the digital economy, innovation requires a balance between invention and adoption.

この比喩をさらに続けると、イノベーションはより広範な家族から生まれます。Continuing with the analogy, innovation comes from a more extended family. 顧客の共感はイノベーションを誇りに思う親です。Customer empathy is the proud parent of innovation. イノベーションを推進するソリューションを作成するには、重要な課題を解決するために顧客に継続的に立ち返ってもらえるよう、確固たる顧客のニーズが必要になります。creating a solution that drives innovation requires a legitimate customer need that keeps the customer coming back to solve critical challenges. このようなソリューションは、顧客の望みや気まぐれではなく、顧客のニーズに基づいています。These solutions are based on what a customer needs rather than on their wants or whims. 真のニーズを見つけるには、まず共感、つまり、顧客のエクスペリエンスを深く理解することから始めます。To find their true needs, we start with empathy, a deep understanding of the customer's experience. 共感は、多くのエンジニア、製品マネージャー、さらにはビジネス リーダーであってもあまり開発されていないスキルです。Empathy is an underdeveloped skill for many engineers, product managers, and even business leaders. 幸いなことに、クラウド アーキテクトの役割のさまざまな相互作用と急速なペースによって、このスキルの促進が既に始まっています。Fortunately, the diverse interactions and rapid pace of the cloud architect role have already started fostering this skill.

なぜ共感が重要なのでしょうか。Why is empathy so important? 実用最小限の製品 (MVP) の最初のリリースから、市場グレードのソリューションの一般提供まで、顧客の共感を利用すると、顧客の経験を理解し、共有することができます。From the first release of a minimum viable product (MVP) to the general availability of a market-grade solution, customer empathy helps us understand and share in the experience of the customer. 共感は、より優れたソリューションを構築するために役立ちます。Empathy helps us build a better solution. さらに重要なことは、導入を促進するソリューションを発明しやすい位置に着くことです。More importantly, it better positions us to invent solutions that will encourage adoption. デジタル経済では、顧客のニーズに最も迅速に共感できる者が、市場を再定義し、リードする明るい未来を築くことができます。In a digital economy, those who can most readily empathize with customer needs can build a brighter future that redefines and leads the market.

共感を構築する方法How to build with empathy

想定を定義することは、計画の基本部分です。Defining assumptions is a fundamental part of planning. 計画を多く立てるほど、優れたアイデアの基盤となる想定が増えます。The more we plan, the more we see assumptions creep into the foundation of a great idea. 通常、想定は自己への共感から生まれます。Assumptions are typically the product of self-empathy. 言い換えると、"自分がこの立場だったら、何を望むだろうか" ということです。In other words, what would I want if I were in this position? 構築フェーズから開始すると、想定がソリューションに入り込む期間が最短になります。Starting with the build phase minimizes the period in which assumptions can invade a solution. また、このアプローチでは、実際の顧客とのフィードバック ループが加速され、早期に共感を学んで研ぎ澄ませる機会のきっかけになります。This approach also accelerates the feedback loop with real customers, triggering earlier opportunities to learn and sharpen empathy.


構築対象を適切に定義することは難しい場合があるため、何らかの演習が必要です。Properly defining what to build can be tricky and requires some practice. あまりにも短時間で構築すると、顧客のニーズを反映していない可能性があります。If you build something too quickly, if might not reflect customer needs. 初期の顧客のニーズとソリューションの要件を理解するために時間がかかりすぎると、何かを構築する機会を得る前に、市場によってそれらが満たされるかもしれません。If you spend too much time trying to understand initial customer needs and solution requirements, the market may meet them before you have a chance to build anything at all. いずれのシナリオでも、学ぶ機会は大幅に遅れるか、減る可能性があります。In either scenario, the opportunity to learn can be significantly delayed or reduced. 場合によっては、データが破損する可能性もあります。Sometimes the data can even be corrupted.

歴史上最も革新的なソリューションは、直感的な信念から始まりました。The most innovative solutions in history began with an intuitive belief. その直感は、既存の専門知識と直接観察の両方から得られます。That gut feeling comes from both existing expertise and firsthand observation. 構築フェーズから始めるのは、その直感を迅速にテストするためです。We start with the build phase because it allows for a rapid test of that intuition. そこから、理解を深め、共感の度合いを明確にすることができます。From there, we can cultivate deeper understanding and clearer degrees of empathy. ソリューションのイテレーションまたはリリースのたびに、顧客の共感を示す MVP を構築することでバランスが生まれます。At every iteration or release of a solution, balance comes from building MVPs that demonstrate customer empathy.

このバランスを安定させるために、次の 2 つのセクションでは、共感を構築し、MVP を定義する概念について説明します。To steady this balancing act, the following two sections discuss the concepts of building with empathy and defining an MVP.

顧客重視の仮説を定義するDefine a customer focused-hypothesis

共感の構築とは、特定の顧客のニーズを示す定義済みの仮説に基づいてソリューションを作成することを意味します。Building with empathy means creating a solution based on defined hypotheses that illustrate a specific customer need. 次の手順は、共感の構築を促進する仮説を立てることが目的です。The following steps aim to formulate a hypothesis that will encourage building with empathy.

  1. 共感を構築するときは、常に顧客が中心です。When you build with empathy, the customer is always the focus. この意図は多くの形を取ることができます。This intention can take many shapes. 解決する問題の中で、顧客の原型、特定のペルソナ、さらには顧客の写真を参照する場合があります。You could reference a customer archetype, a specific persona, or even a picture of a customer in the midst of the problem you want to solve. そして、顧客は内部 (従業員またはパートナー) または外部 (消費者またはビジネス顧客) の場合があることに留意してください。And keep in mind that customers can be internal (employees or partners) or external (consumers or business customers). この定義が、テストされる最初の仮説です。この特定の顧客を助けることはできるでしょうか。This definition is the first hypothesis to be tested: can we help this specific customer?
  2. 顧客の経験を理解します。Understand the customer experience. 共感を構築するということは、顧客の経験に共感し、顧客の課題を理解することを意味します。Building with empathy means you can relate to the customer's experience and understand their challenges. この思考様式は、テストされる次の仮説を示しています。このような対処可能な課題を抱えているこの特定の顧客を助けることはできるでしょうか。This mindset indicates the next hypothesis to be tested: can we help this specific customer with this manageable challenge?
  3. 1 つの課題に対してシンプルなソリューションを定義します。Define a simple solution to a single challenge. 人、プロセス、各分野の専門家の専門知識に頼ると、ソリューションにつながる可能性があります。Relying on expertise across people, processes, and subject matter experts will lead to a potential solution. これが、テストされる完全な仮説です。提案したソリューションを通して、このような対処可能な課題を抱えているこの特定の顧客を助けることはできるでしょうか。This is the full hypothesis to be tested: can we help this specific customer with this manageable challenge through the proposed solution?
  4. 価値の提示に到達します。Arrive at a value statement. このような顧客にどのような長期的な価値を提示したいでしょうか。What long-term value do you hope to provide to these customers? この質問への答えによって、ご自身の完全な仮説が成立します。提案したソリューションを使用して、このような対処可能な課題に取り組むことで、これらの顧客の生活はどのように改善されるでしょうか。The answer to this question creates your full hypothesis: how will these customers' lives be improved by using the proposed solution to address this manageable challenge?

この最後の手順は、共感に基づく仮説の頂点です。This last step is the culmination of an empathy-driven hypothesis. これによって対象ユーザー、問題、ソリューション、改善の基準となる指標を定義します。これらはすべて顧客中心です。It defines the audience, the problem, the solution, and the metric by which improvement is to be made, all of which center on the customer. 測定と学習のフェーズでは、各仮説をテストする必要があります。During the measure and learn phases, each hypothesis should be tested. チームが対処可能な顧客ベースに対して共感を深めるにつれて、顧客、問題の提示、またはソリューションの変更が予想されます。Changes in the customer, problem statement, or solution are anticipated as the team develops greater empathy for the addressable customer base.


目標は、顧客の共感を "計画" することではなく、顧客の共感を "構築" することです。The goal is to build with customer empathy, not to plan with it. 完璧な顧客の共感の提示を見つけるために、計画と調整の無限のサイクルに巻き込まれることはよくあります。It's all too easy to get stuck in endless cycles of planning and tweaking to hit upon the perfect customer empathy statement. このような提示を作成しようとする前に、MVP の定義と構築に関する次のセクションを確認してください。Before you try to develop such a statement, review the following sections on defining and building an MVP.

中心となる想定が証明されたら、その後のイテレーションでは、共感テストに加えて成長テストに焦点を当てます。After core assumptions are proven, later iterations will focus on growth tests in addition to empathy tests. 共感の構築、テスト、検証が完了すると、大規模に対処可能な市場がわかるようになります。After empathy is built, tested, and validated, you can begin to understand the addressable market at scale. これは、前に説明した標準的な仮説の定型を拡張することで実現できます。This can be done through an expansion of the standard hypothesis formula described earlier. 使用可能なデータに基づいて、市場全体の規模 (潜在顧客数) を推定します。Based on available data, estimate the size of the total market (the number of potential customers).

そこから、市場全体のうち、同様の課題が発生し、このソリューションに関心を持つ可能性がある割合を推定します。From there, estimate the percentage of that total market that experiences a similar challenge and that might therefore be interested in this solution. これが対処可能な市場です。This is your addressable market. 次にテストする仮説は、提案したソリューションを使用してこの対処可能な課題を解決することで、顧客の生活の x% がどのように改善するかです。The next hypothesis to be tested is: how will x% of customers' lives be improved by using the proposed solution to address this manageable challenge? 顧客のわずかなサンプリングにより、関係する顧客のプールへの影響の割合を示す先行指標が明らかになります。A small sampling of customers will reveal leading indicators that suggest a percentage impact on the pool of customers engaged.

仮説をテストするソリューションを定義するDefine a solution to test the hypothesis

構築 - 測定 - 学習のフィードバック ループの各イテレーションで、共感を構築する試みは、MVP で定義されます。During each iteration of a build-measure-learn feedback loop, your attempt to build with empathy is defined by an MVP.

MVP とは、"顧客と共に" 学ぶことができる十分なソリューションを作成するために必要な最小の作業単位 (発明、エンジニアリング、アプリケーション開発、またはデータ アーキテクチャ) です。An MVP is the smallest unit of effort (invention, engineering, application development, or data architecture) required to create enough of a solution to learn with the customer. すべての MVP の目標は、以前の仮説の一部またはすべてをテストし、顧客から直接フィードバックを受け取ることです。The goal of every MVP is to test some or all of the prior hypotheses and to receive feedback directly from the customer. この結果は、業界を変えるために必要なすべての機能を備えた美しいアプリケーションではありません。The output is not a beautiful application with all the features required to change your industry. 各イテレーションの目的とされた結果から、学習機会が得られます。つまり、仮説をより詳細にテストする機会になります。The desired output of each iteration is a learning opportunity, a chance to more deeply test a hypothesis.

"タイムボックス化" とは、製品の無駄をなくすための標準的な方法です。Timeboxing is a standard way to make sure a product remains lean. たとえば、迅速なテストを可能にするために、開発チームは、1 回のイテレーションでソリューションを作成できるように考えます。For example, make sure your development team thinks the solution can be created in a single iteration to allow for rapid testing. 速度、イテレーション、リリースを使用して最小限の意味を定義する方法の詳細については、速度、イテレーション、リリース、およびイテレーション パスの計画に関する記事を参照してください。To better understand using velocity, iterations, and releases to define what minimal means, see Planning velocity, iterations, release, and iteration paths.

複雑さを軽減し、技術的なスパイクを遅らせるReduce complexity and delay technical spikes

イノベーションの方法論内の発明の規範には、成熟したイノベーションまたはスケール対応の MVP ソリューションを提供するために必要とされることが多い機能が説明されています。The disciplines of invention found in the Innovate methodology describe the functionality that's often required to deliver a mature innovation or scale-ready MVP solution. こうした規範は、機能を含めるための長期的なガイドとして使用します。Use these disciplines as a long-term guide for feature inclusion. 同様に、ソリューションの顧客の価値と共感を早期にテストする際の注意ガイドとして使用します。Likewise, use them as a cautionary guide during early testing of customer value and empathy in your solution.

機能の幅と発明のさまざまな規範を一度にすべて作成することはできません。Feature breadth and the different disciplines of invention can't all be created in a single iteration. 複雑な複数の規範を含めるには、複数回の MVP ソリューションのリリースが必要な場合があります。It might take several releases for an MVP solution to include the complexity of multiple disciplines. 開発への投資によっては、複数の仮説をテストするために、異なる規範で作業する複数の並行チームが存在する場合があります。Depending on the investment in development, there might be multiple parallel teams working within different disciplines to test multiple hypotheses. このようなチーム間でアーキテクチャの整合性を維持することは賢明ですが、価値の仮説が検証されるまで複雑な統合ソリューションの構築を試みることは賢明ではありません。Although it's smart to maintain architectural alignment between those teams, it's unwise to try to build complex, integrated solutions until value hypotheses can be validated.

複雑さは、技術的なスパイクの頻度または量によく見られます。Complexity is best detected in the frequency or volume of technical spikes. 技術的なスパイクは、顧客と簡単にテストできない技術ソリューションを作成する作業です。Technical spikes are efforts to create technical solutions that can't be easily tested with customers. 顧客価値と顧客共感がテストされていない場合、技術的なスパイクはイノベーションのリスクを表すので、最小限に抑える必要があります。When customer value and customer empathy are untested, technical spikes represent a risk to innovation and should be minimized. 移行作業で見つかった成熟したテスト済みソリューションの種類については、導入全体を通して技術的なスパイクは一般的な場合があります。For the types of mature tested solutions found in a migration effort, technical spikes can be common throughout adoption. ただし、イノベーションの取り組みでは仮説のテストが遅れるため、可能な場合は常に延期するようにします。However, they delay the testing of hypotheses in innovation efforts and should be postponed whenever possible.

MVP の定義には、たゆまない単純化アプローチが推奨されます。A relentless simplification approach is suggested for any MVP definition. このアプローチは、仮説を検証する能力を強化しないすべてのものを取り除くことを意味します。This approach means removing anything that doesn't add to your ability to validate the hypothesis. 複雑さを最小限に抑えるには、仮説のテストに必要のない統合と機能の数を減らします。To minimize complexity, reduce the number of integrations and features that aren't required to test the hypothesis.

MVP の構築Build an MVP

各イテレーションでは、MVP ソリューションはさまざまな形を取る可能性があります。At each iteration, an MVP solution can take many different shapes. 一般的な要件は、結果が仮説の測定とテストを可能にすることだけです。The common requirement is only that the output allows for measurement and testing of the hypothesis. このシンプルな要件によって科学的プロセスが始まり、チームは共感を構築できるようになります。This simple requirement initiates the scientific process and allows the team to build with empathy. この顧客第一の焦点を実現するために、最初の MVP では発明の規範の 1 つのみを利用することがあります。To deliver this customer-first focus, an initial MVP might rely on only one of the disciplines of invention.

場合によっては、イノベーションへの最速のパスは、クラウド導入チームが正確に仮説が検証されたと確信するまで、このような規範を一時的に完全に回避することを意味します。In some cases, the fastest path to innovation means temporarily avoiding these disciplines entirely, until the cloud adoption team is confident that the hypothesis has been accurately validated. Microsoft のようなテクノロジ企業によるこのようなガイダンスは、直感に反するように聞こえるかもしれません。Coming from a technology company like Microsoft, this guidance might sound counterintuitive. ただし、これは、特定の技術の決定ではなく、顧客のニーズが MVP ソリューションにおける最優先事項であると強調することです。However, this simply emphasizes that customer needs, not a specific technology decision, are the highest priority in an MVP solution.

一般に、MVP ソリューションは、最小限の機能と限られた洗練を備えたシンプルなアプリケーションまたはデータ ソリューションで構成されます。Typically, an MVP solution consists of a simple application or data solution with minimal features and limited polish. プロフェッショナルな開発の専門知識を持つ組織にとって、多くの場合、このパスは学習とイテレーションへの最速のものです。For organizations that have professional development expertise, this path is often the fastest one to learning and iteration. 次に、チームが MVP を構築するために利用できるその他のアプローチをいくつか紹介します。The following list includes several other approaches a team might take to build an MVP:

  • 99% の時間は間違っているが、特定の望ましい結果を示す予測アルゴリズム。A predictive algorithm that's wrong 99 percent of the time but that demonstrates specific desired outcomes.
  • 運用規模で安全に通信することはできないが、プロセス内のほぼリアルタイムのデータの価値を実証する IoT デバイス。An IoT device that doesn't communicate securely at production scale but that demonstrates the value of nearly real-time data within a process.
  • 仮説をテストしたり、小規模なニーズを満たしたりすることができる、市民開発者によって作成されたアプリケーション。An application built by a citizen developer to test a hypothesis or meet smaller-scale needs.
  • 従うべきアプリケーションの利点を再現する手動プロセス。A manual process that re-creates the benefits of the application to follow.
  • 顧客が十分にやり取りすることができる詳細なワイヤーフレームまたはビデオ。A wireframe or video that's detailed enough to allow the customer to interact.

MVP の開発には、多額の開発投資は必要ありません。Developing an MVP shouldn't require massive amounts of development investment. 一度にテストする仮説の数を最小限に抑えるために、可能な限り投資を制限することをお勧めします。Preferably, investment should be as constrained as possible to minimize the number of hypotheses being tested at one time. その後の各イテレーションと各リリースで、発明の複数の規範を表すスケール対応ソリューションへとソリューションを意図的に改善します。Then, in each iteration and with each release, the solution is intentionally improved toward a scale-ready solution that represents multiple disciplines of invention.

MVP 開発を加速するAccelerate MVP development

イノベーションを成功させるには、市場投入までの時間が非常に重要です。Time to market is crucial to the success of any innovation. より速いリリースは、より速い学習につながります。Faster releases lead to faster learning. より速い学習は、より迅速にスケールできる製品につながります。Faster learning leads to products that can scale more quickly. 従来のアプリケーション開発サイクルでは、このプロセスに時間がかかる可能性があります。At times, traditional application development cycles can slow this process. 多くの場合、イノベーションは利用可能な専門知識の制限によって制約されます。More frequently, innovation is constrained by limits on available expertise. スタッフの予算、人員数、および空き状況はすべて、チームが処理できる新しいイノベーション数への制限となる可能性があります。Budgets, headcount, and availability of staff can all create limits to the number of new innovations a team can handle.

人員配置の制約と、共感を構築したいという切望が、市民開発者へと急速に成長する傾向を生み出しました。Staffing constraints and the desire to build with empathy have spawned a rapidly growing trend toward citizen developers. このような開発者は、組織のプロフェッショナルな開発コミュニティ内のリスクを軽減し、スケールを提供します。These developers reduce risk and provide scale within an organization's professional development community. 市民開発者は、顧客の経験に関する主題の専門家ですが、エンジニアとしてトレーニングされていません。Citizen developers are subject matter experts where the customer experience is concerned, but they're not trained as engineers. このような個人は、プロの開発者なら眉をひそめる可能性があるプロトタイピング ツールや軽量の開発ツールを使用します。These individuals use prototyping tools or lighter-weight development tools that might be frowned upon by professional developers. これらのビジネス志向の開発者は、MVP ソリューションとテスト理論を作成します。These business-aligned developers create MVP solutions and test theories. 適切に調整すれば、このプロセスで価値を提供する運用ソリューションを作成できますが、十分に効果的な規模の仮説は立証できません。When aligned well, this process can create production solutions that provide value but don't pass a sufficiently effective scale hypothesis. また、スケールの作業を開始する前に、これらを使用してプロトタイプを検証することもできます。They can also be used to validate a prototype before scale efforts begin.

イノベーション計画には、クラウド導入チームがポートフォリオを多様化し、市民開発者の作業を含める必要があります。Within any innovate plan, cloud adoption teams should diversify their portfolios to include citizen developer efforts. 開発作業をスケールすることにより、少ない投資でより多くの仮説を形成し、テストできます。By scaling development efforts, more hypotheses can be formed and tested at a reduced investment. 仮説を検証し、対処可能な市場を特定すると、プロの開発者は最新の開発ツールを使用してソリューションを強化およびスケールできます。When a hypothesis is validated and an addressable market is identified, professional developers can harden and scale the solution by using modern development tools.

最終的なビルド ゲート:顧客の痛みFinal build gate: Customer pain

顧客の共感が強ければ、明確に存在する問題を簡単に特定できるはずです。When customer empathy is strong, a clearly existing problem should be easy to identify. また、顧客の痛みは明らかなはずです。The customer's pain should be obvious. 構築中、クラウド導入チームは、顧客の問題点に基づいて仮説をテストするソリューションを構築します。During build, the cloud adoption team is building a solution to test a hypothesis based on a customer pain point. 仮説が明確に定義されていても問題点が定義されていない場合、ソリューションは顧客の共感に基づいていません。If the hypothesis is well-defined but the pain point is not, the solution is not truly based on customer empathy. このシナリオでは、構築は適切な出発点ではありません。In this scenario, build is not the right starting point. 代わりに、最初に共感を構築し、実際の顧客から学ぶことに投資します。Instead, invest first in building empathy and learning from real customers. 共感を構築し、痛みを検証するための最良のアプローチは簡単です。顧客の声に耳を傾けることです。The best approach for building empathy and validating pain is simple: listen to your customers. 頻繁に発生する痛点を特定できるようになるまで、顧客と会って観察することに時間をかけます。Invest time in meeting with and observing them until you can identify a pain point that occurs frequently. 痛点をよく理解した後は、その痛みに対処するための仮説ソリューションをテストできます。After the pain point is well-understood, you're ready to test a hypothesized solution for addressing that pain.

このアプローチを適用しない場合When not to apply this approach

多くの法律、コンプライアンス、および業界の要件では、代替のアプローチが必要になる可能性があります。Many legal, compliance, and industry requirements that might necessitate an alternate approach. 開発中のソリューションの公開リリースが、特許のタイミング、知的財産保護、顧客データの漏洩、または確立されたコンプライアンス要件違反に対するリスクとなる場合、そのアプローチは適切ではない可能性があります。If public releases of a developing solution create risk to patent timing, intellectual property protection, customer data leaks, or violation of established compliance requirements, this approach may not be suitable. このようなリスクが認識されている場合は、リリース管理のガイド付きアプローチを導入する前に、弁護士に相談してください。When perceived risks like these exist, consult legal counsel before adopting any guided approach to release management.


この記事の概念の一部は、Eric Ries 氏の書籍『リーン スタートアップ』で説明されているトピックに基づいています。Some of the concepts in this article build on topics discussed in The Lean Startup by Eric Ries.

次のステップNext steps

MVP ソリューションを構築した後は、共感の値と規模の値を測定できます。After you've built an MVP solution, you can measure the empathy value and scale value. 顧客への影響を測定する方法を学びます。Learn how to measure for customer impact.