DevOps プロセス: 顧客からのフィードバック

ソフトウェア プロジェクトでは、デベロッパーは多くの場合、数か月または数年にわたって製品を開発します。構築する機能が実際にユーザーの問題を解決できているかどうか、その機能自体が使用されているかどうかはまったく検証せずに、複数回リリースする場合もあります。

顧客からのフィードバックは、バリュー ストリームでの作業の可視性小さいバッチ単位の作業チームのテストなど、幅広い機能グループの一部です。これらはともに製品管理へのリーン アプローチを表しています。

これらの機能を一緒に使用すると、次の予測を行うことができます。

  • ソフトウェア配信パフォーマンス。配信の頻度、安定性、リリース時期の観点から測定されます。
  • 組織のパフォーマンス。収益性、市場シェア、生産性の観点から測定されます。

DevOps の調査と評価(DORA)の調査では、チームはこれらの機能を利用し、また次の作業を行っている組織で働く場合、より高いパフォーマンスを達成することが示されています(PDF へのリンク)。

  • 顧客満足度の指標を定期的に収集する。
  • 製品および機能の品質に関する顧客からのフィードバックを積極的に入手し、それに対処する。
  • このフィードバックに基づいて製品と機能の設計を行う。

顧客からのフィードバックの実装方法

製品を開発しているときには、成功を測定する主要な指標を設定することが重要です。これらの指標により、実際の問題が解決されているかどうか、ソリューションが十分迅速に導入されているかどうか、ユーザーがソリューションの利用を継続して他のユーザーにも推奨するかどうかを理解できます。これらの指標は、顧客が製品と対話する方法から明示的に導出する必要があります。これらの指標を使用するには、顧客からのフィードバックを慎重に収集して分析する必要があります。

消費者向け SaaS 製品で一般的な指標のセットの 1 つとして、AARRR があります。AARRR とは、Acquisition(獲得)、Activation(活性化)、Retention(継続)、Referral(紹介)、Revenue(収益)の頭文字を取った用語です(順序は提示する人によって異なる場合があります)。この頭字語は、海賊の呼び声になぞらえて綴られることから、海賊指標とも呼ばれることもあります。

この考え方は、次の 5 つの主要な指標に沿って、顧客体験を繰り返して改善するというものです。

  • ユーザー獲得: サイトにアクセスしてアカウントを作成するユーザーの割合。
  • 利用の開始: アカウントの利用を開始してサービスを使用する獲得ユーザーの割合。
  • 利用の継続: サービスを再訪する活性化ユーザーの割合。
  • 紹介: 他のユーザーにサービスを紹介する継続ユーザーの割合。
  • 収益の発生: 実際にサービスに課金している紹介ユーザーの割合。

これらの指標がビジネスや製品に適していない場合、より適切な指標を見つけて定期的にモニタリングし、製品戦略の主要な推進力として使用することが不可欠です。

この記事で説明するアプローチは、外部向け製品だけを対象としているのではありません。組織内の他のユーザー向けに構築された内部製品やサービスにも、同様に適用できます。内部ツールの構築にも、まったく同じアプローチが必要です。構築するツールで実際に問題を解決できるように、実際のユーザーとの早期かつ頻繁なエンゲージメントが必要です。そうでなければ、誰も使用しないツールを構築して使用することになります。このことは、ツール作成に取り組む人員の意欲をなくし、好みではないツールを使用しなければならないユーザーに不満を与えます。また、ユーザーにとって不十分なテクノロジー マッチが構築されるため、会社にとって大きなコストとなります。

顧客の問題を解決する可能性を最大限に高めるには、次のパターンを使用する必要があります。

  1. 潜在的な機能を定義する前に、顧客からのフィードバックを収集する。
  2. 実際の問題が解決されているかどうかを検証する。
  3. その問題を実際に解決するソリューションを繰り返し構築する(それ以外は何もしない)。
  4. ソリューションが実行可能なビジネスにつながることを確認する(たとえば、コストが予想収益よりも少ないこと)。
  5. 主要な指標を追跡して成功を評価する(たとえば、AARRR)。
  6. 上記を繰り返して、これらの指標を改善する。

成功するには、ソフトウェアを迅速にデプロイおよびリリースするだけでなく、顧客のニーズにより良く、よりスマートに、より迅速に対応する必要があります。これは、競合他社よりも多くのテストを行うことで実現できます。小売業は、これで特に成功を収めている(PDF へのリンク)業界の 1 つです。仮説駆動型開発、顧客獲得のための目標到達プロセスの定義および測定、A/B テストなどの手法により、ユーザーテストを実施できます。これにより、創造性が促進され、イノベーションが加速し、組織学習が生まれます。

顧客とのエンゲージメントの増加と製品管理プロセスへの参加は、組織の目標と価値(PDF へのリンク)をより明確に特定することに寄与します。その結果、組織のパフォーマンス向上につながります。

主な注意点

顧客からのフィードバックの効果的な使用を阻害する要因としては、一般に次のようなものが挙げられます。

  • フィードバックの収集に失敗する。ソフトウェア開発会社は、顧客からのフィードバックをまったく収集しないのが一般的です。
  • フィードバックの収集がタイムリーでない。企業は、ソフトウェア配信ライフサイクルにおいて顧客のフィードバックを収集する時期が遅すぎるため、フィードバックを活用できない場合があります。
  • 問題を理解していない(または顧客のフィードバックを誤解している)。企業は、顧客に対して非現実的な期待を抱いている場合や、顧客が製品に何を望んでいるのかを理解できていない場合があります。チームは、顧客からのフィードバックが正確であるにもかかわらず、不都合であるという理由からフィードバックを明示的に無視することさえあります。この状況は、開発チームが現在開発しているソリューションを配信する際のリスクを適切に評価もしくは管理していない場合、または解決するべき問題を単に理解していない場合に発生する可能性があります。開発チームは、問題解決に要する作業の範囲を最小限に抑えたいと考えています。問題が、チームが設計した製品の範囲を超えていると、チームはこれに付随する作業を「要件変更」として誤って処理する場合があります。これは、顧客にとって不完全なソリューションをもたらし、最終的には製品の故障につながります。
  • チームがフィードバックに基づいて行動できない。チームのテストに関するドキュメントで説明するように、フィードバックに応じて、システムの設計または仕様を変更する権限を配信チームに与える必要があります。
  • 間違った指標に基づいて成功を測定する。場合によっては、十分に顧客検証を行っていないソリューションが、最終的な要件として開発チームや配信チームに提供されます。そのような場合、配信チームの成功は、チームが実際に問題を解決したか、または顧客のために結果を出したかではなく、仕様どおりの機能を配信したかどうかに基づいて測定されます。
  • 顧客の問題に対処できない。A/B テストの業界データ(PDF へのリンク)によると、成功する製品に関して、実際に配信されたときにビジネスの成果を改善できるのは、提案された機能のうち約 3 分の 1 だけです。残りの 3 分の 2 の機能は、ビジネスにまったく寄与しないか、マイナスの成果をもたらします。そのため、ユーザー調査を実施していない場合、チームが取り組んでいる作業の少なくとも 3 分の 2 は、望んだ結果を達成できていないか、むしろ事態を悪化させている可能性があります。チームがライフサイクルの初期段階にある製品、特に革新的な製品に取り組んでいる場合、チームが望む結果を達成できる確率はかなり低くなります。
  • 顧客からのフィードバックに応答するために必要な時間と労力を過小評価している。チームは、提案するソリューションに問題があることを想定し、少なくとも 3 分の 2 を破棄できるようにしておく必要があります。残りの 3 分の 1 のソリューションについて、チームは顧客からのフィードバックに応じて、それらを大きく進化させられるようにしておく必要があります。

顧客からのフィードバックの改善方法

ユーザー エクスペリエンス デザイン(UX)の分野は、改善を理解するためのフレームワークを提供します。多くの組織は、UX を製品 UI の見栄えを良くするものとして扱います。しかし、UX は、ユーザーの実際の問題を解決するためのものです。より広い意味で、UX とは、ユーザーが組織とやり取りするときに経験するすべてのものを指します。優れた UX が成功する製品とサービスを構築するうえでどれほど重要であるかに留意する必要があります。

配信プロセスに特化した顧客フィードバックを構築することが不可欠です。重要な機能は、解決するべき問題に基づいて構築する必要があります。これには、考えられるソリューションを決定して候補を選択するためのユーザー調査の実施が含まれます。コードを記述する前に、ユーザー調査の結果を分析する必要があります。

ライフサイクルの初期段階にある製品の場合、チームはコードを記述する前に、リーン スタートアップの動きで提案されたアイデアを導入して、製品の基礎となるビジネスモデルを検証する必要があります。実際の問題を解決しているかどうかを検証してから、問題解決のためのソリューションを繰り返し構築する一方で、実行可能なビジネスモデルを提供する必要があります。

既知のビジネス上の問題に対する新しいソリューションを実装している既存の製品についても、同様のパターンに従う必要があります。ソリューションの設計が検証されたら、さらに調査とテストを実施できるようにプロトタイプを作成する必要があります。機能が目標を達成していることをテストで検証して初めて、完全な本番環境の機能が完成します。

多くの組織は、この作業をすべてスキップして失敗します。ただし、これらの手順を厳密に実施しても、成功が保証されるわけではありません。この取り組みのポイントは、可能な限り失敗のリスクを最小限に抑えることです。

顧客からのフィードバックの測定方法

顧客からのフィードバックを収集して可視化し、それに対処することを実現するために、高度なデータ収集は必要ではありません。次の質問により、製品設計のために顧客からのフィードバックをどの程度活用しているかを判断できます。

  • 顧客満足度を測定する指標はありますか?これらは定期的に更新され、チームに定期的に配信されますか?それらに対処していますか?
  • すべての機能を構築する前に検証を行い、配信の一環としてプロトタイプを使用してユーザー調査を実施していますか?
  • このユーザー調査に基づいて機能に変更を加えていますか?
  • ユーザーから積極的かつ定期的にフィードバックを収集し、それに対処していますか?

次のステップ