ソリューションアーキテクト(SA)とは、クライアントとともに企業の事業やシステムの課題と向き合い、システムのアーキテクチャの改善案を提案して課題解決をする職業。クライアント企業のCTOやテックリードとディスカッションする機会も多いため、システムについての豊富な知識だけではなく、ビジネスや開発組織の今後を考慮した設計能力や論理的な説明能力なども求められます。
こう書くと、「学生時代からコンピューターサイエンスを専門的に学んでいた人でなければ、ソリューションアーキテクトとして活躍できないのでは」と思われるかもしれません。しかし、アマゾン ウェブ サービス ジャパン合同会社(以下、AWS)のソリューションアーキテクトとしてスタートアップを支援する塚田朗弘さん*は、大学時代には文学部国文学科に所属していました。そして、エンジニアリングの勉強を本格的に始めたのも、20代半ばになってからだったのです。いったい、どのような経験を積んでスキルを向上させてきたのでしょうか。
今回は塚田さんがこれまで歩んできたキャリアについてインタビュー。テクノロジーの世界に足を踏み入れたきっかけや印象に残る業務、ソリューションアーキテクトという職業の面白さなどを聞きました。
*…塚田さんの現在の正式な肩書きは、スタートアップ事業本部 技術統括部 本部長です。
ギタリストからエンジニアへのキャリアチェンジ
――塚田さんがITの世界に足を踏み入れた経緯についてお聞きします。
ITの世界に関わり始めたのは26歳くらいの頃でした。その直前まで私はバンドマンをしており、楽器はギターを担当していました。名古屋から上京して、かなり力を入れて音楽をやっていたんですが、残念ながらバンドが解散したんですよね。「これから何の仕事をしようかな」と、次のキャリアを考えました。
当時、未経験からシステムエンジニアになる人が周りに増え始めていたんです。それに、学生時代には趣味でHTMLやFlashを学んでいましたし、バンドマンになってからはバンドのWebサイトの運営も担っていたので、エンジニアになろうと思いました。ただ、私は慎重な性格なので、いきなり会社に就職するのは怖くて。バンド解散後はいったん専門学校に行きました。
後のキャリアにも影響することですが、この時代にはIT勉強会の運営を積極的に行っていました。「自分も優秀なエンジニアのコミュニティに加わりたい」という思いがあったんですが、学生にとって高度な内容を扱う勉強会に参加するのはすごくハードルが高いです。
そこで、自分を含めて学生が活きた情報を得られる場を設けたいという思いから、IT勉強会の運営をしていましたね。専門学校で3年間学んだ後、独立系のSIerに入って金融系システムのシステムエンジニアとしてキャリアを歩みました。
CTOを経験し、自分自身のスキル不足を痛感
――その後は、どのような会社で働かれましたか?
株式会社ドワンゴに入って、多くのユーザーを抱えるサービスのバックエンドを担当しました。大規模なWebサービスの開発・運用を経験できたのは、人生における貴重な財産です。大量のアクセスやデータのあるサービスでは、エンジニアが考慮すべき点も増えます。
たとえば、十分にパフォーマンスを考えてSQLを書いたつもりでも、何か少しでも考慮が漏れていれば、システムのリリース直後にサービスがダウンすることもありえます。大きなサービスは、外部から攻撃を受けたときの影響も大きいので、セキュリティの考慮漏れが致命的なリスクにつながります。当時のエンジニアリングマネージャーが「パフォーマンスやセキュリティを考えられないエンジニアはありえない」とよく言っていましたし、今でも自分がアーキテクチャを考える際の優先順位の基準になっています。
それから、巨大なシステムだったため「技術的負債とどう向き合うか」が重要でした。どのようなプランで技術的負債を解消すべきか、その作業とビジネスの成長をどうすれば両立させられるかといったことを、同僚と日々ディスカッションしていました。そして、自分自身もその技術的負債を着実に積み上げる一人でもあったと思います。
1社目は金融系のシステムを扱うという意味のシビアさを経験しました。そして、ドワンゴではユーザーの体験に自分たちのコードが直結するという体験をしたことが、エンジニアとしての成長につながったと思います。
――次はスタートアップでCTOを経験されたと伺っています。
スタディプラス株式会社に転職しました。先ほど、専門学校時代にIT勉強会の活動をしていた旨を話しましたが、そうした活動と並行してIT業界で活躍する学生にフォーカスした記事を書いていました。スタディプラスは教育関連の事業を展開されているので、CEOの廣瀬高志さんが私の記事を目にして声をかけてくれたのが最初だったと思います。
前職で技術的負債と向き合うなかで、「すでに出来上がっているものを後から変えるのは難しい。ならば、アーリーフェーズで筋の良いシステムをイチから作っていく経験を積んでみたい」と思っていたのです。その頃のスタディプラスはシリーズAくらいで、自分を含めて正社員のエンジニアが2〜3名でした。一人目の子供が生まれて2ヶ月ほどでにスタートアップに転職したので、「こんなタイミングで環境がガラッと変わってすまない」という話をしたのを覚えています。
黎明期のスタートアップというのは、システムも組織も未成熟ですから、自分たちの力で作り上げていく必要があります。その環境下で、自分のスキル不足を痛感しました。システムをイチから作り上げるといっても、考えるのと実践するのとではわけが違います。それにCTOとして組織作りの役割も担っていましたが、前職までそうした経験を積んでおらず、知識を豊富にキャッチアップしてからスタートアップに参画したわけではなかったのです。
毎日悩みながら、業務を通じて学ばせていただきました。周囲の人々には多大なるご迷惑をおかけしましたが、すごく貴重な経験でした。
モヒカン族にはなれないから、物理的にモヒカンになった
――そこから、AWSのソリューションアーキテクトとして働き始めたのは?
企業のフェーズに応じて、CTOが担う役割は変化します。私の場合は社員のエンジニアが2~3人という状況から参画して、それを10人くらいに増やすまでは「手を動かすCTO」としての役割を担いました。しかし、さらに次のシリーズCに行き組織をスケールさせるためのスキルが、当時の自分には足りないと思いました。
スタディプラスではAWSを採用しており、たまにスタートアップ担当のAWSのソリューションアーキテクトと話す機会がありました。AWSが主催するカンファレンスに参加・登壇することもありました。転職活動を始めた頃は、AWSは全く選択肢に入っていませんでしたが少しづつ考えが変わっていきました。
私が前職のスタートアップに移った理由は「なるべく早期のフェーズでアーキテクチャのベストプラクティスを取り入れたり、リスクを回避したりすることで、ビジネスの成長に寄与したい」という思いからでした。そして、多くのスタートアップに使われているであろうAWSのソリューションアーキテクトという仕事ならば、多くのスタートアップの方々とそういう関わり方ができるのではないかという考えにたどり着いたのです。そうして、AWSで働くことを決めました。
――塚田さんはモヒカンがトレードマークですが、AWSに入られてからこの髪型にしたのですか?
そうです。この仕事に就いてから会う人の数が増えたので、覚えてもらいやすい特徴を作ろうと思いました。それから、エンジニアの性質を表す言葉に“モヒカン族”というスラングがあるじゃないですか。私は比較的大人しい性格なので、モヒカン族のようなエンジニアにはなれないと考えています。論理的にモヒカン族になれないのなら、物理的にモヒカンになってみようと思ったのが、半分は冗談で、半分は本当の理由でした。エンジニアとしてモヒカンのほうがいいと言いたいわけではないのですが。
――ソリューションアーキテクトという仕事の魅力はどのような点でしょうか?
ソリューションアーキテクトの仕事は単にAWSのプロダクトをおすすめするとか売るといったことではなくて、お客さまのビジネスの成功に向けたお手伝いをすること。つまりお客さまと並走しながらシステムや事業の課題の解決策を一緒に考えることです。AWSを用いたインフラのことだけではなく、アプリケーションの実装内容まで踏み込んで、お客さまとディスカッションしています。多くの方々と一緒に深い話ができて、示唆に富む毎日です。
自分の担当したお客さまのビジネスがその後成長して、プロダクトマーケットフィット(PMF)を実現できた際に「一緒に議論して構築したアーキテクチャで、事業の成長を支えられました」と言っていただけたときは、大きな達成感を覚えます。
それから、技術的に正しい情報や新しい考え方などを日本のエンジニアにお伝えすることも重要な仕事です。私たちはこれをソートリーダーシップ(Thought Leadership)と呼んでいます。たとえば、ブログを書くとかイベントに登壇するといった活動を通じて、情報発信しているのです。
アウトプットし続けるためには、当然ながらその源泉となるインプットが必要です。AWSの情報を日々学習し続けなければなりませんし、同時にAWSに限らない最新の技術トレンドなどもキャッチアップする必要があります。エンジニアは新しいことを学ぶことが好きな人が多いですから、そうした個人としての欲求と会社から自分へのリクエストが一致するのは魅力的です。
加えて、重要な業務としてAWSのサービスに対する改善要望や課題のフィードバックがあります。普段の業務でAWSを使う方々の声を、直接的に聴くのは私たちなのです。そこから上がってきた意見を咀嚼してサービス開発チームにフィードバックすること、そしてサービスの開発の方向性に影響を与えることは重要な責務です。ただお客さまの声をそのまま伝えればいいというわけではなく、AWSを使うお客さまとエンジニアの言葉で会話をし、理解をし、本当に必要な改善とは何なのかを整理した上で、サービス開発チームと議論を重ねることが求められます。
他に、イベントの企画・運営や、技術コンテンツの作成と公開を通じた情報発信などもソリューションアーキテクトの業務です。その内容はAWSに関するもの、技術的なものももちろん多いですが、それに限りません。たとえば、技術リーダーの方々が一堂に会するCTO Night and Day。参加者の方々から、「CTOやVPoEは会社のなかで孤独になりがちなので、悩みを相談できる仲間がいることがものすごくうれしい」という声を毎回いただきます。
テクニカルカンファレンスAWS Dev Dayのコンテンツリードも毎年担当していまして、ありがたいことに年々CFPの数が増えています。それから、目黒のコワーキングスペースAWS Startup Loft Tokyoも2018年の立ち上げから関わっていて、イベント運営やソリューションアーキテクトに質問できるAsk an Expertのコーナーを運営しています。
AWS Startup Loft TokyoやAsk an Expertなどの活動を通じて、お客さまから「2週間悩んでいた部分を30分で解決できました」とか「AWS Startup Loft Tokyoの開設日と会社の登記日が一緒でして、そこから共に育っています」といった声をかけていただくこともあって。直接的に多くの企業の方々と接して、ビジネスやシステムの成長のために一緒に考えている時間は、この仕事の面白さを感じます。
すべての経験は今の自分の働き方につながっている
――AWSに入社したばかりの頃と今とで、変わった部分はありますか?
もともと私は、良くも悪くも自分の役割にこだわりがない人間で、そのとき必要なことを何でもやるというスタンスです。とはいえ、AWSに入社する前や入社したばかりの頃はエンジニアリングに関する業務が主体でしたが、徐々に日本のスタートアップソリューションアーキテクト組織を統括する立場になるにつれてマネジメント志向・ビジネス志向がより強くなってきたように思います。個人として頑張るというよりも、チームや企業として動き、日本全体や世界全体にインパクトを与えることに面白みを感じるようになりました。
Amazonのカルチャーに「ピザ2枚のルール」と呼ばれるものがあります。「社内のすべてのチームは、2枚のピザを食べるのにピッタリなサイズでなければいけない」という意味合いで、要するに一つひとつのチームがオーナーシップを持って、小さな会社のように振る舞うことを良しとする文化なのです。それによって、Amazonがこれだけ大きな会社になっても、個々の意思決定のスピードを保つことができるというメカニズムです。一方、各チームがそれぞれのミッションを持って動いていて、単純に全員でひとつのゴールを目指すというシンプルな体制ではありません。
そういった状況では、全員で特定のゴールに向かって動いていく従来型のコラボレーションだけではなく、複雑かつコントローラブルではない状況でもうまく共創していくストレッチコラボレーションが求められます。その中で、いかにして成果を最大化するかに今は興味を持っています。
――塚田さんはAWSのスタートアップ事業本部に所属されていますが、スタートアップを支援することの魅力とは何だと思われますか?
スタートアップで働く方々は、スキルが高く斬新なアイデアや情熱を持っています。そういった方々と関わること自体が刺激的で面白いです。そして、スタートアップの方々が私たちAWSを信頼してくださり、システムの重要な課題をご相談いただくなかで、ディスカッションを通じてレバレッジを効かせて世の中に影響を与えられることにもやりがいを感じています。
現在、日本政府はスタートアップを生み育てるエコシステムを創出するために「スタートアップ育成5か年計画」を掲げています。国全体がスタートアップに投資していく流れのなかで、その支援ができる仕事。ひいては、自分の家族が将来幸せに暮らせる国を作るための手助けができる仕事というのは、有意義だと思います。
――最後に、読者の方々へのメッセージをいただきたいです。
正直なところ、私は何か特定のスキルが秀でているとは思っていません。でも、これまで経験して身に付けたいくつかの要素が、かけ算として合わさっているからこそ、こうして働けているのだと思います。
たとえば、IT勉強会のコミュニティに参加したり、自分で主催したりといった活動は現在のコミュニティ運営の仕事に活きています。最初に入った金融系のSIerの経験がなければ、ソリューションアーキテクトとしてFintech系の事業の支援もできなかったはずです。
ドワンゴでの大規模Webサービスの開発・運用経験や、スタディプラスでサービスや組織を大きくしていった経験もそうです。AWSに入った頃は英語もまったくできませんでしたが、何を思ったのか積極的に英語で登壇する機会などに挑戦していった結果、なんとか今はグローバルチームの中で生きていけています。
自分にとって未知の領域やそれほど得意ではない領域であっても、前向きに取り組むことがその後のキャリアにとってプラスになりました。新しいことを積極的に試してみると、良い結果が生まれるのではないかと思います。
取材・執筆:中薗昴
撮影:漆原未代