アーキテクトとして参画するには｜業務委託で任される範囲と、見られる経験の積み方

アーキテクトとして参画するには、システム全体の構造と方式を、性能・可用性・セキュリティ・費用などのかね合いを説明しながら決めた経験を示せることが入口になります。図を描けることより、「なぜその構成にしたのか」「ほかの案をなぜ採らなかったのか」「運用に入ってから設計がどう働いたか」を話せるかが見られます。

この記事では、業務委託のアーキテクトが任される範囲、公的な人材像、見られやすい経験、設計者やテックリードから広げる道、案件を選ぶときの確認点、スキルシートと面談での示し方を順に説明します。

アーキテクトの案件で任される範囲

アーキテクトという呼び名も、案件によって指す範囲が違います。よく見られる案件の形を分けると、次のようになります。

一つの開発チームの中で技術の判断を担うテックリードに比べ、アーキテクトは複数のチームやシステムにまたがる判断を任されることが多くなります。また、要件定義や基本設計などの上流工程から関わることが多い点も特徴です。テックリードについてはテックリードとして参画する記事、上流工程への広げ方は上流工程の記事で扱っています。

公的な人材像を手がかりにする

アーキテクトの役割を考えるときは、IPA（情報処理推進機構）の情報処理技術者試験の一つ、システムアーキテクト試験の「対象者像」も手がかりになります。IPAは、この試験の対象者を、ITストラテジストの提案を受けて、情報システムに必要な要件を定義し、それを実現するアーキテクチャを設計して開発を主導する人として示しています。

あわせて示されている業務と役割には、次のようなものがあります。

• 全体最適の観点から、対象システムの構造を設計する
• 開発に必要な要件を分析・整理し、取りまとめる
• 要件を実現し、情報セキュリティを確保できる最適なシステム方式を設計する
• 品質とセキュリティを確保した設計・開発・テスト・運用・保守を検討し、システムを開発する
• 対象システムとその効果を評価する

構造を設計するだけでなく、要件をまとめ、開発を主導し、出来上がったシステムの効果まで評価する役割として描かれている点が参考になります。

なお、IPAは2027年度から試験制度を見直す予定で、応用情報技術者試験と高度試験を統合・再編して「プロフェッショナルデジタルスキル試験」（仮称）を新設し、「マネジメント領域」「データ・AI領域」「システム領域」の3つの区分とする案を2026年3月に示しています。案は検討中で、今後変わる場合があります（2026年10月時点）。受験を考えている場合は、IPAの公式ページで最新の情報をご確認ください。資格全体の位置づけは資格の記事で扱っています。

アーキテクトの案件で見られやすい経験

1. 非機能の要件を、数字で決めた経験

応答の速さ、同時に使う人数、止まってよい時間、データを戻せる時点など、機能以外の要件を、発注側と話し合って数字で決めた経験です。要件があいまいなまま設計に進むと、後で構成を作り直すことになりかねません。何を決めずにおくと困るかを分かっていることが見られます。

2. かね合いを説明して構成を選んだ経験

性能を上げれば費用が増え、可用性を上げれば構成が複雑になります。こうしたかね合いを、発注側が判断できるよう選択肢として示し、選んだ理由を文書に残した経験です。

3. 既存のシステムとつないだ・移した経験

新しく作るだけの案件は多くありません。古いシステムと連携させたり、データを移したり、段階的に切り替えたりした経験は、刷新の案件で重く見られます。

4. 運用に入ったあとまで見届けた経験

設計が運用に入ってからどう働いたか、想定と違ったところをどう直したかを話せる経験です。障害や性能の問題をきっかけに設計を見直した経験も含みます。運用の考え方はSREのスキルの記事、クラウドの設計で見られるスキルはAWSのスキルの記事で扱っています。

5. 設計を文書にし、他の人に引き継いだ経験

構成図に加えて、方式の判断とその理由、前提にした条件を文書に残し、開発チームや運用チームが迷わず使える形にした経験です。

設計者・テックリードからアーキテクトへ広げる道

アーキテクトの経験も、今の案件の中で少しずつ積めます。次の順で広げると、経験として示しやすくなります。

1. 非機能の設計を担う：性能試験の計画や、バックアップ・監視の設計など、機能以外の設計を担当する
2. 方式設計の一部を任される：認証の方式、外部とのつなぎ方など、一つの方式の検討を受け持つ
3. 設計のレビューに入る：ほかの人の設計を、全体の構造との整合の観点から確かめる
4. 全体の構成の検討に加わる：構成の候補を比べる場に入り、検討の資料づくりを担う

インフラ側から広げる人は、構成を作った経験に、アプリケーションやデータの設計の知識を足すと、全体を見る役割に近づきます。アプリケーション側から広げる人は、基盤・ネットワーク・運用の知識を足すと、非機能の判断ができるようになります。

案件を選ぶときに確かめること

アーキテクトの案件は、同じ呼び名でも、任される範囲と責任の重さが大きく違います。参画前に次の点を確かめます。

• だれが最終的に決めるか：自分が構成を決めるのか、発注側の判断を支える立場なのか
• 何を成果物とするか：設計書を納めるのか、検討の支援や助言が中心なのか
• 実装にどこまで関わるか：設計のあと、開発チームの相談相手として残るのか、設計で終わるのか
• 関わる範囲：ほかのベンダーやチームの設計まで見るのか

成果物の扱いは、契約の形とも関係します。設計書の完成を約束する請負の形と、検討の作業そのものを引き受ける準委任の形では、責任の範囲が変わります。違いは準委任と請負の記事で整理しています。

スキルシートと面談での示し方

スキルシートに書くこと

アーキテクトの経験は、使った製品の一覧よりも、何を決めたかで書きます。

• システムの規模と、自分が決めた範囲（全体の構成、ある方式、クラウドの設計など）
• 決めた非機能の要件と、その数字の決め方
• 比べた候補と、選んだ理由を一文
• 運用に入ったあとの結果や、設計の見直し

製品名や技術名は、スキル一覧の欄にまとめ、プロジェクト欄では判断の中身を中心に書くと読みやすくなります。基本の構成はスキルシートの書き方の記事をご覧ください。

面談で話すこと

面談では、ホワイトボードや画面で構成を説明するよう求められることがあります。説明は「前提の要件」「候補」「選んだ構成と理由」「運用に入ってから」の順にすると、かね合いを考えて決めたことが伝わります。発注側の業務や経営の観点から話を広げたい場合は、ITコンサルのスキルの記事も参考になります。

よくある質問

システムアーキテクト試験に合格していないと、アーキテクトの案件には入れませんか？

合格を条件にしている案件ばかりではありません。多くの案件では、実際に構成や方式を決めた経験のほうが重く見られます。試験は、経験を体系的な知識で裏付ける材料として役立つことがあります。制度が見直される予定のため、受験する場合はIPAの最新の案内をご確認ください。

クラウドの経験しかありませんが、アーキテクトを名乗れますか？

クラウドの構成を、要件とかね合いを考えて決めた経験があれば、クラウドの設計を担うアーキテクトの案件に応募できます。全体の方式設計の案件を狙う場合は、アプリケーションやデータ、既存システムとの連携の知識も足しておくと、任される範囲が広がります。

アーキテクトの案件は、実装から離れることになりますか？

案件によります。設計と助言が中心の案件もあれば、自分も実装に関わりながら構成を決める案件もあります。手を動かし続けたい場合は、面談で実装への関わり方を聞き、希望に合うかを確かめます。