クラウド導入に関連するイノベーション
どの IT ポートフォリオにも、市場での企業の地位を大幅に向上させる可能性があるワークロードやアイデアがいくらか含まれています。 ほとんどのクラウド導入作業では、既存のワークロードの移行と最新化に重点を置いています。 ただし、クラウド イノベーションにより、ビジネス価値を最大限に高めることができます。 クラウド導入に関連したイノベーションにより、新しい技術スキルと拡張されたビジネス機能が利用可能になります。
クラウド導入フレームワークのイノベーション手法では、顧客のニーズを理解することと、顧客と製品のやりとりを形成するイノベーションの短期構築に集中的に取り組みます。 この記事では、MVP (Minimum Viable Product/実用に足る最小限の製品) の価値を届けるアプローチについて説明します。
クラウド導入ライフサイクルのこのフェーズの準備として、フレームワークでは、次のクラウド イノベーションの演習を提案しています。
|
事業価値における合意に基づく仮説の作成: 技術的なソリューションを決定する前に、新しいイノベーションによってビジネス価値がどのように促進されるかを識別し、顧客のニーズについて仮説を立てます。 |
|
最初の MVP の構築: アプリケーションに組み込むのに十分な価値の可能性が仮説にあることが検証されたら、構築プロセスを開始します。 開発スプリントはできるだけ速くする必要があります。 クイック スプリントを使用すると、チームは仮説をすばやく検証または拒否したり、必要な機能をアプリケーションと統合する方法を微調整したりできます。 |
|
MVP からの測定および学習: できるだけ早く仮説の正確さを確認する必要があります。 実用最小限の製品 (MVP) とは、フィードバックを収集し、正しい方向に進んでいるかどうかを確認するのに十分な機能を提供する、新しい機能の予備バージョンです。 |
|
デジタル イノベーションの展開: 次のようなイノベーション規範やデジタル発明を使用して仮説を洗練します。 |
イノベーションの概要
次のアプローチは、既存のリーン手法に基づいて構築されています。 この目的は、顧客の導入についてクラウド志向の会話を行い、ビジネス価値を生み出すための科学的なモデルを作成できるよう支援することです。 また、このアプローチでは、既存の Azure サービスを管理可能な意思決定プロセスに対応付けます。 この調整は、特定の顧客のニーズや仮説への対処に適した技術的なオプションを見つけるのに役立ちます。
MVP の構成時には、次のようなデジタル発明の 5 つの規範の使用を検討する必要があります。
- データの民主化
- アプリケーションを介したエンゲージ
- 導入の強化
- デバイスの操作
- 予測と影響
この一連の記事では、この手法の次の点を重点的に説明します。
- 第 1 に、常に Customer Adoption (顧客による製品/サービスの採用) から始め、フィードバックを生成します。これにより、Build-Measure-Learn (構築-計測-学習) フィードバック ループを介してカスタマー パートナーシップが形成されます。
- 第 2 に、採用に優先順位を付けるデジタル発明を開発するための手法について調べます。
すべてのプラクティスを一度に採用する必要はありません。 これらの規範では、デジタル発明を開発するためのいくつかのアプローチが強調される一方で、導入と顧客の共感に焦点を当てることもできます。
次のセクションでは、このアプローチで成功を達成するために必要なイノベーションとコミットメントの公式について説明します。
イノベーションの公式
イノベーションの成功とは、大規模な変革や、わかりにくく神話的なプロセスによるものではありません。 イノベーションにおける成功はむしろ、曲芸の綱渡りのようなものであり、イノベーション = 発明 + 採用という単純な等式で表わされます。
イノベーションは、発明と採用が交わるところで発生します。 真のイノベーションは、新しい手法、新しいプロセス、新しいテクノロジを介して人間の体験がゆっくりと調整されることで生まれます。 この公式では、イノベーションとは、顧客のニーズを満たす新しいソリューションの作成を意味します。 反対に、採用とは、新しいソリューションを適用して人間の行動や対話を形成することです。 発明と採用の間で正しいバランスを見つけるには、イテレーション、データに基づく意思決定、絶え間ない学習、成長志向が必要です。 現代のデジタル社会で学習する数え切れない機会について行けるテクノロジも必要です。
クラウドはしばしば、イノベーションの発明または技術面にとって優れたプラットフォームとなります。 残念ながら、優れたアイデアのほとんどは、思考過程や発明過程ではなく、採用というハードワークの間に落とされます。 成功を確実にするには、開発チームは常に、イノベーションのテストとして採用から始める必要があります。 そのため、この手法は採用時から開始されます。 この手法を使用するには、チームが次の 3 つのコミットメントに同意する必要があります。
全社的コミットメント
イノベーション手法を採用して、この記事で概説しているメトリックを効果的に使用するには、会社全体でのコミットメントが必要になります。 イノベーションを進める手法を変更する前に、導入チームとリーダーシップ チームがこうした約束をできることを確認してください。
テクノロジよりも顧客を優先するというコミットメント
どこの開発チームも、自分たちにとって最もなじみのあるツールやテクノロジを揃えています。 そのような強みを活かすこと、知っていることを使うことは賢いことです。 しかしながら、イノベーションを成功させるには、チームは顧客のニーズとテストする仮説に対する焦点を維持する必要があります。 この焦点が、特定のツールの機能やアーキテクチャ上のアプローチと適合しない場合があります。 イノベーションで成功するには、開発チームはオープン マインド (先入観を持たない心) を維持する必要があります。 発明プロセスの間は、チームの嗜好より顧客のニーズを優先させることを技術面の決定の中心に据えます。
透明性に対するコミットメント
イノベーション手法における計測を理解するには、まず、透明性に対するコミットメントを理解する必要があります。 イノベーションは、成長志向に固守する環境でのみ育ちます。 経験から学習すること至上命令とする企業風土が、成長志向の根底にあります。 成功するイノベーションと継続的な学習は、計測において透明性を約束することから始まります。 これはクラウド導入チームにとって勇敢なコミットメントです。 しかしながら、リーダーシップ チームやクラウド戦略チームが提唱する透明性コミットメントと一致しないなら、この約束には意味がありません。
透明性が重要になるのは、顧客への影響を測定しても正しいのか間違っているのかという質問には答えてくれないからです。 影響の測定は、導入チームの仕事の質を示すものでもありません。 そうではなく、顧客のニーズを知り、それにより良く対応する機会を表わします。 イノベーション メトリクスの誤用はその企業風土を抑えつけかねません。 やがて、そのような誤用はメトリックの改ざんにつながり、その結果、発明、サポート スタッフ、最終的にはデータを誤用した管理構造の長期的失敗につながります。 リーダーと貢献者は共に、MVP ソリューションを知り、改善するための機会のため以外には、測定を利用するべきではありません。
イテレーションに対するコミットメント
イノベーション周期全体を通して、1 つだけ正しいと言えることがあります。最初の試みでは成功しないということです。 測定は、望まれる結果を得るために必要な調整を理解する上で役立ちます。 好ましい成果につながる変化は、Build-Measure-Learn (構築-計測-学習) のプロセスを繰り返すことから生まれます。 クラウド導入チームとクラウド戦略チームは、成長志向や Build-Measure-Learn (構築-計測-学習) 手法を取り入れる前に、繰り返し志向を約束する必要があります。
次のステップ
次のすぐれた発明を構築する前に、導入と顧客の共感を念頭に置きながらデジタル発明の開発に対するさまざまなアプローチを確認します。