デジタル発明で導入を強化する

  • [アーティクル]

イノベーションの最終的なテストは、その発明に対する顧客の反応です。 仮説は正しかったのか。 顧客はこのソリューションを使用するのか。 期待する割合のユーザーのニーズに合うようにスケーリングされているのか。 最も重要なこととして、ユーザーは使い続けてくれるのか。 これらの質問は、実用最小限の製品 (MVP) ソリューションがデプロイされるまで確認できません。

この記事では、継続的インテグレーションと継続的デプロイ (CI/CD) パイプライン ツールを使用した導入の強化に焦点を当てます。 継続的インテグレーションとは、1 日に複数回行われるコードの自動化です。その目的は、更新された 1 つのプロジェクトを持つことです。 継続的デプロイとは、1 日を通してこれらの機能を自動的に配信することです。

導入に影響する CI/CD の摩擦の軽減

導入におけるいくつかの障害は、テクノロジとプロセスを組み合わせることによって、最小限に抑えることができます。 CI/CD または DevOps プロセスについての知識がある場合は、次の CI/CD パイプライン プロセスをご存じでしょう。 この記事では、クラウド導入チームのために出発点を確立します。これにより、イノベーションとフィードバック ループが促進されます。 この出発点は、製品やチームが成熟するにつれて、より堅牢な CI/CD または DevOps アプローチに発展する可能性があります。

「顧客への影響を測定する」で説明するように、仮説の有益な検証には反復と決断が必要になります。 この CI/CD に関する記事は、ベスト プラクティスを維持できるようにしながら、イノベーションを失速させる技術的スパイクを最小限に抑えることを目的としています。 これにより、チームは顧客の現在のニーズに対応しながら、将来の成功に向けて設計を行うことができます。

導入とデジタル発明の強化: 成熟度モデル

イノベーション手法の主な目標は、顧客パートナーシップを構築し、フィードバック ループを加速させることです。これにより、市場のイノベーションが実現します。 次の図および以降のセクションでは、この方法論をサポートする初期実装について説明しています。

導入強化の成熟度モデルを示す図。

技術的スパイクを最小限に抑えるために、これらの原則において最初は成熟度が低いと仮定します。 仮説がより詳細になるにつれてスケーリングが可能なツールとプロセスを調整して、事前に計画します。 Azure では、GitHub と Azure DevOps により、小規模なチームが摩擦をほとんど生じさせずに作業を開始できます。 これらのチームは、何千人もの開発者がスケーリング ソリューションで共同作業を行い、何百もの顧客の仮説をテストする規模に発展する可能性があります。 この記事の残りの部分では、これらの原則にわたって導入を強化するための、"大きく計画し、小さく始める" というアプローチについて説明します。

共有ソリューション

「顧客への影響を測定する」で説明するように、仮説の有益な検証には反復と決断が必要になります。 イノベーション サイクル中は、成功よりも失敗の方がはるかに多いでしょう。 これは予期されることです。 ただし、顧客のニーズ、仮説、ソリューションを大規模に調整すると、世界はすぐに変わります。

デジタル発明とイノベーションをスケーリングする場合、ソリューションの共有コード ベースほど有益なツールはありません。 残念ながら、どの反復または MVP の組み合わせが成功につながるのかを確実に予測する方法はありません。 このため、共有コード ベースまたはリポジトリはいつ確立しても早すぎるということはありません。 これは、遅滞すべきでない技術的スパイクの 1 つです。 チームはさまざまな MVP ソリューションを反復するため、共有リポジトリによって共同作業がしやすくなり、迅速な開発が可能になります。 ソリューションの変更が学習メトリックに悪影響を及ぼす場合は、バージョン コントロールを使用して、以前のより効果的なバージョンのソリューションにロールバックできます。

コード リポジトリを管理するために最も広く採用されている CI/CD ツールは GitHub です。これを使うと、いくつかの手順を実行するだけで共有コード リポジトリを作成できます。 また、Azure DevOps の Azure Repos 機能を使用して、Git または TFVC リポジトリを作成することもできます。

フィードバック ループ

イノベーション サイクル中に顧客パートナーシップを構築するための鍵となるのは、顧客をソリューションに組み込むことです。 これは、顧客への影響を測定することによってある程度実現されます。 これには、顧客との会話と直接的なテストが必要になります。 これらによって得られるフィードバックを効果的に管理する必要があります。

すべてのフィードバック ポイントは、顧客のニーズに対する解決策となる可能性を秘めています。 さらに重要なこととして、顧客から直接得られるすべてのフィードバックは、パートナーシップを改善する機会となります。 フィードバックが MVP ソリューションに取り入れられたら、顧客と喜びを分かち合います。 フィードバックが実用的ではない場合でも、そのフィードバックの優先度を下げるという決定を明らかにすることで、成長思考と継続的な学習の重視を示します。

Azure DevOps には、フィードバックの要求、提供、管理を行うための方法が含まれています。 これらのツールにより、フィードバックを 1 か所にまとめることができるため、チームは透明性のあるフィードバック ループに対応するためのアクションを実行し、フォローアップを提供できます。

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

継続的インテグレーションとは、1 日に複数回行われるコードの自動化です。その目的は、更新された 1 つのプロジェクトを持つことです。 導入の規模と仮説が大規模な真のイノベーションに近づくにつれて、テスト対象となる小さな仮説の数が急速に増加する傾向があります。 正確なフィードバック ループとスムーズな導入プロセスを実現するには、これらの仮説が統合され、イノベーションの背後にある主要な仮説を支えることが重要です。 それには、イノベーションと成長のためにスピードが求められ、複数の開発者が中核となる仮説のバリエーションをテストすることが必要となります。 開発作業の後半の段階では、1 つの共有ソリューションに向けて構築を行う複数の開発者チームが必要になることもあります。 継続的インテグレーションは、すべての変動要素を管理するための最初の一歩となります。

継続的インテグレーションでは、コードの変更がメイン ブランチに頻繁にマージされます。 自動化されたビルドおよびテスト プロセスにより、メイン ブランチのコードが常に運用品質であることが確認されます。 これにより、開発者が協力して、正確で信頼性の高いフィードバック ループを提供する共有ソリューションを開発できるようになります。

Azure DevOps と Azure Pipelines では、GitHub やその他のリポジトリでいくつかの手順を実行するだけで継続的インテグレーション機能が提供されます。 詳細については、「継続的インテグレーションとは」を参照するか、継続的インテグレーションのハンズオン ラボを試してください。 Azure DevOps 経由での CI/CD パイプラインの作成を高速化できるソリューション アーキテクチャが提供されています。

信頼性の高いテスト

どのソリューションでも欠陥によって、擬陽性や偽陰性が発生する可能性があります。 予期しないエラーが発生すると、ユーザー導入のメトリックが誤って解釈される可能性があります。 また、仮説のテストを正確に表していない、顧客からの否定的なフィードバックが生まれる可能性もあります。

MVP ソリューションの初期の反復期間には欠陥が想定されています。 早期導入者はそれらを好意的に受け入れる場合もあります。 初期リリースでは、通常、承認テストはありません。 ただし、共感を得ながらの構築の一側面はニーズと仮説の検証に関係します。 どちらも、コード レベルの単体テストと、デプロイ前の手動承認テストによって完了できます。 これらを組み合わせることで、テストの信頼性を高めることができます。 明確に定義された一連のビルド、単体、承認の各テストの自動化を試す必要があります。 これらにより、仮説および結果として構築されたソリューションのより細かい調整に関連する信頼性の高いメトリックが確保されます。

Azure Test Plans 機能には、手動または自動テストの実行期間にテスト計画を作成して実施するためのツールが用意されています。

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

導入を強化する最も意味のある要素はおそらく、ソリューションの顧客へのリリースを制御できることです。 ソリューションを顧客にリリースするためのセルフサービス パイプラインまたは自動化されたパイプラインを提供することによって、フィードバック ループを加速させることができます。 顧客がソリューションの変更をすぐに操作できるようにすることで、顧客をプロセスに引き込みます。 また、このアプローチでは仮説のより迅速なテストがトリガーされるので、仮定を減らし、再作業の可能性が低減されます。

ソリューションのデプロイにはいくつかの方法があります。 最も一般的な 3 つの方法を次に示します。

  • 継続的デプロイは、コード変更が運用環境に自動的にデプロイされるため、最も高度な方法です。 成熟したチームが成熟した仮説をテストする場合は、継続的デプロイが非常に有効である可能性があります。
  • 開発の初期段階では、継続的デリバリーの方が適している場合があります。 継続的デリバリーでは、コード変更は運用環境に似た環境に自動的にデプロイされます。 開発者、ビジネスの意思決定者、チームの他のメンバーは、この環境を使用して、作業内容が実稼働可能であることを検証できます。 また、この方法を使用して、進行中のビジネス アクティビティに影響を与えずに、顧客と共に仮説をテストすることもできます。
  • 手動デプロイは、リリース管理の最も洗練されていないアプローチです。 名前が示すように、チームのだれかが最新のコード変更を手動でデプロイします。 このアプローチはエラーが発生しやすく、信頼性が低いものです。また、ほとんどの経験豊富なエンジニアはアンチパターンであると考えます。

前述の評価にもかかわらず、MVP ソリューションの最初の反復では、手動デプロイが一般的です。 ソリューションが非常に流動的で、顧客のフィードバックが不明な場合、ソリューション全体 (または中核となる仮説) の再設定には重大なリスクがあります。 手動デプロイの一般的なルールは、顧客によるテストは実施しないこと、デプロイを自動化しないことです。

早期の投資は、時間損失につながる可能性があります。 さらに重要なことは、リリース パイプラインの依存関係を作成すると、チームが初期の方向転換に対して耐性を持てるようになります。 最初の数回の反復を終えた後、または顧客からのフィードバックが成功の可能性を示しているときは、より高度なデプロイ モデルを早急に導入する必要があります。

仮説の検証のどの段階でも、Azure DevOps と Azure Pipelines は、継続的デリバリー機能と継続的デプロイ機能を提供します。 継続的デリバリーの詳細については、こちらをご覧ください。または、ハンズオン ラボを参照してください。 ソリューション アーキテクチャにより、Azure DevOps を使用した CI/CD パイプラインの作成を高速化することもできます。

統合された測定

顧客への影響を測定するときは、ソリューションの変更に対する顧客の反応を理解することが重要です。 "テレメトリ" と呼ばれるこのデータでは、ユーザー (またはユーザーのコーホート) がソリューションの使用時に行ったアクションに関する分析情報が提供されます。 このデータから、仮説の定量的な検証を簡単に取得できます。 これらのメトリックを使用して、ソリューションを調整し、より詳細な仮説を生成できます。 これらの微妙な変更により、初期ソリューションがその後の反復でさらに成熟し、最終的に大規模な導入を繰り返すことができます。

Azure では、Azure Monitor に、カスタマー エクスペリエンスからデータを収集して確認するためのツールとインターフェイスが用意されています。 これらの観測と分析情報を適用して、Azure Boards でバックログを調整できます。

次のステップ

導入を強化するために必要な CI/CD パイプライン ツールとプロセスについて理解したら、より高度なイノベーション規範であるデバイスの操作を確認します。 この規範により、物理的エクスペリエンスとデジタル エクスペリエンス間の障壁を減らして、ソリューションをさらに簡単に導入できるようになります。

デバイスの操作