Amazon Web Services ブログ
効果的な e コマース技術チームを組織する方法
これは、The CTO Guide to Ecommerce Architectures: People, Process, and Technology(2021年)( Matthias Patzak 、Paul Vassu 著)からの抜粋です。
適切な組織がなければ、描かれたすべての e コマース・アーキテクチャは目的を達成できません。 CTO として、文化、人材、プロセス、技術から、ビジネス価値を提供する実用的なシステムを構築しなければなりません。効果的な e コマース組織には、共通の目的と原則に沿って高度に連携して活動するマーケティング、プロダクト、テクノロジーの各部門の人々が含まれます。
顧客中心主義、リーン・アジャイル、そして DevOps
この組織の重要な資質は、顧客中心主義、リーン・アジャイル、そして DevOps です。顧客中心主義とは、あなたが作ったすべての機能が顧客に価値を提供することを意味します。方法論としては、デザインシンキングとリーンスタートアップ、特にリーンスタートアップのコンセプトである MVP ( Minimum Viable Product : 実用最小限の製品)と構築・測定・学習サイクルが挙げられます。アマゾンでは、プレスリリースや FAQ を書き、ビジュアルを加えて、お客様やそのニーズ、価値など、問題やソリューションの重要な側面を説明するという、ワーキングバックワードのアプローチを採用しています。 AWS はこの手法をお客様と共有しています。
エクストリーム・プログラミング、スクラム、カンバンのようなリーンおよびアジャイルの方法論は、予測可能で信頼できるプロセスを用いて、組織が迅速かつ安全に機能を構築できます。
DevOps には、予測可能で、信頼性が高く、再現性があり、安全で、高速なプロセスで顧客に機能を提供するためのすべてのプラクティスが含まれます。すべてのチームがいつでも機能を本番環境にリリースでき、ソースコントロールから本番環境へのリリース期間が数日単位ではなく数分単位で計測されるようになれば上出来です。
クロスファンクショナルな製品開発チーム
クロスファンクショナルな製品開発チームは、組織の核となるものです。クロスファンクショナルとは、製品の定義、開発、展開、実行を、個々のチームメンバーのレポートラインに関係なく、異なる役割の人々が共同で行うことを意味します。このようなチームの典型的な役割は、プロダクトマネージャー、ソフトウェアエンジニア、ユーザビリティエンジニア、デザイナー、テスターなどです。
健全なチームサイズは6〜10人程度です。アマゾンでは、 Two-Pizza のルールを採用しています。これは、ピザ 2 枚(アメリカンサイズ)で賄える人数を超えてチームを拡大してはならないというものです。このようなチームに所属するソフトウェア・エンジニアは、アプリケーション・スタックのあらゆる部分を扱えるジェネラリストであり、かつ専門的な技術知識も持っていることを強く推奨します。このような、いわゆる T 字型またはフルスタックのエンジニアは、通常、e コマースソリューションの最も重要な要素を管理することができます。また、商用の既製品ソリューション( commercial off-the-shelf : COTS )を使用している組織でも、たとえソフトウェア開発の必要性が少ないとしても、クロスファンクショナルチームを使用するべきです。その場合、ソフトウェア開発者は、既成品ソリューションの構成に専門性を持ちます。
短期的なプロジェクトではなく、長期的な製品を中心にする
パフォーマンスの高いクロスファンクショナルなチームは、チェックアウト、商品検索、レコメンデーション、決済などのビジネスプロセスを、すべての技術的レイヤー(フロントエンド、バックエンド、データベースなど)にわたって担当します。これは、チームがお客様のニーズを十分に理解し、長期的なメンテナンス性を考慮してソフトウェアの品質を設計するための最良の方法です。
これは、プロジェクトの個々の部分をデリバリするために何度もチームが結成されるプロジェクトベースのアプローチとは対照的です。プロジェクトベースのチームの結果に対する責任は、デリバリされた時点で終わります。保守性は優先事項ではありません。チームは単に一緒に働く個人の集まりに過ぎません。
機能ではなく価値を提供する
e コマース組織のすべてのメンバーは、「機能は必ずしも価値を提供するものではない」という基本的な信念を共有する必要があります。1日に何度も変更をリリースして配信しても、組織の KPI が変化しない組織をよく見かけます。アウトプットはあっても、アウトカムがないのです。良かれと思って機能を構築しても、その機能が必ずしも顧客のニーズを満たしているとは限りません。
このような機能主導型の考え方を克服するためには、企業はエリック・リースが『 The Lean Startup: How Constant Innovation Creates Radically Successful Businesses 』で初めて詳細に説明した「構築・測定・学習」の考え方を採用する必要があります。仮説駆動型の考え方では、アイデアをテストすべき実験として扱います。組織は、いくつかの A/B テストを並行して実行し、新しいアイデアが現在の実装や他の利用可能なソリューションに対してどのように機能するかを判断する必要があります。
これらの実験の成功は、データに基づいて判断されなければいけません。この目的のために、組織は強力なビジネスインテリジェンスとデータアナリティクスのスキルを必要としています。アナリティクス、 AI 、 ML は、成功する e コマース組織に不可欠な能力です。
シンプルで、簡単で、ストレスのないユーザー体験は、すべての e コマースサイトの重要なパフォーマンス指標です。プロダクトマネジメント、エンジニアリング、データスキルに加えて、ユーザー体験のデザインは、組織が習得すべき第 4 の分野です。ユーザー体験のデザインには、フロントエンドの魅力的な見た目や操作性や、合理的なプロセスフローが含まれます。特にユーザー体験については、組織はデータとユーザーからのフィードバックに基づいて意思決定を行う必要があります。ユーザー体験に変更を加える際には、必ず A/B テストを行う必要があります。
疎結合と高い整合性
ビジネスでは、意思決定、仮説や実験、新機能の導入、アップデートのリリースなどのためにスピードが重要になります。どのアーキテクチャを採用するにしても、組織のスピードを最大化するためには、「疎結合」と「高い整合性」の組織を構築します。
疎結合とは、チームがお互いやマネジメントリーダーからできる限り自立して機能することです。そのためには、組織内のコミュニケーションやシステムアーキテクチャの依存関係を減らす必要があります。
企業は、無秩序になることなく、自律性を高めるべきです。マネージャーは、日々の戦術的な決定への関与を減らし、代わりに組織内の戦略的な整合性に焦点を当てるべきなのです。整合性を作り出すためには、原則や信念、戦略文書などいくつかの手段を用います。一方で、目標と重要な結果( OKR )やカンバンのフライトレベルは、チームの戦術的なオーケストレーションのための優れたツールです。
———-
マティアスやAWSへのご質問は、このブログのコメント欄にお寄せください。詳細については、ホワイトペーパー「 The CTO Guide to Ecommerce Architectures 」やデジタルコマースソリューションのページをご覧いただくか、アカウントチームまでお問い合わせください。
著者について
Matthias Patzak
Matthias Patzak は、 Amazon Web Services のプリンシパルアドバイザーです。それ以前は、 AutoScout24 社の IT 部門バイスプレジデント、 Home Shopping Europe 社のチーフデジタルオフィサーを務めました。両社では、リーン・アジャイルの運用モデルを大規模に導入し、クラウドの変革を成功に導き、納期の短縮とビジネス価値の向上を実現しました。
翻訳は Solutions Architect 玉置が担当しました。原文はこちらです。