カテゴリー: 若手インフラSE向け

この記事でわかること

• 「コードを書かないSE」というキャリア観の中身
• 全体設計・PM・インフラリードという役割の共通点
• このキャリア観がプロダクト企画職への転身にどうつながったか

エンジニアのキャリアというと、プログラミングスキルを磨いて技術を極めていくイメージが強いかもしれません。しかし私は、業務の本質はプログラミング実装そのものよりも、全体設計・プロジェクトマネジメント・インフラリードにあると考えてキャリアを築いてきました。この「コードを書かないSE」というキャリア観について書きます。

「コードを書かないSE」とは何か

実装そのものより、全体最適の設計判断に価値を置くキャリアの選び方です。

エンジニア職の中には、コードを書く実装力を磨いていく方向性と、システム全体の設計・調整・意思決定に軸足を置く方向性の、大きく2つの道があります。私は後者を選び、インフラエンジニアとしてのキャリアの中でも、構築作業そのものより「なぜこの設計にするのか」を考え、関係者と合意形成する役割を意識的に担ってきました。

なぜこのキャリア観にたどり着いたか

実装の細部よりも、全体がどう機能するかを考えることに強い興味がありました。

情報系の学生時代から、特定の技術を深く極めるより、複数の技術・関係者・制約をどう組み合わせて全体を成立させるかという問題に関心がありました。インフラエンジニアとしてのキャリアの中で、デジタル庁の法人認証基盤PoCのような大規模プロジェクトのインフラリードを務めた経験が、このキャリア観をより明確にしてくれました。

「コードを書かないSE」に必要なスキル

技術理解・言語化力・調整力の3つが土台になります。

• 技術理解：実装の詳細を自分で書けなくても、技術的な妥当性を判断できる知識
• 言語化力：技術的な判断根拠を、非エンジニアにも伝わる言葉に翻訳する力
• 調整力：異なる立場の関係者の要望を整理し、現実的な着地点を見つける力

これらのスキルは、特定の言語やフレームワークの知識よりも陳腐化しにくく、長期的なキャリア資産になると考えています。

このキャリア観が転身にどうつながったか

インフラリードとして培った「技術×説明責任」の力が、プロダクト企画職でもそのまま活きています。

国内大手メーカーでインフラエンジニアとしてキャリアを積んだ後、国内大手通信企業のプロダクト企画職へ転身しましたが、この「コードを書かないSE」というキャリア観があったからこそ、企画職という選択肢が自然に視野に入りました。実装力ではなく設計・調整・意思決定に価値を置くという軸が、職種を超えて一貫していたからです。

転身の詳しい経緯は転身体験記にまとめています。技術は好きだけど、実装よりも全体設計に興味があるという方には、このキャリア観が一つの参考になれば幸いです。

この記事でわかること

• インフラリードという役割が具体的に何をするのか
• デジタル庁の法人認証基盤PoCで得た学び
• インフラリードに求められる「説明責任」

国内大手メーカーで、Webシステムのインフラ開発・保守・運用を一貫して担当し、その中でデジタル庁が推進する法人認証基盤の民間開放PoCにインフラリードとして参加した経験があります。「インフラリード」という役割が具体的に何をするのか、実体験ベースでまとめます。

インフラリードは「作業者」ではなく「意思決定者」

手を動かす作業よりも、設計判断とその説明責任が中心的な役割です。

インフラエンジニアとして経験を積む中で、リードという立場になって最初に戸惑ったのは、自分で構築作業をすること以上に、「なぜこの構成にするのか」を関係者に説明し、合意形成する役割が中心になることでした。技術的に正しい選択をするだけでなく、コストや運用負荷とのバランスを取りながら、非エンジニアの関係者にも納得してもらえる説明をする力が求められます。

デジタル庁PoCで求められた「高い要求水準」

国の重要インフラに関わるプロジェクトは、通常の商用システム以上に可用性・セキュリティへの要求水準が高いものでした。

法人認証基盤の民間開放PoCは、国の制度に関わる基盤であるため、可用性・セキュリティの両面で厳格な要求水準がありました。設計段階から「なぜこの構成にするのか」を、通常の商用プロジェクト以上に丁寧に説明できるレベルで理解しておく必要があり、この経験を通じてインフラ設計の説明責任という感覚が大きく鍛えられました。

インフラリードに求められる3つの力

技術力・説明力・調整力のバランスが求められます。

• 技術力：可用性・セキュリティ・コストのトレードオフを理解し、適切な設計を選べる力
• 説明力：技術的な妥当性を、非エンジニアにも分かる言葉で説明する力
• 調整力：複数の関係者の要望や制約を整理し、現実的な落としどころを見つける力

この3つの力は、後にプロダクト企画職への転身を考えたときにも、そのまま活きる基礎になりました。

まとめ：インフラリード経験は「技術×説明責任」の訓練になる

インフラリードという役割は、単なる技術力の延長ではなく、技術的な妥当性を事業サイドに翻訳して説明する力を鍛える機会でもあります。この経験がキャリアにどう活きたかは、転身体験記で詳しくまとめています。

この記事でわかること

• 学習サービス・問題集を選ぶときの基準
• 実際に使った教材・サービスの特徴比較
• 資格別のおすすめ組み合わせ

2025年3月にAWS認定資格を3つ（SAA・Security Specialty・SOA）取得した際に実際に使った教材・学習サービスを比較します。実務経験があっても独学だけでは埋まらない知識の抜け漏れを、どう補ったかという視点でまとめています。

学習サービス・問題集を選ぶ基準

実務経験の有無で、必要なアプローチが変わります。

実務でAWSに触れている人は、参考書を通読するより先に問題集で自分の弱点を洗い出す方が効率的です。逆にAWS実務経験が浅い人は、まず参考書でサービス全体像を掴んでから問題演習に入るのがおすすめです。

実際に使った教材・サービス比較

参考書は「ざっくり1周」、学習時間の大半はWeb問題集に充てました。

教材・サービス	種別	特徴
AWS WEB問題集で学習しよう（TechStock）	Web問題集	AWS認定試験の大半の科目をカバー。本試験モードで実際の試験形式に近い演習ができる
AWS認定資格試験テキスト（通称オレンジ本）	参考書	図解が豊富でAWS全体のサービス体系を理解しやすい。章末の練習問題も活用
Udemy	動画講座	セール時に安価で購入可能。ハンズオン形式で実際に手を動かしながら学べる講座が多い

資格別おすすめの組み合わせ

SAAは「参考書→Web問題集」、Security SpecialtyとSOAは「実務知識→Web問題集で穴埋め」が効率的でした。

• SAA：AWS全体像の理解が必要なため、参考書で土台を作ってからWeb問題集で演習する順序がおすすめ
• Security Specialty：実務でのセキュリティ対応経験がある人は、Web問題集で出題傾向を掴み、知識が曖昧な分野だけ参考書で補強する方が効率的
• SOA：運用実務との重なりが大きいため、いきなりWeb問題集から始めて弱点を洗い出す進め方が向いている

独学で挫折しないための学習の進め方

「完璧に理解してから次に進む」のではなく、「問題集を繰り返し解いて知識を定着させる」方針に切り替えたことが効きました。

参考書を完璧に理解しようとすると学習が止まりがちです。7割理解できたら問題集に進み、間違えた問題を通じて知識を補強していく方が、結果的に学習効率が高くなります。

学習ロードマップの詳細は「AWS SAA→Security Specialty→SOAの順で取得して見えたこと」で詳しくまとめています。

この記事でわかること

• 転職エージェントを選ぶときに見るべき3つの比較軸
• インフラ・クラウドエンジニアに強いエージェントの特徴比較
• 企画職などへのキャリアチェンジを見据えたエージェント活用のコツ

私自身、国内大手メーカーのインフラエンジニアから国内大手通信企業のプロダクト企画職へ転職した際、複数の転職エージェントを併用しました。その実体験を踏まえて、インフラ・クラウドエンジニアにおすすめのエージェントを比較します。

転職エージェントを選ぶときの比較軸

「非公開求人の質」「インフラ特化度」「キャリアチェンジ支援の有無」の3つで選びます。

同じ「IT系転職エージェント」でも、得意分野は大きく異なります。インフラ・クラウド領域の求人を厚く持っているか、未経験分野へのキャリアチェンジ支援に慣れているかは、事前にチェックしておくべきポイントです。

おすすめエージェント比較

併用を前提に、特徴の異なる2〜3社に登録するのが効率的です。

エージェント	特徴	こんな人におすすめ
レバテックキャリア	IT特化型。クラウド・ネットワーク・サーバー・セキュリティなどインフラ領域の求人が豊富	インフラ・クラウド専門性を活かして転職したい人
Geekly	IT・Web・ゲーム業界特化。書類添削などサポートが手厚い	書類作成に不安がある人
ハタラクティブ	20代・未経験者向けのIT学習サポートが充実	未経験分野へのキャリアチェンジを考えている人
UZUZ	20代・第二新卒向け、丁寧なカウンセリングに定評	じっくり相談しながら進めたい人

自身が転職活動で実際に使った基準

インフラ経験を「企画職向け」に翻訳して提案してくれるかどうかを重視しました。

インフラ出身での企画職転職は求人数自体が多くないため、複数のエージェントに登録し、それぞれの担当者がどれだけ自分のキャリアの文脈を理解して求人を提案してくれるかを比較しました。単に求人を右から左に流すだけの担当者と、こちらのキャリアの意図を汲んで提案してくれる担当者とでは、その後の転職活動の質が大きく変わります。

未経験からのキャリアチェンジ（企画職）を目指す場合の注意点

「インフラ特化型」と「未経験サポート型」を両方使うのがおすすめです。

インフラ・クラウド特化型のエージェントは専門性の高い求人を持っている一方、未経験領域への転職支援には必ずしも強くありません。逆に未経験サポートが手厚いエージェントは、インフラの専門求人を十分に持っていないこともあります。両方のタイプを併用し、視野を広げることをおすすめします。

まとめ：目的別おすすめの組み合わせ

「インフラを極めたい人」はレバテックキャリア中心、「企画職へ転身したい人」は複数併用がおすすめです。

• そのままインフラ・クラウドエンジニアとしてキャリアを伸ばしたい人 → レバテックキャリアを中心に
• 企画職などへのキャリアチェンジを考えている人 → レバテックキャリア＋ハタラクティブ／UZUZの併用
• 書類作成に不安がある人 → Geeklyのサポートを活用

転身の実体験は「インフラエンジニアからプロダクト企画職へ」で詳しくまとめています。

この記事でわかること

• SAA→Security Specialty→SOAという取得順序を選んだ理由
• 各資格の学習期間の目安とつまずいたポイント
• 現在挑戦中のSAP-C02に向けた学習の進め方
• 資格取得がキャリアチェンジにどう効くか

2025年3月にAWS認定資格を3つ（ソリューションアーキテクト-アソシエイト、セキュリティ-専門知識、SysOpsアドミニストレーター-アソシエイト）取得し、現在はプロフェッショナルレベルのSAP-C02を学習中です。国内大手メーカーでのインフラ実務経験と並行して取得してきたこの3資格について、なぜこの順番で取得したか、それぞれどう学習したかを実体験ベースでまとめます。

なぜこの順番で取得したか

実務で触れる領域に近い資格から順に取得しました。

インフラエンジニアとして日々の業務で最も接点が多かったのが、システム全体のアーキテクチャ設計でした。そのため、まず土台となるソリューションアーキテクト-アソシエイト（SAA）から着手し、その後、業務で重要性を増していたセキュリティ領域（Security Specialty）、最後に運用の専門性を深めるSysOpsアドミニストレーター（SOA）という順で取得しました。実務の延長線上にある知識から資格化していくことで、学習内容がそのまま仕事に還元される好循環を作れました。

SAA（ソリューションアーキテクト-アソシエイト）

AWS全体のサービス体系を理解する、最初の一歩として最適でした。

学習期間は業務の合間を縫って2〜3ヶ月ほど。実務でAWSに触れていたとはいえ、使ったことのないサービス（コスト管理系、移行系のサービス等）の範囲は広く、参考書とWeb問題集を併用して知識の抜け漏れを埋めていきました。実務経験があると有利な反面、「経験があるからこそ自己流の理解で止まってしまう」部分もあり、公式ドキュメントで用語の定義を確認し直す作業が特に効きました。

Security Specialty（セキュリティ-専門知識）

SAAの次にセキュリティを選んだのは、業務でのセキュリティ要件の重みが増していたためです。

デジタル庁の法人認証基盤PoCなど、可用性・セキュリティへの要求水準が高いプロジェクトに関わる中で、IAM設計や暗号化、監査ログの体系的な知識の必要性を強く感じていました。SAAより出題範囲が深く、インシデント対応やコンプライアンスに関する問題も多いため、実務での障害対応・監査対応の経験がそのまま得点力に直結した実感があります。

SOA（SysOpsアドミニストレーター-アソシエイト）

運用エンジニアとしての「当たり前」を、体系的な知識として裏付ける資格です。

日々の運用監視・障害対応・パフォーマンスチューニングの実務内容と最も重なる資格でした。実務経験がある分、対策時間は3資格の中で最も短く済みましたが、CLIコマンドの詳細な仕様など、普段使わないオプションを問われる問題もあり、侮れない試験だと感じました。

現在挑戦中のSAP-C02（ソリューションアーキテクト-プロフェッショナル）に向けて

アソシエイト3資格の知識を土台に、より複雑な要件のアーキテクチャ設計を学んでいます。

コスト最適化・移行戦略・マルチアカウント管理など、単一サービスの知識だけでは解けない複合的な問題が中心です。これまでの3資格がインフラエンジニアとしての実務に直結していたのに対し、SAP-C02は経営・事業視点の判断が絡む場面も多く、今のプロダクト企画職の仕事とも接点を感じながら学習を進めています。

資格取得におすすめの学習法・サービス

参考書とWeb問題集の併用が、最も効率的だと感じています。

具体的にどのサービス・教材を使ったかは、比較記事にまとめています。

資格はキャリアチェンジにどう効くか

「実務経験を体系的な知識として証明できる」ことが、資格の最大の価値でした。

インフラエンジニアから企画職への転職活動でも、AWS資格は技術的な素養を客観的に示す材料として機能しました。資格取得はゴールではなく、実務理解を整理し直すプロセスです。今インフラエンジニアとして働いている方にも、キャリアチェンジを考えている方にも、体系的な棚卸しの手段としておすすめします。

「今のままインフラエンジニアを続けていいのか」「技術は好きだけど、もっと事業やサービス全体に関わりたい」——そんなモヤモヤを抱えているインフラSEの方に向けて、この記事を書いています。

結論から言うと、インフラエンジニアとしての経験は、プロダクト企画職においてむしろ武器になります。私自身、国内大手メーカーでインフラエンジニアとして数年間働いたのち、国内大手通信企業のプロダクト企画職へ転職しました。

この記事でわかること

• 国内大手メーカーで積んだインフラ経験の中身
• 企画職への転職を意識したきっかけ
• 転職活動でインフラ経験をどう「翻訳」してアピールしたか
• 企画職に移って感じた評価軸のギャップと、インフラ経験がどう活きているか

国内大手メーカーで積んだインフラ経験

要件定義から障害対応まで、インフラのライフサイクルをひと通り経験したことが今の土台になっています。

新卒で入社した国内大手メーカーでは、Webシステムのインフラ開発・保守・運用を一貫して担当していました。要件定義からインフラ設計、構築、運用監視、障害対応まで経験できたことは、今振り返っても大きな財産です。

中でも印象に残っているのが、デジタル庁が推進する法人認証基盤の民間開放PoCに、インフラリードとして参加した経験です。国の重要インフラに関わるプロジェクトでは、通常の商用システム以上に可用性・セキュリティへの要求水準が高く、設計段階から「なぜこの構成にするのか」を関係者に説明できるレベルの理解が求められました。この経験が、後にプロダクト企画で「技術的な妥当性を事業サイドに翻訳して説明する」場面で活きることになります。

なぜ企画職への転職を考えたのか

「自分がやっているのは全体のごく一部だ」という感覚が、キャリアを見直すきっかけでした。

インフラエンジニアとしての仕事にやりがいを感じる一方で、次第に強くなっていったのが、どのサービスをどう作るか、何を優先するかという意思決定には直接関与できないという感覚でした。

私は元々、業務の本質はプログラミング実装そのものよりも、全体設計やプロジェクトマネジメントにあると感じていました。「コードを書かないSE」というキャリアの選択肢を強く意識するようになったのも、ちょうどこの頃です。インフラの技術理解を持ったまま、事業の意思決定に近いところで動ける仕事はないか——そう考えたときに選択肢として浮かんだのが、プロダクト企画職でした。

転職活動で意識したこと

作業内容ではなく、「なぜその設計にしたのか」という意思決定のプロセスを言語化することが鍵でした。

「サーバーを構築・運用していました」だけでは、企画職としての適性は伝わりません。可用性要件とコストのバランスをどう取ったか、障害発生時に何を優先して対応したか——こうしたエピソードは、そのままプロダクト企画で求められる「複数の制約の中で最適な意思決定をする力」の証明になります。

転職エージェントも複数活用しましたが、インフラ出身での企画職転職は求人数自体が多くないため、エージェント選びも重要なポイントでした。

国内大手通信企業の企画職に転職して感じたギャップと共通点

「止めないこと」重視のインフラ時代から、「早く仮説を検証する」企画職へ。評価軸は大きく変わりました。

実際に国内大手通信企業のプロダクト企画職として働き始めて感じたのは、評価軸の違いです。最初はこのスピード感の違いに戸惑いましたが、技術理解があることは想像以上に武器になりました。エンジニアチームと会話する際に実現可能性や工数感を自分で判断できるため、企画とエンジニアの間の「翻訳」がスムーズになります。

インフラ経験がプロダクト企画でどう活きているか

技術的な裏付けを持って企画議論に参加できることが、最大の強みです。

新機能の企画段階で「このデータをどう扱うか」「システム間の連携はどう設計すべきか」といった議論に、技術的な裏付けを持って参加できることが大きな強みになっています（担当している具体的なサービス内容はここでは伏せますが、社内のエンジニアチームとの折衝で技術理解が直接役立つ場面は日常的にあります）。インフラ経験を積んだ上で企画職を目指すという選択は、決して遠回りではありません。

これからインフラSEからキャリアチェンジを考える人へ

「なぜその設計にしたのか」を言語化する習慣が、企画職への転身における最大の武器になります。

日々の業務の中にある意思決定プロセスを言語化する習慣に加えて、AWSなどのクラウド資格を取得しておくことも技術的な裏付けとして有効です。私自身、AWS認定資格を段階的に取得してきましたが、その過程で得た知識体系は、今の企画職の仕事でも折に触れて役立っています。インフラエンジニアとしての経験は、決して閉じたキャリアではありません。