資格とキャリア

AWS資格はフリーランスで通用するか|案件要件を読んで会社員のうちに用意したこと

記事内に広告リンクを含みます

結論から言うと

公開されている案件要件を読んだ限り、AWS資格は「必須要件」ではなく「歓迎要件」に置かれていることが多く、資格だけで案件が決まる構造にはなっていません。ただし資格の勉強で身につく範囲は、案件要件に並ぶサービス名を読み解く土台にはなります。私はフリーランスになったことがないため、単価や稼働の実態は書けません。個人差があります。

この記事でわかること

  • 私はフリーランスとして働いたことがない。この記事は案件要件の読み方と準備の話に限定している
  • 案件要件では実務経験が必須要件、資格は歓迎要件に置かれている書き方をよく見かけた
  • 資格の勉強範囲は「案件要件に並ぶサービス名の意味が分かる」レベルまでは届く
  • 会社員のうちにやれることは、担当した構成の棚卸しと、説明できる設計判断の準備
  • 単価・稼働率・保障などの条件は個人差が大きく、エージェントや公式サイトで直接確認するのが確実

「AWS資格を取ったらフリーランスでやっていけますか」という質問を、社内の勉強会のあとに受けたことがあります。

先に正直に書いておきます。私はフリーランスとして働いたことがありません。 私は会社員として、オンプレのサーバ・ネットワーク運用を数年やったあと、社内のAWS移行プロジェクトに移った立場です。SAAとSAPは独学で取りましたが、それを持って独立したわけではありません。

なので、この記事に「フリーランスになったら単価がこうなった」という話は一切書けません。書けるのは、公開されている案件要件をまとまった数読んでみて分かった「資格がどの欄に置かれているか」と、会社員のうちに用意しておくと後で効きそうなものの整理です。

そのつもりで読んでもらえればと思います。実際の単価や稼働の条件は、個人差が非常に大きい領域です。

先に結論

✅ ここだけ読めばOK

  • 案件要件では、実務経験が「必須要件」、資格は「歓迎要件」に置かれている書き方をよく見かけた
  • つまり資格は入口を開ける鍵ではなく、同じ経験年数の中で差を付ける材料に近い
  • ただし資格の勉強範囲は「案件要件に並ぶサービス名の意味が分かる」ところまでは届く。ここは実際に効いた
  • 会社員のうちにやれるのは、担当した構成の棚卸しと、説明できる設計判断の準備
  • 単価・稼働率・契約条件は公開情報からは読み切れない。ここはエージェントに直接聞くしかない

案件要件の中で資格がどこに置かれているか

まず、私が何を見たかをはっきりさせておきます。私が読んだのは、フリーランス向けエージェントや求人サイトで公開されている案件情報の「必須スキル」「歓迎スキル」の欄です。実際に応募したわけでも、面談を受けたわけでもありません。

必須要件に並ぶのは経験年数と担当範囲だった

AWS関連の案件で必須要件として書かれていたのは、だいたい次のような形式でした。

  • AWSを用いたインフラ構築・運用の実務経験(年数指定つき)
  • Linuxサーバの構築・運用経験
  • ネットワーク(VPC・サブネット設計など)の基本的な理解
  • IaC(TerraformやCloudFormation)を用いた構築経験

読んでいて印象的だったのは、必須要件の側に資格名が出てくることがほとんどなかったことです。「AWS認定ソリューションアーキテクト必須」といった書き方は、私が見た範囲ではかなり少数派でした。

一方で歓迎要件のほうには、「AWS認定資格保有者歓迎」という一行が入っていることがそこそこあります。つまり資格は、案件に入るための鍵ではなく、条件が近い人の中で「まあこの人は基礎は押さえているだろう」という補助情報として置かれている、という理解が自然だと感じました。

資格名の指定はほとんど見なかった

これは意外だったのですが、「SAAが必要」「SAPが必要」と資格名まで指定している案件を、私はあまり見ませんでした。多くは「AWS認定資格」という括りです。

ここから言えるのは、フリーランスの案件獲得を目的に資格を選ぶなら、資格名の選択にそこまで神経質になる意味は薄いということです。どの資格を取るかは、案件要件に合わせるよりも、自分が担当したい領域に合わせるほうが素直だと思います。

資格の順番そのものについてはAWS認定はどれから受けるべきかに、12資格を並べて考えた内容を書いています。

⚠️ 注意点

ここに書いたのは、私が公開されている案件情報を読んで受けた印象です。案件情報の書き方はエージェントによって異なり、非公開案件の要件は当然読めていません。実際にどう評価されるかは案件と時期によって変わります。

それでも資格の勉強が効いたと感じた部分

「資格は必須要件じゃない」と書くと、取る意味がないように読めてしまうので、実際に効いたと感じている部分も書いておきます。これは私が社内でAWS移行を担当したときの実感です。

案件要件に並ぶサービス名を読み解ける

案件要件には、サービス名が羅列されていることがよくあります。「ALB、Auto Scaling、RDS、ElastiCache、CloudFront、WAF、Route 53」といった並びです。

SAAの勉強をする前の私は、この羅列を見ても「たぶんWebシステムなんだろう」くらいしか読み取れませんでした。SAAの範囲を一通り通したあとは、同じ羅列から「フロントにCDNとWAFを置いて、ALB配下でスケールさせて、セッションかキャッシュをElastiCacheに逃がしている構成だろう」という当たりが付くようになりました。

これは案件を選ぶときに直接効きます。要件を読んで、自分が担当できそうかどうかを自分で判断できるようになるからです。判断を他人に丸投げしなくて済むというのは、独立を検討するうえでは地味に大きいと思っています。

SAAで実際にどこまでの範囲を扱うかはAWS SAA の出題範囲と配点にまとめています。

担当外の領域に穴があることに気づける

実務でやっていると、担当範囲に知識が偏ります。私の場合はネットワークとサーバ寄りに寄っていて、データベースの可用性設計やコスト最適化の考え方は薄いままでした。

試験の勉強は範囲が決まっているので、自分の穴がどこにあるかを機械的に炙り出せます。「この分野の問題だけ正答率が低い」という形で出てくるので、ごまかしが効きません。

フリーランスとして単独で案件に入るなら、「その領域は担当外なので分かりません」と言える範囲は会社員のときより狭くなるはずです。穴を先に把握しておくこと自体に意味があると考えています。

資格が「効かない」と感じた部分も書いておく

逆に、資格の勉強では埋まらないと感じたのは次のような部分です。

  • 実際の障害対応の勘所(試験に出るのは設計の正解であって、壊れたあとの動き方ではない)
  • 顧客やチームとの合意形成の進め方
  • 見積もりと工数感覚
  • 契約・請求・確定申告といった事業者側の手続き

最後の項目は資格とはまったく無関係ですが、独立を考えるなら避けて通れない部分です。私はここを実地で経験していないので、これ以上具体的なことは書けません。

案件要件でよく見たサービスの組み合わせ

資格の勉強が要件の読解に効く、という話を具体的にしておきます。私が案件情報を読んでいて、繰り返し出てきたと感じた組み合わせを3つ挙げます。

Webサービスの運用・改善寄り

ALB、Auto Scaling、EC2、RDS、ElastiCache、CloudFront、Route 53、CloudWatch といった並びです。既存のWebサービスを運用しながら改善していく案件で見かけました。

この並びを見たときに読み取れるのは、「新規構築ではなく、動いているものを支える側の仕事だろう」という点です。要件に監視系のサービスが入っているかどうかは、運用の比重を測る目安になります。SAAの範囲がほぼそのまま重なるので、SAAを通した人にとっては読みやすい部類だと思います。

コンテナ・IaC寄りのモダナイズ

ECS、EKS、Fargate、Terraform、GitHub Actions、CodePipeline といった並びです。既存の構成をコンテナに寄せる、あるいはCI/CDを整備するという文脈で出てきました。

この系統は、SAAの範囲だけだと厳しいと感じます。IaCとCI/CDは試験でも触れますが、実際に手を動かした経験がないと要件を満たしたことにならないはずです。資格と実務のギャップがいちばん大きく出るのがこの領域だと考えています。

移行・アセスメント寄り

Direct Connect、Transit Gateway、DMS、Storage Gateway、Organizations といった並びです。オンプレからの移行や、既存環境の見直しに関わる案件で見ました。

この系統は、オンプレ側の経験が直接効きます。私自身がオンプレ運用からAWS移行に移った経緯もあって、いちばん現実味を持って読めたのがこの並びでした。SAPの範囲と重なる部分が多く、AWS SAP の出題範囲で扱う移行戦略の話がそのまま出てきます。

3つとも、「サービス名の羅列を見て、どういう仕事かの見当がつく」ことが前提になっています。この見当がつくかどうかが、資格の勉強で変わった部分です。案件を選ぶ側に立つなら、ここは持っておいて損がないと思います。

会社員のうちに用意しておけることの整理

ここからは、「もし自分が独立を検討するなら、会社員のうちに何をやるか」という観点での整理です。私は実際に独立していないので、あくまで準備の設計の話として読んでください。

担当した構成を書き出しておく

これは私が社内でAWS移行の担当になるときに実際にやったことです。それまでに触った環境を、構成レベルで書き出しました。

書き出すときに効いたのは、サービス名の羅列ではなく「規模」と「役割」まで書くことでした。「EC2を触った」ではなく「常時20台規模のWebサーバ群の構成変更とパッチ適用を担当した」という粒度です。粒度を上げると、自分が本当に担当した範囲がどこまでだったかがはっきりします。

やってみると、思っていたより「関わったが説明できない」ものが多いことに気づきました。この気づき自体が準備になります。

説明できる設計判断を用意しておく

案件の面談では、経験の一覧より「なぜそうしたか」を聞かれるはずだと考えています。少なくとも社内で移行担当に手を挙げたときは、そこを聞かれました。

そのため私は、「A案とB案を検討して、こういう理由でA案にした」という形で語れるエピソードを2〜3個用意していました。これは技術スタックが変わっても使い回しが効きます。判断の筋道の話なので、AWSに限った話にならないからです。

このあたりの考え方はクラウドエンジニアへの転職で準備したことにも書いています。会社員の転職を前提に書いたものですが、準備の構造は共通する部分があります。

資格の有効期限を独立のタイミングと合わせて見る

見落としやすいのがここです。AWS認定には有効期限があり、放置すると失効します。会社員のうちは会社の補助で再認定を受けられることがありますが、独立するとその補助は当然なくなります。

有効期限と再認定の考え方はAWS認定の有効期限と再認定に、受験料と会社の補助制度についてはAWS認定の受験料まとめにまとめています。独立を検討しているなら、この2つは先に読んでおいたほうがいいと思います。

手を動かせる検証環境を自分名義で持っておく

会社の環境は、当然ながら辞めた瞬間に使えなくなります。自分名義のアカウントで、小さくてもいいので触り続けられる環境を持っておくのは、独立の準備としては素直な打ち手だと思います。

Route 53やCloudFrontのように、独自ドメインが無いと検証しづらいサービスもあります。私はSAPの勉強のときに、証明書とDNSまわりを自分のドメインで一通り通してみて、ようやく腹落ちしました。

PR

検証用ドメインを確認する

取り扱っているドメインの種類や料金は変動するので、サービス内容は公式サイトで確認してください。

公開情報では埋まらない部分をどう埋めるか

ここまで書いてきて、正直に認めなければいけないことがあります。独立を判断するために本当に必要な情報のほとんどは、公開されている案件情報からは読み取れません。

具体的には、次のようなものです。

  • 自分の経験年数と担当範囲で、実際にどのレンジの案件に入れるのか
  • リモート可の案件がどれくらいあるのか、常駐前提はどの程度残っているのか
  • 稼働が途切れたときに何が起きるのか
  • 契約形態、支払いサイト、保障の有無

これらは案件情報の一覧には書かれていないか、書かれていても「応相談」で終わっています。私はここを実体験として持っていないので、推測で書くことはしません。

現実的な埋め方は、会社員のうちにエージェントに登録して、自分の経歴で何が言われるかを聞いてみることだと思います。登録=独立ではないので、情報収集の段階で使えます。ここは転職エージェントに相談してみるのと構造は同じです。

聞くべきことを先に決めてから登録する

ただ登録しただけだと、返ってくるのは案件一覧のメールで終わってしまう可能性があります。私が転職の相談をしたときの反省でもあるのですが、こちらの質問が曖昧だと、返ってくる答えも一般論になります。

独立の検討段階なら、聞くことを先に決めておいたほうが情報として使えるものが返ってくるはずです。私なら次の5つを用意します。

  • 自分の経歴(担当範囲・年数・使ったサービス)で、いま実際に打診できる案件はどういう種類か
  • リモート可の案件と常駐前提の案件の比率はどれくらいか
  • 参画までにかかる期間はおおよそどれくらいか
  • 契約が終了するときの通知のタイミングはどうなっているか
  • AWS認定を持っていることが、実際の打診で言及されることはあるか

最後の項目は、この記事のテーマそのものです。案件情報の「歓迎要件」に書かれている一行が、実際の商談でどう使われているのかは、外からは絶対に読み取れません。担当者に直接聞くのがいちばん早い部分だと思います。

PR

契約条件や取り扱い案件は時期によって変わるため、最新の内容はMidworksの公式サイトで確認してください。

会社を辞める前に確認しておくこと

これは資格ともAWSとも直接関係しませんが、順番として先に来る話なので書いておきます。

会社員のうちにしか確認できないものがあります。資格の受験費用が会社の補助対象かどうか、再認定を受けるタイミングが在職中に来るかどうか、社内の環境で触れているサービスのうち自分名義では再現できないものはどれか、といった項目です。

私の場合、SAPの再認定の時期と、社内のAWSアカウントで触れる範囲を、独立とは関係なく一度整理したことがあります。そのときに「会社の環境が前提になっている知識」がそれなりにあることに気づきました。マルチアカウント構成の運用や、組織単位のガードレールの設計は、個人のアカウントでは同じ規模を再現できません。

こういう「会社にいるからこそ触れているもの」を洗い出しておくと、在職中に優先して経験を積むべき領域が見えてきます。独立するかどうかを決める前の段階でも、やっておいて損はない作業だと思います。

✅ この記事を読んだ後の次の一歩

資格を取るかどうかで悩むより、「今の自分の経歴で、どういう案件の話が来るのか」を一度確認したほうが判断は早く進みます。フリーランス向けのエージェントでは、AWS案件の必須要件・稼働条件・契約形態を担当者経由で確認できます。独立を決める前の情報収集としても使える部分です。

MidworksでAWS案件の要件を確認する公式サイトへ移動します

私はMidworksを利用したことがないため、保障の内容・手数料・案件数といった条件については書けません。サービスの詳細は公式サイトと担当者への確認でお願いします。契約条件は時期によって変わります。

よくある質問

AWS資格を持っていればフリーランス案件は取れますか

私が読んだ範囲の案件要件では、資格は歓迎要件に置かれ、必須要件には実務経験が書かれていることが多かったです。資格だけで決まる構造ではないと考えています。案件の獲得には個人差があります。

フリーランスを狙うならSAAとSAPのどちらがいいですか

案件要件で資格名まで指定されているものを私はあまり見なかったので、資格名で選ぶ意味は薄いと感じています。担当したい領域に近いほうを選ぶほうが自然だと思います。SAPを取ったあとに何が変わったかはAWS SAP を取る意味はあるかに書いています。

実務未経験でもAWS資格でフリーランスになれますか

私が読んだ案件要件では、実務経験年数が必須要件に書かれていることが多く、未経験からいきなり案件を受けるのは難しいと感じました。未経験からの資格取得については実務未経験でも AWS SAA に受かるかを参考にしてください。ただし試験に受かることと案件に入れることは別の話です。

会社員と比べて収入は上がりますか

私はフリーランスとして働いたことがないため、書けません。会社員側の話であれば、求人票の提示レンジから考えた内容をAWS資格で年収は上がるのかにまとめています。フリーランスの場合は稼働が途切れる期間の扱いも含めて考える必要があるため、単純な比較にはならないと理解しています。

⚠️ 注意点

この記事は、公開されている案件要件を読んだ範囲の整理と、会社員としての私の準備経験をもとにしたものです。フリーランスとしての稼働実績にもとづくものではありません。単価・契約条件・案件の獲得しやすさには個人差があり、時期やスキルセットによっても変わります。AWS認定の制度(試験範囲・受験料・有効期限)は変更される可能性があるため、受験前に公式サイトで最新情報を確認してください。

まとめ

✅ ここだけ読めばOK

  • 私はフリーランス経験がない。この記事は案件要件の読み方と準備の整理に限定している
  • 案件要件では実務経験が必須要件、資格は歓迎要件に置かれている書き方が多かった
  • 資格名まで指定している案件は少数派だった。資格名で悩む優先度は低いと考えている
  • 資格の勉強は「要件のサービス名の羅列から構成を読み取れる」ところまでは効いた
  • 会社員のうちにやれるのは、構成の棚卸し・説明できる設計判断・自分名義の検証環境の確保
  • 単価や契約条件は公開情報から読めない。ここはエージェントに直接聞くのが確実

資格そのものの価値をどう考えるかについては「AWS資格は意味ない」と言われる理由を分解するに、職務経歴書での見せ方はAWS資格を職務経歴書にどう書くかに書いています。独立を考えているなら、経歴の言語化は先に済ませておいて損はないと思います。

繰り返しになりますが、この記事は独立の成功体験ではありません。判断は個人の状況によって変わるものなので、最終的にはご自身で確認したうえで決めてください。

よくある質問

AWS資格を持っていればフリーランス案件は取れますか?

公開されている案件要件を読んだ限り、資格は歓迎要件に置かれ、必須要件には実務経験が書かれていることが多いです。資格だけで決まる構造ではないと考えています。案件の獲得には個人差があります。

フリーランスになるならSAAとSAPのどちらを取るべきですか?

案件要件に「どの資格が必要」と書かれているケースを私は多く見ていないため、資格名で選ぶ意味は薄いと感じています。担当したい領域に近いほうを選ぶのが自然だと思います。

実務未経験でもAWS資格でフリーランスになれますか?

私が読んだ範囲の案件要件では、実務経験年数が必須要件として書かれていることが多く、未経験からいきなり案件を受けるのは難しいと感じました。実態はエージェントに確認するのが確実です。

管理人はフリーランスとして働いた経験がありますか?

ありません。私は会社員としてオンプレ運用からAWS移行を担当してきた立場です。この記事は体験談ではなく、案件要件の読み方と会社員側でできる準備の整理です。

料金や特典の条件は思ったより頻繁に変わります。申し込む前に、公式サイトで今の条件を確認してください。

Midworks(フリーランスエンジニア向けエージェント)の公式サイトを見る 公式サイトへ移動します

ヒロ

2017年からインフラ実務、2022年に SAA、2024年に SAP 取得

事業会社の情報システム部門でインフラを担当している会社員です。社内システムのオンプレ運用から入り、いまは AWS への移行と運用設計を担当しています。AWS認定は SAA と SAP を取得済み、DVA は勉強中です。市販教材と公式ドキュメントだけで独学したので、どこでつまずくかは一通り経験しました。名前はペンネームです。

どういう基準で書いているか

Midworks(フリーランスエンジニア向けエージェント) 公式サイトを見る