re:Invent 2024: AWSが語るSolutions Architectの役割とスキル
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Navigating the journey to becoming a cloud solutions architect (ARC211)
この動画では、AWSのSolutions Architecture部門のManagerを務めるNomin BatsaikhanとVikas Guptaが、Solutions Architectの役割と必要なスキルについて解説しています。Solutions Architectはビジネスニーズを解決するためにアーキテクチャのビジョンを作り、技術コンポーネントとその相互関係を定義する存在で、Working Backwardsという手法を用いて顧客中心のソリューションを生み出します。Solutions Architectには発明家型、起業家型、作曲家型、提唱者型の4つのペルソナがあり、技術スキル、ビジネススキル、ソフトスキルという3つの要素をバランスよく持つ必要があります。AWS Skill Builder、Solutions Library、Well-Architected Toolなどを活用することで、Solutions Architectとしての学習と実践を始めることができます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Solutions Architectの役割と本セッションの概要
おはようございます。今朝は皆様お早い時間からお越しいただき、ありがとうございます。このセッションはサイレントセッションで、同時中継も行っていますが、今朝は皆様の参加が必要です。そこで、会場の皆様にお聞きしたいのですが：Solutions Architectを目指している方はいらっしゃいますか？素晴らしい、多くの手が挙がり、うなずいている方も多いですね。おめでとうございます。まさに適切なセッションにお越しいただきました。では、Solutions Architectを採用したい方はいらっしゃいますか？あちらで1名手が挙がりましたね。ようこそ。このセッションは貴方にもぴったりです。では、現役のSolutions Architectの方はいらっしゃいますか？何名か手が挙がりましたね。ようこそ。
私の名前はNomin Batsaikhanです。Amazon Web ServicesのSolutions Architecture部門のManagerを務めています。マネージャーの仕事以外では、美食家、というかフードファナティックと言えるかもしれません。高級レストランから穴場の店まで、あらゆる種類のレストランで食事をすることが大好きです。本日は大西洋の向こう側から来た私の仲間を紹介します。はい、まさに向こう側からです。皆様、おはようございます。私はVikas Guptaと申します。Nominさんありがとうございます。私もイギリスを拠点とするAWSのSolutions Architecture部門のManagerです。少し自己紹介させていただきますと、約25年前にコーディングを学び始めた頃、私はコードをフロッピーディスクに保存していました。皆様もご使用されたことがあると思いますが、最近ではもう見かけなくなりました。技術の進化とともに、CDやUSBメモリを使用するようになり、現在はクラウドを使用しています。私のデータにとって、クラウドの方がより信頼性が高く、安全だと考えているからです。
本日はクラウドソリューションアーキテクチャについてお話しさせていただきます。始めてよろしいでしょうか？ありがとうございます。では、これから1時間をどのように過ごすかについてお話しします。Solutions Architectとは何か、そして彼らは何をするのか？Solutions Architectとしてどのようなペルソナを体現する必要があるのか？Solutions Architectとして成功するために必要なスキルは何か？そして最後に、皆様がどの段階にいらっしゃっても始められるツールをご紹介させていただきます。
アーキテクチャの定義とSolutions Architectの重要性
では、Solutions Architectureとは何か、 そしてSolutions Architectとは誰なのでしょうか？その前に、まずArchitectureについて考えてみましょう。TOGAFでは、Architectureを「コンポーネントの構造、それらの相互関係、そして設計と時間の経過に伴う進化を支配する原則とガイドライン」と定義しています。この定義はISO/IEC/IEEEに基づいています。お気に入りのテクノロジー情報源で調べると、異なる定義が得られるかもしれませんが、おそらくその定義もこの3つの部分の本質を捉えているはずです。
最初の部分は、コンポーネントの構造です。これは、各コンポーネントが役割 と責任を持ち、全体を形成するために正しい組み立てが必要であることを意味します。2番目の部分である相互関係とは、各コンポーネントが他のコンポーネントと関係の網を持ち、直接的な依存関係があるかもしれないし、ないかもしれないということです。 そして最後の部分、設計と時間の経過に伴う進化を支配する原則とガイドラインとは、変化が予想され期待されており、今日以降の意思決定の基礎となる信念体系が必要であることを意味します。
これはアーキテクチャの話ですが、今日は Solutions Architect について話していきましょう。Solutions Architect とは一体どのような存在なのでしょうか？私と Vikas は、Solutions Architect とは、ビジネスニーズを解決するために、アーキテクチャのビジョンを作り、技術コンポーネントとその相互関係を定義する人だと考えています。少し長い説明になりましたが、最も基本的なレベルで見ると、 Solutions Architect とはビジネスニーズを解決する人なのです。営利・非営利を問わず、組織にはミッションを前進させるチャンスと、それを妨げるリスクが存在します。Solutions Architect であるあなたは、そのようなチャンスとリスクの両方に対処し、目指すべき最終状態への解決策を提供します。では、その目的を達成するための手段は何でしょうか？まず第一に、アーキテクチャビジョンの創造です。アーキテクチャビジョンは、インスピレーションを与え、かつ意欲的なものでなければなりません。理想的な状況下で、技術的なソリューションがどのようにビジネスニーズを解決するかを示すものです。
アーキテクチャビジョンには、セキュリティ、ガバナンス、信頼性、パフォーマンスなどの技術的な品質に関する意思決定の要素が含まれることがあります。目的達成のための第二の手段は、技術コンポーネントの定義です。Solutions Architect として、この定義は、コンピューティング、ストレージ、ネットワーキングといった高レベルで抽象的なものから、住所標準化サービスや税金計算サービスといったビジネスサービスの具体的な定義まで可能です。さらには、使用するプログラミング言語やライブラリの選定といった細かいレベルまで及ぶこともあります。そして、Solutions Architect であるあなたがこれらをどのように組み合わせるかが、目的達成のための手段を完成させる方法となります。
ビジネス成長におけるSolutions Architectの役割とWorking Backwards
ここまで定義について話してきましたが、定義を示すことと、この役割の微妙な違いや複雑さを真に理解することは、まったく異なります。では具体的に、Solutions Architect は何をするのでしょうか？そして最も重要なのは、なぜビジネスに Solutions Architect が必要なのでしょうか？ありがとう、Nomin。今共有してくれた Solutions Architect の定義は素晴らしいですね。Solutions Architect の役割の「なぜ」と「何」について話す前に、ビジネスが求めているものについて考えてみましょう。
どんな組織やビジネスにとっても、最も重要な目標は何でしょうか？ それはビジネスの成長です。ビジネスを成長させるためには、明確な目標を設定する必要があります。ビジネス目標を設定する際は、組織を特定の方向に成長させるというコミットメントを実現することが重要です。ビジネス目標とは、組織が達成したい測定可能なターゲットのことです。ビジネスは収益を上げ、顧客を維持し、新しい市場に進出し、顧客満足度を向上させたいと考えています。ビジネスの成長を可能にする技術やフレームワークについて、適切な判断を下すためにアーキテクトやテクノロジストが必要なのです。
理解を深めていきましょう。組織が Solutions Architect を必要とする理由は、変革に関する作成、調整、そして十分な情報に基づいた意思決定を行うためです。 プラットフォーム、データインフラストラクチャ、アプリケーションに関する適切な判断を必要とする技術的な変革もあれば、 業務効率を向上させコストを削減するために、ビジネスオペレーションを最適化、デジタル化、自動化するプロセス変革もあります。また、リスクを低減または軽減するためにも Solutions Architect が必要です。 Solutions Architect はアーキテクチャを深く理解し、リスクを把握し、それらのリスクがビジネスに影響を及ぼす前に解決策を見出します。
最後に、Solutions Architectは技術とすべてのコンセプトを学び、それを広めていきます。 彼らは最高のエバンジェリストです。なぜなら、自分たちのプラクティスやベストプラクティスがどのように重要で、それをプロダクトチームやビジネスに教えることで、どのように他者に利益をもたらすことができるかを理解しているからです。では、Solutions Architectはどのようにしてそれを実現するのでしょうか？Amazonで私たちが使用している手法についてお話ししましょう。 それは「Working Backwards」と呼ばれています。Working Backwardsは、顧客を喜ばせるためのAmazonの発明の仕組みです。これにより、私たちは顧客obsessedであり続けることができます。私たちは、製品やサービス、体験が顧客の手に届く瞬間から逆算して考えます。
Working Backwardsがどのように機能するのか理解しましょう。Working Backwardsには5つのステージがあり、各ステージでは特定の質問をし、一連の推奨事項を導き出します。 まず「Listen」ステージから始まります。このステージでは、顧客を理解することが重要です。顧客が誰で、彼らについて何を知っているのかを把握します。私たちは顧客と対話し、インタビューを行い、エピソードを集め、データを分析します。Working Backwardsを始める前に、まず顧客を知ることが重要なのです。
次に「Define」ステージに入ります。 このステージでは、顧客の問題に焦点を当てます。最も顕著な顧客機会は何でしょうか？Listenステージで分析したデータから、顧客が解決を望んでいる最も重要な問題を特定するのに役立つトレンドが明らかになります。その後、「Invent」ステージに入ります。これはソリューションを見つけ、なぜそのソリューションが他の選択肢より優れているのかを判断するステージです。発明は、ソリューションに焦点を当てながら、さまざまなことを試し、実験することを含むため、混沌としたプロセスになることがあります。
その後、「Refine」ステージに入ります。これはエンドツーエンドのビジネスと顧客体験を理解するステージです。 ソリューションにどのようなフィードバックの仕組みを組み込んでいるか、スポンサーに対してROIを提供できているかを評価する必要があります。そして、「Test and Iterate」では、製品を顧客に見せ、早期フィードバックを得て、素早く失敗し、提供したい製品を改善し続けます。このWorking Backwardsの仕組みは、小規模か大規模か、社内か社外かを問わず、あらゆるタイプの顧客に対して機能します。Working Backwardsは顧客に最高の体験を提供することであり、Minimum Lovable Productに焦点を当てています。時にはMinimum Viable Productだけでは、顧客との長期的な関係には不十分です。例えば、私はMinimum Viable Aircraftには乗りたくありません。リスクが高すぎるからです。
Solutions Architectの具体的な業務と必要なスキル
Solutions Architectがなぜ必要なのかについて話してきましたが、次は彼らが何をするのかについて説明しましょう。Nominはこのセッションの冒頭でSolutions Architectの役割について素晴らしい定義を示してくれましたので、それについて掘り下げていきましょう。Solutions Architectには3つの重要な特性があります：技術力、ビジネスの洞察力、そして強力なアドバイザリースキルです。 彼らはビジネス目標を理解し、それをアーキテクチャに変換します。まずWorking Backwardsの仕組みを通じて特定されたビジネス上の課題と機会を理解し、それらをArchitecture Visionと呼ばれる技術的な方向性に変換します。そのVisionは、アーキテクチャの長期的な未来と、時間の経過とともに顧客ニーズをどのように満たしていくかについてのものです。
その後、Solutions Architectは設計を実現するために必要な技術的能力を確立します。チームとしてすでに持っている能力もあれば、まだ持っていない能力もあるでしょう。新しい能力は、イノベーションスパイク、リサーチ、その他のプロセスの形で獲得します。これらの能力を手に入れたら、設計の構築を開始します。大きな問題を解決する際には、まずそれを小さな部分に分解することを考えます。例えば、パズルを解くときは、まず要素を正しい領域に分類してから、それぞれを適切な場所にはめ込んでいきます。これを分解（デコンポジション）と呼びます。小さな領域ができたら、それぞれの問題に対する解決策がどのように機能するかを理解し、再構成（リコンポジション）を通じて統合していきます。
システムを使用する度にそのシステムで生活することになるお客様のことを常に考えてください。Solutions Architectとして、プロダクトチームや開発チームと協力しながら構築部分を推進します。あなたの仕事はアーキテクチャだけではなく、実際に製品を提供するためにビルドチームと協働することです。最後に、正しい方向に進んでいることを確認するための検査を行います。これには反復、フィードバックの収集、アーキテクチャの改善が含まれます。 皆さんの中で、定期的にアーキテクチャの検査を行っている方は何人いらっしゃいますか？素晴らしいですね。多くの手が挙がりました。通常、これは一度きりの作業ではなく、反復的なプロセスとライフサイクルなのです。
まず、アーキテクチャやシステムにおける問題点である改善目標を特定することから始めます。例えば、アーキテクチャやワークロードのパフォーマンス、セキュリティ、信頼性、コスト効率、持続可能性などです。アプリケーションの日常的な運用において、主な問題点が何であるかが分かるため、まずそれらの問題を特定する必要があります。
そして、アーキテクトとして、それらの改善領域を評価し、優先順位付けを行います。シンプルな論理として、その問題を解決しなかった場合に発生する可能性のある障害やインシデントのコストについて、自分自身とビジネスチームに質問する必要があります。これにより、どの問題が最も深刻であるかを特定し、最初に取り組むべき改善の優先順位を示すバックログを作成することができます。ビルドチームやプロダクトチームと協力して、ソリューションのテスト、構築、検証を行います。最も重要なのは、設計にメトリクスとテレメトリを組み込むことです。これにより、成功度を理解し、スポンサーがこのアーキテクチャ検査に費やした努力に対して適切な投資リターンを得ているかどうかを把握することができます。
AWSには、AWS Well-Architected Frameworkというツールがあります。 このツールには6つのピラーがありますが、これらの6つのピラーに関して「Well-Architectedですか？」という同じ質問をすると、異なる回答が得られるかもしれません。システム設計時に行うトレードオフは優先順位に基づいており、それぞれの人や組織によって優先順位が異なる可能性があるため、人によって答えが異なるかもしれません。しかし、ベストプラクティスは同じです。このフレームワークは、何千ものお客様とともに働き、アーキテクチャの構築を支援してきた経験から定義された、アーキテクチャのベストプラクティスを理解することに焦点を当てています。
Solutions Architectの4つのペルソナ
これまでSolutions Architectの役割の「なぜ」と「何」についてお話ししてきました。では次に、異なるペルソナについて話し合ってみましょう。 Solutions Architectureへの道筋は様々ですが、そのポジションに到達すると、Solutions Architectとして異なるペルソナを体現しなければなりません。単にそれらを体現するだけでなく、真に受け入れる必要があります。なぜなら、真に受け入れることで、ひとつではなく多くのスーパーヒーローになれるからです。私たちはAWSや顧客企業で何百人ものSolutions Architectと働く機会がありました。今日は、最も一般的に見られる4つのペルソナについてご紹介したいと思います。
まず最初に、発明家型のSolutions Architectです。この人たちは組織のビジョンに対して深い信念を持っており、遠い未来に生きています。なぜなら、彼らにとって遠い未来はそれほど遠くないからです。発明家型SAは、自分たちの手で新しいものを生み出せるという考えから大きなエネルギーを得ています。彼らは新しい体験、新しい働き方、新しい生き方を発明します。まだニーズが明確に表現されていなくても、AWS LambdaやAmazon Kindleのような発明こそが必要とされていたものだったのです。会場やシミュルキャストでご覧の皆様には、Expo Hallのビルダーフェアに足を運んでいただき、これらの発明家型SAによる素晴らしい発明品をぜひご覧いただきたいと思います。
次は起業家型SAです。 彼らは組織のミッションに対して深い信念を持っており、それが指針となっています。彼らは今日と明日に生きており、起業家型SAは不可能を可能にするというアイデアから大きなエネルギーを得ています。彼らはその課題を専門的にも個人的にも捉えます。起業家型SAは、ミッションが終わっても立ち止まりません。彼らは自発的に、スポットライトや注目を求めることなく、オープンソース化やブログ、ポッドキャスト、re:Inventのような大会での講演を通じて、自分たちの学びを直接のチームや組織を超えて共有します。
次は作曲家型SAです。 作曲家型SAは「これはどのように機能するのか？」という質問をし、さらに「本当のところ、どのように機能するのか？」と掘り下げます。彼らはシステムの内部を覗き込み、どのように組み立てられているのか、なぜそのように機能するのかを理解しようとする人々です。作曲家型SAは混沌とした世界から秩序を見出します。彼らはほとんどの技術的問題が新しいものではないことを知っているため、複雑なタスクを分解することが得意です。作曲家型SAにとって、答えは既存のパターンを発見し、再パッケージ化し、再構成し、再利用することにあります。
そして最後に提唱者型SAです。提唱者型SAは、システムのユーザーに共感する人です。彼らはシステムをサポートしなければならない技術者たちや、システムの内外でプロセスをサポートしなければならない担当者たちに共感します。彼らはシンプルさ、効率性、効果を推進する人々です。
さて、今朝はずっと手を挙げていただいていましたが、もう一度お願いします。これらのペルソナの中で自分に当てはまるものがあった方は手を挙げてください。2つ以上当てはまる方はそのまま手を挙げていてください。3つは？4つは？素晴らしいですね。1つでも、それ以上でも、あるいはすべてのペルソナに当てはまると感じた方がいらっしゃいましたが、すべてのスーパーヒーローにはスーパーヒーローのスキルが必要です。そこで、次はそれについてお話ししたいと思います。
Solutions Architectに必要な3つのスキルセットと学習ツール
これは三角形です。これは緑の三角形、大きな三角形、小さな三角形、画面の中央に配置された三角形と言えるでしょう。しかし、この三角形の特徴的な点は、これが正三角形であることです。つまり、各角度が60度で、すべての辺の長さが等しいのです。2022年、コメディアンで作家のLilly Singhは「Be a Triangle」という本を出版しました。Lillyはこの本の中で、人生で成功するためには三角形、特に正三角形になる必要があると述べています。なぜなら、正三角形は強固な基盤を持っているからです。この三角形を軸で回転させても、どの辺が底辺になっても、その強固な基盤は変わりません。
Solutions Architectとして、テクニカルスキル、ビジネススキル、そしてソフトスキルが必要です。注目すべき点は、どの辺も、つまりどのスキルも、他のスキルより重要でも、重要でなくもないということです。2019年、David Epsteinは「Range: Why Generalists Triumph in a Specialized World」という本を出版し、New York Times のベストセラーリストで1位になりました。Wall Street JournalやNational Public Radioを含む多くのメディアがこの本を高く評価しました。実際、Forbesはこれを「今年最も重要なビジネス書であり子育ての本」と評しました。著者のProfessor Adam Grantは、「専門化にますます執着する世界において、スター科学ライターのDavid Epsteinは、未来はジェネラリストのものかもしれないと私たちに確信させてくれる」と述べています。
この本の中で、David Epsteinは2つのことを明確にしています。1つ目は、音楽、スポーツ、医学、テクノロジーなどの分野での早期専門化が、必ずしもその職業のより優れた習熟につながるわけではないということです。2つ目は、ジャーナリストが医学分野で素晴らしい発見をし、医学における最も素晴らしい発見の一部が、まったく異なる研究分野の研究者によってなされたということです。これらはすべて意図的な発見でした。最高のアスリートやミュージシャンたちは、専門化する前、あるいは全く専門化せずに、様々な楽器や異なるスポーツを幅広く試していました。
これは典型的な職業経験で、私自身のものかもしれませんし、皆さんのものかもしれません。エントリーレベルのエンジニアとしてスタートし、経験を積んでミッドレベルのエンジニアになり、さらに経験を積んでシニアエンジニアやリードエンジニアになっていきます。この直線的な進歩は、私たちが子供の頃や若い頃、あるいは現在でも、社会から期待されるように条件付けられてきたものです。「上に進む」という絶え間ないプレッシャーがあります。私たちは皆「キャリアの進歩」という言葉を知っていますが、もしキャリアの進歩とキャリアの遊び場を組み合わせたらどうでしょうか？
幅広くサンプリングするとどうなるでしょうか？異なる役割を持ち、遊び場の子供のように新しいスキルを学び、様々な役割を経験し、新しい友達を作り、そして最も重要なことは、それを楽しみながら行うことができたらどうでしょうか？私たちが自分の役割や会社を変える特権を持っていないかもしれないことは理解していますし、それは問題ありません。 幅広くサンプリングするもう一つの方法は、ビジネスの異なる部分に関わることです。例えば、組織のDevOpsムーブメント、コストムーブメント、あるいはSecurityムーブメントをリードすることができるかもしれません。
左側の経験を持っているにせよ、右側の経験を持っているにせよ、あなたは自分の実体験を持ち込んでいます。Amazonの有名な人物、Andy Jassyが言ったように、「経験に対する圧縮アルゴリズムは存在しない」のです。あなたの経験こそが、技術的に恐れることなく、必要な専門知識を獲得し、これまでのものとそこから得られる教訓を理解し、そしてアーキテクチャのビジョンを保ちながら柔軟性を持つことを可能にします。12月のレビュー時期と来年の目標設定の時期にあたり、皆さんに自己反省をし、リーダーとキャリアについての対話、成長についての対話をスケジュールし、異なる技術領域や分野における教育、経験、そして知見をどのように得ていくかを考えることを推奨したいと思います。
これは正三角形の最初の辺である技術スキル、技術の幅についてでした。次のスキルまたは辺はビジネススキルです。これを説明している間、私は自分の過去のキャリアについて考えていました。ビジネススキルに関して、誰もが自分のビジネスがどのようにして収益を上げているのか、自分の製品は何か、顧客は誰か、競合他社は誰か、製品提供を制限または可能にする法律やフレームワークは何か、そして内部または外部の制約は何かを理解する必要があります。製品提供を可能にするこれらの内部または外部の制約とは何でしょうか。
Solutions Architectは、組織構造上でシステムをアーキテクトする際にこれらのポイントが重要となるため、これらの要素をすべて知っている必要があります。Solutions Architectは、組織構造を理解する必要があります。なぜなら、その複雑さを通り抜けて賛同を得て、障害を予測し、事前に緩和することが重要だからです。Solutions Architectが必要な主な理由の一つは速度であり、そのため彼らはこれらの障害を取り除き、組織構造を通り抜ける方法を理解する必要があります。
コスト組織について、Solutions Architectはハードウェアやソフトウェアの購入が収益にどのような影響を与えるかを理解する必要があります。クラウドコンピューティングのPay-as-you-goモデルが収益にどのように影響するか、労働コストが収益にどのように影響するかを考慮しなければなりません。これらのポイントはすべて、長期的に運用されるシステムについて考える際のアーキテクチャに影響を与えます。これがビジネススキルについての説明でした。
三角形の最後の部分である、ソフトスキルについてお話ししましょう。ソフトスキルについては、5つのCを考えていただきたいと思います。最初のCはPlayer-Coachで、これには3つの要素があります。1つ目の要素は「学ぶ」ことです。Solutions Architectは、動画、ブログ、チュートリアル、GitHubリポジトリ、さらにはシステム構成を読むことを通じて、ソリューションを進化させるために必要な概念を学びます。医学や法律の分野と同様に、アーキテクチャの仕事にも日々の実践がありますが、医師や弁護士以上に、Solutions Architectは現在のトレンドや今後の展開について、徹底的な再学習に多くの時間を費やします。AWS re:Inventは、将来の発展について学ぶ絶好の場です。
2つ目の要素は「構築」です。皆さんはBuilderであり、どんな技術でも理解するためには、その複雑さの深部まで手を入れることが重要です。キャリア初期の技術者には、どんなソリューションの複雑さを理解するためにも、まず構築することから始めることを強くお勧めします。素早く失敗し、実験し、より早く学ぶのです。一人で構築するだけでなく、プロダクトチームと共に構築し、ビルドチームのパートナーとなって、それらの構築がどのように機能するかを理解し、設計やパターンに変換し、顧客が必要とする重要なソリューションを生み出すプロセスを実行します。
3つ目の要素は「教える」ことです。知識を閉じ込めたままで共有されなければ、何の意味があるでしょうか？Solutions Architectは優れたエバンジェリストであり、自身が学習に使用したのと同じリソースを活用して他者を支援します。彼らはリソースを構築し、ブログ、動画、GitHubリポジトリ、その他の資料を作成して、学んだことを広めます。AWSでは、Solutions ArchitectがさまざまなImmersion Day、Game Day、ワークショップを実施して、サービスの使用方法や新しい概念を他者に教えています。 Solutions Architectとして、ネットワークアーキテクト、データアーキテクト、セキュリティアーキテクト、ソフトウェアエンジニア、開発者、DevOpsエンジニア、QAエンジニア、監査担当者、そして経営陣と効果的にコミュニケーションを取る必要があります。
Solutions Architectはこの輪の中心に位置し、これらの技術者全員に対して、何が重要で、なぜ重要なのかを伝える必要があります。これには、彼らが気にすべきことと、気にかけている課題をどのように解決するかが含まれます。なぜ気にすべきかという理由は、おそらくこれらの技術者全員にとって同じでしょう。しかし、何を気にすべきかは技術者によって異なる可能性が高く、気にかけている課題をどのように解決するかは間違いなく異なります。Solutions Architectとして、メッセージの受け手に合わせてコミュニケーションを調整する必要があります。
プロダクトオーナーやビジネス意思決定者に対して、取締役会の場で、Solutions Architectが技術者たちに全てのビジネス判断を繰り返さなかったように、取締役会に対してもメッセージを調整する必要があります。全ての技術的制約や技術的判断を繰り返すのではなく、それらをビジネス機能とビジネスリスクに変換して伝えることで、プロダクトオーナーや取締役会が十分な情報に基づいた意思決定を行えるようにします。
もちろん、これは技術カンファレンスでアーキテクチャトラックですから、このコミュニケーションはどのようなアーキテクチャパターンに似ているか考えてみましょう。Fan-outとFan-inが思い浮かんだのではないでしょうか。さて、ソフトスキルの2番目はコミュニケーション、3番目は好奇心です。私たち誰もが生まれながらに好奇心を持っていますが、それを伸ばすには練習が必要です。Working Backwardsの5つのステージについて先ほど話しましたが、各ステージで膨大な好奇心が必要となるため、職場での好奇心を育てる筋力を鍛える必要があります。
4番目は勇気です。勇気があれば行き詰まりから抜け出せます。キャリアの中で、決断できない人々、プロジェクト、組織に出会ったことは何度ありますか？そういった人々は情報が不足していたわけではありません。実際には、数ヶ月後、数年後、あるいは数十年後に間違いが判明するかもしれないという不安から、勇気が足りなかったのです。Amazonには「One-way doorなのか、Two-way doorなのか？」という言い回しがあります。ビジネスにおけるほとんどの決断は覆すことができます。状況が変われば引き返せることを知った上で、その扉を勇気を持って開けましょう。ビジネスではスピードが重要で、スピードには勇気が必要なのです。
そして最後は思いやりです。同情があり、共感があり、そして思いやりがあります。思いやりとは、同情や共感に応えて助けたいと思う気持ちと、実際に助ける行動のことです。Solutions Architectとして、あなたは多くの人々に対して様々な役割を担うことになります。Solutions Architectとしてのすべての仕事において、思いやりを持ち、それを実践してください。
まとめると、この正三角形の3つの辺は、幅広さと深さを持つ技術スキル、ビジネススキル（自社の収益構造を理解し、組織構造を効果的に活用でき、企業財務を理解していること）、そしてソフトスキルです。Player/Coachとなり、効果的かつ効率的にコミュニケーションを取り、そして大いなる好奇心、勇気、思いやりを発揮してください。
さて、これがre:InventでありAWSである以上、始めるためのツールを皆さんにお伝えせずには終われません。では、そのツールについて話しましょう。学習を始める最も簡単な方法は、AWS Skill Builderを利用することです。600以上の無料コースがあり、自分のペースで、必要なときに学習でき、体系的な学習パスを選ぶこともできます。
学習した後は何をすべきでしょうか？認定資格を取得して、その学びを確実なものにしましょう。先ほど、Solutions Architectを目指している方が多くいらっしゃいましたね。Solutions Architectを目指す方は全員、Solutions Architect Associate認定資格を取得すべきです。取得したら、LinkedInに投稿してVikasと私にタグ付けしてください。もしすでにある程度の経験をお持ちでしたら、Solutions Architect Professionalの認定を取得して、同様にタグ付けしてください。もちろん、両方の認定をお持ちの方は、Machine Learning、Networking、Securityなどのスペシャルティ認定に挑戦してみてください。
学習した後は何をするのか？私たちはBuilderなので、構築します。AWS Solutions Libraryには1,300以上のソリューションが用意されており、検証済みでデプロイを待っています。これが最高の学習方法です。これらのソリューションは何千ものお客様に利用されており、ぜひ皆さんも試してデプロイしてみることをお勧めします。LinkedInで私とNominにタグ付けして、成功事例を共有してください。もしAWS上でワークロードを実行している場合は、先ほどトレードオフやベストプラクティスについて話しましたが、AWS Well-Architected ToolとFrameworkについて学んでみてください。オンラインリソースやAWS Skill Builderポータルでトレーニングを見つけることができます。また、このFrameworkについて詳しく知りたい場合は、パートナーや担当のAWSアカウントチームにお問い合わせください。
構築した後は何をするのか？先ほど言ったように、宝物を鍵をかけて共有しないでおくのは良くないですよね。だから、私たちは教えます。教え始めるための最も簡単な方法は、AWS re:Postで仲間から投稿された質問に答えることです。ご存知の通り、質問に対する答えは1つではありません。ですから、2番目、3番目、4番目、そしてあらゆる代替案を提供してください。中には教えることを新しいレベルに引き上げる人もいます。AWS Heroesは、教えることで大きな影響を与えているAWSプラクティショナーの活気に満ちた世界的なコミュニティです。すべてのスーパーヒーローにはオリジンストーリーがあります - もしかしたら、これがあなたのストーリーになるかもしれません。ヒーローになってください。
先ほど私は大の食通、つまりフーディーだと言いましたが、食べ物やレストランのレビューを読んだり書いたりすることが私にとって本当に重要なんです。それでは、Vikasとともにみなさんに今日のセッションへのご参加に感謝申し上げます。この機会に、スマートフォンを取り出していただき、このセッションの感想をフィードバックとしてお寄せください。みなさん、ありがとうございました。セッションがお役に立てば幸いです。こちらがLinkedInのQRコードです。ぜひ私たちとつながりましょう。Nominが申し上げた通り、AWS Events appを通じてフィードバックをお願いします。お話したい方や質問がある方は、このセッション後に会場の外でお会いしましょう。ありがとうございました。素晴らしいre:Inventをお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion