はじめに
東京のIT業界でエンジニアとして20年以上生き抜いてきました。AccentureやIBMといった外資系コンサルの現場も経験し、現在はSalesforceのテクニカルアーキテクトとして働いています。
正直にお伝えします。かつての私は「コードを書き続けることが正解」だと信じて疑いませんでした。しかし現実は違いました。
この記事では、現場エンジニアからアーキテクトへの転換で「何を捨て、何を拾うべきか」について、実体験を交えてお伝えします。
2000年代初頭、東京のコードの真っ只中で
私がIT業界に入ったのは、大規模SIer全盛時代のことです。不夜城のような現場で、仕様書通りにコードを書くことだけを求められていました。
当時の評価基準はシンプルでした。「速く、正確にコードを書けるか」──それだけです。
しかし規模が大きくなり、責任ある立場を任されるようになって初めて、ある冷徹な現実に気づきました。
「コードが書けるだけでは、ビジネスの課題は解決できない」
技術スタックの変遷：コードを書く人間から、設計する人間へ
私のキャリアはJavaから始まりました。大規模SIの現場で、基幹システムや業務アプリの開発を黙々と担う日々でした。
その後、時代の流れとともにPython・Node.js・PHP・Vue・Flutterと、プロジェクトの要件に応じてさまざまな言語・フレームワークを使い分けてきました。言語の習得にかける時間も労力も惜しみませんでした。それが「優秀なエンジニア」の証明だと、疑いもなく信じていたからです。
転機が訪れたのは、あるプロジェクトのアーキテクチャレビューに初めて同席したときのことです。
そこにいたコンサルタントは、私より圧倒的にコードを書きません。しかし、ビジネス要件を構造化し、技術的な制約と照らし合わせながら、意思決定の根拠を明快に語っていました。
「自分には、あれができない」
その一言が、私のキャリア観を根底から揺るがしました。
その後、私はコンサルティングファームへの転身を決断しました。Accenture・IBMといった外資系の現場に飛び込み、テクニカルアーキテクトとしてのキャリアを積み直しました。
そこで痛感したのは、コンサルという世界では「何の言語が書けるか」ではなく「なぜその設計を選ぶか」を語れる人間が評価されるということです。
Java・Python・Node.jsで培った実装の経験は確かに武器になりました。しかしそれ以上に求められたのは、技術をビジネス価値に変換する論理力と、ステークホルダーを動かすコミュニケーションの設計力でした。
「技術への執着を捨てる」──それは技術を軽視することではありません。技術を「目的」から「手段」へと再定義することです。
この転換こそが、私がエンジニアとしての限界を突き破った瞬間でした。
日本のIT業界で「今、求められる人材」の変化
20年前に重宝されたのは「仕様書通りに動くものを作る人」でした。コードの品質と納期。それだけが評価の軸でした。
しかし外資系コンサルの現場に身を置いて、その常識は完全に覆されました。
クライアントが本当に求めているのは「動くシステム」ではなく「ビジネスが前進すること」です。そのために何を設計し、なぜその選択をするのか──その論理を語れる人間だけが、テーブルの上座に座れます。
言語やフレームワークは時代とともに変わります。しかし、ビジネス要件を技術設計に落とし込み、ステークホルダーを納得させる「アーキテクチャの論理」は、20年前も今も変わりません。これが私がコンサルの世界で最初に学んだことです。
アーキテクトとして生き残るための3つの鉄則
20年で学んだことを3つに絞ると、こうなります。
鉄則1：流行に踊らされず「本質」を見極める
新しい技術は「手段」に過ぎません。その技術がビジネスのどの課題を解決するのかを、常に問い続けてください。「流行っているから使う」というエンジニアは、5年後に確実に陳腐化します。
鉄則2：コミュニケーションを「設計の一部」と捉える
優れたアーキテクチャも、周囲の理解が得られなければ動きません。ドキュメント・プレゼン・交渉──これもアーキテクトの仕事です。
私がSalesforceのTA（テクニカルアーキテクト）として最も時間を使うのは、実はコードではなく「会話の設計」です。
鉄則3：自分の市場価値を客観視し続ける
東京のIT市場、あるいはグローバル市場で今の自分のスキルセットがどう評価されるか、冷徹に把握し続けてください。感覚ではなく、データで見ることが重要です。
※ 参考：Salesforceアーキテクトの年収・市場価値については別記事で詳しく解説している
AI時代、アーキテクトの「本当の役割」とは
「AIがエンジニアの仕事を奪う」という議論が続いています。私はこれを20年のキャリアを通して、こう見ています。
AIは「書き方」を教えてくれます。しかし「何を作るべきか」という問いには答えられません。
「AIを使いこなす」──その先にあるもの
ここで誤解していただきたくないのですが、「AIを使いこなすことは不要だ」と言いたいわけではありません。むしろ逆です。現場ではAIを使いこなせるかどうか、それ自体が生産性の差として直接現れます。
しかしAIをただ「便利なツール」として使うのと、「レバレッジ」として使うのとでは、アウトプットの質がまったく異なります。
例えば、こんな問いかけをするエンジニアがいます。
「このバグを直してください」
これでは、AIは「その場の答え」しか返せません。
一方、こう問いかけるとどうでしょうか。
「このシステムはSalesforceのAPIを呼び出す構成で、現在こういうエラーが出ています。エラーの発生条件・影響範囲・修正方針の3点を、公式ドキュメントに基づいて整理してください」
前提情報・制約・期待するアウトプットの形式を整理した上でAIに投げると、AIは驚くほど精度の高い答えを返してきます。これはコードの修正だけではありません。要件定義・設計ドキュメント・ステークホルダー向け資料の作成まで、あらゆる場面で同じことが言えます。
AIと協働するために必要な「問いの設計力」
AIに与える情報の質が、AIのアウトプットの質を決めます。これはアーキテクトが持つ本質的な能力──「要件を構造化し、整理し、正確に伝える力」──と完全に一致します。
さらに言えば、AIに自社のシステム構成・業界のコンテキスト・過去の意思決定の背景を継続的に学習させることで、AIそのものが自分の仕事のパートナーになっていきます。
テクニカルアーキテクトとして、私が今確信していること──
コードを書く速度はAIに任せればいい。その先にある「何を設計するか」「なぜその設計を選ぶか」という意思決定と、「AIに何を・どう問うか」という問いの設計力。これが、これからのアーキテクトに求められる核心です。
まとめ：技術を捨てることで、本物の設計者になれる
- 特定の言語・技術への執着は、アーキテクトへの成長を妨げます
- 「なぜその技術か」を語れる人だけが、市場で生き残ります
- AI時代こそ、「問いの設計力」と意思決定能力の差が拡大します
- AIを使いこなすことは必須です。しかしそれ以上に、AIに何を問うかが重要です
このブログについて
私ケイは、このブログを通じて20年分の実務知識とSalesforceアーキテクトとしてのリアルな視点を発信していきます。
年収・転職・技術・AI戦略──東京のIT現場で戦う方々に、少しでも役に立つ情報をお届けしたいと思っています。
コメント