GitHubがほぼ空だった私が年収200万円上げるまでにやったこと【2026年転職記】

3年前、自分のGitHubはプライベートリポジトリしかなかった。転職活動で面接官に「何かアウトプットはありますか？」と聞かれるたびに「社内ツールを作ってます」としか答えられなくて、毎回ちょっと恥ずかしい思いをしていた。

それから色々やって、去年の転職で年収が約200万円上がった。自慢したいわけじゃなくて、「自分がやったことを整理したい」という気持ちと、同じように悩んでいる人に何か参考になれば、という気持ちで書いている。

結論から言うと、「希少な技術を一つ深掘りする」「定量的に見せられるアウトプットを作る」「副業で市場の感触をつかむ」の3つを同時に動かしたのが効いた。どれか一つじゃたぶん足りなかったと思う。

2026年のIT市場で何が起きているか、まず把握した

動く前に調べた。転職エージェント3社のデータと、実際の求人票を100件くらい読んで、肌感を掴んだ。

2026年時点で需要が強いスキルセットを整理するとこんな感じだ。

スキル領域	需要	平均年収レンジ（東京）	競合人口
AI/ML基盤エンジニア	★★★★★	1,000〜1,800万	少ない
クラウドネイティブ（AWS/GCP）	★★★★★	800〜1,400万	中程度
プラットフォームエンジニア	★★★★☆	900〜1,500万	少ない
フロントエンド（React/Next.js）	★★★☆☆	600〜1,100万	多い
バックエンド（汎用）	★★★☆☆	600〜1,000万	多い
データエンジニア	★★★★☆	800〜1,300万	中程度

フロントエンドやバックエンドは競合が多くて、正直「普通にできる」だけじゃ差別化しにくい。一方でAI基盤周りやプラットフォームエンジニアリングは需要に対して供給が追いついていない。

これを見て、自分の現状と照らし合わせた。当時の自分はバックエンド（Go/Python）が中心で、AWSは「なんとなく触れる」程度。この「なんとなく」をいかに「深く使える」に変えるかが最初の課題だった。

xychart-beta
  title "スキル別求人数と平均年収（2026年東京、転職エージェント調べ）"
  x-axis ["AI/ML基盤", "クラウドNative", "Platform Eng", "データEng", "フロントエンド", "バックエンド"]
  y-axis "平均年収（万円）" 600 --> 1800
  bar [1400, 1100, 1200, 1050, 850, 800]

「広く浅く」より「一点突破×T字型」で進めた

よく「T字型人材になれ」と言われるが、実際にやってみると「Tの縦棒をどこに打つか」の選択が全てだと感じた。

自分が選んだのはクラウドネイティブ×セキュリティの領域。理由は単純で、AWSを日常的に使っていたのと、うちのチームがSOC2対応を始めた時期と重なって、セキュリティの知識が急に重要になったから。正直、最初から戦略的に選んだというより「流れでハマった」感じだ。

実際に試したアプローチはこうやって段階的に進めた。

【フェーズ1：基礎固め（3ヶ月）】
- AWS Solutions Architect Professionalを取得
- 業務でAWS Organizationsのマルチアカウント設計を担当
- GuardDutyやMacieを本番導入（正直めちゃくちゃ苦労した）

【フェーズ2：アウトプット（3ヶ月）】
- 運用で学んだことをブログ記事として言語化
- LT発表（社内2回、外部1回）
- GitHubにツール系コードを公開

【フェーズ3：外部評価（2ヶ月）】
- 副業でインフラ設計の案件を受ける
- 転職エージェント3社に同時登録してフィードバックを集める

フェーズ1はしんどかった。GuardDutyを導入したら最初の1ヶ月でFalse Positiveが嵐のように出て、チームのSlackが通知だらけになった。そのあたりの格闘記はGuardDuty導入3ヶ月の地獄と脱出戦略に書いたので、似たような状況にいる人はぜひ読んでほしい。

「苦労話をブログに書く」は思った以上に評価された。面接で「あの記事読みました」と言われることが3回あった。完璧にうまくいった話より、詰まって解決した話のほうが共感されるんですよね。

アウトプットの「見せ方」を意識して変えた

ここが地味に重要で、最初は全然できていなかった。

技術ブログを書いているエンジニアは2026年時点でかなり増えている。Zennだけでも毎日数百件の記事が投稿されている。その中で「読まれる・評価される」アウトプットにするには、3つのことを意識するようになった。

1. 定量的な成果を入れる

「改善しました」じゃなく「ビルド待機時間が20分から5分になった」という表現にする。数字があると採用担当者に刺さりやすい。CodePipeline V2とCodeBuild Fleetでビルド待機時間が20分から5分に短縮された話も、数字を前面に出したら想定の5倍くらいビューが伸びた。これは正直やってみるまで半信半疑だったけど、数字の引力ってすごい。

2. 「なぜそうしたか」の判断プロセスを書く

実装コードを貼るだけじゃなく、「他の選択肢もあったが、〜という理由でこっちにした」という思考の流れを書く。これが一番差別化になる。

3. OSSへの小さい貢献を積み上げる

フルコミットしなくてもいい。ドキュメントの誤字修正でもissueへのコメントでも、GitHubの草が増えていく。OSS貢献初心者向けガイドに具体的なステップを書いたけど、最初のPRを出すまでのハードルを下げることが大事。

実際に自分のGitHubプロフィールがどう変わったか、コントリビューションの数で見るとこんな感じだった。

xychart-beta
  title "GitHubコントリビューション数の推移（月次）"
  x-axis ["2025/5", "2025/7", "2025/9", "2025/11", "2026/1", "2026/3", "2026/5"]
  y-axis "コントリビューション数" 0 --> 200
  line [12, 28, 45, 89, 134, 156, 178]

最初の数ヶ月はほとんど業務コード（プライベートリポジトリ）だったから草が薄い。ブログ記事をMarkdown管理するリポジトリを作ったり、小さいCLIツールを公開し始めてから一気に増えた。「草を生やすためにブログを書く」という逆転現象も起きて、地味にモチベーション維持に効いた。

副業で「市場の生の声」を拾った

これは個人的に一番大きかった施策かもしれない。

副業を始めた最初の動機は正直「収入を増やしたい」だったけど、結果として「市場が自分のどのスキルにお金を払うか」が分かった。これは社内にいるだけでは絶対に分からない情報だ。

実際に受けた案件はこんな流れで積み上がっていった。

flowchart TD
    A[副業開始\nクラウドコンサル\n月10万円] --> B[AWS構成レビュー案件\n月15万円]
    B --> C[セキュリティ設計支援\n月25万円]
    C --> D[転職活動開始]
    D --> E[年収200万UP転職成功]
    
    A -->|学び| F[自分の市場価値の感触]
    B -->|学び| G[企業が困っている課題の把握]
    C -->|学び| H[希少領域の確信]
    F --> D
    G --> D
    H --> D

副業で分かったのは、「AWS設計ができる人はいるが、セキュリティまで込みで設計できる人が圧倒的に少ない」という実態だった。GuardDutyやMacieの運用を業務でやっていたのが、そのまま差別化になった。

もう一つ副業で気づいたのは、コミュニケーション能力の重要性。エンジニア視点の説明をそのままビジネス側に話しても刺さらない。「このセキュリティ設定が必要な理由をビジネスリスクで説明する」というスキルは、副業の現場で鍛えられた。これは転職してからも地味にめちゃくちゃ役立っている。

キャリアのネットワーキング戦略についてはIT技術者のネットワーキング戦略2026にも詳しく書いたので、人脈作りをもっと体系的に考えたい人は読んでみてほしい。

転職活動で「見せ方」を最適化した

転職活動を実際に動かしてみて、評価されたことと全然評価されなかったことがあった。正直に書く。

評価されたこと（面接官のリアクションが良かった）

• ブログ記事のURL（「GuardDutyで詰まった話」が刺さった）
• 副業での成果（「月25万円のプロジェクト」という数字）
• 本番障害の対応経験（何をどう判断したか）
• チーム内での「橋渡し役」経験（テックリードとビジネス側の翻訳役）

期待したほど評価されなかったこと

• 資格（AWS SAP取ったけど「ふーん」くらいの反応）
• 使用技術の羅列（GoもPythonもできますは特に差別化にならない）
• 業務でのコード品質改善（具体的な数字がないと伝わりにくい）

資格については補足しておくと、「資格が無意味」ということではなく、資格だけでは差別化できないということ。IT資格取得戦略2026年完全ガイドでも書かれているように、資格は学習のフレームワークとして使うのがベストだと思う。実際、AWS SAPを取るために体系的に勉強したことが後々の設計判断に生きた場面は何度もあった。

pie title 転職面接での評価要素（自己分析）
  "実務アウトプット（ブログ・OSS）" : 35
  "定量的な成果実績" : 28
  "副業・外部評価" : 22
  "資格・学歴" : 8
  "コミュニケーション" : 7

この比率はあくまで僕の主観だけど、「実務アウトプット」と「定量的な成果実績」で過半数を占めるイメージは、面接を10社以上受けた感触と一致している。

「長期で積み上げる」ことの複利効果

ここまで色々書いたけど、正直なところを言うと「1年でここまで来れると思っていなかった」のが本音だ。

最初の3ヶ月は全然成果が見えなくて、「ブログ書いても読まれないし、副業も単価低いし」とモチベーションが下がる時期があった。でも続けた理由は単純で、「やめたら確実にゼロになる」という消去法的な判断だった。かっこいい話じゃないけど、それが本当のところだ。

技術の深掘りは特に複利効果が大きい。GuardDutyを運用して苦労した経験があるから、次のプロジェクトでは設計段階で「この構成だとFalse Positiveが多発するから変えましょう」と言えるようになった。その発言が「この人はちゃんと実運用を知っている」という評価につながる。

今、自分のスキルを「誰かに説明できる形」でアウトプットできているだろうか。「業務でやってることをブログにまとめるだけ」で始めるのが、一番摩擦が少なくてオススメだ。

まとめ

2026年のIT市場で市場価値を上げるために実際にやったことを振り返ると、以下に集約できる。

1. 市場調査を先にやる：需要と競合人口のバランスを見て、「レッドオーシャンの普通人材」より「ニッチで高需要」を狙う
2. 業務の苦労話を定量的なアウトプットにする：完璧な成功談より「詰まって解決した話」のほうが評価される
3. 副業で市場の生の声を拾う：社内だけでは分からない「何にお金が払われるか」を体感する
4. GitHub・ブログは採用担当者が見ていると思って整備する：資格より実際のアウトプットが見られている
5. 3〜6ヶ月で成果を求めない：複利効果が出るまで続けることが最重要

次のアクション（今週できること）

• 直近1ヶ月で詰まった技術課題を1つ選んで、ZennかブログにGに書く
• GitHubプロフィールREADMEを整備する（5分でできる）
• 転職エージェント1社に登録して「自分の現在地」を確認する

正直まだ検証中の部分もある。例えば「海外向けのアウトプット（英語での発信）が国内評価にどう影響するか」は今まさにやっているところで、半年後にまた書くかもしれない。

市場価値を上げるのは一朝一夕じゃないけど、「何もしない」よりは「ちょっとずつ続ける」方が確実に違う未来になる。少しでも参考になれば嬉しい。