外資ソリューションアーキテクトの究極ガイド: 組織論・スキル・給与体系・評価制度

外資ソリューションアーキテクトの組織や求められるスキル、評価制度や給与体系、キャリアの最終系について、複数の外資企業でソリューションアーキテクトとしてキャリアを詰み、且つWorkCircleのユーザー様が全貌を紹介します。

✏️

著者について 所属企業: ユニコーン外資テック企業所属職種: ソリューションアーキテクト経歴: B2Cユーザ企業エンジニア、ソリューションアーキテクト

外資ソリューションアーキテクトと関連するロールの理解

外資におけるソリューションアーキテクトの理解

最初に補足しておくと、ソリューションアーキテクトというロールは各社でロールとしての役目が違う。例えばAmazon Web Servicesでいうソリューションアーキテクトはプリセールス的（技術営業）な役目であるし、Google Cloudや、Snowflakeなどで言う所のソリューションアーキテクトはポストセールス（既存顧客の技術支援）である、だが筆者のバックグラウンドからここで言うソリューションアーキテクトとはいわゆるプリセールスエンジニアという前提でお話する。

いわゆるソリューションアーキテクトは販売する製品についてある時は営業と共に、ある時は個別に技術に軸足をおいてその製品の導入支援、または技術的な観点からのアピールを行うロールといえる。またソリューションアーキテクトに求められる役割は各外資企業によって異なることも多く、営業との業務のオーバーラップについても各外資企業によって異なる。例えばある外資企業では広く導入の説明、デモなどをメインに行うが、ある外資企業ではPoC（Proof of Concept）にDive Deepしサポートすることをメインの業務とする事もある。

そして大事な点はソリューションアーキテクトは営業であり、エンジニアである、という点である。

業務内容

ソリューションアーキテクトとしての主な仕事を説明する。前述した通りこれがソリューションアーキテクトとしての仕事と毎回アラインする訳では無い事に留意していただきたい。

お客様との折衝

お客様に自社製品を使っていただけるためのガイドや、PoCに向けての案件整理、技術的な要件の整理を行う。またどのようなタイプのお客様が、どういった技術的な要件を持っており、技術的課題は何か、など具体的な技術的な問題を解決していくために自社製品をどう使っていけるか、という技術面からの案件創出を行う。ここでは先ほどいった通り、営業でもあり、エンジニアでもあるという点を最大限に発揮し、顧客の技術的な信用を得る事に大きな意味があり、これは自社製品を売る、という目的はもちろんあるが、顧客の中のいちエンジニアとして課題を解決することが大事と筆者は考える。

PoCサポート

次にソリューションアーキテクトが具体的な大きく活躍することになるパートはPoCサポートのパートだ。具体的な課題感があり、自社製品がフィットする場合にお客様はPoCという形で製品の導入検討を行うことになる。この場合、お客様が自走できる場合、できない場合、パートナー経由で検討する場合、ある課題に対してワークアラウンドが必要な場合、他社製品との組み合わせが必要な場合、など適切な技術面でのサポートを行う。ドキュメントの提示から始まり、サンプルコードの作成、チューニングのサポートなどまで時には行うが、プリセールスとしてサポート範囲の選択は慎重に行う必要がある。時にはPoCの進捗管理や、進捗を前に進めるためのミーティングをセットするなど様々な方法を用いてPoCを成功に導く活動を行う。

製品開発との連携

ソリューションアーキテクトの大事な業務のもう一つは、お客様からのフィードバックを製品開発チームに届けることである。この製品には日本の商習慣に置いてこの機能が足りない、この製品にはこの機能がないと他の製品と組み合わせられない、この機能がないため運用がめんどくさい、この機能がないと導入できない、などなど...製品をお客様の声を聞きつつ一緒に改善していくために製品開発チームとできるだけ近い距離を取れるようにし、時にはお客様と製品開発チームをあわせてミーティングをし、直接フィードバックをしてもらう事も行う。自社製品を更により良い製品とするために必要なコミュニケーションをしていくのもソリューションアーキテクトの大事な業務である。

対外活動

そしてもう一つ、ソリューションアーキテクトの仕事として求められるのは「製品の顔」となることである、マーケティングチームはもちろん製品の対外的な影響力の向上を常に考えてくれているが、エヴァンジェリストや、DevRelといったロールの人がいる組織だけではない。また、それらのロールは広くアピールすることを主とするロールであり、それだけでは不十分で、ボトムアップで製品のアピールをすることも大事となる。そのためソリューションアーキテクトも製品の顔となり、技術面のアピールを行うことがある。対外イベントや、自社プラットフォームを使い製品の技術的な優位などをアピールし、どのような技術的な課題を解決するのかや、そもそもその技術の要素技術などについて説明する。この場合の評価指標について考慮事項はあるがこれは後述する。

ソリューションアーキテクトに求められるスキル

次にソリューションアーキテクトに求められるスキルについて説明していく

テクニカルスキル

ソリューションアーキテクトは基礎的なテクニカルスキルを保つ必要がある。中にはテクニカルスキルを持たずに技術営業を行っているソリューションアーキテクトもいるとは思うが、その場合できることは製品紹介や、デモ止まりになってしまい必要な案件解決に対した提案を行うことはできない。前述した通りPoCサポートや、そうでなくても自社製品のみならずその周辺機能まで検証したり、そもそもの技術の潮流や、顧客のアーキテクチャを見つつそれにあった提案をする必要があるソリューションアーキテクトは自分で手を動かし技術的な検証や、技術の整理を行う必要がある。

製品知識

これは言わずもがなだが、自社製品の強み、弱みを知り尽くすことがソリューションアーキテクトには必要になる。製品の各機能がどういった機能で、何ができるのか？そして何ができないのかを知らずに顧客に向けて製品の推薦はできない。必要な案件に応じた機能を提供し、自社製品だけでは十分ではないと判断すれば、時にはパートナー製品との組み合わせを提案し、競合とのコンペの場合には他社製品と比べた強み、弱み、まで含めた知識を保つ必要がある。

業界知識

営業もそうだが、ソリューションアーキテクトもある特定の業界を担当として保つ場合が多い。製造、リテール、金融、アドテク、DNB（デジタルネイティブビジネス）、ゲーム業界などなど。それらの業界には商習慣もあるが、業界ごとに技術的な基本の考え方がある、例えばアドテクで言えばレイテンシを極限まで低くする必要があるため、アーキテクチャによってはあえてデータセンタの冗長化戦略（AWSで言えばシングルAZといえばよいか）を取らないパターンもある。こういった各業界に特化した知識を活用することでより案件にフィットした技術提案を行うことができる。

英語

英語は会社によると思うが、読み、書き、会話など必要に応じて使うことになる。ドキュメントは殆どの規模の外資であれば日本ブランチは大きくないことが多いためその場合ドキュメントの殆どは英語であるため読みはできる必要がある。大きなブランチであれば日本語のドキュメントが充実していることもあるが...。殆どのやりとりは現在Slack等のチャットや、各社独自のチケットシステムで行うことが多いため、読み書きができれば基本的なコミュニケーションはできるためここまでがまずは重要である。だが、詳細なコミュニケーションや、顧客と開発チームとのミーティングなどをセットする様な流れになると会話ができる必要もあるので長期では英語ができることはキャリアの広がりにもつながる。

最近はAIなどを使えるので英語の障壁は低くなっていると筆者は考える。

文化

外資では意外と、というと意外かもしれないが、会社文化を非常に大事にする傾向がある。有名な所で言えば、AmazonのOur Leadership Principle（OLP）などである。これはなぜかというと、文化という共有認識があると様々な人とやり取りがしやすいからである。様々なロールと協働する必要がある外資ではロール間のやり取りを円滑にする目的もあると筆者は考える。例えばOLPの中には「Customer Obsession」「Have Backbone; Disagree and Commit」という項目があり、これは「顧客第一主義」、「各々のバックボーンにおいて同意できない場合は意義を唱える、だが同意したことはコミットしてやる」、ということだが、何らかの案件において問題が発生した場合に「Customer Obsession」であればこうだが、私の立場からは「Have Backbone; Disagree and Commit」に基づいてこういう内容にできるのならコミットします。という話をすることができる。これはグダグダ空中戦をするのと比べて非常に話が早い、こういった各社の文化をうまく利用して利益を最大化、最速化するのが大事である。

コミュニケーションスキル

コミュニケーションスキルというのは難しいが、ここでいうコミュニケーションスキルというのは営業の様にうまく喋れる事ではない（喋れるならそれは武器になるが）顧客のエンジニアとしての技術のレベル感や、属性（自分で全部やりたい人、技術に対してこだわりのある人、自分で責任を取りたくない人など色んなタイプがあると思う）を理解したうえでそれに合わせたやり取りができるスキルを持つ事である、例えば技術力はすごく高く、気難しいタイプと、技術力は低く、自身で責任を取りたくないタイプでは全く違うコミュニケーションが求められる。そういうコミュニケーションを使い分けることができるのが大事であると考える。大きなミーティングの方向性は営業が作ってくれることを期待してソリューションアーキテクトとしてはエンジニアリングの方向性をまとめて行くことに注力する様に役割分担するのが良い流れだと考える（時にはそうできない場合もあるとは思うが...）

インフルエンス力

前述した対外活動を行う場合に必要な事がインフルエンスの力である。インフルエンス力を定量的に測る方法はない気がするが、一般的にSNSでのビジビリティや、セミナーなどでの登壇回数などで育てていくことができると考える。加えて大事なのは発表内容である、おとなしい、ただの製品紹介スライドを見せられてもエンジニアは面白くない。そうではなく「今日から使える技術」を持って帰ってもらうつもりで実際の環境で使える内容を発信していくことでエンジニアからの信頼を得ることができるのではないか、と筆者は考える。こういった活動により自身の発信力を高めることは自身のビジビリティを高めることになるし、それは製品自体のビジビリティをも高めることにもなる。

評価制度

基本的な評価指標

評価制度自体は会社ごとに異なっているが、基本的な考え方は数段階（4〜5が多い感じがする）に別れた評価段階の何処かに割り振られるパターンである。もちろん高い評価であればより高い報酬やRSU、そしてプロモーションにつながる。評価指標としては、これも各社複数のKPIを持っているが、基本的にはインパクトのある案件を前に進める事が大きな評価につながる。例えば売上の大きなアカウントでWinした、やグローバルやローカルで、ネームバリューのある企業でのWin、新しいプロダクトでのWin等である。そしてもちろん営業組織の一員であるため、売上をより上げたソリューションアーキテクトを評価する流れも存在している（会社によっては売上規模を見ない会社もある）そして前述したが、難しいのは外部の情報発信である。ソリューションアーキテクトは外部への情報発信を行うことがあると言ったが、これが評価に入っている会社もあればボランティアでやっている場合もあり、評価に入っている場合はいいが、そうではない場合はアピールポイントとしてマネージャーなどと評価を握る必要があり、そうしないと本当にただのボランティアになってしまう可能性があるのでまず活動時にマネージャーと軽くでもいいのでKPIを握っておくことをおすすめする。

プロモーション

プロモーション、昇進である。これも各社に置いて様々な指標があると思うが、基本的なプロモーションの考え方としては「（今のレベルではなく）プロモーション対象のレベルの仕事が既にできていること」が基本的なプロモーションの考え方になっていると筆者は考える。

プロモーションのためにはそのためのドキュメントを作る必要があり、それはマネージャーとの年密なプランの元作成することが多い。加えてエンドースコメントを周囲の同僚から貰うことも多いのでプロモーション時にアピールしたい案件は事前にまとめ、マネージャーと握りつつプロモーションを計画的に進めることをおすすめする。

給与体系

給与体系と企業間差異

報酬の内訳は以下のようなものの組み合わせが多い

ベース給与

売上連動賞与

例えばAmazon Web Servicesではソリューションアーキテクトは売上連動賞与はないが、Google Cloudではある、等と会社によって異なる。ベース給与、売上連動賞与は毎年の評価に応じてベースアップしていく。加えてボーナス的に与えられるのはRSUなことが多く、これは目覚ましい活躍をした人に対して通常より多いRSUを付与するなどが行われることがある。売上連動賞与の条件は会社ごとに違うが、例えば、日本全体の売上、チーム全体の売上、個人の売上など様々な条件があるのでオファーサイン前に採用人事に確認してみることをお進めする。

キャリアアップの種類・方法

それでは次はソリューションアーキテクトはインターナル次にどういった道に派生する事が多いかを説明していく。

マネージャーとしての道

よくある話として、ICのソリューションアーキテクトからソリューションアーキテクトマネージャーにロールチェンジするパターンである。これは今までの仕事を活かしつつチームをまとめるというより組織をスケールするための仕事につくということである。ソリューションアーキテクトのモチベーションを下げずにより良いメンバーを採用していく、より上のラダーのマネージャーとの連携といったより組織の中の大きな仕事を行うことができるのは非常にエキサイティングである。

ICとしての道

マネージャーをやりたくない、合わないという方はICのまま業務を続けていく方もいる。「ICのままでいつまでできるんだろう...」と思う方もいらっしゃるかもしれないが外資において年齢はあまり気にされず、前述するスキル群を満たせていれば別け隔てなく仕事ができる懐の深さがある（その代わり満たせていなければ...）また、ICのままレベルを上げていくといった道もあるが、これはマネージャーのままレベルを上げるよりも難易度は高い。なぜならレベルの高いICというのはそもそもポジションが少なく、例えば遊撃隊の様に日本の炎上案件にスポットで入るようなソリューションアーキテクトのように例えば日本のブランチを代表するようなソリューションアーキテクトになる道である。この様な人材が中々いないことはおわかりかと思う。

スペシャリストとしての道

もう一つの道としてはソリューションアーキテクトの業務を行う中で得たスペシャリティを活用してそのテクニカルドメインのスペシャリストとして他のソリューションアーキテクトのサポートをするスペシャリストソリューションアーキテクトというロールへの転身である。例えばソリューションアーキテクトを進める中でデータベースの技術に詳しくなったため、データベースのスペシャリストソリューションアーキテクトになる、などである。これはもちろん技術ドメインとしては今までの広い技術領域をカバーする戦略から、狭く深くという戦略になるため今までとは違ったキャリアプランを求められるようになるので選択としては慎重に考慮したい。この派生として、機会は少ないが海外の開発チーム付きのソリューションアーキテクトになるパターンも有り、リモートでの業務にはなるが開発チームに近い所で働けるのは大きなメリットである。先ほどいった、ICのレベルが上げづらい問題もスペシャリストソリューションアーキテクトであればドメイン知識へDiveDeepすることにより、ICとしてレベルを上げやすい傾向がある事も補足しておく。

エンジニアとしての道

これはおそらく一番難易度が高い道になるが、ソリューションアーキテクトから製品開発チームへの異動を行うという道である。開発拠点が日本にある場合は比較的容易ではあるが、海外にしか拠点がない場合はリモートもしくは海外トランスファーということになるのでそういった点でも非常に難易度は高い。ただ元々開発していた人で、開発に戻りたい、もしくは開発チームに元々いきたいがいきなり行くにはパスがないのでソリューションアーキテクトで実績を作って開発チームに行く、というキャリアプランを作っている方も一定数存在している。このためにはソリューションアーキテクトでの業務をしている中でサービスへのフィードバックや対外活動などで開発チームへのビジビリティを高めておくことが重要となる。

キャリアの終わり

ソリューションアーキテクトは、技術と事業の橋渡し役として重要な職種である。しかし、キャリアの終着点ではなく、むしろソリューションアーキテクトとしての経験は次のステップへの強力な足がかりとなる。多くの経験豊かなソリューションアーキテクトがキャリアの転機を迎えたとき、「次は何をすべきか」という問いに直面することになる。

キャリアの「終わり」という考え方

キャリアに「終わり」はあるのか。技術の世界では常に新しい知識やスキルが求められ、ソリューションアーキテクトとしての役割も時代とともに変化しているため、これまでのソリューションアーキテクトとしての経験を活かした「次のステージ」と捉えることで、新たな可能性を考える事ができる。ソリューションアーキテクトとしての経験は、技術的な深い知識だけでなく、顧客との関係構築、問題解決能力、コミュニケーション能力など、様々な分野で活かせる貴重な資産といえるからだ。

FIRE

別外資のプリセールスエンジニア

別事業会社のエンジニア

ベンチャー事業会社のCXOなど

その他

など、ソリューションアーキテクトのキャリアは、終わりではなく新たな始まりのための基盤となり、ソリューションアーキテクトとしての経験で培った技術力、コミュニケーション能力、問題解決能力は、さまざまな分野で高く評価される。重要なのは、自身の強みを活かしつつ、次のステージで必要となるスキルや経験を計画的に積み重ねていくことである。

キャリアの選択肢は決して限られたものではなく、むしろソリューションアーキテクトとしての経験があることで、より多くの可能性が開かれているとも言える。自己分析と市場調査を通じて、自分に最適なキャリアパスを見つけ、具体的なアクションプランを立てること。あなたにとってのベストな選択は何か。じっくりと検討を進める事が大事である。

WorkCircleの外資ソリューションアーキテクトコンテンツ

💸 証明済み年収データベース

オファーレターや給与情報が証明できる書類によって証明された700件以上の年収データが登録されています。登録された方にのみデータベースへのアクセス権が与えられます。年収値の他、年収の各内訳(RSU, Pay Mixなど)、職歴年収、英語力などの詳細情報が確認可能です。

🟠 WorkCircleコミュニティ

約200件の#営業、300件の#外資関連のコンテンツが投稿されています。 (投稿例) - 外資大手テック企業の役員やっていますが何か質問ありますか？ - 一番稼げる職種は営業なのか？

💰 証明済み年収物語

現在の年収までの道のり、経歴や年収の上がり幅、現在所属する企業や年収への想いが物語となったコンテンツが20件以上投稿されています。 (WorkCircleコミュニティ内で閲覧可) (投稿例) - Google アカウントマネージャーの証明済み年収物語 - VMware アカウント営業の証明済み年収物語

🧑‍💻 求人

WorkCircleのパートナー企業16社が募集する求人では、多数の営業職が募集されています。 WorkCircleスカウトに求人プロフィールを登録することでポジションとプロフィールがマッチした場合、企業の採用責任者がご連絡致します。カジュアル面談も可能です！

🏢 パルスサーベイ

各企業の企業情報データベース内で、所属するユーザー社員が感じる報酬・待遇、カルチャー等への満足度を登録・閲覧可能です。