ソリューションアーキテクトの職務経歴書の書き方｜書類通過率を上げる実例テンプレート
ソリューションアーキテクト（SA）の職務経歴書は、「何を設計したか」だけでなく「なぜその設計を選び、どのようなビジネス成果に結びつけたか」を体系的に示すことが、書類通過率を左右する。採用担当者やテクニカルレビュアーが一読して技術的な深さとビジネス感覚の両立を確認できる構成こそが、選考を前に進める職務経歴書の骨格である。
以下では、SAとしての経験を採用側が求める観点へ変換するための構成論、各セクションの記述ポイント、そして実例の型を順に解説する。
ソリューションアーキテクトの職務経歴書が難しい理由
SAは職種として幅が広い。クラウドベンダーのプリセールスSA、SIerの上流設計担当、SaaS企業のソリューションエンジニア、事業会社のエンタープライズアーキテクト——いずれも「SA」と名乗るケースがある。そのため、職務経歴書に記した業務内容が、応募先の文脈で適切に解釈されないリスクが高い。
加えて、SAの仕事は成果の可視化が難しい。受注した・構築したという明確な数値が残りやすいセールスやエンジニアと異なり、「設計の妥当性」「顧客との合意形成の質」「長期的なアーキテクチャ判断の正しさ」は定量化しにくい。
こうした特性を踏まえると、SAの職務経歴書で意識すべき軸は以下の3点に絞られる。
- スコープの明示：どの工程・範囲を担ったか
- 判断の根拠：なぜその技術選定・アーキテクチャを採用したか
- ビジネスへの接続：設計の結果、顧客や自社にどのような価値が生まれたか
この3軸が揃わない職務経歴書は、どれほど技術的に高度な内容を書いていても「すごそうだが評価しにくい」という印象で止まりやすい。
全体構成の推奨フォーマット
職務経歴書のページ数はA4で2〜3枚が目安である。3枚を超えると重要情報が埋もれる傾向があり、1枚にまとめようとすると技術的な深さが失われる。
推奨する構成は以下のとおりである。
| セクション | 内容 | 目安の分量 |
|---|---|---|
| ①プロフィールサマリー | 技術領域・経験年数・強みを3〜5文で要約 | 5〜8行 |
| ②スキルセット | 技術スタック・資格・言語を構造化して列挙 | 表形式 |
| ③職歴詳細 | 企業・期間・役割・案件ごとの詳細 | 中核部分 |
| ④保有資格・認定 | クラウド認定資格等を網羅 | 箇条書き |
| ⑤学歴 | 最終学歴のみで可 | 1〜2行 |
このうち③が全体の7割程度を占めるべきであり、ここに3軸の情報を集中させる。
各セクションの記述ポイント
プロフィールサマリーの書き方
サマリーは採用担当者が最初に目を通す箇所であり、「技術的な信頼性」と「ビジネス感覚」の両方が伝わる内容にする。
避けるべき表現の例：「クラウドを活用したシステム構築の経験があります」 改善後の例：「エンタープライズ向けマルチクラウド環境の設計を主軸に、プリセールスから本番稼働後の最適化まで一気通貫で担当してきました。直近3年は製造業・小売業の顧客に対するクラウドマイグレーション案件をリードし、オンプレミスから段階的移行する際のリスク設計と運用コスト削減の両立を得意としています」
後者は応募先が「この人物に何を期待できるか」を具体的に判断できる。
スキルセットの構造化
技術スキルを羅列するだけでは読み手が評価できない。「経験年数」「関与の深さ」を付記することで信頼性が増す。
| 領域 | 技術・ツール | 経験年数の目安 | 関与レベル |
|---|---|---|---|
| クラウドインフラ | AWS（EC2, RDS, VPC, CloudFormation） | 5年程度 | 設計・実装・レビュー |
| クラウドインフラ | Azure（仮想ネットワーク, AKS） | 2年程度 | 設計・提案 |
| アーキテクチャ設計 | マイクロサービス, イベント駆動アーキテクチャ | 3年程度 | 主担当 |
| セキュリティ | ゼロトラスト設計, IAM設計 | 3年程度 | 設計・レビュー |
| プリセールス | 提案書作成, PoC設計・実施 | 4年程度 | 主担当 |
このような形式にすることで、技術的な幅と深さのバランスが視覚的に伝わる。
職歴詳細の書き方：STAR+Tフレームワーク
SAの職歴詳細には、一般的なSTARフレーム（状況・課題・行動・結果）に「T：技術的判断の根拠」を加えた「STAR+T」の形式が適している。
記述要素
- Situation（状況）：顧客の業種、規模、既存システムの状況
- Task（課題）：解決すべきビジネス・技術課題
- Action（行動）：自分が設計・提案・実施したこと（他者との役割分担を明記）
- Result（結果）：定量・定性両面の成果
- Technical Rationale（技術的根拠）：なぜその設計を選んだか、代替案との比較
この枠組みに沿うと、単なる作業記録ではなく「判断の履歴」として読めるようになる。
実例の型：ケーススタディ形式の職歴記述
以下は、あるSA経験者の職歴記述を実例の型として示したものである。固有の企業名・数値は架空だが、構成の参考として活用できる。
【会社名】 クラウドインテグレーター A社（従業員500名規模） 【在籍期間】 20XX年4月〜20YY年3月（3年間） 【役職・役割】 シニアソリューションアーキテクト（チームリード）
主要プロジェクト：大手流通業者の基幹系クラウドマイグレーション
- 状況：国内売上高数千億円規模の流通企業が、老朽化したオンプレミス基幹システムのクラウド移行を検討。既存システムはメインフレームと複数のサードパーティパッケージが密結合した構成で、移行リスクが高い状態だった。
- 課題：一括移行は停止リスクが許容できないため、段階的移行の設計が必要。かつ移行後の運用コストを現行比20〜30%削減することが経営上の要件だった。
- 行動（自分の担当範囲）：アーキテクチャ設計のリードを担当。フロントエンドシステムから段階的に移行するストラングラーフィグパターンを採用し、メインフレームとの一時的な共存を可能にするAPIゲートウェイ層を設計した。PoC実施においては自ら構成管理コードを記述し、再現性を担保した。プロジェクトマネージャーおよびセキュリティエンジニアと3者体制で推進。
- 技術的根拠：完全リプレイスはビジネス継続性の観点からリスクが高く、リフトアンドシフトのみではコスト削減目標を達成できないと判断。段階的なリアーキテクチャを可能にするアプローチとして、既存コードへの変更を最小化しながらクラウドネイティブな拡張を行えるパターンを選択した。
- 結果：移行完了後、インフラ運用コストが対前年比で概ね25%削減（顧客提示のレポートによる）。無停止での移行を実現し、顧客の次フェーズ案件にも継続して参画。
この型の特徴は「自分が何を判断し、なぜその選択をしたか」が明示されている点にある。同様の記述を2〜3案件分揃えることで、職歴詳細として十分な厚みが生まれる。
書類通過率を下げやすい記述パターン
SAの職務経歴書でよく見られる、採点が難しくなる記述のパターンを整理する。
| 問題のある記述パターン | 採用担当者側の解釈 | 改善の方向性 |
|---|---|---|
| 「クラウド全般の設計に携わった」 | スコープが不明で評価できない | 具体的なサービス・工程を明記する |
| 「チームとして〇〇を達成した」 | 個人の貢献が見えない | 自分が担当した判断・成果物を明記する |
| 「最新技術を積極的に取り入れた」 | 何を、なぜ採用したかが不明 | 技術選定の根拠を一文加える |
| 資格・認定の列挙のみ | 実務での活用が確認できない | 資格が活かされた案件と紐づける |
| 「顧客満足度向上に貢献した」 | 定性的すぎて評価基準がない | 具体的なフィードバックや継続案件の有無を示す |
よくある質問
Q1. プリセールスSAとデリバリーSAでは職務経歴書の書き方を変えるべきですか？
応募先がどちらの役割を求めているかによって、強調する内容を変えることが適切です。プリセールス色が強い求人であれば、提案数・受注貢献の規模・顧客折衝の経験を前面に出す構成が効果的です。一方、デリバリー寄りのSAを求める求人では、設計の深さ・技術選定の根拠・実装への関与度を中心に据える構成が合います。両方の経験がある場合は、サマリーでその両立を宣言したうえで、案件ごとに役割を明記する方法が有効です。
Q2. 資格（AWS認定等）は職務経歴書のどこに記載すべきですか？
専用の「保有資格」セクションに記載するのが基本ですが、それだけでなく職歴詳細の案件記述と紐づけることで実務的な信頼性が増します。たとえば「AWS認定ソリューションアーキテクト – プロフェッショナルの知識を活用し、マルチアカウント設計を担当した」のように文脈に組み込む方法が効果的です。
Q3. 経験年数が3〜5年の場合、職務経歴書をどのように差別化できますか？
案件の量より「判断の質」を示すことが差別化につながりやすい傾向があります。少ない案件数であっても、技術的根拠・代替案との比較・ビジネス成果の3点が揃っていれば、経験年数が長い候補者と比べて遜色なく評価されるケースがあります。加えて、オープンソースへの貢献・社内勉強会のリード・技術ブログの執筆といった活動を補足することで、技術的な姿勢と学習意欲を補完できます。
Q4. 案件の内容が機密で詳細を書けない場合はどうすれば良いですか？
業種・規模・課題の抽象度を上げることで、機密に触れずに実務の深さを伝えることは可能です。「大手金融機関向け」「国内売上規模〇〇〇億円超の製造業向け」のように業界・規模感を示し、具体的なシステム名や社名を伏せる形式が一般的です。技術的な判断の根拠や自分の役割は機密情報に直接触れないことがほとんどであるため、そこを中心に記述することで情報量を確保できます。
まとめ
ソリューションアーキテクトの職務経歴書は、技術スタックの列挙にとどまらず「なぜその設計を選んだか」という判断の根拠と、それがビジネスにどう結びつい