職種・体制

ソフトウェアアーキテクト

（そふとうぇああーきてくと／Software Architect）

登場（海外）: 2000年
国内で見られるように: 2009年ごろ
更新: 2026-08-24

一言でいうと

システム全体の構造を設計する職種で、後から変えにくい判断を担当し、その理由を残して開発チームへ渡します。

この職種の出自と登場時期

ソフトウェアの構造を建築になぞらえる考え方は1990年代に広がり、2000年に IEEE 1471 としてアーキテクチャ記述の標準がまとまりました。この規格は後に ISO/IEC/IEEE 42010 へ引き継がれています。設計の記述方法が標準化されたことで、アーキテクトの成果物が個人の図から共有できる文書へ変わりました。

一方で、この職種には長く批判もついてきました。実装から離れた「象牙の塔のアーキテクト」が現場と噛み合わない図を描くという指摘です。Martin Fowler は、アーキテクチャを「変えるのが難しいもの」と捉え、アーキテクトの仕事はチームから設計を取り上げることではなく、チームの設計能力を上げることだと整理しています。現在の求人票でも、実装を続けるアーキテクトを求める例が主流です。

国内では、情報処理技術者試験の区分名が2009年にシステムアーキテクト試験へ改称され、呼称が定着しました。ただし国内では、SIer の上流工程担当を指す用法と、事業会社で自社プロダクトの構造を設計する用法の両方があり、求人票では業務内容の確認が必要です。

ミッション

責任範囲は、後から変えにくい判断を誤らないことです。フレームワークの選択、サービスの分割、データの持ち方、外部との連携方式といった、実装が進むほど戻せなくなる決定に責任を持ちます。

同時に、判断の理由を残すことが職務に含まれます。図だけを渡しても、前提が変わったときに再判断できません。何を捨てて何を採ったかを文書に残すところまでが成果です。

主な業務範囲

全体構造の設計。システムの分割、責務の割り当て、連携方式を決める
非機能要件の設計。性能・可用性・拡張性・セキュリティの目標と実現方法を定める
技術選定。フレームワークやミドルウェアを比較し、選択と不採用の理由を残す
設計レビュー。各チームの設計が全体の方針と整合しているかを確認する
移行の計画。既存システムからの段階的な移行の手順とリスクを設計する

求められる能力

技術面では、複数のアーキテクチャスタイルを比較して選べることが前提です。分散システムの制約、データ整合性、障害時の挙動といった、選択の帰結を具体的に説明できる必要があります。

技術以外では、書いて伝える力が中心になります。設計文書、意思決定の記録、レビューでの説明のいずれも、文章の質がそのまま伝達の質になります。事業側の制約を設計へ翻訳する力も欠かせません。

この職種に就く人のキャリア経路

多いのはバックエンドやインフラで設計を担ってきたエンジニアからの移行です。SIer では上流工程の担当として早い段階から任される経路もあります。

Principal Engineer や CTO へ進む例が代表的です。顧客向けの構成設計へ移り、ソリューションアーキテクトになる人もいます。

隣接職種との違い

職種	責任の中心	ソフトウェアアーキテクトとの違い
テックリード	担当チームの技術判断	単位がチーム。アーキテクトはシステム全体の構造が対象
Staff Engineer	チームを越えた技術課題の解決	課題の発見から着地まで。アーキテクトは構造の設計が職務
ソリューションアーキテクト	顧客への提案段階での技術構成	対象が顧客のシステム。ソフトウェアアーキテクトは自社システムを扱う
Principal Engineer	全社の技術方針と長期の技術投資	投資と組織まで含む。アーキテクトは設計に軸足を置く

採用担当の見極めポイント

求人票では、実装を続けるかどうかを明記してください。設計専任を想定していると、実装したい候補者は応募しません
職務経歴書では、設計が運用に乗った後の経験を確認してください。設計しただけの経験と、運用で問題が出てから直した経験では、判断の深さが変わります
既存システムの状態を伝えてください。新規設計か、動いているシステムの改善かで、必要な経験が異なります

求人・市場の傾向

呼称の指す範囲が広く、SIer の上流担当と事業会社の設計担当が同じ職種名で並びます。実際の件数は媒体ごとの職種カテゴリの定義で変わるので、自社が使う媒体の検索結果で確認してください。

設計専任か、実装を続けるか。この一点が書かれていないと、応募の段階で見送られます。