re:Invent 2024: AWSが語る組織変革の障壁と解決策 - Two-pizza teamとWardley maps
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How not to sabotage your transformation (SEG104)
この動画では、AWSのEnterprise StrategistであるMatthias Patzakが、組織の変革を妨げる要因とその解決策について解説しています。時代遅れの原則や過度なサイロ化、誤ったリソース配分、組織の慣性など、変革の障壁となる要素を具体的に指摘し、Amazonが実践するTwo-pizza teamやSingle-threaded leadershipの考え方、Wardley mapsを用いた価値の可視化などの解決策を提示しています。また、Digital native企業とレガシー企業の予算配分の違いや、リーダーシップチームの在り方、人材採用における態度とスキルのバランスなど、組織変革の具体的な方法論を豊富な実例とともに紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Enterprise Strategistによる組織変革の洞察
こんにちは。ドイツのミュンヘンを拠点とする Matthias Patzak です。私は AWS の Enterprise Strategist を務めています。これはあまり分かりやすい肩書きではありませんね。私たちは、商業部門や公共部門の組織でTransformationを自ら主導してきた元リーダーたちによる小さなチームです。私は、ヨーロッパで最大の中古車マーケットプレイスである AutoScout24 の CEO を務めていました。Enterprise Strategist として、私たちは現在の AWS のお客様に、どのようにTransformationを主導してきたかを共有しています。そして、お客様は私たちに、Transformationや新しい働き方についての現在の考えを共有してくださいます。
時には、お客様が共有してくださる文書をレビューすることもありますが、時々少し奇妙に見えることがあります。 まるで Simple Sabotage Manual（妨害マニュアル）のようなものですが、私たちは自分たちの組織を妨害したりしませんよね？でも、皆さんの中で「ああ、これは少し変だな、おかしいな」と思ったことのある組織に所属していた方はいらっしゃいませんか？ これから45分ほどかけて、私たちが組織で観察してきたパターンと、組織が自らのTransformationをどのように妨害しているのかについて、私たちの考えを共有したいと思います。
時代遅れの組織原則と現代の課題
最初に観察されるのは、時代遅れの原則です。 こちらは Henri Fayol と Lyndall Urwick です。Henri Fayol は20世紀初頭の鉱山技師で、Lyndall Urwick は経営コンサルタントでした。そうです、100年前にも経営コンサルタントは存在していたのです。彼らは両者とも、組織の設立と運営方法について本を執筆しました。 これらは彼らが提唱した原則の一部です：専門化を促進するための業務の分割と権限。彼らの視点からすると、権限、つまり命令を下す権利と服従を要求する力は、非常に重要でした。
実際、彼らが書いた原則のすべてが、21世紀の現代において間違っていると認識されているわけではありません。彼らは方向性の重要性についても言及し、従業員がイニシアチブを取り、特定の目標を持ち、組織に継続性を持たせることの重要性についても語っていました。 残念ながら、これは Netflix の Reed Hastings の言葉ですが、「大量生産・低エラーの製造業からの経営パラダイムが、ビジネスの組織的実践を支配するようになってしまった」のです。
私はドイツ人ですが、ドイツでは GDP の26%が製造業に基づいています。イギリスやフランスでは約16%、アメリカも同様ですが、それでも多くの組織が、製造業でさえも、まったく異なるタイプの仕事のために作られたこれらの原則を適用しています。 これが、Accenture の最近の調査で、94%の CXO が「オペレーティングモデルが成長と業績を危険にさらしている」と述べた理由です。問題は人でもなく、文化でもなく、オペレーティングモデルなのです。本来は逆であるべきで、オペレーティングモデルは成功とイノベーションの enabler であるべきです。
組織の変革を望むお客様を観察していると、依然としてサイロ化された組織構造に依存していることがわかります。 具体的に見てみましょう。組織にはデザイン部門、マーケティング部門、営業部門といった異なる機能部門があります。これらの部門の人々が協力して共創しようとする場合、通常はヒエラルキーを上って、 他部門との協働の許可をチームリーダーに求めなければなりません。チームリーダーは部門長に確認し、最終的には会社のトップまで話が上がっていきます。これは管理のために作られた構造なのです。
しかし実際には、私たちは管理を望んでいませんし、必要としてもいません。 私たちが本当に必要としているのは、顧客へのビジネス価値とイノベーションの提供を最適化し、同時にフローも最適化する運用システムです。そのため、現代の組織はクロスファンクショナルチームを基盤としています。Amazonではこれらを Two-pizza teamと呼んでいますが、小規模で機動的でありながら、価値を大規模に提供するために必要なすべてのスキルと機能を備えています。 その背後にある基本原則はシンプルでした。組織内の誰かが他の人の助けを必要とする場合、その人に直接連絡を取り、隣のオフィスや階、建物に行って助けを求めればいいのです。
現実には、意思決定には多くの人々が関与する必要があります。 8人の場合、28の接点、 28の関係性を維持しなければならず、議論や意思決定に関わる人が増えれば増えるほど、それだけ時間がかかります。 これが主な問題です。なぜなら、意思決定プロセスに多すぎる人々が関与すると、 誰が本当に責任者なのかが不明確になるからです。Amazonでは、後ほど説明する Single-threaded leaderという考え方を持っています。このような状況が組織と変革を遅らせているのです。
Amazonでは、コミュニケーションは機能不全の兆候だと考えています。 なぜなら、人々がコミュニケーションを必要とするということは、密接で有機的な方法で協働できていないことを意味するからです。Jeff Bezosは、チーム間のコミュニケーションを増やすのではなく、減らす方法を見つけるべきだと述べています。これが私たちの組織設計の方法です：顧客に価値を提供できる小規模なTwo-pizza teamを作るのです。
Wardley mapsと組織の差別化要因
また、私たちが観察しているのは、誤ったリソース配分です。 リソース配分の問題は明確です。なぜなら、どこに向かうべきかが不明確で、これらの組織に欠けているのはガイダンスだからです。ガイダンスと方向性を与えるのが地図です。これから数分間、2×2のメトリクスを使用して、最終的にWardley mapsについて説明します。これは組織の価値の流れとリソース配分をマッピングする方法です。予測可能性（低い予測可能性と高い予測可能性）と自律性という2つの次元があります。
私のチームメンバーの一人が挙げた例をご紹介します。マクドナルドの薬局のような例です。マクドナルドでは、フライドポテトを調理する際、ムンバイでもミュンヘンでも同じように見えなければなりません。そのため、非常に予測可能な結果を求め、それを提供する人々の自律性を低く抑えています。新しい店舗を建設する場合は、予測可能性が低くなるため、より多くの自律性を与えます。ERPシステムを導入する場合は、不確実性が高いため、より多くの自律性を提供する必要があり、イノベーションの領域に入る場合も、チームにこの不確実性に対応するための十分な自律性を与える必要があります。
このマップは4つの領域に分けることができます。最初の領域はGenesisです。これは真のイノベーションが起こる領域です。何か新しいものを発明した場合、誰かがそれに対してカスタムビルドのソリューションを作ります。十分な数の組織や企業が特定の問題に対してカスタムビルドのソリューションを構築すると、必ず誰かがそれを製品化します。そして、一部の製品はUtilityになります。その一例がCloud Computingで、1950年代にイノベーションとして始まり、その後ラックサーバーという製品となり、私も何千台ものラックサーバーを購入しました。最終的に、2014年に私がお客様として Cloud Transformationを行った時には、ラックサーバーはAmazon EC2というUtilityになっていました。
ソフトウェアでも同じことが言えます。私がキャリアを始めた頃は、フロッピーディスクでソフトウェアをインストールしていましたが、これらの製品もUtilityになりました。より多くの製品やUtilityを使用することで、インフラストラクチャーと組織の複雑さを解消することができます。これは先ほどのKeynoteで話した内容のフォーカスポイントであり、より多くのイノベーションとカスタムビルドソリューションを可能にするのに役立ちます。多くのAWSサービスの目的は、組織の複雑さを解消し、組織の真の競争優位性がある領域にリソースを配分できるよう、製品とUtilityを提供することにあります。
組織の真の競争優位性に焦点を当てる際、イノベーションを妨げ、サボタージュするのは組織の慣性です。製品からUtilityへの移行における組織の慣性の例に戻りましょう。これは通常、Cloud Transformationにおいて、組織の非常に経験豊富な専門家に新しい製品やAmazonのサービスを学んでもらう時に起こります。業界で20年や30年の経験を持ち、特定の製品、データベース、ネットワーク製品に精通している人に新しいことを学んでもらうように頼むとき、彼らの視点からすると、これまでの知識やスキルにリセットボタンを押されているように感じるでしょう。
実際にはそうではありません。確かに新しいことを学ぶ必要があります。例えば、Oracleの管理者だった人が、Amazon RDS AuroraやAmazon DynamoDBの仕組みを学ぶ必要があるかもしれません。しかし、これまでの経験全てにリセットボタンが押されるわけではありません。On-premiseからCloudへの移行を行う際は、このような変化をマネジメントする必要があります。再教育とスキルアップの観点から、私はいつも、人々が新しく学ぶ必要のないもの、つまり大規模システムのアーキテクティングにおける彼らの経験を強調することから始めることをお勧めしています。コンソールでデータベースを設定して起動する方法のトレーニングから始めるのではなく、Well-Architected Frameworkから始めて、Amazonで大規模なシステムをどのように構築するかを説明するのがいいでしょう。このようにすれば、経験を活かしながら、彼らが将来も必要とされ、重要な存在であるという自信を与えることができます。そして、この知識を基盤として、コンソールサービスの基礎的なトレーニングを本格的に始めるのです。
多くの変革を妨げるもう1つの要因は、差別化要因を忘れてしまうことです。差別化要因とは、あなたの組織らしさ、つまり業界内の他社と比べて何が特徴なのかということです。ここで Wardley マップが役立ちます。横軸には依然として予測可能性があり、Genesis、Custom-built、Product、Utilityの領域があります。一方、縦軸には可視性があり、これは顧客にとってどれだけ見えやすいかを表します。モデルマップの上部にある項目は、顧客に近く、非常に見えやすいものとなります。
この例は請求書の支払いに関するものです。1990年代の個人向け銀行サービスを利用する顧客を考えてみましょう。当時、支払いは支店に行くか電話で行うことができました。銀行は低速WANやPSTNなどのカスタムビルドソリューション、製品、サービスを使用したインフラを構築していました。しかし、このビジネスモデルは複雑化し、2010年代には顧客はアプリやWebでも支払いができるようになりました。銀行は組織内により多くのバリューストリームとインフラを構築する必要がありました。
では、Digital nativeな銀行が同じ顧客ニーズをどのように解決しているか見てみましょう。2020年代のDigital native銀行は、先ほどの例と比べてやっていることがシンプルです。使用する製品は少なく、Utilityサービスにより大きく依存しています。Utilityサービスを積極的に活用することで、業務やビジネスプロセスをシンプルにしています。そのおかげで、より多くのリソースとデジタル人材をカスタムビルドソリューションやイノベーションの領域に投入できるのです。そのため、ビジネスプロセスの観点からもフロントエンドの観点からも、通常より優れたユーザビリティを提供できています。
これらの組織が行っているのは、やらなくて済む作業を最大限に増やすことです。クラウドテクノロジーを活用し、製品も使用・導入しますが、過度にカスタマイズされた商用ソフトウェアが最終的にビジネスプロセスの障害になる危険性をよく理解しています。私が関わったプロジェクトのほとんどは、当初はカスタマイズせずにそのまま使用するという約束で始まりました。
しかし、実際にはそうはなりませんでした。常に大規模なカスタマイズとカスタムコードが必要となり、最終的に組織の足かせとなっていました。これらの組織は、製品やコモディティプロセスの領域ではカスタマイズを行わず、ソフトウェアで定義された既存のプロセスに従います。そして、このアプローチこそが、これらの組織が成功している理由なのです。
リーダーシップの役割と予算配分の重要性
重要な要因の1つは、コスト効率の良いクラウドインフラを活用することで、従来型の組織とは異なる投資・予算構造を持っているということです。従来型の組織では、組織予算の最大部分（55%から80%）がProductsやUtilitiesに配分され、イノベーションやカスタムソリューションの構築に使える予算はわずかしか残りません。 Digital native bankのような組織は異なる予算構造を持ち、Genesis、イノベーション、カスタムビルドソリューションにより多くの予算を確保できます。また、過度の効率化も変革を妨げる要因となります。 効率性は確かに重要ですが、それが主目的になってしまうと、効果的でも迅速でもなくなってしまいます。
ここで疑問が生じます：あなたの組織はスピードと効率性のどちらを重視しているでしょうか？実際のところ、 Amazonを含むほとんどの組織は、その両方に取り組む必要があります。コスト効率を追求しながら、同時にスピードも確保しなければなりません。ProductsやUtilitiesの領域では、コストを最適化し、コスト効率を高め、バリエーションを減らすことを目指します。私たちのフルフィルメントセンターやデータセンターを考えてみてください - これらはSix Sigmaのプロセスです。一方、カスタムビルドソリューションやイノベーションを目指す領域では、組織はスピードを最適化する必要があり、それは素早く実験と反復を行うための学習コストを削減することを意味します。
このため、組織が異なる働き方や運営モデルを持つことは、完全に受け入れられ、むしろ必要なことなのです。UtilitiesやProductsの領域では、より多くのSix Sigma的な考え方を適用したいと考え、Genesisやカスタムビルドソリューションの領域では、Agileな働き方を適用したいと考えます。私がAmazonに入社したとき、ソフトウェア開発プロセスがどのように定義されているのか興味がありました。実際には単一のプロセスは存在せず、チームはScrum、Kanban、Prince2、そして各チームのニーズに合わせて自ら開発した57以上もの方法論を使用しています。
組織で適用できる24種類の異なる働き方があります。Genesisとイノベーションの領域では、より開拓者的なアプローチとなります。開拓者たちが人々の生活の糧を見つけようと西部開拓時代に冒険した様子を思い浮かべてください。彼らの後に続いたのが、 谷に定住して生活を営もうとした入植者たちでした。彼らが成功すると、町づくりの人々が現れ、最終的には、 学校や消防署、オペラハウス、映画館のある都市を計画し始めました。
このため、組織内で異なるソーシングモデルを持つことも可能です。ProductsやUtilitiesの領域では、バリエーションが少ないため要件をより明確に定義できることから、アウトソースや調達ソリューションをより多くのサプライヤーと共に使用することが認められます。一方、Genesisやカスタムビルドソリューションの領域では、ビジネス上の課題や顧客ニーズ、技術を真に理解し、組織の目的に共感する社内の知見を活用したいと考えます。
モデルのソーシング以外にも、多くの組織で「マネジメント」が「リーダーシップ」よりも優先されている状況が見受けられます。これはどういう意味でしょうか？ 今日のリーダーたちの予算と時間の使い方を見てみると、予算の大部分は既存の業務運営に費やされ、イノベーションにはごくわずかしか使われていません。リーダーの時間の使い方も同様です。ほとんどの時間が日常的な業務運営に費やされ、人材の採用・確保・育成にはあまり時間が割かれていません。組織全体と協力して戦略を立て、その実行を推進することにも、十分な時間が使われていないのです。
しかし、これからは変革を遂げた組織では、リーダーは時間の使い方を変える必要があります。予算は、既存の業務運営には少なめに、そしてイノベーションにより多くを配分すべきです。リーダーの時間の使い方についても同じことが言えます。リーダーとして、業務の詳細を理解し、顧客ニーズやプロセスの実際の問題点を把握して組織を発展させることは必要です。しかし、より多くの時間を人材の確保・育成・維持に充て、戦略の推進と実行に注力すべきなのです。
組織文化と人材マネジメントの新しいアプローチ
リーダーのチーム、つまりリーダーシップチームについて、私たちは2つのパターンを観察してきました。これは、あるリーダーたちのチームの例です。彼らは1週間のオフサイトミーティングで、顧客中心主義になるという新しい目標を掲げました。これは異なる部門や機能を担当するリーダーたちでした。オフサイトから戻ってきた後、実際に起こったのは、それぞれが自分の部門のニーズに合わせてメッセージを解釈し、チームに伝えたことです。あるリーダーはコスト削減が必要だと言い、次のリーダーは新製品を開発すべきだと言い、また別のリーダーは販売製品数を減らすべきだと言い、さらに別のリーダーは店舗数を増やすべきだと、完全に矛盾する方針を示したのです。
このため私たちは、単なるリーダーの集まりではなく、真のリーダーシップチームを持つことを推奨しています。そこでは、ミッション、目標、成功、失敗を共有し、時には同じオフィススペースも共有します。私がAutoScout24にいた時は、CTOとして Product VPと同じオフィスを共有していました。では、リーダーシップは何をするのでしょうか？まずはミッションを定義することから始まります。これは私がAIを使って作成した人工的なミッションです：「私たちはグローバルなシナジーを活用してデータ駆動型の組織となり、オムニチャネルの競合他社では真似のできない世界クラスの顧客中心主義を実現します」。多くの企業のミッションがこのような調子で書かれていますが、これは本当に方向性と明確さを提供しているでしょうか？そうではありません。
これはAmazonのミッションで、「地球上で最も顧客中心主義の企業になる」というものです。そして、これはAmazonの顧客が日々実感していることです。私たちは本当に顧客ニーズから逆算して、顧客の課題解決に取り組んでいます。また重要なのは、リーダーが原則を定義することです。組織で実現したい文化や行動を表す原則です。そして、これらの原則と行動が、多くの企業にとって組織の接着剤となっていると私たちは考えています。
いくつか例を挙げてみましょう。「私たちは、お客様や見込み客との関係において、オープンに、正直に、誠実に、誠意を持って接するべきだと信じています」。これは Enron のリーダーシップ原則の1つでした。Enron のことを覚えている人はいますか？彼らは明らかにこの原則に従っていませんでした。「従業員を大切にする」「お客様から選ばれる企業を目指す」「法の範囲内で事業を行う」といった原則が必要な組織は、深刻な問題を抱えているのです。このような原則を掲げる組織を見ると、まるで幼稚園で学んだ10のルールを思い出します。
例えば、「みんなで分け合いましょう」「人を叩いてはいけません」「誰かを傷つけたら謝りましょう」「使ったものは元の場所に戻しましょう」「自分の後片付けをしましょう」「食事の前に手を洗いましょう」といった具合です。私が AutoScout24 で経験した例をいくつか紹介します。
私たちがオンプレミスのデータセンターにある Oracle データベースと Microsoft テクノロジーを使用したモノリスから、Scala を使用したマイクロサービスへと移行した時のことです。後で議論できる唯一の後悔する決断でしたが、アーキテクチャと真の「You build it, you run it」体制を整えました。原則の1つは実際に「You build it, you run it」でした。つまり、プロダクト開発チームが自分たちのプロダクトの設計、構築、運用、保守に責任を持つということです。本番環境とお客様からの素早いフィードバックが、継続的な改善を支援してくれます。
また、「Be bold（大胆であれ）」という原則もありました。ソフトウェア開発者は早期に本番環境にデプロイし、テストよりもモニタリングを重視すべきだと考えました。「Monitoring is the new testing（モニタリングが新しいテスト）」と言っていました。素早く失敗し、回復して学んでください。そして、私たちは Mean Time Between Failures（障害間平均時間）ではなく、Mean Time To Recover（平均復旧時間）の最適化を目指しました。これは組織の全員に対して、何を最適化し、何を最適化しないのかを明確に示す原則でした。
また、セキュリティ、コンプライアンス、データプライバシーが重要だと宣言しました。速く構築することは大切ですが、最小権限の原則とデータプライバシーを念頭に置いて構築し、脅威モデルを理解してください。失敗した場合は、影響範囲を制限してください。私たちにとって、AWS ファーストという原則も重要でした。既存のテクノロジースタックを廃止し、イノベーションにリソースと労力を投入したかったのです。そのため、自前で構築したソリューションや、自前でホストするオープンソース、他のマネージドサービスよりも、AWS のサービスを優先して使用することを決めました。
リーダーは組織内にガードレールとメカニズムも定義します。残念ながら、多くのメカニズムとガードレールは官僚主義につながってしまいます。私たちは、組織はシンプルであるべきだと考えています。これは今朝 Werner が詳しく説明したミッションでもあります。先週の自分の組織の官僚主義指数を計算することができます。先週を振り返って、顧客価値を生み出さない作業と組織内の他の人を待つ時間の合計を、全作業時間で割ってみてください。
私たちが今でも目にするのは、組織がスキルを重視して採用を行い、態度を重視していないということです。実際には、態度とスキルの両方で採用すべきだと私は考えています。リーダーは採用のたびに文化的な基準を引き上げる必要があります - 態度の面でより良い組織になっていく必要があるのです。本当に採用したいのは、好奇心旺盛な人、毎日「わぁ、これって面白いな」と言うような人です。学び続ける人を採用したいのです。なぜなら、テクノロジーは変化し、働き方も変化し、顧客の期待も変化していくからです。そして現在、保育園にいる子供たちの65%は、まだ存在していない職業に就くことになるのです。
残念ながら採用に関して、採用する組織の希望と、新入社員の希望は大きく異なることが多いのです。組織は通常、市場価格以下の給与を提示し、控えめなボーナスを用意し、株式は提供しません。彼らは明日の仕事ではなく、今日の業務に必要な特定のスキルを求めます。マネージャーとの文化的フィットを重視し、新入社員は確実に指示に従うべきで、タスクに対して柔軟であるべきだと考えます。しかし新入社員として新しい組織に参加することを考えると、異なる願望があります。市場最高レベルの給与を期待し、学びたいと思い、優れたテクノロジーとツールを期待します。私の観点からすると、これは非常に重要な側面です - デジタル人材を惹きつけたいのであれば、適切なアーキテクチャとテクノロジーを整備する必要があります。人々は当事者意識を持ちたいと考え、成果と企業の目的に触発されたいと思っています。これはAdrian Cockcroftの言葉です。彼はNetflixの元CTOで、AmazonのVPも務めました。今年のre:Inventで彼に会い、このような講演を行い、Netflixの
働き方、特にNetflixが大規模なマイクロサービスアーキテクチャをどのように構築しているかについて共有してくれました。彼らの素晴らしい文化について話していた時、Fortune 100のあるCTOが講演後にこう言いました。「でも私たちはNetflixをコピーできません。あなたたちにはスーパースターエンジニアがいるけど、私たちにはそういう人材がいないから」彼の答えは？「はい、確かに私たちにはそういう人材がいます。でも彼らはあなたたちの会社から採用したんです。そして私たちは彼らの邪魔をしないようにしているだけです」なぜなら、多くの場合、人材が問題なのではなく、環境と文化が問題なのです。だからこそモチベーションがとても重要なのです。
今日がSilent Discoでなければ、このセッションで皆さんにこの質問をして、皆さんの答えを聞いてみたいところです。最近、あるカンファレンスでモチベーションが最も高まる時はいつかと尋ねたところ、「金曜の午後」という答えが返ってきました。これは残念なことです。私は、人々のモチベーションが最も高いのは、新しい組織に入る前日か初日だと考えています。彼らは大きな期待を抱き、高いモチベーションを持ち、新しい会社、新しい目的、新しい仕事を楽しみにしています。だからこそ、ある経営理論では「人々を本当に動機づけることはできない - ただ意欲を削ぐことができるだけだ」と言っています。リーダーとして、常にこれらの人々の障害や意欲を削ぐ要因を取り除くよう努めるべきです。
トランスフォーメーションの実践と注意点
人材の定着に関して、組織と従業員の間にはニーズと願望の違いがあります。組織は人々に現在の役割に留まってほしいと望み、指示に従い、昇給を求めず、マネージャーだけが話すパフォーマンス評価に満足し、週末に自分の時間でスキルアップすることを望みます。一方、従業員の願望は異なります - キャリアパスと昇進の明確さを期待し、素晴らしいことに取り組む自律性を求め、市場水準の給与を望み、評価の公平性を求め、成長できる継続的な学習環境を期待しています。
モチベーションに関して1冊だけ本を推薦するとすれば、Daniel Pinkの本です。彼によると、従業員のモチベーションを高めるには、自律性（行動の自由）、熟達（誰もが自分の達成したことや能力を誇りに思いたい）、そして目的が必要だと言っています。熟達と人材の定着に関して言えば、組織の全員にキャリアプランを用意することが重要です。Amazonでは、Individual ContributorのTechnical Trackには、Senior VPやDistinguished Engineerまでのキャリアパスが用意されています。今日のKeynoteでは、S3のVPとDistinguished Engineerが登壇しましたが、これはManagement Trackと同じレベルです。多くの組織では、Technical Trackはレベル6か7で終わってしまい、それ以上の昇進の可能性がないことを私は知っています。
トランスフォーメーションの後期段階では、ほとんどの組織がサプライヤーと協力して仕事を進めます。これは良いことです。私の組織では、ソフトウェア開発者の70%は社内、30%は社外とし、特に製品やユーティリティを活用できる分野で外部リソースを活用することにしました。しかし、トランスフォーメーションが進むにつれて、異なるニーズが出てきます。成果を出すことを求めるようになるのです。サプライヤーに期待することは、Co-loで働き、アジャイルで実験的なマインドセットを持っていることです。自動化によるコスト削減を支援してくれることを望み、高度なスキルを持った複合的な技術専門家を期待します。当然、時間ではなく結果に対して支払いをしたいと考え、リスクも共有したいと思います。しかし、従来型のサプライヤーは自社の収益を最適化することに注力します。予測可能で文書化された要件を求め、利益率を維持したがり、混在したスキルセットを提供し、時間単位での支払いに関心があり、リスクを共有したがりません。
この業界で長年の実績を持つ優れたAWSパートナーは多く、その多くが自己変革を遂げています。それでも、従来型ではない優れたコンサルティング会社やパートナーも多く存在します。素晴らしい組織は数多く存在するのです。
トランスフォーメーションの journey を進める上で、重要なDoとDon'tがいくつかあります。他社の組織構造をそのままコピーしてはいけません。2014年にSpotifyモデルは組織の様々な側面を構築する上で素晴らしい指針を提供しましたが、それに触発されるべきであってコピーすべきではありません。過度な計画を立てたり、変化のペースを過大評価したりしてはいけません。ビジョンに関しては頑固に、詳細に関しては柔軟であるべきです。物事は常に予想とは異なる形で進むものです。
単に役割やプロセスの名前を変えるだけではいけません。新しい役割を作るだけの問題ではありません。組織の特定の側面を単にリブランディングすることはできません。採用した新しい働き方の背後にある原則をしっかりと理解し、その新しい働き方を一貫して実践することが重要です。抵抗を無視せず、チェンジマネジメントに力を入れましょう。
人々に時間を与え、彼らの不安を理解し、人材に投資し、心理的安全性を確保してください。そして最後に、変革を委任してはいけません。日常業務は委任しても構いませんが、変革は委任しないでください。あなた自身が変革をリードし、成果を推進し、その変革の一部となる必要があります。
ご清聴ありがとうございました。さらにご質問がございましたら、LinkedInでお気軽にご連絡ください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion