re:Invent 2023: AWSのエキスパートが語るクラウドソリューションアーキテクトへの道
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - What is the path to becoming a cloud solutions architect? (ARC211)
この動画では、AWSのSolutions ArchitectureマネージャーであるNomin BatsaikhanとPrincipal Solutions ArchitectのJohn Walkerが、Solutions Architectになるための道筋を解説します。4つの典型的なペルソナや、必要なテクニカルスキル、ビジネススキル、ソフトスキルについて具体的に語ります。また、AWS Skill BuilderやSolutions Libraryなど、すぐに活用できるツールも紹介。Solutions Architectを目指す人や、組織でこの役割を構築したい人にとって、貴重な洞察が得られる内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Solutions Architectの世界へようこそ
みなさん、こんにちは。AWSや自社で Solutions Architect を目指している方はいらっしゃいますか？おめでとうございます。まさに適切なセッションに来られました。すでに Solutions Architect の方はいらっしゃいますか？はい、何人かいらっしゃいますね。ようこそ。自社で Solutions Architect の実践を構築している方はいらっしゃいますか？おめでとうございます。あなたも適切なセッションに来られました。
私は Nomin Batsaikhan と申します。AWSの Solutions Architecture のマネージャーをしています。本日は同僚の John Walker を招いています。彼はAWSの Principal Solutions Architect です。Johnは皆さんが今まさに踏み出そうとしている、あるいはすでに踏み出している道のりを歩んできました。そこで、彼の話と経験を共有してもらうようお願いしました。John、お願いします。
John Walkerのアーキテクト経験：失敗から学ぶ
ありがとう、Nomin。この数年間、あなたと一緒に仕事をして多くのことを学びました。あなたには素晴らしい経験がたくさんありますね。ここでは、私自身が若手アーキテクトだった頃の経験を少し共有したいと思います。Solutions Architecture の仕事に惚れ込んだ最初の出会いは、実は問題から始まりました。AWSに入社する前、フラッグシップ製品にパフォーマンスの問題があり、さまざまなデータソースを取り込む必要がありました。顧客から苦情が来始めていたので、私は会社のオーナーに「これを書き直させてください」と言いました。これが私の最初の間違いでした。
2つ目の間違いは、このソフトウェアシステムの中核部分を書き直すのに100万ドルのプロジェクトで9ヶ月かかると見積もったことでした。私は仕事に取り掛かり、そしてアーキテクトの仕事に夢中になりました。設計、デザインパターンの考案、問題解決、顧客が直面していた問題を回避する新しい方法の開発など、すべてが楽しかったのです。しかし、同時に起こっていたのは、顧客が既存のアーキテクチャを使い続け、それが変化していたということです。
新しいソリューションを設計し、書き直しを試みる中で学んだレッスンを、私はサポートチームにフィードバックしていました。現在使われているアーキテクチャが製品1号となり、私の製品は2号となりました。結果として、顧客は既存の製品に満足し、私の製品はキャンセルされてしまいました。これは、アーキテクトやアーキテクチャが失敗する一つの例です。しかし、完全な失敗ではなかったと思います。なぜなら、私はクビにならず、後にこの会社のChief Architectに昇進したからです。その後、この製品を一連の進化的な変更を経て、Software as a Service アプリケーションアーキテクチャへと移行させました。
これが私のAWS内でのソリューションアーキテクトとしての専門分野です。3年前にAWSに移り、それがソリューションアーキテクトになる道でした。しかし、いくつかのことを学びました。アーキテクチャは生きたシステムであり、進化します。それらはそのアーキテクチャを使用し、その中で生活する人々のためのものです。Nomin、今日はソリューションアーキテクトの道筋で何を学ぶのでしょうか？
Solutions Architectの定義と役割
はい、始める前に、その素晴らしい回復力と謙虚さの物語をありがとうございます。 今日は、ソリューションアーキテクトとは誰で、何をするのか、このロールへの異なる道筋は何か、このロールで成功するために必要なスキルは何か、そして最後に、あなたがどの段階にいても始められるツールをお伝えします。
では、ソリューションアーキテクチャとは何で、ソリューションアーキテクトとは誰なのでしょうか？The Open Group Architecture Frameworkはアーキテクチャを「コンポーネントの構造、それらの相互関係、そしてそれらの設計と時間の経過に伴う進化を支配する原則とガイドライン」と定義しています。この定義はISO、IEEE、IECに基づいていますが、テクノロジーに関するお気に入りの情報源を参照すると、異なる定義が得られるでしょう。しかし、その定義はおそらくこの定義の3つの異なる部分を包含しているはずです。では、見てみましょう。
最初の部分、コンポーネントの構造。これは、各コンポーネントが役割と責任を持ち、全体を作るには正しい組み立てが必要であることを意味します。それらの相互関係。これは、各コンポーネントが他のコンポーネントとの関係の網を持ち、直接的な依存関係があるかもしれないし、ないかもしれないことを意味します。そして最後の部分、それらの設計と時間の経過に伴う進化を支配する原則とガイドライン。これは、変化が予想され、進化が期待され、基本的な信念システムが必要であることを意味します。
この基本的な信念システムに基づいて、今日以降の選択がなされます。しかし、これはアーキテクチャ一般の話です。私たちはここでソリューションアーキテクトについて話すつもりです。結局のところ、それが私たちが約束したことですからね。
Cloud Solutions Architectの具体的な仕事内容
さて、solutions architectの定義に入りましょう。まずは基本的な定義から始めます。これは私にとって非常に重要なポイントです。先ほど、アーキテクチャの進化について話しましたが、今度はsolutions architectとは何かについて話しましょう。ここでは特に、cloud solutions architectについて話します。これは、あなたの会社でAWSを扱うcloud solutions architectかもしれませんし、AWSを扱わない人かもしれません。あるいは、AWS内のsolutions architectかもしれません。ここでの定義では、solutions architectとは、ビジネス上の問題を解決するための技術的アーキテクチャを設計し、指導する人のことを指します。先ほど、アーキテクチャについて、それが進化すべきものであり、コンポーネントを持ち、問題を解決できなければならないと話しました。問題はビジネスによって定義され、テクノロジーによって解決されます。そして、この2つを結びつけるのがsolutions architectの仕事なのです。
さて、定義を済ませ、基礎を固めたところで、Nominさん、solutions architectは実際に何をするのでしょうか？
Solutions Architectは「キッチンの料理長」
おや、今何時ですか？ 3時6分ですね。もしかしたら、皆さんの頭の中はすでに夕食か、このセッション後の午後のおやつのことでいっぱいかもしれませんね。少しお付き合いください。もし私が「この料理を作ったのは誰ですか？」と尋ねたら、あなたの答えはおそらく「キッチン全体がこの料理を作りました」となるでしょう。でも、「この料理を考案したのは誰ですか？」と尋ねたら、あなたの答えは何になるでしょうか？それはchef de cuisine、つまり料理長であるはずです。
Solutions architectは自分のキッチンの料理長です。もう一度言いますが、Solutions architectは自分のキッチンの料理長なのです。では、説明させていただきましょう。料理長とは、ビジネスニーズやお客様のニーズを受け取り、最初のプルーフオブコンセプトを作る人物です。彼らは豊富な料理経験を活かし、ビジョンを描き、実験し、料理を創造します。料理長は、ソース、ガーニッシュ、ベース、フォーカルポイントなどの構成要素の構造を定義し、さらに味、食感、温度、盛り付けなどを通じて、それらの相互関係を定義する人物です。
そして料理長は、キッチンの他の専門シェフ全員にその料理全体を説明します。専門シェフたちは、技術を磨く人たちです。彼らは個々の構成要素を高めていきます。これらすべてを、料理長が提示した元のビジョンと基本システムに忠実に従いながら行うのです。そしてもちろん最後に、料理長は料理の準備を監督します。料理から料理へ、サービスからサービスへと。
実際にキッチンで働いた経験がある方や、数多くの料理番組のファンの方なら、料理長の仕事がこれだけではないことをご存知でしょう。彼らは仕入れ業者、サプライヤー、ワインペアリングの専門家、経営陣、衛生規制当局などとも協力します。つまり、料理長はキッチンチームと協力して料理を提供します。Solutions architectは、技術チームと協力して、独立した単独の価値を持つソリューション、製品、コンポーネントを提供します。だからこそ、Solutions architectは本当に自分のキッチンの料理長なのです。
Solutions Architectが組織にもたらす価値
ジョン、私たちはしばらく料理長について話してきましたが、キッチンに料理長が必要な理由は明らかですね。では、なぜ企業にSolutions architectの役割を果たす人が本当に必要なのでしょうか？
素晴らしい質問ですね。正直、少しお腹が空いてきました。Solutions Architectの役割は、より速くビルドしデプロイすることを可能にすることです。アーキテクトは、アーキテクチャのどの部分がシステムのデプロイメントを遅くする原因になるかを考える必要があります。プロダクションへのリリースを速めれば速めるほど、システムの品質が実際に向上するという統計があります。つまり、より速くビルドしデプロイすることで、より頻繁に、より迅速に実験を行い、新しいことを試し、より頻繁に価値をプロダクションにリリースすることができるのです。
次に、リスクを軽減し、緩和します。新しい実験を試したり、プルーフオブコンセプトを行ったりして、アーキテクチャに組み込む前にコンセプトが機能するかどうかを確認することは、Solutions Architectの主要な責任の一つです。アーキテクチャをSolutions Architectの中核的な責任に組み込むことは不可欠です。
これらすべての学びを取り入れて、十分な情報に基づいた決定を下すことができます。そうすることで、ビジネスチームと技術チームは、先ほどの例の専門シェフたちのように、その情報を活用して非常に優れた実行を行うことができるのです。
最後に、ベストプラクティスを学び、教える必要があります。AWSでは、AWS Well-Architected Frameworkに基づいたアーキテクチャのベストプラクティスがあります。このフレームワークは6つの柱で構成されており、ホワイトペーパーと、何千もの顧客との協業から得たAWSのベストプラクティスに照らしてアーキテクチャを評価するためのツールが用意されています。
Solutions Architectのコミュニケーション戦略
では、solutions architectがさまざまなステークホルダーとどのようにコミュニケーションを取るかについて見ていきましょう。Nominさん、このコミュニケーションプロセスについて詳しく説明していただけますか？
「もちろんです。data architects、network architects、security architects、皆さんは画面上に表示されています。 software engineersとdevelopersの皆さん、すでにエディタを開いているのが見えますね。DevOps engineers、testers、そしてmanagementの皆さんも画面に描かれています。 business leadersとproduct managementの皆さんは、会議室に表示されています。では、この会議室と右側のすべての技術者たちをつなぐのは誰でしょうか？ それがsolutions architectです。
solutions architectはコミュニケーションの要として機能しますが、その役割は単なる橋渡し以上のものです。会議室からの情報を技術者に単に繰り返したり増幅したりするのではありません。むしろ、ビジネスニーズを理解し、技術的なアーキテクチャを作り上げます。そして、その技術的なアーキテクチャと関連するビジネスの詳細を、これらすべての技術者に伝えるのです。
solutions architectは、なぜ気にかけるべきか、何を気にかけるべきか、そしてどのように対処するかを説明します。「なぜ」については技術者間で似通っているかもしれませんが、「何を」と「どのように」は異なる可能性が高いです。したがって、solutions architectは各受け手に合わせてメッセージをカスタマイズし、それぞれの特定の言語や方言で話す必要があります。
逆に、ソリューションアーキテクトは全ての技術的な決定や課題を取締役会に伝えるわけではありません。これらをビジネスリスクや能力に変換し、取締役会に効果的に伝えるのです。
Solutions Architectの組織内での位置づけと役割
John、この説明は、顧客対応や、ビジネス上の問題を個々の専門家向けの技術用語に翻訳する経験と共鳴します。機会があれば、Gregor Hohpeのセッションに参加することを強くお勧めします。彼は「The Software Architect Elevator」の著者で、ここAWSで働いています。優れたソリューションアーキテクトが取締役会からエンジンルームまで効果的にコミュニケーションを取る方法について議論しています。
では、アーキテクトがプロジェクト内でどのように働くかについて話しましょう。Nomin、青、黄、ピンクのチーム、そして左側のオレンジ色のアーキテクトチームの組織構造について説明できますか？アプローチには複数の方法がありますが、私はアーキテクトがプロジェクトチーム内で組織される際に最もよく遭遇する2つの構造に焦点を当てます。
企業がプロジェクトの問題に対処するためにソリューションアーキテクトを初めて導入する場合、通常は複数の進行中のプロジェクトがあります。彼らは、たとえその正確な肩書きがまだなくても、ソリューションアーキテクトの役割を果たす1人を導入するかもしれません。多くの場合、この人物は共有リソースとして共有され、これは始めるには非常に効率的です。これらのアーキテクチャは、プロジェクト間で一貫性を持つ傾向があります。なぜなら、同じチーム内で働く同じアーキテクトのグループが複数のプロジェクト間で共有されるからです。
これはかなり効率的ですが、そうでなくなる時が来ます。プロジェクトを追加するほどコンテキストスイッチングが発生するからです。規模の問題が積み重なり始めます。そして、これらのチームの1つでアーキテクトとしての時間の60〜80％を費やしている場合、アーキテクトを配置する異なる組織構造について考え始める時かもしれません。
アーキテクトが単一のアーキテクチャグループに所属している場合、時として「象牙の塔のアーキテクト」という弊害に陥ることがあります。「象牙の塔のアーキテクト」という言葉を聞いたことがある人はいますか？誰もこのような立場になりたくはないでしょう。そこで、この問題の解決策をお教えしましょう。アーキテクトとして、自分が下した決定の結果に責任を持つことが大切です。つまり、アーキテクトはプロジェクトの実装に何らかの形で関わる必要があります。それが最小限のサービスを構築するための概念実証であっても、ライブラリに新しいデザインパターンを作成することであっても、詳細に踏み込んで自分の決定の結果を実感する必要があります。
しかし、これだけが方法ではありません。Nominさん、右側の組織構造について少し説明してください。「はい、右側の組織構造は通常、スケールアップの答えとなります。この「通常」という言葉を使いましたが、このモデルでは、solutions architectが直接、製品開発チームに組み込まれています。これらのチームは、独立した価値を持つ製品やコンポーネントの開発に集中しています。このモデルでは一般的に、一貫性のあるアーキテクチャが見られます。つまり、マイクロサービスへの移行や、強力なインターフェース、APIドリブンのインターフェースなどです。
このような開発チームは、ローカルな決定を下すことができます。どのライブラリを使用するか、どのフレームワークやプラットフォームを採用するかなど、ローカルな決定が可能です。リスクやトレードオフに関してもローカルな決定ができるため、開発速度が大幅に向上します。先ほどJohnが言ったように、solutions architectを置く理由の一つは、より速くビルドしてデプロイすることです。つまり、solutions architectはこれらのチーム内で高速な意思決定を促進する役割を果たしています。
もちろん、このモデルにも良くない面があります。それは、チーム外での連携が増えることです。他のチームが既に構築したものを再利用したり、発見したりすることは自然には起こりにくいのです。そのため、このモデルでは、ドキュメンテーション、発見、再利用に関する強力な規律が絶対に必要です。さて、solutions architectがどのように、誰とコミュニケーションを取るか、組織構造の中でどこに位置するか、そしてsolutions architectが技術的なアーキテクチャを作成することについて話しました。でも、John、実際にどのようにそれを行うのでしょうか？」
Solutions Architectの具体的な業務プロセス
solutions architectureの仕事を行うには、実際にこれらのチームの中で働く必要があります。私がこのようなチームにいる時、具体的に何をするのか？それが次のトピックです。先ほどのコミュニケーション図を見ましたが、技術的なソリューションで解決したいビジネス上の問題を伝える人々は、自分たちが望むことを正確に伝えてきます。しかし、すべてが実現可能というわけではありません。一部は話し合いを重ね、一緒に達成したいビジョンを作り上げる必要があります。これが目標であり、達成しようとする輝かしい目標なのです。ただし、そのためには方向性について合意し、強力な技術的方向性を設定する必要があります。
次に、その方向性には、私がまだ知らないことが含まれているかもしれません。 例えば、日曜日にリリースされたばかりのRedshift MLを使ってLLMを組み込む方法をまだ知らないかもしれません。そこで、これを学ぶ必要があります。これは研究のスパイクです。イノベーションの方法を調べなければなりません。イノベーションスパイクを開始し、プルーフオブコンセプトを行います。技術的に答える必要のある質問をし、この作業を行うために新しい技術的能力を習得します。すでに持っている能力もあります。例えば、SQL serverデータベースの使い方をすでに知っているかもしれません。クラウドでReserved Instancesを使ってそれらを使用する方法をすでに知っているかもしれません。Webデザインやウェブサイト作成の方法をすでに知っているかもしれません。
しかし、最終的に作り出すものは、私たちの能力セットの組み合わせであり、デザインを生み出します。デザイン作業はとても楽しいものです。大きな問題を取り上げ、それらを構成要素に分解します。これは分解と呼ばれ、個々の問題を解決します。そして、それらの解決策を再結合します。これは再構成と呼ばれます。これらのアーキテクチャをどのように選んで再結合するかが、最終的なデザインになります。しかし、そのデザインはアーキテクチャの全体像ではありません。
アーキテクチャは生きたシステムです。その生きたシステムは、あなたのデザインと実装されるシステムアーキテクチャの組み合わせになります。これは、実際に稼働し、人々が使用し、作成し、運用し、その結果と共に生きているdev system、test system、production systemです。ちなみに、これはアーキテクトにとって、プロジェクト内でチームと一緒に何かを作り、構築する素晴らしい機会です。手を汚し、袖をまくり上げて、少し作業をすることで、その一部を体験できます。
そして、設計したアーキテクチャが成功したかどうかをどのように知ることができるでしょうか？測定しない限り、わかりません。そのため、設計に、アーキテクチャに、検査の方法を組み込む必要があります。KPIを設定しましょう。ログがCloudWatchに出力されるメトリクスを作成するようにしてください。それらをダッシュボードにまとめます。どのようなメトリクスを気にする必要がありますか？ビジネス問題を解決しようとしていることについて気にする必要があります。そのため、ビジネス問題の解決を試みているKPI（主要業績評価指標）を示すダッシュボードを作成します。
すべてをつなぎ合わせましょう。人々が実際に作成したシステムからビジネス価値を得ているかどうかを見ることができる素晴らしいデザインを作成し、自分の決定の結果の一部を体験し、人々が創造を始め、この継続的なサイクルのループを閉じることができます。そして、測定によってシステムを検査した後、私たちの仕事は完了です。ここまで、ソリューションアーキテクトの定義について話し、基礎を築きました。それが自分のキッチンのヘッドシェフのようなものであることについて話しました。コミュニケーションの方法と組織構造について話し、そして今、プロジェクト内でその仕事が実際にどのように行われるかについて話しました。
Solutions Architectへの4つの道筋
では次に、本題であるソリューションアーキテクトになるための道筋について話を進めていきましょう。ソリューションアーキテクトへの道筋について話す中で、主に4つのパターンを取り上げますが、これらがすべてではありません。私が顧客やAWS、その他の場所で出会ってきたアーキテクトの数だけ、ソリューションアーキテクトになるまでの物語や道筋があります。ここでは4つの典型的なパターンだけを取り上げることにします。Nomin、始めてくれますか？
はい。これから4つのタイプについて説明していきますが、ソリューションアーキテクトを目指す皆さんは、自分がこのペルソナに当てはまるか、あるいはこれらのペルソナの要素をそれぞれ少しずつ持ち合わせているか、自問してみてください。 ここにいるソリューションアーキテクチャの実践を構築しようとしている幹部や指導者の方々も、どのようなソリューションアーキテクトを組織に迎え入れるべきか、考えてみてください。では、最初のペルソナである「発明家SA」について説明します。
発明家SAの原点について話してみましょう。これらの人々は、私たちAWSの起源と同じように、ガレージでの試行錯誤から始まることがあります。研究や実験室での作業に取り組むこともあるでしょう。キャリアの初期段階では、スタートアップやインキュベーター、大学などで活動を始めるかもしれません。そして、私自身がアーキテクチャに初めて触れたように、彼らもアーキテクチャの仕事に成長していく責任を担うことになります。彼らは試行錯誤を重ね、実験室に入り込み、そこから大きなエネルギーを得ます。しかし、発明家SAの超能力は、実際に既存のものを超えて、まだ存在しないものを生み出すことです。今日のre:Inventでは、そういった話をたくさん聞くことができるでしょう。Nomin、これらの発明家SAを現場で見かけたときに、どのように見分けられるでしょうか？
そうですね、発明家SAは、並外れた好奇心を持っています。彼らは、夢のようなアイデアであれ、シンプルなアイデアであれ、その中間のものであれ、アイデアを持っています。そして、そのアイデアを頭の中から現実世界に、実在するもの、具体的なものとして生み出したいという強い欲求を持っています。
これらの発明家SAたちが頭の中で考え、手を動かして生み出した発明品を最もよく見られる場所は、Builder Fairです。この会場にいる皆さん全員に、VenetianのExpo Hallで開催されているBuilder Fairをぜひチェックしていただきたいと思います。そこに発明家SAの姿があります。
次のSAタイプは、entrepreneur SAです。これらの人々は、おそらくビジネスの subject matter expert としてキャリアをスタートさせました。ビジネス学位を持っているかもしれません。subject matter expert またはビジネス開発のエキスパートとして、彼らは主題を正しく理解するためにより深い詳細に入り込んでいきます。これらの人々は、ソリューションが達成できる不可能なスケールを夢見ることからエネルギーを得ています。entrepreneur SAは確信と活力を持ってコミュニケーションを取ります。彼らは他の人々にビジョンを見せる人たちです。entrepreneur SAの最良の例は、infrastructure as a serviceです。これは2000年代初頭のコンセプトで、AWSのソリューションとなりました。これがentrepreneur SAの核心的なマインドセットです。
私は、現場でこれらのentrepreneur SAに出会うのが大好きです。私は、solutions architectとして中小企業のお客様を担当していますが、これらの人々に会うと、通常はオーナー兼創業者タイプか、素晴らしいアイデアを思いついた人々です。彼らにとって、それは頭の中に固着していて、必ず創造されなければならないものです。それが実現するまで、彼らは本当に休むことができません。以前、inventor SAについて聞きましたが、彼らは今まで存在しなかった全く新しいものを作り出します。entrepreneur SAはそれを取り上げ、確実に誰もがそれを手にできるようにし、そこに到達するまで止まりません。entrepreneur SAは、より大きな詳細とスケーラビリティの問題を解決し、その発明を実際に大衆に届ける方法を見つけなければなりません。
composer SAについては、彼らはコンピューティングやエンジニアリングの背景、つまり起源のストーリーを持っています。彼らは時にdeveloperやエンジニアタイプとしてキャリアをスタートさせます。セッションが始まる前に、会場の何人かと話をしましたが、皆さんの中にはすでにこのようなモードにいる人もいます。developerやエンジニアタイプで、キャリアの次のステップについて考えている方々です。これを理解するのに適した場所にいることを保証したいと思います。アーキテクチャのパズルを解くことに取り組むにつれて、これがcomposer SAにエネルギーを与えるものとなります。パズルに取り組み、それを展開し、すべてのピースがどこに配置されるかを理解することです。これらの人々がもたらすスーパーパワーは、アイデアを取り上げて再現可能にすること、デザインを取り上げてパターンを導き出すこと、誰もが使えるライブラリやAPIを作ること、つまり誰もが再現可能で、スケーラブルで、使用可能なものを作ることです。
composer SAは通常、「それはどのように機能するのか？」という質問をし、そして「そう、でもそれはどのように機能するのか？」と質問します。これらの人々は、システムがどのように組み立てられ、なぜそのように機能するのかを見るために、フードの下を覗き込みます。composer SAにとって、この会場の多くの皆さんにとって、世界全体が発見し、展開し、再パッケージ化し、再利用するための美しいパターンで作られています。AWS Solutions Libraryには、すでに1300以上のソリューションが公開されています。composer SAの一部は、これらのソリューションの作者です。ぜひAWS Solutions Libraryをチェックしてみてください。
最後のペルソナはadvocate SAです。advocate SAの起源は情報システムにあります。おそらく人文科学や教養学の基礎を持っています。彼らの入り口は顧客と直接接する役割です。つまり、sales、marketing、QAなどで、顧客が最初に仕事を完了するために必要としていたものを顧客から直接聞くことができます。
アドボケイトSAは、エレガントなシステムとエレガントなソリューションについて考えることからエネルギーを得ます。そこでは、顧客がそのアーキテクチャとソリューションの中心にいます。これらのアドボケイトSAの超能力は、非常に高い基準を持っていることです。彼らは、顧客にとって使いやすいエレガントで単純なソリューションが見つかるまで決して止まりません。
アドボケイトSAは、「ユーザーはどのように動作してほしいと思うだろうか？」「なぜまだそのように動作しないのか？」と問いかけます。私は、アドボケイトSAがビジネス上の問題と技術的なソリューションの間のデザインギャップを埋めるために働いているのをよく目にします。多くのSAはこのような原点から始まり、使用され、生活の中で活用される必要のあるデザインから完璧なものを作り上げようと本当に努力しています。AWSのウェブサイトにある顧客成功事例をいくつか見てみると、顧客がアーキテクチャによってどのようにサービスを受けたか、そしてそれらの成功事例がどのようなものかを深く掘り下げることができます。そこで、アドボケイトSAのプロフィールを認識できるかもしれません。
Solutions Architectに必要なスキルセット
私たちは4つの異なるパスについて話してきました。これらは単なるアーキタイプであり、ここで質問したいと思います。ここにいる方々の中で、これらのパスの1つ、これらのタイプの1つに自分を見出す人はいますか？ 良いですね、多くの手が挙がっているのが見えます。今や皆さんは何を探すべきかわかりました。そして、ソリューションアーキテクチャへのこの道を選んだ理由は異なっていても、同じ目的地、同じ役割、同じ仕事を遂行することになります。次に私たちが取り上げたいのは、ソリューションアーキテクトになるという役割を果たすために、今日のre:Inventから持ち帰ることができるスキルとツールのいくつかです。
まず最初に取り上げるのは、3つのうちの1つ目、テクニカルスキルです。その後、ビジネススキル、そしてソフトスキルに進みます。テクニカルスキル：学び、構築し、教える。これが基本です。ソリューションアーキテクトとして必要なのは、学び方を学ぶことです。まず自分自身に教えることです。ブログ記事を通じて、カンファレンスでの講演を聞きに行って、ビデオを見て、ポッドキャストを聴いて、読書をする、あるいは実際にワークショップやラボに手を動かして参加するなど、どんな方法でも構いません。自分のために、まず自分自身に教え、時間を優先的に使って確実に学ぶようにしてください。
なぜなら、医師や弁護士の実践と同様に、その場で仕事をすることで上達するのではありません。問題解決に直面する前に、この仕事の仕方を自分自身に教えることで上達するのです。そして、その多くの作業は自分自身に教えることです。次に2つ目は：構築することです。象牙の塔のアーキテクトにはなりたくありません。だから袖をまくり上げて、ワークショップに参加したり、概念実証（POC）に取り組んだりしましょう。最小限の実行可能な製品（MVP）や最小限の実行可能なサービス（MVS）を作成しに行きましょう。実際に構築してみてください。
あなたが作り出すもの、デザインするもの、他の人に依頼するものの各層の下には、非常に魅力的な複雑さが存在します。頭シェフの比喩のように、料理を人に出す前に、他の人に作ってもらう前に、そしてそれを拡大する前に、自分で味見をする必要があります。次は教えることです。今、私たちはステージ上で教えていますが、100人や何百人もの聴衆に話す必要はありません。ホワイトボードにデザインを描くなど、個別の方法で教えることができます。
一人でやらないでください。一緒にデザインし、一緒に教える必要があります。ブログ記事を書いたり、概念実証やサンプルを作ったりしてください。知識を共有することを忘れずに。比喩的に言えば、すべての料理を自分で盛り付けることはできません。一緒に働くチーム全体が必要で、あなたのアーキテクチャビジョンのコンセプトをそのチームに教える必要があります。そして、そのビジョンを実現するために実際に実行する他の人々の頭の中に、それを確実に入れ込む必要があります。
学び、構築し、教える。
Solutions architectsは、ビジネススキルを絶対に持つ必要があります。実際、あなたはエグゼクティブペルソナなのです。頭シェフは、自分のビジネスがどのように利益を上げているか、ターゲット顧客は誰か、メニューに何があるか、何がないか、季節性が収益にどう影響するかを知る必要があります。同様に、Solutions architectは自分のビジネスがどのように利益を上げているかを知る必要があります。Solutions architectとして、顧客は誰か、製品は何か、顧客がどのように製品を消費するか、ビジネス内外の制約は何か、製品や業界を規制する法律や規制は何かを知る必要があります。これらはすべて、技術的なアーキテクチャを提供するためにSolutions architectとして知っておく必要があることです。
ヘッドシェフは、キッチン、ウェイトスタッフ、マネジメントの組織構造を熟知しています。同様に、Solutions Architectは自社の組織構造を把握する必要があります。Johnが先ほど述べたように、Solutions Architectを置く主な理由の1つは速度を上げることです。Solutions Architectは、組織構造を効率的かつ効果的に把握できて初めて、障害を取り除き、リスクを軽減するなどして、それを実現できるのです。
最後に、企業財務です。ヘッドシェフはキッチンの財務状況を知る必要があります。固定費、売上原価、そしてヘッドシェフとして持つ権限を把握しなければなりません。同様に、Solutions Architectはソフトウェアやハードウェアの購入が収益にどう影響するかを知る必要があります。クラウドコンピューティングの従量課金モデルが収益にどう影響するかも理解しなければなりません。これらは、ここ40分間話してきた技術アーキテクチャを実現するために、Solutions Architectとして知っておくべきことのほんの一例です。つまり、ビジネススキルにおいて、Solutions Architectはエグゼクティブなのです。
これは非常に理にかなっていますね。Nominさん、詳しく説明していただきありがとうございます。企業財務を理解し、それをCost and Usage Reportなどを使って設計に反映させることは、どのサービス、機能、システム、環境が最もコストがかかっているかを知り、その情報をビジネス側の人々に彼らの望む言葉で伝えるのに役立ちます。また、データベースアーキテクトに対して、なぜあるデータベースを別のものより選ぶ必要があるかを説明するのにも役立ちます。これらのビジネススキルは不可欠です。
Solutions Architectに求められるソフトスキル
最後に、ソフトスキルについて触れたいと思います。好奇心は「なぜ」という問いにつながります。「なぜを5回繰り返す」という古い言い回しがあります。システムがどのように組み立てられているかについて、飽くなき好奇心を持ちましょう。Solutions Libraryにアクセスして、他のアーキテクトが作成した他のアーキテクチャを見て学んでください。これは先ほど話した技術スキルの学習と同じです。しかし、特定のクラウドソリューションの設計に取り組む際には、「なぜ」を問いかけてください。技術者にも、ビジネス側の人々にも「なぜ」を問いかけてください。
次は勇気です。行き詰まりを打開するには勇気が必要です。これが行き詰まりを打開する秘訣です。完璧な情報を得ることはありません。アーキテクチャやビジネス上の制約、現在または将来存在する可能性のあるテクノロジーについて完璧な情報を集めるまで待っていたら、何も生み出せません。だから、今すぐ行動を起こすのに十分な情報があると言える勇気を持ちましょう。地面に杭を打ち、決断を下し、前に進みましょう。
次は信念です。Stanford大学の教授であるPaul Saffoは、アーキテクトやテクノロジストは「強い意見を緩やかに保持する」べきだと言っています。これは信念を持つ必要があるということです。
良いものが現れたとき、常に学び続けているあなたは注意を払っているので、それを認識し、機会を活かし、アーキテクチャに組み込むことができます。変更が必要なタイミングを知りましょう。最初にアーキテクチャを設計してそのまま放置し、勢いに任せるのではありません。そうではありません。あなたは常に関与し、信念がアーキテクチャの進化を導くようにしなければなりません。
4番目はコミュニケーションです。コミュニケーションは話すだけでなく、書くことやデザインすることも含みます。コミュニケーション方法を発展させる際には、文章で明確に伝わり、口頭でも明確に伝わり、デザインやデザインドキュメントでも明確に伝わるようにしましょう。そして、専門家が理解できる言葉で伝える必要があります。コミュニケーション方法を使って組織をまとめていきましょう。
最後に、アーキテクチャは人々が使うためのものです。この教訓を今日お伝えしたいと思います。アーキテクチャを毎日使う人々に思いやりを持ちましょう。それは彼らにどのような影響を与えるでしょうか？ユーザーが仕事で毎日あなたのアプリケーションを使わなければならないとき、どうなるでしょうか？どのような摩擦点がありますか？美しく、使いやすく、エレガントなデザインを作りますか？それとも、静かに仕事をこなし、邪魔にならないデザインを作りますか？これらは私が好む最も美しいデザインアプローチの2つです。
Solutions Architectを目指す人へのリソースとアドバイス
次に、持ち帰るツールを用意したいと思います。re:Inventには持ち帰りが付き物ですので、カメラの準備をしてください。ここにいくつかQRコードがありますので、写真を撮って持ち帰ってください。最初は「学ぶ」です。AWS Skill Builderには500以上のコースと学習パスが16の言語で用意されています。ぜひ学んでください。自分のニーズに合わせたキュレーションされた学習パスを選び、自分のペースで学ぶか、必要なときに学んでください。そして、その学びを強化し、認定を取得して学びを検証してください。
この会場にいる全ての Solutions Architect 志望の方は、ぜひ Solutions Architect Associate 認定を取得してください。もしすでにしばらく経験がある方は、Solutions Architect Professional 試験に挑戦してください。もちろん、両方持っている方は、機械学習やセキュリティ、ネットワーキングなどの専門認定に挑戦してみてください。今週、ここにいる間に認定を取得する予定の方はいますか？何人かの方がいるのを聞きました。はい、認定を検討している方が何人かいるようですね。
次は「学ぶ」でした。次は「構築する」ですね。Solutions Libraryを使ってください。1,300以上のソリューションがあります。これらをすぐにデプロイできます。他の人のアーキテクチャを研究することができ、これによってアーキテクトとしてのスキルを強化するのに役立ちます。そして、ベストプラクティスを活用してください。AWSは AWS Well-Architected ホワイトペーパーと AWS Well-Architected ツールを提供しています。設計を作成するとき、あるいは既存のものを評価するとき（正直に言って、私たちは皆、少し混乱した状況に直面したことがありますよね）、これらのツールが整理するのに役立ちます。
AWS Well-Architected ツールは、クラウド上で成功裏に構築してきた何千もの AWS カスタマーから得られたベストプラクティスをガイドしてくれます。3つ目は「教える」です。知識を閉じ込めておいても何の意味もありません。ぜひ、あなたの知恵を共有してください。知恵を共有する最も簡単な方法は、AWS re:Post で質問に答えることです。すでに回答がある質問でも、最初の回答が必ずしも正解とは限りません。あなたの別の回答を投稿してください。あなたの知恵を共有してください。
Heroについてですが、すべてのヒーローにはオリジンストーリーがあります。今日、Solutions Architect になるまでの道のりについて、少しオリジンストーリーの話をしました。AWS Heroは、教えることに情熱を持つコミュニティの熱心な専門家であり、私たちはそういった人々を認識しています。あなたもAWS Heroになることができます。しかし、何が起こるかに関わらず、あなたは自身がHeroになるために必要なことを学びました。おそらく、これがあなたのオリジンストーリーなのかもしれません。
皆さん一人一人に、今日ここで学んだレッスンの一部を持ち帰り、自分が目指すソリューションアーキテクトになるため、あるいは組織内でこの役割を構築するために、これらのツールやスキル、そして今日学んだ構造やコミュニケーションの方法を活用していただきたいと思います。そして、皆さん一人一人にお願いがあります。モバイルアプリケーションでアンケートにご回答いただけると、私にとってとても大きな意味があります。本当にありがたく思います。私とNominと過ごしていただいた時間に心から感謝いたします。Nomin、最後に何か一言ありますか？
re:Inventに来て、インスピレーションを受けていただき、ありがとうございます。JohnとNominはすぐそこにいますので、お話したい方はぜひお越しください。皆さん、ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion