「Salesforceのアーキテクトって、どうやったらなれるんだろう？」

エンジニアとして現場で手を動かしながら、ふとそう思ったことはありませんか？

私、ケイはIT業界で20年以上、東京を拠点にアーキテクトとして活動してきました。アクセンチュアやIBMコンサルティングといった外資系コンサルファームで、製造業・金融・物流・ヘルスケアなど多様な業界のプロジェクトに携わり、現在はSalesforce TAとして設計・提案・実装の現場に立ち続けています。

この記事では、私が実際に体験した「エンジニアからアーキテクトへの転換点」と、これからSalesforceアーキテクトを目指す方へのキャリアロードマップを、現場目線でお伝えします。

この記事でわかること：

エンジニアとアーキテクトの本質的な違い
外資系コンサルでアーキテクトとして生き残るために必要なこと
Salesforce TAから見たCTAへのロードマップ
現場で本当に使える「設計思考」の身につけ方

自社のナレッジを外部に提供しながら、リアルタイムGvGバトルの設計と技術指導を同時に行う、という経験は、「自分の技術をいかに相手に伝えるか」を徹底的に鍛えてくれました。社内でMVPを受賞したことより、この「伝える技術」の重要性に気づいたことの方が、私のキャリアにとって大きな財産になりました。

これが、アーキテクトとしての私の原点です。

外資コンサルで学んだ「設計思考」

アクセンチュアに転職して最初に驚いたのは、「提案書の書き方」でした。

技術の話より先に「ビジネス課題の定義」が来る。解決策より先に「なぜその課題が問題なのか」を語る。

これがコンサルの設計思考です。

私がアクセンチュア時代に特に印象に残っているのは、ある物流会社のファクトリーDXプロジェクトです。

工場内の各工程は、すべて紙ベースで進行していました。「デジタル化したい」というクライアントの要望に対して、単純に「iPadアプリを作ろう」と飛びつくのは簡単です。

でも、まず私が考えたのは「なぜ紙なのか」「紙でないとできないことはないか」「デジタル化した場合の最大のリスクは何か」という問いでした。

工場内はインターネット環境が整備されていない。プッシュ通知による工程間連携をどう実現するか。こうした制約条件を先に洗い出してから設計を始めたことで、結果的にクライアントの満足度は非常に高く、工場全体への拡大（追加契約）につながりました。

また、鉄道会社との機械故障検知POCでは、AIモデルの異常予兆感知精度を90%以上まで高め、エッジシステムとクラウドの連携ブループリントを提供することで商用化提案に成功しました。

こうした経験を通じて、私が身につけたのは以下の3つの設計思考の原則です。

① 課題の本質を捉える（Whyの深掘り）

「○○したい」という要望の背後に「なぜそれが必要か」を必ず問います。表面的な要望に答えるだけでは、真の課題解決にはなりません。

② 解決策のトレードオフを明示する

どんな設計にも「得られるもの」と「失うもの」があります。それを隠さず、ステークホルダーと共有することが信頼につながります。

③ ステークホルダーごとに説明を変える

技術者、事業部門、経営層。同じシステムでも、相手によって伝えるべき内容とレベルはまったく異なります。

この思考法は、Salesforceの設計にもそのまま活きています。

クライアントが「Salesforceを導入したい」と言うとき、本当に必要なのはSalesforceなのか？　他のソリューションの方が適切ではないか？

この問いを持てるかどうかが、TAとSEの大きな違いだと感じています。

Salesforce TAとしての現在地

現在私は、Salesforce TAとして複数のプロジェクトに携わっています。

TAの役割は大きく3つです。

① アーキテクチャ標準の策定

大規模プロジェクトでは、数百人の開発者が同じシステムを構築します。設計の「ブレ」を防ぐための標準ガイドラインの策定が、品質と効率の両方に直結します。

② 技術リスクの早期発見と対処

プロジェクトが進むにつれて発生する技術的な問題を、できるだけ早期に発見し、対処することがTAの重要な役割です。後になるほど修正コストは指数関数的に増大します。

③ 開発チームへの設計ガイダンス

技術標準を作るだけでなく、それをチームが正しく理解・実装できるよう、継続的なサポートを提供します。

⚠️ TAとして現場で感じること

CTAはまだ取得していません。これは正直にお伝えします。ただ、TAとして現場でガイドラインを策定・提示してきた経験から言えることがあります。 CTAの試験が問うのは「知識の広さ」ではなく「設計判断の根拠を説明できるか」です。実務経験なしに合格することは、相当に難しいと思います。

CTAを目指す方へのロードマップ【3ステップ】

ここからが、この記事のメインコンテンツです。

TAとして現場で感じている視点から、Salesforceアーキテクトへの道筋をお伝えします。

Step 1：基礎資格の取得（目安：0〜6ヶ月）

まずは以下の2つを取得しましょう。

Salesforce認定アドミニストレーター
Salesforce認定Platform App Builder

この2つは「Salesforceをどう使うか」を理解するための土台です。Trailheadの学習コンテンツを活用すれば、独学でも十分に取得可能です。

ただし注意点があります。資格取得を「ゴール」にしないことです。あくまでも「設計を学ぶための入口」と捉えてください。

Step 2：アーキテクチャ思考の習得（目安：6〜18ヶ月）

資格を取るだけでは不十分です。

「なぜこの設計にするのか」を説明できるようになることが重要です。

おすすめの学習リソース：

Trailhead – Architect Journey

Salesforceが公式に提供するアーキテクト向け学習パスです。System ArchitectからApplication Architectまで、段階的に学べます。

参考：Salesforce Architect Journey（公式）

また、この段階で意識してほしいのは「設計の意思決定を言語化する習慣」です。

なぜRedisを使うのか。なぜこのデータモデルにしたのか。なぜこのインテグレーションパターンを選んだのか。

これを文章で書けるようになることが、アーキテクトとしての本質的な成長につながります。

Step 3：実案件での設計経験（目安：18ヶ月〜）

座学だけでは絶対に限界があります。

実際のプロジェクトで以下のサイクルを繰り返すことが、最も効果的な学習です。

要件定義への参加
アーキテクチャ設計書の作成
レビューと改善
実装・テストフェーズでの技術サポート
振り返りと学びの言語化

特に「設計書を書く」という経験は、頭の中にある曖昧な考えを構造化する強制力があります。書けないということは、まだ理解できていないということです。

💡 TAとして現場で実感していること

CTAを目指すなら、「正解を選ぶ練習」ではなく「最善のトレードオフを選ぶ練習」を積んでください。 CTAの試験問題は、明確な「唯一の正解」がない問題が多い。「この状況ではAとBどちらが適切か、そしてなぜか」を瞬時に判断できる力が求められます。

まとめ

この記事でお伝えしたことを整理します。

アーキテクトはWhatとWhyを設計する役割であり、エンジニアとは本質的に異なる思考が求められる
外資コンサルで学んだ設計思考（Why深掘り・トレードオフ明示・相手別説明）はSalesforceにも直結する
CTAへの道は「資格→設計思考→実務」の3ステップが現実的
TAとしての現場経験が最大の武器になる。書籍より設計書を1枚書く方が成長できる

最後に、少し個人的な話をします。

私がこのブログ「TokyoArch」を始めたのは、
教科書には載っていない「現場のリアル」を
伝えたいからです。

20年間のIT現場で見てきたこと、失敗したこと、学んだこと。
それを必要としている誰かに届けることができれば、
このブログの存在意義があると思っています。

次回予告としては、以下の2本を準備中です。

次回①
日本市場でのSalesforceアーキテクトの年収・市場価値について、
具体的なデータとともに解説します。

次回②
本記事で触れたCTAロードマップについて、
各ステップをさらに深掘りした詳細版を現在まとめています。
試験の具体的な対策から、実務での設計経験の積み方まで、
TAとしての現場視点でお届けする予定です。
楽しみにお待ちください。

ぜひブックマークして、次の記事もお楽しみに。

— ケイ

【体験談】東京IT20年、エンジニアからアーキテクトへ。現役TAが語るSalesforceアーキテクトへのリアルな道のり

目次

アーキテクトとエンジニアの違いとは？

私がアーキテクトになった転換点