【微経験エンジニア】の職務経歴書|実務1〜2年のエンジニアが職務経歴書で詰まる3つの理由と書き方
- 「微経験」とは何か:実務1〜2年が未経験・経験者のどちらに当たるかを整理する
- 採用担当がエンジニアの職務経歴書で実際に見ている3つのポイント
- スキルの書き方:技術の羅列を「使った文脈つき」に変える方法
- 微経験エンジニア向け例文3つ(Webエンジニア・インフラ・SES経験者):よくある薄い書き方から変換後までを示す
- SES・客先常駐経験しかない場合の書き方
- 書類が通らない人に共通する4つのNGパターンと改善例
「実務経験1年ちょっとしかないけど、職務経歴書に何を書けばいいかわからない」という悩みは、エンジニアの転職相談の中でも特によく出てきます。
書類が通らない原因のほとんどは、経験の浅さそのものではなく、経験の見せ方にあります。採用担当者は「何年やったか」だけでなく「その期間で何を考え、どう動いたか」を見ています。伝え方次第で、同じ1年半の経験でも評価はまったく変わります。
この記事では、まず「微経験」の定義を整理します。転職求人票では「実務経験2年以上」という条件が多く見られます。この2年という基準から、本記事では実務経験1〜2年を「微経験」と定義します。「未経験(実務なし)」でも「経験者(3年以上)」でもない、その中間にいる方が読者の対象です。
| ラベル | 定義 | 職務経歴書の主な課題 |
| 未経験 | 実務経験なし | 書ける業務経験がない |
| 微経験 | 実務経験1〜2年 | 経験はあるが浅く、何をどこまで書くかわからない |
| 経験者 | 実務経験3年以上 | 経験を絞り込む・再現性を示す |
採用担当は何を見ている?微経験エンジニアの評価ポイント
微経験エンジニアの職務経歴書で、採用担当者が確認しているのは主に次の3点です。
| 採用担当者が確認するポイント | 職務経歴書で伝えるべき内容 |
| ①どんな技術を、どんな文脈で使ったか | 技術名だけでなく「何のために・何を解決したか」をセットで書く |
| ②与えられた業務をどう動いたか | 指示待ちではなく自分で考えて動いたエピソードを入れる |
| ③この1〜2年でどれだけ成長したか | 入社直後と現在の担当範囲・できることの変化を示す |
書類が通らない微経験エンジニアに共通する3つのパターン
パターン①:スキルを羅列するだけで「使った文脈」がない
「使用技術:Java、Python、MySQL、AWS、Docker」と並べるだけでは、採用担当者には何も伝わりません。業務で実際に使ったのか、チュートリアルレベルなのか、どのプロジェクトで何を解決するために使ったのかが見えないためです。
技術名には必ず「何のために使ったか」をセットで書くことが重要です。
パターン②:経験が浅いことを前置きにしてしまう
「まだ経験が浅いですが」「実務経験は短いですが」という書き出しは、読む前から採用担当者の期待値を下げます。職務経歴書は謙遜する場所ではなく、自分がやってきたことを事実ベースで示す書類です。
経験の浅さを断りとして書くより、1〜2年の間に担当した業務・工夫した点・成長した軌跡を具体的に書く方が評価につながります。
パターン③:プロジェクトの規模・自分の役割が一切書かれていない
「ECサイトの開発を担当」と書かれていても、チーム5名の開発なのか、自分一人で全部やったのかで評価はまったく変わります。また自分がフロントエンドを担当したのか、バックエンドなのか、テストだけなのかも伝わりません。
プロジェクトには必ずチーム規模・自分の担当フェーズ・使用技術をセットで書いてください。
書き方のポイント|微経験だからこそ伝えるべき3つのこと
ポイント①:「使った技術」より「何を解決したか」を書く
同じPythonを使った経験でも、「データ集計スクリプトを作成してチームの手作業を週3時間削減した」と書くのと「Python使用」と書くのでは、採用担当者の受け取り方がまったく異なります。
技術はあくまで手段です。「何の課題を・どんな技術で・どう解決したか」という流れで書くと、浅い経験でも厚みが出ます。
ポイント②:経験期間より「深さ」で勝負する
1年間同じ業務を繰り返しただけの記述と、「最初の3ヶ月は既存コードの読解から始まり、6ヶ月目に初めて単独でAPI設計を任された」という記述では、後者の方が成長の深さが伝わります。
担当業務がどう広がったか、最初はできなかったことが今はできるようになっているか、という変化を意識して書いてください。
ポイント③:成長の軌跡を時系列で見せる
微経験の強みは「成長途中であること」を素直に見せられる点です。「入社3ヶ月目:テスト工程を担当 → 6ヶ月目:実装を任されるように → 1年目:コードレビューに参加」のように時系列で示すと、採用担当者は「入社後もこのペースで伸びそう」と判断できます。
微経験エンジニアならではの悩みに答える
「実務経験1〜2年では経験者枠に応募できないのでは?」
求人票の「実務経験2年以上」は絶対条件ではないケースもあります。ただし、応募できるかどうかは求人票の条件の書き方と、自分の経験がどこまで言語化できるかによって変わります。「必須」と書かれている場合は慎重に判断し、「歓迎」「あれば尚可」の場合は積極的に応募を検討する価値があります。
いずれの場合も、職務経歴書で「1〜2年の間に何を担当し、何を解決し、どう成長したか」が具体的に伝わるかどうかが書類通過の鍵になります。
「SES・客先常駐しか経験がないと不利ですか?」
不利ではありません。ただし、SES経験の書き方には注意が必要です。
SES・客先常駐経験者が職務経歴書で迷うポイントは2つあります。1つ目は「クライアント名を書いていいか」、2つ目は「案件が複数あるのをどう整理するか」です。
クライアント名は守秘義務がある場合は伏せて構いません。「大手製造業向け基幹システム(ユーザー数約300名規模)」のように業種・規模・システムの概要で代替できます。
案件が多い場合は、直近2〜3件を詳しく書き、それ以前は概要のみにまとめるのが基本です。また複数現場を経験したSES経験者には「環境適応の速さ」「異なる開発スタイルへの対応力」という固有の強みがあります。これを自己PRに入れると、一社のみの経験者との差別化になります。
例文
例①:Webエンジニア(実務1年・バックエンド中心)
◆ よくある書き方(変換前)
【業務内容】
・Ruby on Railsでの開発
・テストコードの作成
・GitHubを使ったバージョン管理
【主な取り組み】
・基礎知識の習得に努め、日々の業務に真剣に取り組みました
【業務内容】
・Ruby on Railsを使ったAPIの実装・修正(既存機能の改修が中心)
・RSpecを用いたユニットテストの作成
・GitHubでのプルリクエスト作成・コードレビュー対応
・Jiraを使ったタスク管理・進捗報告
【実績】
・入社から6ヶ月間、月平均4〜6件のプルリクエストをチームにマージ
・コードレビューで指摘を受けた内容をメモに記録し、同じ指摘を繰り返し受けることがなくなった
・担当したAPIのレスポンスが遅い原因を調べ、上長に改善案を提案した(実装は上長が対応)
【主な取り組み】
コードレビューで指摘された内容を毎回メモに残し、翌週の実装に反映する習慣をつけた。「なぜそう書くのか」を理解してから次に進むことを意識してきたため、同じ種類の指摘は徐々に減っていった。
自己PRでのアピールポイント
指摘を記録して次に活かす習慣が身についている。まだ担当できる範囲は限られているが、わからないことを放置せず、調べて確認してから進めるスタンスで業務に取り組んできた。同じ姿勢で次の職場でも早期に自走できる状態を目指したい。
例②:インフラエンジニア(実務1年半・クラウド構築補助)
◆ よくある書き方(変換前)
【業務内容】
・AWSを使ったインフラ構築
・手順書の作成
・障害対応のサポート
【主な取り組み】
・上長の指示のもと、インフラ業務全般を担当しました
【業務内容】
・AWSを使った開発・検証環境の構築補助(EC2・S3・RDS・VPC)
・Terraformを使ったインフラコードの修正・既存テンプレートへの変更対応
・CloudWatchを使った監視設定の追加・アラート閾値の調整
・障害発生時の一次対応・ログ確認・上位エンジニアへのエスカレーション
・Confluenceを使った手順書・構成図の作成・更新
【実績】
・担当した検証環境3件を手順書に沿って構築し、すべてスケジュール内で完了
・障害対応の一次切り分けを10件以上経験し、ログ確認から原因の絞り込みまで対応できるようになった
・手順書の抜け漏れ箇所をリスト化して上長に共有し、改訂版の作成に参加した
【主な取り組み】
作業のたびに「なぜこの手順が必要か」を手順書や先輩への質問で確認するようにした。理解を優先したことで、似た作業を別の環境で応用できる場面が増えた。手順書の不備に気づいた際は放置せず上長に共有することを習慣にしてきた。
自己PRでのアピールポイント
与えられた作業を指示通りこなすだけでなく、手順の意味を理解してから進めるスタンスが身についている。まだ単独で設計・構築を任される段階ではないが、作業の背景を理解する姿勢を次の職場でも続け、早期に独力で動ける範囲を広げたい。
例③:SES経験者(実務2年・複数現場経験)
◆ よくある書き方(変換前)
【業務内容】
・Webシステムの開発・テスト
・バグ修正
・複数の現場でさまざまな業務を経験しました
【主な取り組み】
・各現場の業務にすばやく慣れるよう努力しました
【業務内容】
・案件A(Web系企業・8ヶ月):PHPを使った既存機能の改修・バグ修正、GitLabでのバージョン管理
・案件B(中堅SIer・16ヶ月):Javaを使った業務システムの結合テスト・不具合修正、Redmineでのチケット管理
【実績】
・案件Aにて、バグ修正対応を月平均8〜10件担当。対応内容を毎回チケットに記録し、同種バグの再発防止に活用した
・案件Bにて、テスト工程で検出した不具合を30件以上記録・報告。担当範囲内のテストを期日通りに完了した
・案件Bの後半から実装フェーズにも参加し、既存コードの修正を単独で対応できるようになった
【主な取り組み】
新しい現場に入るたびに、最初の2〜3週間でコードベースと開発フローの全体像を把握することを優先した。わからない点はその日のうちに先輩に確認し、翌日以降に持ち越さないことを意識した。案件Bでは実装フェーズへの参加を自分から希望し、上長の承認を得て担当範囲を広げた。
自己PRでのアピールポイント
異なる技術スタックと開発フローを持つ2つの現場を経験してきたことで、新しい環境へのキャッチアップに慣れている。テストから実装へと担当範囲を広げてきた経験から、次の職場では実装を中心に担当しながら、より深い技術力を身につけたいと考えている。
書き方ステップ
① 経験したプロジェクトをすべて書き出す
期間・チーム規模・担当フェーズ・使用した技術・自分が担当した作業を一覧にします。「アピールになるか」はこの段階では考えなくて構いません。まず全部書き出すことが重要です。
② 技術スタックを「業務経験あり」と「学習中」に分けて整理する
GitHubやAWSなど、業務で実際に使った技術と、個人で学習中の技術を必ず分けて書きます。混在させると採用担当者が実力を誤解するリスクがあります。業務外で使っている技術は「業務外で学習中」と明示すれば、むしろ積極性のアピールになります。
③ 数字になるものを探す
バグ対応件数・プルリクエスト数・担当した環境の数・処理時間の変化など、プロジェクトに紐づく数字を洗い出します。「正確な数字を覚えていない」場合でも「約〇件」「月平均〇件程度」という概算で十分です。
④ 成長の軌跡を時系列で整理する
入社直後にできたこと・半年後にできるようになったこと・現在担当できることを時系列で並べます。この変化を書くことで、採用担当者は「入社後もこのペースで成長できる人」と判断しやすくなります。
⑤ 「何を解決したか」の視点で業務を書き直す
ステップ①で書き出した業務内容を「技術を使って何の課題を解決したか」という視点で書き直します。「Dockerを使った」ではなく「開発環境の差異によるバグを減らすためにDockerで環境を統一した」という形に変えると、技術の使い方の理解度が伝わります。
NG例 → 改善例|通らない書き方の直し方
失敗①:技術を羅列するだけ
失敗②:プロジェクト記述が薄い
失敗③:経験の浅さを前置きにしてしまう
失敗④:自己PRが抽象的で終わっている
経験年数別アドバイス
実務経験1年前後
担当できる業務の範囲がまだ限られている時期です。実績の数字が少なくても、「どう考えて動いたか」のエピソードが1〜2つあれば十分にアピールになります。
振り返るべき問いは「コードレビューで指摘を受けたとき、どう対応・改善したか」「わからないことをどうやって解決したか(調べ方・質問の仕方)」「業務の中で自分から動いたことがあるか」の3つです。大きな実績がなくても、こうした日常の動き方を具体的に書くことで、「一緒に働きたい人材」という印象につながります。
実務経験1年半〜2年
担当範囲が広がり、実績の数字が出てきている時期です。この段階では「成長の変化」と「自発的な行動のエピソード」を両方書くことが重要です。
「最初はAを担当していたが、今はBまで任されている」という担当範囲の変化を明示してください。また自分から担当範囲の拡大を希望した経験、業務上の非効率に気づいて上長に共有した経験なども積極的に書きましょう。こうした経験は「与えられた業務だけをこなす人ではない」という印象につながります。
よくある質問
求人票の「実務経験2年以上」が「必須」か「歓迎」かによって判断が変わります。「歓迎」や「あれば尚可」の場合は積極的に応募を検討する価値があります。いずれの場合も、職務経歴書で「1年間で何を担当し、どう成長したか」が具体的に伝わるかどうかが書類通過の鍵になります。
求人票の指定に従うのが基本です。「職務経歴書のみ」と指定されている場合は、職務経歴書内にスキルセクションを設けて統合します。両方求められる場合は分けて作成し、スキルシートには技術と習熟度を、職務経歴書のプロジェクト経歴には「何のためにその技術を使ったか」を書く形にすると読みやすくなります。
書けます。ただし「業務経験」と混在させないことが前提です。「業務外での学習・個人開発」として明示したうえで、何を作ったか・何の技術を使ったか・GitHubのURLなどを添えると、積極性のアピールになります。スクール経験も「〇〇スクールにて△△を学習、卒業制作として〇〇を開発」のように具体的に書くと評価されやすいです。
実務経験1〜2年であればA4で2枚程度が目安です。経験が少ないからといって1枚にまとめようとすると内容が薄くなります。プロジェクト経歴を「業務内容・実績・主な取り組み」の3ブロックで書くと、自然に2枚程度になります。3枚を超える場合は、応募職種と関連性が薄い情報を削りましょう。
職務経歴書に転職理由を詳しく書く必要はありません。自己PRの末尾に「自社サービスの開発に携わり、エンジニアとしての専門性をさらに深めたい」のように、前向きな志向として一文添える程度で十分です。ネガティブな転職理由は面接で聞かれたときに答える準備をしておくことの方が重要です。
まとめ
微経験エンジニアの職務経歴書で評価されるのは、経験の長さではなく「その期間に何を考え、どう動いたか」です。
- 「微経験」とは実務経験1〜2年。未経験でも経験者でもない、固有の見せ方がある
- 技術名の羅列ではなく「何の課題を・どの技術で・どう解決したか」をセットで書く
- プロジェクトにはチーム規模・自分の担当フェーズ・使用技術を必ず入れる
- 成長の軌跡を時系列で示すことで「入社後も伸びる人」という印象を与えられる
- SES経験者はクライアント名を伏せて業種・規模で代替し、複数現場の適応力を強みにする
- 自己PRは抽象的な表現ではなく、具体的な行動エピソードで書く
ショクレキでは、ヒアリングをもとに職務経歴書を一緒に作成するサービスを提供しています。「自分の経験をどう整理すればいいかわからない」「書類選考が通らない」という方は、ぜひ一度ご相談ください。

