「Laravel経験3年以上」は何を証明するのか——年数が独り歩きするエンジニア転職

導入——求人票に並ぶ四つの条件

求人サイトを眺めていたずんだもんは、画面の前で腕を組んだ。

そこには、よく似た条件が並んでいる。

・エンジニア経験3年以上
・Laravelを用いた実務経験3年以上
・AWSを利用した開発経験
・基本設計の経験

💚ずんだもん

GoやRustでWebシステムを作れる人でも、Laravelが3年未満なら未経験扱いになるのだ？

HTTPもデータベースも分かっているのに、Laravelを3年使っていないだけで応募できないのは不思議なのだ。

🎀めたん

その違和感は正しいわ。

経験年数は能力を直接測った数字ではありません。本来は「この人に一人でどこまで任せられるか」を推測するための代理指標です。

⚔️つるぎ

身長や体重を測るように、設計能力や障害対応力を直接数値化することはできません。

だから企業は、経験年数、使用技術、担当工程、役職といった観測しやすい情報から、実際の能力を推測します。

💚ずんだもん

つまり「3年以上なら必ずできる」という意味ではないのだ？

🎀めたん

ええ。ただし、代理指標が応募資格や案件参画条件として固定されると、何を推測したかったのかが忘れられます。

本来確認すべき能力を調べず、数字だけを通行証として使う。これが、経験年数の独り歩きです。

この記事で扱う問いは四つある。

「3年以上」は何を証明するのか。

「未経験」という言葉には、何が混ざっているのか。

AI時代に経験の価値はどう変わるのか。

そして転職者は、年数の代わりに何を示せばよいのか。

　「Laravel3年以上」は何を測っているのか

同じ3年でも、経験の中身は違う

💚ずんだもん

でも、3年も仕事をしていたら、やっぱり詳しくなるのではないのだ？

🎀めたん

詳しくなる可能性は高まります。ただし、時間と能力は同じものではありません。

二人のエンジニアを比べてみましょう。

AさんはLaravel経験3年。

既存のCRUD画面、つまりデータの登録・表示・更新・削除を行う管理画面の修正を中心に担当してきた。設計、テスト方針、障害対応は別の担当者が決めている。指示された範囲では、安定して実装できる。

BさんはLaravel経験なし。

GoでWeb APIを開発し、認証・認可、データベース、トランザクション、Queueによる非同期処理、ログ、監視を担当した。本番障害やデータ移行にも対応している。

💚ずんだもん

「Laravel3年以上」という条件なら、Aさんが通りやすいのだ。

でも、原因不明の障害を調べたり、既存システム全体を理解したりする仕事では、Bさんの方が早く動けるかもしれないのだ？

⚔️つるぎ

その可能性は十分にあります。

AさんはLaravelの操作経験を持っています。BさんはWebシステムの問題構造を扱った経験を持っています。どちらが適任かは、募集している仕事によって変わります。

🎀めたん

問題は、求人票が仕事の違いを書かずに「Laravel3年以上」だけで済ませていることです。

既存画面を短期間で修正する人が欲しいのか、障害原因を調査できる人が欲しいのか。それを区別しなければ、年数だけでは適任者を選べません。

年数条件に合理性がある場合

💚ずんだもん

では、経験年数を書く会社は、全部おかしいのだ？

🎀めたん

そこまで単純ではありません。年数条件が合理的な場面もあります。

たとえば顧客との契約で「Laravel経験3年以上」が指定されている案件です。企業側が条件を変えられないこともあります。

⚔️つるぎ

入社直後から単独で本番障害を担当させる場合も、Laravel固有の知識が重要です。

サービスコンテナの挙動、Eloquentの癖、Queueワーカーの運用、設定キャッシュ、バージョンアップ時の互換性などは、一般的なWeb知識だけでは補えません。

🎀めたん

教育やレビューの余裕がない会社もあります。

大量の応募者を低コストで絞り込む必要がある採用では、年数による足切りが運用上の妥協として使われます。

💚ずんだもん

能力を正確に測れるからではなく、採用や教育にかかる費用を下げやすいから使われるのだ？

🎀めたん

その通りです。

年数条件の合理性は、測定精度よりも、契約、営業、教育、選考にかかるコストから生まれています。

⚔️つるぎ

だから応募者は、年数が足りないことを隠してはいけません。

代わりに「その条件が推測しようとしている能力を、別の経験で証明できるか」を考えます。

「未経験」という一語が粗すぎる

四種類の未経験を分ける

💚ずんだもん

求人票には「未経験可」や「未経験不可」とも書かれているのだ。

でも、何を経験していなければ未経験なのだ？

🎀めたん

そこには少なくとも四種類の未経験が混ざっています。

一つ目は、エンジニアリング未経験です。

要件を整理し、実装し、テストを受け、レビューで修正し、リリースし、運用する。

この一連の仕事を経験していない状態が、エンジニアリング未経験である。

個人開発でコードを書いたことがあっても、利用者への説明、他者のレビュー、障害対応、継続運用を経験していなければ、業務上は未経験の部分が残る。

⚔️つるぎ

二つ目は、特定技術未経験です。

Web開発の経験はあるものの、Laravel、Go、Rust、AWSなど、求人票に書かれた技術を業務で使ったことがない状態です。

🎀めたん

三つ目は、ドメイン未経験。

医療、金融、EC、製造、物流など、対象となる業務の知識がない状態です。

⚔️つるぎ

四つ目は、現場未経験です。

その会社固有のコード、顧客との約束、運用手順、障害履歴、暗黙の判断基準、組織内の調整関係を知らない状態です。

💚ずんだもん

Laravel経験者でも、新しい会社の業務や既存システムについては未経験なのだ？

⚔️つるぎ

当然です。

Laravelを10年使っていても、その会社の商品、顧客、データ、障害履歴までは知りません。技術経験があれば学習速度は上がりますが、現場固有の知識を省略できるわけではありません。

自社採用と案件配属型では評価構造が違う

🎀めたん

未経験の扱いは、採用形態によっても変わります。

自社サービスや自社の受託開発組織で採用する場合、企業は入社後の担当範囲を調整できます。

⚔️つるぎ

最初は小規模改修、次にテスト追加、その後に設計というように、段階的に責任を広げられます。

他のフレームワークで身につけた能力が自社へ移転されれば、育成投資も会社に残ります。

🎀めたん

一方、SESなどの案件配属型では、顧客の案件票に経歴書を合わせる必要があります。

ただし、SESは業界で広く使われる呼び方であり、労働者派遣と法的に同じものではありません。準委任などの契約と、派遣契約は区別する必要があります。

💚ずんだもん

採用されたら、すぐ開発案件へ入れるとは限らないのだ？

🎀めたん

ええ。

会社に採用されることと、顧客案件へ参画できることは別です。Laravel経験年数が顧客側の営業条件なら、技術的な移転可能性より、経歴書上の一致が優先されやすくなります。

⚔️つるぎ

その構造を知らずに「未経験歓迎だから経験を積める」と考えるのは危険です。

誰が最初の仕事を用意するのか。誰がレビューするのか。待機中に何を学ぶのか。一年後にどのような成果物と責任経験が残るのか。入社前に確認するべきです。

🎀めたん

エンジニア不足という言葉も、無条件の採用を意味しません。

不足しているのは、仕事を分解し、レビューを受けながら改善し、最終的に一定範囲を任せられる人です。未経験者を育てる仕組みが不足している会社も多いのです。

エンジニアは過去の経験を新しい技術へ移転している

フレームワークが変わっても責務は消えない

💚ずんだもん

GoやSymfonyの経験は、Laravelでも本当に役に立つのだ？

書き方も関数名も違うのだ。

⚔️つるぎ

APIは違います。しかし、Webシステムが負っている責務は大きく変わりません。

HTTPリクエストを受け、ルーティングし、必要な処理へ渡す。依存関係を管理し、認証された利用者に権限があるかを確認する。データベースを更新し、失敗時には整合性を守る。

🎀めたん

さらに、入力値の検証、Queueによる非同期処理、キャッシュ、テスト、ログ、監視、デプロイ、ロールバックがあります。

フレームワークは、これらの責務を実装するための構造と部品を提供しています。

⚔️つるぎ

GoやSymfonyの経験者はLaravelのAPIを知らなくても、問題が起きそうな場所を予測できます。

Eloquentで関連データを読み込んだとき、N+1と呼ばれる大量の追加クエリが発生しないか。

複数の更新を、どのトランザクション境界でまとめるべきか。

💚ずんだもん

Queueの再実行で、同じメールを二回送ったり、同じ請求を二回処理したりしないかも確認するのだ？

⚔️つるぎ

その通りです。

認証と認可が混同されていないか。Migrationを安全に戻せるか。外部APIが停止したときに業務全体まで止まらないか。ログから障害原因を追跡できるか。

こうした質問は、フレームワークが変わっても残ります。

知識の価値は「どこを見るか」にある

🎀めたん

機械修理の有名な逸話があります。

ハンマーで叩く作業に一ドル。どこを叩くか知っていることに九十九ドル、という話です。

💚ずんだもん

ソフトウェアなら、コードを数行直す作業より、どこを直せばよいか特定する方に価値があるのだ？

⚔️つるぎ

そうです。

障害の原因が、画面、API、認証、データ、キャッシュ、外部サービス、設定、デプロイのどこにあるのか。変更すると何が壊れるのか。どのテストで安全を確認するのか。

価値は、コード量だけでは測れません。

🎀めたん

DDD、つまりドメイン駆動設計も、特定のコード形式を暗記するためだけの知識ではありません。

業務ルールをどこが所有するのか。変更理由が異なる責務をどう分けるのか。データの整合性をどの単位で守るのかを考える枠組みです。

⚔️つるぎ

AWSの参照アーキテクチャやWell-Architectedも同じです。

信頼性、セキュリティ、コスト、性能、運用をどの観点で点検するかという質問集を提供します。システム設計面接の学習も、未知の要件を分解し、制約と選択肢を整理する訓練になります。

外部の専門能力と現場知識を組み合わせる

💚ずんだもん

企業改革をするコンサルタントに、「その会社で3年以上働いた経験」を求めることは少ないのだ。

それなのに、エンジニアだけ同じ技術を長く使う年季が必要だと考えるのは、少し変なのだ？

🎀めたん

外部コンサルタントは、汎用的な専門知識を持ち込み、現場を調査し、内部の担当者と協働して改革案を作ります。

エンジニアも、未知の現場を調査し、内部知識を持つ人と協働する専門職です。

⚔️つるぎ

ただし、外部知識だけで改革できるわけではありません。

現場担当者が知っている例外処理、顧客との約束、繁忙期の運用、過去の失敗を無視すれば、理論的に美しくても使えないシステムになります。

🎀めたん

必要なのは、五つの組み合わせです。

移転可能な専門能力。現場知識を獲得する方法。小さく検証する仕組み。判断に必要な権限。内部担当者との協働です。

⚔️つるぎ

熟練とは、過去の正解を丸暗記することではありません。

未知の現場で、誰に何を聞き、どこを疑い、どの変更から小さく試すかを設計できることです。

AI時代には経験の意味が変わる

AIが圧縮する経験差

💚ずんだもん

AIコーディングエージェントがあれば、知らないフレームワークでもコードを書いてもらえるのだ。

それなら経験年数は、ますます要らなくなるのだ？

⚔️つるぎ

なくなるのではなく、経験の価値が移動します。

AIは文法やAPIの検索、フレームワーク間の対応関係、定型コード、テストの雛形、既存コードの要約を高速化します。

🎀めたん

試作品の実装、ドキュメント整理、複数案の比較も得意です。

以前なら数日かかった調査と初期実装を、数時間で進められる場面も増えます。特定APIを何度も手で書いた経験の差は縮まりやすくなります。

💚ずんだもん

では、新人でも会社の大きなシステムを自由に直せるのだ？

🎀めたん

それは別の話です。

コードを生成できることと、本番変更を任せられることは同じではありません。

人間に残る判断と責任

⚔️つるぎ

AIを使っても、解くべき問題の選択は人間に残ります。

現場固有のルールを確認し、AIの出力を検証し、データ整合性、セキュリティ、権限管理を守る必要があります。

🎀めたん

変更による副作用の予測、導入と撤退の判断、障害時の復旧、結果への責任も残ります。

AIは「実装できる案」を大量に出せます。しかし、「この会社が今取り組むべき案」を自動的には決められません。

💚ずんだもん

新入社員に提案する権利を与えることと、本番環境を自由に変更する権限を与えることは別なのだ。

⚔️つるぎ

その区別が重要です。

新人でも、Excelとメールによる集計の自動化、問い合わせ対応状況の一元化、CSV変換作業の自動化、社内文書検索の試作は提案できます。

既存システムへの回帰テスト追加や、手作業のレポート作成の自動化も良い題材です。

改善を成立させる組み合わせ

🎀めたん

新入社員による改善を成功させるのは、個人の万能さではありません。

次の組み合わせです。

⚔️つるぎ

たとえば、新人が「毎週、同じCSVを手で並べ替える必要がありますか」と質問する。

現場担当者が、列の意味、例外データ、締め時間を説明する。AIが変換方法を提案し、コーディングエージェントが試作品を作る。責任者が検証基準と権限を確認する。

これなら、小さく試して、問題があれば元の手作業へ戻せます。

🎀めたん

AI時代には別の格差が生まれます。

良い問題を選べるか。AIへ適切に委任できるか。出力を検証できるか。現場担当者から必要な情報を引き出せるか。

⚔️つるぎ

さらに、小さく試して戻せるか。責任境界を理解できるか。

「AIを使える」という一言ではなく、AIに何を任せ、自分は何を判断し、誰が最終確認したかを説明する必要があります。

年数ではなく、経験の移転可能性を示す

エンジニアリング未経験者が作るべき証拠

💚ずんだもん

実務経験がない人は、何を見せればよいのだ？

「勉強しました」「アプリを作りました」だけでは足りないのだ？

⚔️つるぎ

コードだけでは、仕事の進め方が分かりません。

どの問題を選び、誰のどんな作業を改善するのか。どの制約があり、どの選択肢を比較したのかを示してください。

🎀めたん

さらに、どこまで実装し、どのテストを行ったか。

AIに何を任せ、自分が何を判断したか。失敗時にどう戻し、導入後の運用を誰が担当するかまで整理します。

💚ずんだもん

派手なSNSクローンを作るより、問い合わせ管理やExcel集計の方がよい場合もあるのだ？

⚔️つるぎ

転職用の成果物としては有効です。

予約受付、問い合わせ対応漏れの防止、CSV変換、WordPressの更新手順改善などは、利用者、制約、失敗条件、運用責任を具体的にできます。

未経験者の面談では、次のように説明できる。

「実務経験はありませんが、問い合わせ対応漏れという問題を対象に、現状整理、選択肢比較、試作、テスト、運用手順まで作成しました。AIにはコード生成を任せましたが、データ項目、失敗条件、検証基準は自分で定義しました」

🎀めたん

ここで重要なのは、実務経験があるように装わないことです。

実務ではないものは実務ではないと明示し、そのうえで、仕事に近い改善サイクルをどこまで完了したかを示します。

技術移行者が示す四点

💚ずんだもん

すでにエンジニアだけれど、Laravelは未経験という人はどうするのだ？

⚔️つるぎ

「未経験ですが勉強します」では弱すぎます。

四点を示してください。

一つ目は、既存経験から移転できる能力。

二つ目は、新技術固有の差分。

三つ目は、その差分を補完した証拠。

四つ目は、入社後の参加計画です。

🎀めたん

共通能力だけを強調して、Laravel固有の知識を軽視してはいけません。

反対に、Laravelを知らないという一点だけで、Web開発経験すべてを未経験扱いする必要もありません。

技術移行者は、面談で次のように説明できる。

「Laravelの実務経験はありません。一方で、GoによるWeb API開発で、認証・認可、トランザクション、非同期処理、テスト、監視、障害対応を経験しています。Laravel固有の差分として、Eloquent、Service Container、Queue、Policyを調査し、既存アプリへの小規模改修とFeature Testを作成しました。入社後は小規模改修から参加し、業務ルールと運用上の前提を把握して担当範囲を広げます」

💚ずんだもん

「できます」と言い切るのではなく、できる部分、知らない部分、補った部分、最初に任せてほしい仕事を分けているのだ。

⚔️つるぎ

それが責任ある説明です。

採用側も、候補者をどの支援条件で受け入れればよいか判断できます。

求人票を年数条件から職務定義へ変える

🎀めたん

企業側にも改善できることがあります。

悪い例は、条件だけを書く求人票です。

「Laravelを用いた実務経験3年以上」

これでは、何を任せたいのか分かりません。

⚔️つるぎ

改善例は、職務、責任、利用技術、支援条件を書くことです。

「Laravelで構築された既存システムの保守と機能追加を担当します。Eloquent、Migration、認証・認可、Queue、Feature Testを使った変更を、レビューを受けながら進められる能力を求めます。他言語・他フレームワークで同等のWeb開発経験がある方も対象とします」

💚ずんだもん

これなら、Laravel経験がない人も、自分の経験が対応するか確認できるのだ。

Laravel経験者も、単なる画面修正ではなく、Queueやテストまで必要だと分かるのだ。

🎀めたん

企業が評価すべきなのは、年数だけではありません。

候補者が問題をどう整理したか。不足情報を質問できたか。選択肢を比較したか。変更範囲を限定できたか。

⚔️つるぎ

テストと復旧方法を考えたか。AI出力を検証できたか。必要な支援を説明できたか。

そして、過去の経験を新しい技術と現場へ移転できるかです。

🎀めたん

年数条件を完全に廃止する必要はありません。

契約上必要なら書けばよい。ただし、それとは別に、担当する仕事、求める責任範囲、レビュー体制、入社後の立ち上がり方を明示するべきです。

まとめ——過去の時間を、未来の仕事へ翻訳する

💚ずんだもん

経験年数は、過去にどれだけ時間を使ったかを示す数字なのだ。

でも、未来にどんな成果を出せるかを、そのまま保証する数字ではないのだ。

🎀めたん

同じ3年でも、担当した判断と責任によって経験の密度は変わります。

指示された修正を安定して行った3年と、設計、障害対応、データ移行、運用改善まで担った3年では、証明できる能力が違います。

⚔️つるぎ

エンジニアリング未経験者には、小さな改善を完了した証拠が必要です。

問題整理、選択肢比較、試作、テスト、復旧、運用までを一つのサイクルとして示してください。

🎀めたん

新しい技術へ移るエンジニアには、過去の経験を新技術へ対応付ける説明が必要です。

共通する責務、固有の差分、差分を補った成果物、入社後の参加計画を分けて伝えます。

⚔️つるぎ

企業には、技術名と年数だけでなく、職務、責任、必要な支援を定義する責任があります。

「何年使った人が欲しいか」ではなく、「どの仕事を、どの支援条件で、どこまで任せたいか」を求人票に書くべきです。

💚ずんだもん

AI時代には、コードを書く速さだけを競っても足りないのだ。

どこを直すのか。何を守るのか。どう検証するのか。問題が起きたらどう戻すのかを説明できることが大切なのだ。

⚔️つるぎ

年数条件を見て、すぐに応募を諦める必要はありません。

その数字が何を推測しようとしているのかを読み解き、自分が持っている証拠と不足している証拠を分けてください。

不足しているなら、経歴を飾るのではなく、小規模改修、テスト、調査記録、運用手順、移行計画として補います。

過去に費やした時間は変えられません。しかし、過去の経験を未来の仕事へどう翻訳するかは、今から設計できます。