デジタル発明で導入を強化するEmpower adoption with digital invention

イノベーションの最終的なテストは、その発明に対する顧客の反応です。The ultimate test of innovation is customer reaction to your invention. 仮説は正しかったのか。Did the hypothesis prove true? 顧客はこのソリューションを使用するのか。Do customers use the solution? 期待する割合のユーザーのニーズに合うようにスケーリングされているのか。Does it scale to meet the needs of the desired percentage of users? 最も重要なこととして、ユーザーは使い続けてくれるのか。Most importantly, do they keep coming back? これらの質問は、実用最小限の製品 (MVP) ソリューションがデプロイされるまで確認できません。None of these questions can be asked until the minimum viable product (MVP) solution has been deployed. この記事では、導入の強化の規範に焦点を絞って説明します。In this article, we'll focus on the discipline of empowering adoption.

導入に影響する摩擦の軽減Reduce friction that affects adoption

導入において問題になる摩擦のポイントはいくつかあります。それらは、テクノロジとプロセスを組み合わせることによって、最小限に抑えることができます。A few key friction points to adoption can be minimized through a combination of technology and processes. 継続的インテグレーション (CI) と継続的デプロイ (CD) または DevOps プロセスの知識がある読者の場合、以下の内容について理解していると思われるかもしれません。For readers with knowledge of continuous integration (CI) and continuous deployment (CD) or DevOps processes, the following will be familiar. この記事では、クラウド導入チームのために出発点を確立します。これにより、イノベーションとフィードバック ループが促進されます。This article establishes a starting point for cloud adoption teams that fuels innovation and feedback loops. 今後は、この出発点は、製品やチームが成熟するにつれて、より堅牢な CI/CD または DevOps アプローチに発展する可能性があります。In the future, this starting point might foster more robust CI/CD or DevOps approaches as the products and teams mature.

顧客への影響を測定する」で説明するように、仮説の有益な検証には反復と決断が必要になります。As described in Measure for customer impact, positive validation of any hypothesis requires iteration and determination. イノベーション サイクル中は、成功よりも失敗の方がはるかに多いでしょう。You'll experience far more failures than wins during any innovation cycle. これは予期されることです。This is expected. ただし、顧客のニーズ、仮説、ソリューションを大規模に調整すると、世界はすぐに変わります。However, when a customer need, hypothesis, and solution align at scale, the world changes quickly. この記事は、イノベーションを失速させる技術的スパイクを最小限に抑えながら、信頼性の高いベスト プラクティスを維持できるようにすることを目的としています。This article aims to minimize technical spikes that slow innovation but still make sure you keep a few solid best practices in place. これにより、チームは顧客の現在のニーズに対応しながら、将来の成功に向けて設計を行うことができます。Doing so will help the team design for future success while delivering on current customer needs.

導入の強化:成熟度モデルEmpower adoption: The maturity model

イノベーションの方法論の主な目的は、顧客パートナーシップを構築し、フィードバック ループを加速させることです。これにより、市場のイノベーションが実現します。The primary objective of the Innovate methodology is to build customer partnerships and accelerate feedback loops, which will lead to market innovations. 次の図および以降のセクションでは、この方法論をサポートする初期実装について説明しています。The following image and sections describe initial implementations that support this methodology.

導入の強化: 成熟度モデル

技術的スパイクを最小限に抑えるために、これらの各原則において最初は成熟度が低いと仮定します。To minimize technical spikes, assume that maturity will initially be low across each of these principles. ただし、仮説がより詳細になるにつれて、スケーリングが可能なツールやプロセスに合わせて調整を行って、事前に明確に計画を立てます。But definitely plan ahead by aligning to tools and processes that can scale as hypotheses become more fine-grained. Azure では、GitHubAzure DevOps により、小規模なチームが摩擦をほとんど生じさせずに作業を開始できます。In Azure, the GitHub and Azure DevOps allow small teams to get started with little friction. これらのチームは、何千人もの開発者がスケーリング ソリューションで共同作業を行い、何百もの顧客の仮説をテストする規模に発展する可能性があります。These teams might grow to include thousands of developers who collaborate on scale solutions and test hundreds of customer hypotheses. この記事の残りの部分では、これらの各原則にわたって導入を強化するための、"大きく計画し、小さく始める" というアプローチについて説明します。The remainder of this article illustrates the "plan big, start small" approach to empowering adoption across each of these principles.

共有ソリューションShared solution

顧客への影響を測定する」で説明するように、仮説の有益な検証には反復と決断が必要になります。As described in Measure for customer impact, positive validation of any hypothesis requires iteration and determination. イノベーション サイクル中は、成功よりも失敗の方がはるかに多いでしょう。You'll experience far more failures than wins during any innovation cycle. これは予期されることです。This is expected. ただし、顧客のニーズ、仮説、ソリューションを大規模に調整すると、世界はすぐに変わります。However, when a customer need, hypothesis, and solution align at scale, the world changes quickly.

イノベーションをスケーリングする場合、ソリューションの共有コード ベースほど有益なツールはありません。When you're scaling innovation, there's no more valuable tool than a shared code base for the solution. 残念ながら、どの反復または MVP の組み合わせが成功につながるのかを確実に予測する方法はありません。Unfortunately, there's no reliable way of predicting which iteration or which MVP will yield the winning combination. このため、共有コード ベースまたはリポジトリはいつ確立しても早すぎるということはありません。That's why it's never too early to establish a shared code base or repository. これは、遅滞すべきでない技術的スパイクの 1 つです。This is the one technical spike that should never be delayed. チームはさまざまな MVP ソリューションを反復するため、共有リポジトリによって共同作業がしやすくなり、迅速な開発が可能になります。As the team iterates through various MVP solutions, a shared repo enables easy collaboration and accelerated development. ソリューションの変更が学習メトリックに悪影響を及ぼす場合は、バージョン コントロールを使用して、以前のより効果的なバージョンのソリューションにロールバックできます。When changes to the solution drag down learning metrics, version control lets you roll back to an earlier, more effective version of the solution.

コード リポジトリを管理するために最も広く採用されているツールは GitHub です。これを使うと、いくつかの手順を実行するだけで共有コード リポジトリを作成できます。The most widely adopted tool for managing code repositories is GitHub, which lets you create a shared code repository in just a few steps. また、Azure DevOps の Azure Repos 機能を使用して、Git または TFVC リポジトリを作成することもできます。Additionally, the Azure Repos feature of Azure DevOps can be used to create a Git or TFVC repository.

フィードバック ループFeedback loops

イノベーション サイクル中に顧客パートナーシップを構築するための鍵となるのは、顧客をソリューションに組み込むことです。Making the customer part of the solution is the key to building customer partnerships during innovation cycles. これは、顧客への影響を測定することによってある程度実現されます。That's accomplished, in part, by measuring customer impact. これには、顧客との会話と直接的なテストが必要になります。It requires conversations and direct testing with the customer. これらによって得られるフィードバックを効果的に管理する必要があります。Both generate feedback that must be managed effectively.

すべてのフィードバック ポイントは、顧客のニーズに対する解決策となる可能性を秘めています。Every point of feedback is a potential solution to the customer need. さらに重要なこととして、顧客から直接得られるすべてのフィードバックは、パートナーシップを改善する機会となります。More importantly, every bit of direct customer feedback represents an opportunity to improve the partnership. フィードバックが MVP ソリューションに取り入れられたら、顧客と喜びを分かち合います。If feedback makes it into an MVP solution, celebrate that with the customer. フィードバックが実用的ではない場合でも、そのフィードバックの優先度を下げるという決定を明らかにすることで、成長思考継続的な学習の重視を示します。Even if some feedback isn't actionable, simply being transparent with the decision to deprioritize the feedback demonstrates a growth mindset and a focus on continuous learning.

Azure DevOps には、フィードバックの要求、提供、管理を行うための方法が含まれています。Azure DevOps includes ways to request, provide, and manage feedback. これらの各ツールにより、フィードバックを 1 か所にまとめることができるため、チームは透明性のあるフィードバック ループに対応するためのアクションを実行し、フォローアップを提供できます。Each of these tools centralizes feedback so that the team can take action and provide follow-up in service of a transparent feedback loop.

継続的インテグレーションContinuous integration

導入の規模と仮説が大規模な真のイノベーションに近づくにつれて、テスト対象となる小さな仮説の数が急速に増加する傾向があります。As adoptions scale and a hypothesis gets closer to true innovation at scale, the number of smaller hypotheses to be tested tends to grow rapidly. 正確なフィードバック ループとスムーズな導入プロセスを実現するには、これらの各仮説が統合され、イノベーションの背後にある主要な仮説を支えることが重要です。For accurate feedback loops and smooth adoption processes, it's important that each of those hypotheses is integrated and supportive of the primary hypothesis behind the innovation. これは、イノベーションと成長のためにはスピードも重要であることを意味し、複数の開発者が中核となる仮説のバリエーションをテストすることが必要となります。This means that you also have to move quickly to innovate and grow, which requires multiple developers for testing variations of the core hypothesis. 開発作業の後半の段階では、1 つの共有ソリューションに向けて構築を行う複数の開発者チームが必要になることもあります。For later stage development efforts, you might even need multiple teams of developers, each building toward a shared solution. 継続的インテグレーションは、すべての変動要素を管理するための最初の一歩となります。Continuous integration is the first step toward management of all the moving parts.

継続的インテグレーションでは、コードの変更がメイン ブランチに頻繁にマージされます。In continuous integration, code changes are frequently merged into the main branch. 自動化されたビルドおよびテスト プロセスにより、メイン ブランチのコードが常に運用品質であることが確認されます。Automated build and test processes make sure that code in the main branch is always production quality. これにより、開発者が協力して、正確で信頼性の高いフィードバック ループを提供する共有ソリューションを開発できるようになります。This ensures that developers are working together to develop shared solutions that provide accurate and reliable feedback loops.

Azure DevOps と Azure Pipelines では、GitHub やその他のさまざまなリポジトリでいくつかの手順を実行するだけで継続的インテグレーション機能が提供されます。Azure DevOps and Azure Pipelines provide continuous integration capabilities with just a few steps in GitHub or a variety of other repositories. 継続的インテグレーションの詳細については、こちらをご覧ください。または、ハンズオン ラボで詳細を確認してください。Learn more about continuous integration, or for more information, check out the hands-on lab. Azure DevOps 経由での CI/CD パイプラインの作成を高速化できるソリューション アーキテクチャが提供されています。Solution architectures are available that can accelerate creation of your CI/CD pipelines via Azure DevOps.

信頼性の高いテストReliable testing

どのソリューションでも欠陥によって、擬陽性や偽陰性が発生する可能性があります。Defects in any solution can create false positives or false negatives. 予期しないエラーが発生すると、ユーザー導入のメトリックが誤って解釈される可能性があります。Unexpected errors can easily lead to misinterpretation of user adoption metrics. また、仮説のテストを正確に表していない、顧客からの否定的なフィードバックが生まれる可能性もあります。They can also generate negative feedback from customers that doesn't accurately represent the test of your hypothesis.

MVP ソリューションの初期の反復期間には、欠陥が想定されており、早期導入者はそれらを好意的に受け入れる場合もあります。During early iterations of an MVP solution, defects are expected; early adopters might even find them endearing. 初期リリースでは、通常、承認テストはありません。In early releases, acceptance testing is typically nonexistent. ただし、共感を得ながらの構築の一側面はニーズと仮説の検証に関係します。However, one aspect of building with empathy concerns the validation of the need and hypothesis. どちらも、コード レベルの単体テストと、デプロイ前の手動承認テストによって完了できます。Both can be completed through unit tests at a code level and manual acceptance tests before deployment. これらを組み合わせることで、テストの信頼性を高めることができます。Together, these provide some means of reliability in testing. 明確に定義された一連のビルド、単体、承認の各テストを自動化することを目指す必要があります。You should strive to automate a well-defined series of build, unit, and acceptance tests. これらにより、仮説および結果として構築されたソリューションのより細かい調整に関連する信頼性の高いメトリックが確保されます。These will ensure reliable metrics related to more granular tweaks to the hypothesis and the resulting solution.

Azure Test Plans 機能には、手動または自動テストの実行期間にテスト計画を作成して実施するためのツールが用意されています。The Azure Test Plans feature provides tooling to develop and operate test plans during manual or automated test execution.

ソリューションのデプロイSolution deployment

導入の強化の最も意味のある要素は、顧客へのソリューションのリリースを制御する能力に関係していると考えられます。Perhaps the most meaningful aspect of empowering adoption concerns your ability to control the release of a solution to customers. ソリューションを顧客にリリースするためのセルフサービス パイプラインまたは自動化されたパイプラインを提供することによって、フィードバック ループを加速させることができます。By providing a self-service or automated pipeline for releasing a solution to customers, you'll accelerate the feedback loop. 顧客がソリューションの変更をすぐに操作できるようにすることで、顧客をプロセスに引き込みます。By allowing customers to quickly interact with changes in the solution, you invite them into the process. また、このアプローチでは仮説のより迅速なテストがトリガーされるので、仮定を減らし、再作業の可能性が低減されます。This approach also triggers quicker testing of hypotheses, thereby reducing assumptions and potential rework.

ソリューションのデプロイにはいくつかの方法があります。The are several methods for solution deployment. 最も一般的な 3 つの方法を次に示します。The following represent the three most common:

  • 継続的デプロイは、コード変更が運用環境に自動的にデプロイされるため、最も高度な方法です。Continuous deployment is the most advanced method, as it automatically deploys code changes into production. 成熟したチームが成熟した仮説をテストする場合は、継続的デプロイが非常に有効である可能性があります。For mature teams that are testing mature hypotheses, continuous deployment can be extremely valuable.
  • 開発の初期段階では、継続的デリバリーの方が適している場合があります。During early stages of development, continuous delivery might be more appropriate. 継続的デリバリーでは、コード変更は運用環境に似た環境に自動的にデプロイされます。In continuous delivery, any code changes are automatically deployed to a production-like environment. 開発者、ビジネスの意思決定者、チームの他のメンバーは、この環境を使用して、作業内容が実稼働可能であることを検証できます。Developers, business decision-makers, and others on the team can use this environment to verify that their work is production-ready. また、この方法を使用して、進行中のビジネス アクティビティに影響を与えずに、顧客と共に仮説をテストすることもできます。You can also use this method to test a hypothesis with customers without affecting ongoing business activities.
  • 手動デプロイは、リリース管理の最も洗練されていないアプローチです。Manual deployment is the least sophisticated approach to release management. 名前が示すように、チームのだれかが最新のコード変更を手動でデプロイします。As the name suggests, someone on the team manually deploys the most recent code changes. このアプローチはエラーが発生しやすく、信頼性が低いものです。また、ほとんどの経験豊富なエンジニアはアンチパターンであると考えます。This approach is error prone, unreliable, and considered an antipattern by most seasoned engineers.

前述の評価にもかかわらず、MVP ソリューションの最初の反復では、手動デプロイが一般的です。During the first iteration of an MVP solution, manual deployment is common, despite the preceding assessment. ソリューションが非常に流動的で、顧客のフィードバックが不明な場合、ソリューション全体 (または中核となる仮説) の再設定には重大なリスクがあります。When the solution is extremely fluid and customer feedback is unknown, there's a significant risk in resetting the entire solution (or even the core hypothesis). 手動デプロイの一般的なルールは、顧客によるテストは実施しないこと、デプロイを自動化しないことです。Here's the general rule for manual deployment: no customer proof, no deployment automation.

早期の投資は、時間損失につながる可能性があります。Investing early can lead to lost time. さらに重要なことは、リリース パイプラインの依存関係を作成すると、チームが初期の方向転換に対して耐性を持てるようになります。More importantly, it can create dependencies on the release pipeline that make the team more resistant to an early pivot. 最初の数回の反復を終えた後、または顧客からのフィードバックが成功の可能性を示しているときは、より高度なデプロイ モデルを早急に導入する必要があります。After the first few iterations or when customer feedback suggests potential success, a more advanced model of deployment should be quickly adopted.

仮説の検証のどの段階でも、Azure DevOps と Azure Pipelines は、継続的デリバリー機能と継続的デプロイ機能を提供します。At any stage of hypothesis validation, Azure DevOps and Azure Pipelines provide continuous delivery and continuous deployment capabilities. 継続的デリバリーの詳細については、こちらをご覧ください。または、ハンズオン ラボを参照してください。Learn more about continuous delivery, or check out the hands-on lab. ソリューション アーキテクチャにより、Azure DevOps を使用した CI/CD パイプラインの作成を高速化することもできます。Solution architecture can also accelerate creation of your CI/CD pipelines through Azure DevOps.

統合された測定Integrated measurements

顧客への影響を測定するときは、ソリューションの変更に対する顧客の反応を理解することが重要です。When you measure for customer impact, it's important to understand how customers react to changes in the solution. "テレメトリ" と呼ばれるこのデータでは、ユーザー (またはユーザーのコーホート) がソリューションの使用時に行ったアクションに関する分析情報が提供されます。This data, known as telemetry, provides insights into the actions a user (or cohort of users) took when working with the solution. このデータから、仮説の定量的な検証を簡単に取得できます。From this data, it's easy to get a quantitative validation of the hypothesis. これらのメトリックを使用して、ソリューションを調整し、より詳細な仮説を生成できます。Those metrics can then be used to adjust the solution and generate more fine-grained hypotheses. これらの微妙な変更により、初期ソリューションがその後の反復でさらに成熟し、最終的に大規模な導入を繰り返すことができます。Those subtler changes help mature the initial solution in subsequent iterations, ultimately driving to repeat adoption at scale.

Azure では、Azure Monitor に、カスタマー エクスペリエンスからデータを収集して確認するためのツールとインターフェイスが用意されています。In Azure, Azure Monitor provides the tools and interface to collect and review data from customer experiences. これらの観測と分析情報を適用して、Azure Boards でバックログを調整できます。You can apply those observations and insights to refine the backlog by using Azure Boards.

次のステップNext steps

導入を強化するために必要なツールとプロセスについて理解したら、より高度なイノベーション規範であるデバイスの操作を確認します。After you've gained an understanding of the tools and processes needed to empower adoption, it's time to examine a more advanced innovation discipline: interact with devices. この規範により、物理的エクスペリエンスとデジタル エクスペリエンス間の障壁を減らして、ソリューションをさらに簡単に導入できるようになります。This discipline can help reduce the barriers between physical and digital experiences, making your solution even easier to adopt.