イノベーション ライフサイクルに従う
Tailwind Traders 社には、他の多くの組織にも影響を与えるイノベーションに関する疑問があります。
- 実行中のビジネスに影響を与えることなく変更率を高めるにはどうすればいいのでしょうか?
- イノベーションを最大限に活用するためには、イノベーションを実現する部分や実装する変更点は、どうやって決定すればいいのでしょうか?
どちらの疑問に対する答えも、Tailwind Traders 社が組織の文化の一部として変更を受け入れる必要があるということです。 変更を好まない組織が変更に関連する停止に頻繁に見舞われる理由の 1 つは、変更や影響が大きすぎるためです。 制御された現実的な環境で変更をテストするのは困難です。
変更を頻繁に導入するためのプロセスが確立されている場合、変更のサイズもリスクも小さくなります。 ただし、このプロセスでは、特定のツールやテクノロジの採用だけが含まれるわけではありません。 これには、変更を促進し、失敗を受け入れるような文化が必要です。
失敗を受け入れるという概念は、直感に反しているように思われるかもしれませんが、イノベーション サイクルにとっては重要です。 誤りのせいで非難の的にされるために失敗を恐れているのは、失敗を恐れて問題解決への新しいアプローチを追求しないようなものです。 そして、組織全体が確立された慣行に囚われたままとなります。
"フェイル ファストする" 文化を確立してもかまわないのです。そこでは、新しい方法を進んで試すことができます。 期待される結果が得られなければ、迅速に方向転換することで、より豊かなイノベーション文化を生み出すことができます。
仮説に基づくイノベーション
イノベーションは、仮説ベースの反復的なサイクルとして説明できます。 問題の存在を特定したときに、根本原因を説明し、解決策につながる可能性がある 1 つ以上の仮説を立てることができます。 問題自体の定義は、評価可能である必要があるため、困難な場合があります。
たとえば、"顧客が支払いプラットフォームの選択肢に満足できない" という問題の定義は測定できないため、解決が困難になります。 この問題を "顧客の 23% が支払いプラットフォームの選択時にショッピング セッションを終了する" として定義できる場合は、考えられる解決策の成功を評価するのに適した立場にあります。
問題を評価可能な方法で定義したら、問題を説明して解決するための候補となる仮説を立てることができます。 たとえば、Tailwind Traders 社の仮説は、「サポートされている支払いプラットフォームに ContosoPay を追加すると、支払いページの顧客離反が 23% から 10% に減少する」と説明されています。これで、アイデアが用意できたので、後はその有効性を検証するだけです。
仮説は、顧客に付加価値を与えることと、組織とのやり取りにおける操作性が向上させることに焦点を合わせる必要があります。 このアイデアは、"顧客共感" と呼ばれることがよくあります。イノベーションの中心に顧客を配置し、双方に対する価値を高めることを重視するものです。
アプリケーション コードに触れることなく仮説を検証する方法はたくさんあります。 お客様へのアンケートと市場調査は、仮説の妥当性を判断するのに役立つ貴重な情報源の 2 つの例です。 これらの情報を確認することで仮説を見極めることができます。また、最も正確で、ビジネスの付加価値の高い仮説を立てることができます。
ビルド
仮説にアプリケーションに組み込むのに十分な価値の可能性があると、ビルド プロセスが開始されます。 ここでも、速度は非常に重要です。
開発スプリントはできるだけ短くする必要があります。 スプリントを短く保つことで、仮説を迅速に実証または棄却することができます。 また、必要な機能をアプリケーションに統合する方法を微調整できる可能性もあります。 その結果、イノベーション サイクルが速くなります。
Measure
できるだけ早く仮説の精度を確認する必要があります。 実用最小限の製品 (MVP) は、フィードバックを収集し、正しい方向に進んでいるかどうかを確認するのに役立つ、新しい機能の暫定版です。
MVP の目標は、仮説だけではなく、行っていたかもしれない仮定も検証することです。 たとえば、Tailwind Traders 社のお客様の 23% が支払いページで購入プロセスを終了した場合、その理由は、会社で十分な支払いプラットフォームが提供されていないことが仮説にあります。 ただし、理由は異なっている可能性があります。 MVP は、これらの想定と仮説を確認または拒否するように設計する必要があります。
Learn
学習フェーズは、プロセスの開始に似ています。 想定または仮説についてさらに学習すると、それらが正しいか、部分的に正しいか、間違っているかがわかることがあります。 成長型思考、そして失敗を認めるのに十分な謙虚さを持っていると、次のいずれかができるようになります。
- MVP で作業を継続する必要がある場合にすばやく方向転換する。
- 他の分野に再び焦点を合わせ、対立仮説を立てる。
想定や仮説が間違っていたとしても、このプロセスによって顧客とビジネスに関する新たな情報を得ることができたことに気づくことが重要です。 それを無駄な時間と考えないでください。 重要なのは、できるだけ早くその知識を得て、将来の仮説に適用することです。 このアイデアがフェイルファスト文化の中核となります。
次に見る部分
「クラウド導入フレームワークのイノベーションの概要」は、イノベーションの方法の調査を開始するのに最適な場所です。