Naomi さん ～ マイグレーション＆モダナイズ ソリューションアーキテクト
前職は外資ソフトウェアベンダーで、新卒からテクノロジーコンサルタントとして働いていました。ユーザー企業や SIer のお客様に対して、データベースやミドルウェア、ハードウェアアプライアンス、クラウドサービス等を利用する際のアセスメントや設計レビュー、パフォーマンス・チューニング、トラブル対応、スキルトランスファー、QA 対応等を有償で支援する仕事です。直近数年では、前職の会社が提供しているクラウドサービス （IaaS とデータベース関連の PaaS）の技術支援と、クラウドとは全く関係がないデータモデリングを両方担当していました。また、担当するお客様も自動車、保険、公共とインダストリーを限定せず幅広く対応していました。具体的には、お客様に対して数か月～ 1 年程度の有償支援のデリバリを担当していました。有償支援の契約後に担当者として引継ぎをして、お客様と提案内容の確認と進め方を決定し、定期的な打ち合わせや支援終了時の報告会の設定等を行い、2 ～ 3 人のチームで支援していました。オンプレミス環境のシステムをクラウドに移行するようなプロジェクトの場合、使用するクラウドサービスの選定を含む大まかな構成のみ決まった状態で引き継ぎ、方式設計の項目について勉強会を行い、設計中の QA に回答し、お客様やSIer 担当者が作成した設計書をレビューするような形で支援を進めることが多かったです。
2018 年にクラウドサービスの支援を始めた頃は、技術領域が幅広いので、キャッチアップがとても大変でした。ただ、もともとデータベースについても、新卒時代に文系出身だったこともあり、RDBMS のアーキテクチャはもちろん、OS やストレージも全くわからないところから勉強し始めた経験があったので、同じようにやるしかないと思って勉強しました。ネットワークは業務で関わりが少なくずっと苦手意識があったのですが、仮想ネットワークの設計をするために、「 IP アドレスとは何か」というところからやり直しました。こういった経験から、お客様に「クラウドはどうやって勉強すればいいか」と聞かれたときに、ゼロから勉強する方法をアドバイスすることができています。
大学は「政策科学部」という社会系の学部を専攻していました。「問題解決の学問」ということもあり、企業においてビジネスの問題を IT で解決するのが面白そうだと考え、システムエンジニアや IT コンサルタントを目指して就職活動を始めました。「 IT 」といっても幅広いので、その中で何をやりたいか調べていくにつれ、スクラッチのアプリケーションよりパッケージ、業務パッケージよりデータベース等のミドルウェアに興味を持ちました。結果、文系出身でもテクノロジー領域を任せてもらえる会社に就職しました。入社後はまず Linux の OS コマンドから躓き、自分の選択を若干後悔しつつ環境構築したのも今となってはいい思い出です。
技術についての勉強は、まず初心者向けの資料や本を読んで概要をつかみ、その後にマニュアルや詳しい技術本を読みながら、できる範囲で環境を作って動かしてみる形で進めることが多いです。ハンズオンを、意味が分からなくても、とりあえず進めてみることもあります。説明だけ読んで「なんとなくわかったつもり」になるより、あらゆるところに躓きながら動かしてみた方が、理解が深まると思います。「自分が躓いたところは、お客様も躓くはず」と思ってよく覚えておくようにしています。他には、IT 系のセミナーや勉強会、カンファレンス等に積極的に参加して、「みんなが何に困っているのか」「何が流行っているのか」を追いかけるようにして、新しく勉強する領域を常に探すようにしています。
前職では有償支援の仕事だったこともあり、自分に引き継がれる段階では、既にクラウドサービスの選定やアーキテクチャがある程度決まっている状態であることが多かったです。支援を始めてお客様の要件を詳しく伺っていると、「このクラウドサービスではないほうが合っている」「想定されている移行方法が合っていない」というようなことがあり、お客様に伝えると「もっと早く言ってくれればよかったのに」「今更引き返せない」と言われることもありました。そのような経験の中で、有償支援の提案ではなく、その前の段階からお客様と会話して、適切なクラウドサービスや移行方法を提案する仕事を、自分がやるべきではないかと考えるようになりました。
また、オンプレミス製品を扱っている頃は、AWS は「自分とは別世界のもの」だと捉えていましたが、他社とはいえクラウドサービスを扱うようになると、サービス自体は違っても、提供する機能に共通点があり、キャッチアップ自体はそんなに難しくないのではないかと思うようになりました。例えば、1 つの RDBMS に詳しくなると、他の RDBMS のアーキテクチャも理解しやすくなりますし、機能も把握しやすくなります。このように、「製品やサービスが異なっても、考え方や経験はそのまま活かせるのでは」と考え、当時は AWS のサービスについての知識はありませんでしたが、転職を考え始めました。
応募自体は、最初はアカウント SA で受けようかと検討していたのですが、どのインダストリーを選ぶか迷ったり、機械学習や IoT まで担当するのは自信がなかったりと決断しきれない状況でした。そのタイミングで、現在のマネージャから「マイグレーション ＆ モダナイゼーションのチームができたので受けませんか？」と声を掛けていただきました。「エンタープライズのお客様のクラウド移行とモダナイゼーションを加速する」というロールであり、「クラウド移行」の領域で自分の経験を活かしながら、「モダナイゼーション」の領域で新しいことにも挑戦できそうだと考え、受けることにしました。幅広いインダストリーを対応できることも、自分に合っていると思います。
入社してからは、まず 3 ヶ月のランプアップ（立ち上がりまでの研修期間）中に、個人ごとに計画されているトレーニング一覧をこなしていくことに集中しました。それを終えた後は、必要なトレーニングや社内向けの勉強会、動画等を自分で探して進めていくことになります。個人的に追加で取り組んだことは、AWS のお客様向けクラスルームトレーニング（ Architecture on AWS 等） をいくつか、お客様と一緒に受講させてもらうことです。講師がお客様にどんな説明の仕方をしているかを参考にしています。また、お客様にトレーニングを紹介する際に、自分が受講したからこそ「こういう学習状況の、こういう方に向いています」と紹介することもできるようになりました。
AWS のサービスは幅広く、社内向けのトレーニングや勉強会も大量に用意されており、全部受けることは時間的に難しいので、自分にとって必要な分野の優先順位をつけてキャッチアップしていく必要があります。AWS のサービスの場合は、SA が作成した資料や動画 （ Black Belt セミナーとして公開されているものも多いです）で概要をつかんだ後は、ハンズオンを使ったり、自分でドキュメントを読みながら手探りでサービスを使ってみたりして、手を動かしてたくさん躓きながら学んでいます。視野が狭くならないように、他社主催のものも含めて、IT 系のセミナーや勉強会にも引き続きたくさん参加するようにしています。
私の場合は前職の元同僚など知人が多いので、入社前からもよく AWS の話を聞いていて、初めての転職ですが大きな戸惑いはなかったです。一方で、リーダーシッププリンシプル（ OLP ）が重視されているのは入社前から知っていましたが、入社してからもトレーニングや評価だけではなく、「それは Earn Trust につながるから重要だね」というように普段の会話にも自然と出てくるところは驚きでした。また、「 Working Backwards 」や「 Two-way Door 」といった Amazon のメカニズムやカルチャーについても、SA として自分が外部に向けて語ることになるのか、というところは驚きでした。
ランプアップ期間中に、「バディ」という相談役の方がつくのですが、その方からは「アンラーニングした方がいいよ」というアドバイスをもらっています。前職が長く、初めての転職ということもあり、前職のルールや考え方、用語の定義と、AWS での業務の「ずれ」に気づかず、会話がかみ合わなかったり、指摘されたりすることが何度かありました。「 XX とはこういうものだ」と考えず、AWS での考え方や定義を、よく確認しながら進めるように気を付けています。また、自分の考え方や説明の仕方が、Amazon らしいか、AWS らしいか、SA らしいか、ということは、社内のメッセージをよく確認したり、マネージャーやチームメンバーに相談したりして、社外へ出すメッセージはどうあるべきかを、よく考えるようにしています。
