記事一覧に戻るスキルシート作成
1年目を終えたジュニアがスキルシートに足すべき3つのことを解説する記事のアイキャッチ
Seriesジュニアエンジニア実務ガイド5 / 6

1年目を終えたジュニアが、スキルシートに足すべき3つのこと

SkillSheet-Port編集部
SkillSheet-Port編集部
2026-04-127分で読める

初案件で1年。右も左もわからなかった自分とは、もう違うはずだ。なのに、スキルシートは入場前のまま。これは本当にもったいない。1年間の現場経験は、ちゃんと書けば次の案件・次の単価・次のキャリアの武器になる。その"足し方"を3つ紹介する。

1年経って、自分のスキルシートを見返したことはあるか

気づけば、入場前のまま放置している

1年経ったある日、エージェントから「そろそろ次の案件どうしますか?」と連絡が来る。「ちょっと考えます」と返して、久しぶりに自分のスキルシートを開く。

そして固まる。

「あ、入場前に作ったスキルシートのままだ」

入場前の自分は、スクールや独学で学んだ内容、ポートフォリオのプロジェクト、学習履歴。精一杯まとめた。それで今の現場に入れた。でも、あの時の自分と今の自分では、経験も視点もまるで違うはず。

それなのに、スキルシートは変わっていない。1年分の経験が、どこにも記録されていない。

このまま2案件目に動くと、もったいないことになる

スキルシートが入場前のまま次の案件に動くと、何が起きるか。

エージェント側はあなたを"まだ初案件を探している人"と同じリストに並べがちだ。エンド企業は「経験1年」と見るが、具体的に何ができるかは書類から読み取れない。結果、初案件と似たような条件で次の案件が決まる。

本当は1年で積んだ経験を、書類上は"ゼロ"に近い形で勝負することになる。これは本当にもったいない。

なぜ"1年経ったスキルシート"が、勝負を分けるのか

次のエージェント面談、1年経験者として見られるかどうか

1年経過は、エージェントや現場からの見られ方が変わるタイミングだ。

  • 0〜6ヶ月: 「初学者枠」
  • 6〜12ヶ月: 「伸びしろを見る枠」
  • 12ヶ月以上: 「経験者として一定の戦力を期待される枠」

書類の段階でこの差が伝わらないと、1年の経験が"値札"として反映されない。具体的には、単価にも、案件の選択肢にも、直接影響する。

単価交渉と案件選びの、直接の原資になる

スキルシートを直しただけで月単価が変わる、という話はよく聞く。実際、1年経ったジュニアで、書き方を変えただけで次の案件から単価が5万〜10万上がった例を、エージェント時代に何度も見てきた。

技術力そのものが急に上がったわけじゃない。1年で実際に積んだ経験を、読める形に"書き足した"だけで、劇的に印象が変わる。

関連: スキルシートを直しただけで月単価30万上がった話

足すべきこと① — "チーム開発での動き方"を書く

これが実は、1年経ったジュニアが最初に書き足すべき、最も重要な要素だ。

現場担当者が見ているのは、技術力じゃなく"動き方"

少しきつく聞こえるかもしれないが、改めて言っておきたい。
現場担当者は、1年経ったジュニアにも、まだ技術力を期待していない

では、何を見ているか。3つだ。

  • チームでの動き方
  • 貢献度合い
  • 自走力

この3つが揃って見えると、「現場でも戦力として貢献してくれそうだ」という評価になる。
逆にこれらがスキルシートから読み取れないと、1年経過した経験者として扱ってもらえない。

"自走力"の本当の意味

ここで特に注意したいのが、自走力の定義だ。

よくある誤解は「自走力=割り当てられたタスクを自分で進められる」。
これは違う。それは最低ラインの話であって、1年経ったジュニアに求められている自走力じゃない。

本当に見られている自走力はこっちだ。

チームのフォローまで気が回る動き方ができるか

たとえば、こんな動きがそれに当たる。

  • 自分のタスクが早く終わった時、他メンバーが詰まっていないか見に行く
  • レビューで気づいた点を、指摘だけでなく改善提案の形で伝える
  • 若手や新人が詰まっていたら、自分の経験をシェアする
  • ドキュメントが足りないと気づいたら、自分で書いてみる
  • 会議で議論が空転していたら、論点を整理してみる

これらは全部、「割り当てられていないのに自分から動いた」経験だ。そしてこれこそが、現場担当者が本当に評価している自走力の正体だ。

具体的に書く例

チーム開発での動き方を具体的に書くと、こうなる。

「5名チームの中で、バックエンドAPI実装とレビュー対応を担当。自分のタスクが先行した時は、他メンバーのPRレビューを優先的に回してブロッカー解消に動いた。後輩2名の質問対応にも入り、Git運用のオンボーディング資料を自分で作成した。」

「開発担当」とだけ書くのと、ここまで肉付けするのでは、読む側の印象が全く違う。この人はチームに貢献できる人だと伝わる。それが次の案件での期待値を決める。

関連: エンジニアに求められる「コミュ力」は、明るさじゃない——言語化と対話の姿勢の話

1年目を終えたジュニアが、スキルシートに足すべき3つのこと の図版 1

足すべきこと② — "1年前の自分"との差分を書く

2つ目。1年前と何が変わったかを、具体的に書き残す

"差分"として捉えると、書くべきことが見える

1年前の自分と今の自分、何が違うか。
抽象的に考えるとフワッとするが、分解すれば書ける。

  • 1年前は「Reactで簡単な画面が書ける」程度 → 今は「Context APIで状態設計ができる」
  • 1年前は「GitはローカルのPushだけ」 → 今は「チームの運用に沿ってPR・レビューができる」
  • 1年前は「タスクが来てから動く」 → 今は「タスクの背景を自分で確認してから着手する」

技術だけじゃなく、動き方の変化も"差分"に含める。
これを書き出す作業自体が、自分の1年を可視化するトレーニングになる。

スキルシートには、"進化の軌跡"が書ける

スキルシートの経歴欄に、1年間の差分を具体的なエピソードで書く。

Before(入場直後):

「Reactを学習。ToDoアプリを個人で開発。」

After(1年後):

「Reactで状態管理を設計。チームの画面実装で、再利用可能なコンポーネント設計を担当。useEffectの依存配列で発生した無限ループを、自分で原因を特定して解決した経験あり。」

同じ「Reactできる」の話なのに、後者は1年の成長の証拠が詰まっている。これが"値札"の原資になる。

足すべきこと③ — "詰まって解決した経験"を書く

3つ目。1年間で「困ったけど自分で解決した経験」を書く
これが実は、最も差がつくポイントだ。

自走力の証拠は、具体エピソードにしか宿らない

現場で1年もやれば、必ず「詰まって、悩んで、解決した」経験が何度かあるはずだ。その時の経緯を、スキルシートに書く。

例えばこんなエピソード。

  • 本番環境でだけ発生したバグを、ログを漁って原因を特定した
  • パフォーマンス問題で、SQLのN+1問題を発見して解消した
  • 仕様が曖昧だった機能を、PMに質問を重ねて認識を揃えてから実装した
  • リリース直前に起きた障害の一次対応に入った

これらは、研修ではぜったいに身につかない経験だ。
だからこそ、書く価値がある。
"詰まったときに、自分で動いて解決できる人"だと伝われば、エージェントも現場も安心して次の案件にアサインできる。

「大したことない」と思っていても、書く

ジュニアがよくやるのが、「このくらいの解決は誰でもできる」と思って書かないパターン。
でもそれは罠だ。本人にとっては小さな解決でも、他人から見れば自走力の証拠になる。

書いてから「これ書きすぎかな?」と削るほうが、書かなすぎて現在地が伝わらないより100倍マシだ。

関連: 自分が携わった案件を説明できないエンジニアが多すぎる——キャリアの記憶は、消える前に記録しろ

1年目を終えたジュニアが、スキルシートに足すべき3つのこと の図版 2

スキルシートを見直して、次の1年の土台を作ろう

改めて、3つの足すべきことを振り返る。

  • ① "チーム開発での動き方"を書く
  • ② "1年前の自分"との差分を書く
  • ③ "詰まって解決した経験"を書く

この3つを足すだけで、スキルシートは別物に変わる。
1年の経験が、ちゃんと値札として反映される形になる。

書き直したスキルシートを、一度俯瞰して見返してほしい

ここまで書き足し終わったら、完成したスキルシートを少し引いて眺めてみてほしい。

どうだろう?
現場での経験を書き足した自分のスキルシートを見てみると——不思議と、自信が湧いてこないだろうか

「あ、自分、この1年でこんなことまで経験してたんだ」
「確かにチームに貢献できてた場面はあったな」
「この時の問題解決、改めて思い返すとよくやれたな」

自分の経験を言語化して、棚卸ししたことで、自身の強みや特徴を一歩深く理解できる
この感覚は、スキルシートを書き直さないと絶対に手に入らない。
日々の業務に追われているだけでは、自分のやってきたことを"価値"として実感する瞬間がほぼ無いからだ。

だから、スキルシートの定期的な見直しは必要だ

スキルシートは、"転職のための書類"じゃない。
定期的に自分を見つめ直すための、キャリアの鏡だ。
年に1回、できれば半年に1回。
経験を棚卸しして、書き足す。
それだけで、次の1年の動き方が変わる。

自信を持って動けるエンジニアと、自分の強みを掴めないまま動くエンジニア。
この差は技術力じゃない。自分を言語化してきたかどうかの差だ。

そして、1年目を終えたジュニアがもう一つ気をつけたいのが、「エージェントが変わると、また書類を作り直す問題」だ。
次の案件探しで別のエージェントを使うなら、スキルシートの形式がそのまま使えないケースが多い。
その時に毎回ゼロから作り直していたら、1年で積んだ経験がまた薄まる。

関連: エージェントが変わるたびにスキルシートを作り直す問題——もう終わりにしよう

Skillsheet-Port|スキルシートポート なら、1年分の経験を追記していくのも、次のエージェントに向けて体裁を整え直すのも、同じフォームで完結する。
差分更新機能で、前回バージョンから今回の追加分だけをサクッと反映できる。
年に1回、経験を総棚卸しするタイミングの相棒になる。

1年の経験を、次の1年の選択肢に変えるのは、ほんの1時間のスキルシート更新から始まる。

Next Action

まずは1枚作って、伝わる形にする

経歴や強みは、スキルシートに落とした瞬間から整理しやすくなります。

Series

ジュニアエンジニア実務ガイド

5 / 6本目

連載
  1. 1

    スクールや職業訓練校を出て半年、案件が取れないジュニアに足りない"たった1つ"のもの

  2. 2

    職業訓練校でJavaを学んだあなたが、案件で選ばれないたった1つの理由

  3. 3

    独学で1年、エンジニアとしての"現在地"を即答できますか?

  4. 4

    初案件の最初の3ヶ月、ジュニアエンジニアが詰む4つの定番パターン

  5. 5

    現在の記事

    1年目を終えたジュニアが、スキルシートに足すべき3つのこと

  6. 6

    ジュニアから"戦力"に見られるようになる、3つの分岐点

Related

関連記事

Latest

最新記事