筑波大学大学院を卒業後、海外駐在を経て、KPMGコンサルティング株式会社に参画。先端技術・DXコンサルタントとして、官民のDX推進・新規事業創出に携わる。その後、リメディからのヘッドハントを受け参画。リメディでは、緻密なキャリア設計・徹底的な選考対策・自身の経験に裏打ちされた深い業務知見を軸とした支援により、コンサルティングファームへの支援に圧倒的な強みを持つ。IT領域を中心に広範な領域で実績を有するが、特にDX領域のエグゼクティブ層支援において業界トップクラスの支援実績を有する。
開発や基盤構築からITアーキテクトへ進むなら、設計対象と入社時の責任で求人を選びます。2026年10月の公式募集では、企業グループの共通基盤、公共案件のアプリケーション方式、SIerのAI・データ基盤で、任される判断と必要な経験が異なります。
クラウド・インフラ、アプリ開発、データ基盤、技術リードやPMを経験してきた人も、製品名や職種名の一致だけでは応募先を決められません。誰の課題を解き、どの方式を決め、実装や運用にどこまで関わるかまで照合してください。
ITアーキテクト求人は、設計対象と入社時の責任で選ぶ
共通基盤を検討する候補枠と、顧客の方式設計を主導する経験者枠では、入社後の期待が違います。次の公式募集では、技術領域に加えて、誰と設計を進め、入社時に何を任されるかも確認してください。
| 募集例・勤務先の立場 | 設計する対象 | 入社時に任される仕事 |
|---|---|---|
| オリックス・システム 企業グループのIT | クラウド、データ活用・AIを含むグループ共通基盤や開発標準 | アーキテクト候補として、先輩と構成を検討し、構想から導入まで経験する |
| ULSパブリス 公共の発注者を支援するITコンサルティング | 自治体等のシステム刷新の方式、アプリケーション共通基盤 | 顧客の技術判断を支え、方式設計や提案・レビュー、基盤の開発・移行を主導する |
| クレスコ 顧客のシステムを担うSIer | AI・データ活用の構成、データ基盤、AIアプリケーションの統合・運用 | 業務要件を受けて構成を設計し、基盤構築、技術選定や検証などを進める |
IPAのITスキル標準の説明は、要素技術を知っていることだけでなく、課題に合わせて選択・統合・適用する実務能力を重視しています。求人選びでも、使う技術の一覧と、自分が決める設計の範囲を分けて確認しましょう。
基盤構築を深めるか、アプリの方式を主導するか、AI・データの統合を担うかで、職歴の強調点は変わります。自分の経験に近い設計対象と、次に任されたい責任を整理してから、技術職の転職を相談する相手を選べます。
候補枠と経験者枠で異なる必須条件を読む
「候補」と書かれた求人も、実務未経験の募集とは限りません。オリックス・システムは開発またはITインフラの実務に加え、上流からリリースまでの工程、クラウド、関係者との推進、技術資料の経験を必須としています。
| 募集例 | 必須条件の全体 | 歓迎条件の例 |
|---|---|---|
| オリックス・システム ITアーキテクト候補 | 開発またはITインフラで3年以上。加えて、要件定義から設計・構築・リリースまでのプロジェクト、パブリッククラウドでの開発または基盤構築、利用部門やベンダーとの推進、設計書や提案資料の作成がすべて必要 | クラウド設計・選定への意欲、上流経験、共通基盤・標準化・自動化、アーキテクトやテックリード等の経験、クラウド等の資格 |
| ULSパブリス 札幌ITアーキテクト | 開発5年以上、技術チームのリーダー、複数フレームワークの利用またはフレームワーク選定、業務システムまたは基盤系システムの開発のすべて | 自治体の業務系開発、共通アプリ基盤の導入・開発・利用支援、開発ルールや統制、提案時の技術支援 |
| クレスコ ITアーキテクト（AI & Data領域） | データアーキテクチャの設計、クラウド上のデータ基盤構築、Python・SQLなどの実装、機械学習やAIモデルを使ったアプリ開発プロジェクトの実務のすべて | データガバナンスやメタデータ管理、MLOps・DataOps、コンテナを使う設計、コンサルティングやSIerでのアーキテクト経験 |
クレスコのクラウド基盤経験は、AWS・Azure・GCPのいずれかです。実装経験の記述は「Python／SQLなど」で、両言語のすべてを必須とする条件へ読み替えないようにします。データ基盤の経験と、AIモデルを使うアプリ開発の経験は別項目です。
ULSパブリスのフレームワーク要件も、複数の利用経験か選定経験のいずれかです。年数だけを見て応募判断をせず、技術リーダーとして何を決め、どの開発を経験したかを照合してください。
企業内の共通基盤、発注者支援、SIerで誰と設計を決めるか
勤務先の立場によって、設計の相手と判断を進める方法が変わります。企業グループのITでは利用部門やベンダー、発注者支援では顧客の業務・システム部門と開発ベンダー、SIerでは顧客や社内の開発関係者が主な接点になります。
グループの共通基盤は、個別要望と共通ルールの両方を扱う
オリックス・システムが募集するのは、グループ各社の課題に応じた構成の検討と、共通基盤・開発標準の整備を担う仕事です。個別システムを作った経験を説明するときも、共通化した部分や、利用部門との調整を振り返ると応募先で生かせる経験を具体的に説明できます。
将来のIT戦略やグループ全体のアーキテクチャを主導する期待は、入社時から最終決定権を持つという意味ではありません。配属や業務の確定後通知の注記もあり、最初に任される案件と先輩との分担は選考で確認します。
発注者支援は、提案に加えて後続の開発まで読む
ULSパブリスが募集するのは、公共の発注者を支援する立場から方式を設計し、顧客やベンダーへの提案・レビューを行う職務です。共通アプリ基盤の基本設計、開発、テスト、移行も含まれます。プロジェクトの進捗管理だけを行う役割とは範囲が異なります。
企業内のITと顧客支援の立場そのものを比較したい場合は、社内SEとITコンサルの違いも判断材料です。発注者側を支援する民間企業への転職と、顧客組織に直接雇用されることは区別してください。
AI・データ基盤は、業務要件から統合・運用までを扱う
クレスコの募集は、データ基盤の設計・構築に加え、機械学習モデルやAIアプリケーションの統合・運用設計を含みます。AIモデルを動かす検証と、業務で使う構成へ組み込む経験を区別すると、担当できる範囲を説明できます。
SIerとコンサルティングでの案件への関わり方は、SIerとITコンサルのビジネスモデルの違いで比べられます。ただし、業態の名称だけで実装を担当するかどうかを決めず、募集する職務の記述を優先してください。
インフラ・アプリ・データ・PM経験から応募候補を絞る
応募候補は、担当した技術と、自分が決めた設計が重なる募集から絞ります。次の表に示す対応関係は公式要件を踏まえたリメディの見解で、経歴だけによる採用可否を示すものではありません。
| 経験 | 照合したい実務 | 足りない場合に確かめること |
|---|---|---|
| クラウド・インフラ構築 | 要件や制約から構成を選び、利用部門やベンダーと導入を進めた経験 | 既定の構成を作った範囲と、標準や方式を検討した範囲の違い |
| アプリ開発・技術リード | フレームワークの比較、共通機能の設計、技術レビュー、後続開発への展開 | チーム運営と、方式の決定・技術上の責任を分けて説明できるか |
| データ基盤・AI開発 | データの構造、クラウド基盤、実装、モデルやアプリの統合・運用 | 基盤構築だけか、AIを使うアプリ開発の実務まで経験したか |
| PM・プロジェクト推進 | 性能・運用・費用等の制約を踏まえた技術提案と設計判断 | 進捗・予算管理とは別に、実際に決めた方式と技術資料を説明できるか |
PMやテックリードの肩書きがあっても、技術判断を別の担当者に任せていたなら、その分担を記します。自分で決めた方式が少ない場合は、候補枠で補える範囲と、入社前に求める実務を照合してください。
資格や個人の学習で得た知識は、職務上の設計経験と区別できます。実務が不足する項目については、現職で担当できる設計・検証を増やすか、補佐として経験を積める募集を探すかを検討してください。
職務経歴書は、技術を採用した理由と実装後の結果を書く
技術の一覧に、採用した理由、他の案を見送った理由、検証と運用への引継ぎを添えます。実装後の状況まで説明すると、設計時の判断がどの結果につながったかを読み取れます。
製品名の列挙を、制約と選択の説明に変える
「クラウド基盤を設計・構築」とだけ書くと、何を決めたかが分かりません。実際の経験に合わせ、「利用部門と可用性・運用の条件を整理し、構成案を比較。検証した結果をもとに案を提案し、承認後の構築と運用担当への引継ぎまで担当した」のように補えます。これは記載方法の作成例であり、実在する候補者の経歴ではありません。
自分が最終承認者でない場合は、検討・提案した範囲と承認者を明示します。費用や障害の改善を数値で示すなら、対象範囲と比較期間、実際の測定記録を揃え、それが設計変更だけによる効果だと決めつけないようにしてください。
説明用の構成図と方式比較を準備する
- 構成図：利用者、処理やデータの流れ、外部との接点、運用上の分担を整理する。
- 方式の比較：制約、採用案と代替案、選択理由、検証結果、残った課題を記す。
- レビューの経緯：誰が何を確認し、自分がどの指摘を受けて設計を変えたかをまとめる。
資料は機密を含まない説明用として自分で再構成します。現職の構成図や顧客のシステム情報をそのまま持ち出さず、担当した判断の筋道を伝える資料にしてください。
設計経験を具体化できたら、コンサル、開発、インフラ、PMなどの職種条件から求人を探せます。検索結果はITアーキテクト専用ではないため、方式を決める役割か、実装への関与があるかを個別の募集要項で確認してください。
リモート・勤務地・報酬は、設計の役割と別に照合する
リモート勤務が可能でも、出社や顧客先への訪問がある募集があります。勤務地や勤務方法を、設計する技術領域とは別の応募条件として確認します。
- オリックス・システム：在宅勤務は可能ですが、週3日以上の出社が必須です。
- ULSパブリス：札幌や近隣の在住者を想定。リモートも可能ですが、週2〜3日以上の出社や客先訪問を想定し、定期訪問・出張の可能性もあります。
- クレスコ：品川の勤務地に加え、都内を中心とした客先常駐の記載があります。
いずれも正社員の募集です。ULSパブリスの公共案件への関与は、自治体に直接雇用されることを意味しません。勤務地、顧客との打合せ、実装チームとの働き方まで希望と合わせてください。
報酬を比較する場合は、月給と賞与、手当の対象、時間外の扱いを分けて確認してください。オリックス・システムの提示目安は諸手当・賞与を含み、住宅手当には対象の規程があります。ULSパブリスは月給にみなし残業手当を含み、専門業務型裁量労働制を記載しています。
クレスコの提示額には想定した時間外手当が含まれますが、時間外手当等は実績に応じて全額支給と記載されています。これを固定残業代の制度と読み替えず、オファー時に基本給や手当、適用制度を照合してください。出典は前掲の各社公式採用ページです。
面接では、技術の正解より制約下の判断を話す
職歴に書いた案件について、制約、選択肢、提案、承認、実装後の確認を順に説明できるよう準備します。以下は募集要項の職務から作った問いであり、企業の過去出題ではありません。
- 技術的には可能でも採用しなかった案は何か。費用や運用負荷など、どの制約で決めたか。
- 性能や可用性の要望が競合したとき、誰と優先順位を決め、何を検証したか。
- 利用部門やベンダーが異なる案を推したとき、どの情報で提案し、誰が最終的に承認したか。
- 移行・運用で想定外の問題が起きたとき、設計のどこを見直し、未解決のリスクをどう引き継いだか。
ULSパブリスは共通基盤の開発・テスト・移行まで職務に含め、クレスコは実装とAI開発の経験を求めています。方式を考える仕事へ進むときも、実装後の問題をどこまで自分で追いたいかを整理すると、希望する設計の役割が具体的になります。
AIを専門に設計する仕事を中心に検討するなら、AIアーキテクトの仕事内容・必要スキルも参照できます。AIの利用経験があることと、データやシステム全体の統合を担当した経験は区別して伝えてください。
求人を自分で比べられる場合と、役割を相談したい場合
設計対象、必須経験、入社時の担当、勤務地が読み取れ、自分の案件と対応するなら、求人ごとの違いを整理して応募準備を進められます。説明用の構成図と方式比較を作り、自分で判断した内容を確かめてください。
候補枠と即戦力枠のどちらが近いか分からない、職種名は合うが決定権や実装担当が曖昧、企業内と顧客支援の立場で迷う場合は、応募前に役割をすり合わせる余地があります。技術名の一致だけで候補を増やすより、任されたい判断を言葉にすると比較が進みます。
担当した設計と、次に担いたい仕事を応募候補の募集要項と並べると、相談する論点を絞れます。利用部門との企画、顧客への方式提案、AI・データの統合のうち迷う点を整理し、技術職のキャリアを相談する担当者を選んでください。
ITアーキテクトの求人選びでよくある質問
クラウド資格があればアーキテクト求人へ応募できますか？
資格を歓迎する募集はありますが、実務要件とは別です。オリックス・システムの候補枠も開発等の経験、クラウド、上流からリリース、関係者との推進、技術文書を求めています。資格と実務を分けて照合してください。
「候補」の求人なら設計未経験でもよいですか？
候補という名称だけでは決められません。先輩と検討する役割でも、どこまでの開発・構築・上流経験を入社時に求めるかを読みます。担当した工程と不足している設計経験を整理してください。
開発経験が少ないPMは、何を確認すればよいですか？
技術方式を自分で検討・提案した経験があるか、必要な開発経験を満たすかを確かめます。進捗管理を担当した経験と、設計や実装を経験したことは分けて記載してください。
ITアーキテクトは完全在宅で働けますか？
勤務方法は求人によるため、今回の募集例にある出社必須、客先訪問、常駐の記載も個別に確認してください。リモート可の表示だけで判断せず、勤務場所と出社・訪問の条件を照合しましょう。
英語は必須ですか？
応募先や担当する案件によります。英語資料の読解や会議での使用など、必要な場面を確認してください。職種名やクラウド製品名から、各社の語学条件を補わず募集要項を優先します。
エンタープライズアーキテクトと同じ求人ですか？
名称だけでは同じ役割と判断できません。全社のIT方針やシステム間の関係まで扱うのか、特定の基盤やアプリケーション方式を扱うのかを確認します。将来の全体戦略への関与と、入社時の設計担当も区別してください。
オリックス・システムの候補枠でも、要件定義からリリースまでの経験や、技術文書の作成が条件です。使ったサービス名に加え、制約をどう整理し、構成をどう検討したかを説明できる案件を振り返ると、応募条件と照合できます。