AWS の 90% はお客様の声から生まれる - Working Backwards と顧客起点のイノベーション

AWS のサービスや機能の 90% 以上が顧客のフィードバックから生まれている背景、Working Backwards プロセス、PR/FAQ、残り 10% の先回りイノベーションを解説します。

90% が顧客の声から生まれるという事実

AWS は日々新しいサービスや機能をリリースしていますが、そのうち約 90% は顧客からのフィードバックに基づいて開発されています。これは AWS の公式ブログで明言されている数字です。顧客が「こういう機能が欲しい」「この部分が使いにくい」と伝えた声が、直接的に製品開発のロードマップに反映されます。残りの約 10% は、技術トレンドや業界動向を観察し、顧客がまだ言語化していない潜在的なニーズを先回りして開発するイノベーションです。顧客のカスタマージャーニーにおける摩擦点を見つけ出し、顧客を驚かせ喜ばせる新機能を生み出します。

Working Backwards - 顧客から逆算する開発プロセス

この顧客起点のイノベーションを支えるのが、Amazon 独自の Working Backwards (逆算) プロセスです。一般的な製品開発では技術やアイデアを起点に「何が作れるか」を考えますが、Working Backwards では「顧客が何を求めているか」を起点に逆算して製品を設計します。プロセスは 5 段階で構成されます。Listen (顧客の声を聴く)、Define (解決すべき課題を定義する)、Invent (解決策を発明する)、Refine (磨き上げる)、Test & Iterate (テストして反復する) です。このプロセスにより、技術的に可能だが顧客が求めていないものを作るリスクを排除します。

PR/FAQ - 開発前にプレスリリースを書く

Working Backwards の中核にあるのが PR/FAQ という手法です。新しいサービスや機能の開発に着手する前に、まずそのサービスが完成した時点で発表するプレスリリースと、顧客や社内から寄せられるであろう質問への回答 (FAQ) を書きます。プレスリリースには、顧客にとっての価値、解決される課題、具体的な利用シナリオを記述します。コードを 1 行も書く前にこの文書を作成し、チーム内でレビューすることで、顧客にとっての価値が不明確なプロジェクトを早期に発見できます。PR/FAQ が説得力を持たないプロジェクトは、技術的にどれほど面白くても開発に進みません。この仕組みが、AWS のサービスが実際のユースケースに即している理由の一つです。

Customer Obsession がすべての起点

AWS の顧客起点のイノベーションは、Amazon のリーダーシッププリンシプルの筆頭に掲げられた Customer Obsession (顧客への執着) に根ざしています。「リーダーは顧客を起点に考え、逆算して行動する。競合に注意を払いつつも、顧客に執着する」という原則です。この原則は採用、評価、意思決定のあらゆる場面で参照され、組織文化として定着しています。re:Invent で発表される新サービスの多くは、特定の顧客との対話から生まれた具体的な課題解決です。発表時に「お客様から X という課題を聞き、Y というサービスを作った」というストーリーが語られるのは、実際にそのプロセスを経ているからです。

まとめ

AWS のサービスや機能の 90% が顧客の声から生まれているという事実は、Customer Obsession と Working Backwards という仕組みによって実現されています。PR/FAQ で開発前に顧客価値を検証し、5 段階のプロセスで顧客から逆算して製品を設計します。200 以上のサービスを展開しながらも各サービスが実際のユースケースに即しているのは、この顧客起点のアプローチが組織文化として根付いているからです。

AWS の優位点

  • AWS の日々のリリース (新サービスや機能強化) の約 90% は、顧客からのフィードバックに基づいて開発されている
  • 残りの約 10% は、技術トレンドや業界動向から顧客がまだ言語化していないニーズを先回りして開発するイノベーション
  • Working Backwards は顧客から逆算して製品を設計する Amazon 独自のプロセスで、Listen・Define・Invent・Refine・Test & Iterate の 5 段階で構成される
  • PR/FAQ は開発着手前にプレスリリースと想定 FAQ を書くことで、顧客にとっての価値を最初に明確化する手法
  • Customer Obsession (顧客への執着) が AWS のリーダーシッププリンシプルの筆頭に位置し、すべての意思決定の起点となっている
  • re:Invent などのイベントで発表される新サービスの多くは、顧客との対話から生まれた具体的な課題解決である
  • この顧客起点のアプローチが、AWS が 200 以上のサービスを展開しながらも各サービスが実際のユースケースに即している理由である

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

同じテーマの記事

AWS の値下げの文化 - 2006 年以来 100 回以上の値下げを支えるフライホイールと規模の経済 AWS が 2006 年のサービス開始以来 100 回以上の値下げを実施してきた背景、Amazon のフライホイールモデル、規模の経済、競合への先手を打つプロアクティブな値下げ戦略を解説します。 AWS Budgets で実現するコスト管理 - 予算アラートと自動アクション AWS Budgets による予算の設定、コスト・使用量アラート、予算超過時の自動アクションを解説します。 クラウドコスト予算管理 - AWS Budgets による支出制御とアラート AWS Budgets を使った予算設定・コストアラート・自動アクションを解説。Cost Explorer との使い分け、予算タイプの選択、Organizations 統合による組織全体の予算管理を紹介します。 AWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジング Compute Optimizer による EC2、Lambda、EBS、ECS のリソース推奨と、コスト削減の実践手法を解説します。 コンピュートリソース最適化 - AWS Compute Optimizer による適正サイジング AWS Compute Optimizer を使ったリソースの適正サイジングを解説。EC2 ・ Lambda ・ EBS ・ ECS on Fargate の推奨事項、コスト削減効果の試算、導入手順を紹介します。 コスト異常検知 - AWS Cost Anomaly Detection で予期しない支出を早期発見する AWS Cost Anomaly Detection を使ったコスト異常の自動検知を解説。ML ベースの異常検出、モニター設定、SNS/Slack 通知、Budgets との使い分けを紹介します。 AWS Cost Explorer でコストを可視化・分析 - タグ戦略と Savings Plans の活用 Cost Explorer によるコストの可視化、タグベースの配分、Savings Plans の推奨と購入判断を解説します。 コスト可視化と分析 - AWS Cost Explorer で実現するクラウド支出の最適化 AWS Cost Explorer を活用したクラウドコストの可視化と分析手法を解説します。CloudWatch メトリクスとの連携による使用量モニタリングと、コスト最適化のための実践的なアプローチを紹介します。 AWS Cost and Usage Report で詳細コスト分析 - Athena クエリと可視化パイプライン CUR による詳細コストデータの取得、Athena でのクエリ分析、QuickSight での可視化を解説します。 AWS Savings Plans で最大 72% のコスト削減 - Compute と EC2 Instance プランの使い分け Savings Plans の種類と選び方、RI との比較、購入判断のベストプラクティスを解説します。 コスト削減戦略 - Savings Plans と Reserved Instances の比較と選択 AWS Savings Plans と Reserved Instances (RI) の仕組み・割引率・柔軟性を比較解説。Compute Savings Plans ・ EC2 Instance Savings Plans ・ SageMaker Savings Plans の使い分けと購入戦略を紹介します。