転職して気づいた“本業だけじゃ足りない”感覚
アメリカに来て最初の3ヶ月、正直いって仕事だけでキャパオーバーでした。C#のWPFアプリを設計開発する日々。英語でのコードレビュー、ミーティング、仕様確認…。慣れない文化に、神経もエネルギーもすり減ってた。
でも、4ヶ月目くらいから、ふと思ったんです。
「このままだと、ただの“社内エンジニア”で終わるな」って。
アメリカの同僚たちは、けっこう“本業以外”にも積極的だった。たとえば：
- GitHubで公開されてるC#ライブラリを週末に手伝ってる
- Tech系ミートアップやカンファレンスに登壇してる
- 自作ツールをブログに公開して、それがポートフォリオ代わりになってる
彼らが持ってる“市場価値”って、会社の中だけじゃなくて、業界全体で認知されてる感じがあったんです。
日本でやってきたWPFのスキルはあるし、UIの実装も得意。だけど、それを**外にどう見せるか？伝えるか？**っていう視点が完全に抜けてた。
そもそも「ポートフォリオ＝就活用」じゃないって気づいた
自分にとって、ポートフォリオって「転職活動のときに出すやつ」っていうイメージでした。
でも、アメリカのエンジニアたちにとってのポートフォリオは、**日々の延長線上にある“公開実績”**だった。
ある日Slackで、同僚が何気なく「この前コミットしたWPFのバグ修正、参考になるかも」ってGitHubリンクを貼ってくれて、そこから世界が変わった。
「こんなにナチュラルに、仕事以外のコードを公開してるのか…」って。
それから、自分も少しずつGitHubを育て始めたんです。
まずやったのは、“小さいWPFツール”の公開
いきなり何か大きなアプリを作ろうとしても続かないのは目に見えてたので、まずは以下のようなWPFツールをいくつか作って公開しました：
- Markdownをリアルタイムでレンダリングするエディタ（MVVM練習用）
- ローカル画像管理アプリ（ObservableCollectionの勉強も兼ねて）
- Windowsのファイル移動をドラッグ＆ドロップで効率化するツール
ポイントは、「自分が仕事で“地味に困ってたこと”をツール化する」ってこと。
実際、作りながら「これ、あの時欲しかったやつだ！」って思うことばかりで、自然とコードに向かうモチベーションが生まれました。
そして、それをGitHubに公開して、英語でREADMEを書く。最初はぎこちないけど、慣れてくるとちょっと楽しい。
サイドギグ＝“技術の見せ場”
さらに、副業として、小さなプロジェクトを受けるようにもなりました。主に日本企業からの依頼で、WPFやWinFormsの保守・UIリファクタリング案件。
ここでも、ただやるんじゃなくて、**「いかに自分の技術スタイルを見せられるか？」**を意識して、以下のような工夫をしました：
- GitHubでソース管理し、共有リポジトリにレビューコメントを積極的に書く
- 実装方針を英語でNotionにまとめて、クライアントと共有
- “使いやすさ”や“保守性”を数値で説明（例：ViewModelの結合度をBefore/Afterで比較）
結果的に、そのNotionの技術資料を海外面接のポートフォリオ資料としても使えるようになって、「これはサイドギグ兼ブランディングだな」と実感しました。
“自分の名前で価値を出す”ってどういうこと？
会社名じゃなく、GitHubの自分の名前で検索されて、誰かに見てもらう。
これは日本ではあまりなかった体験です。
でもアメリカでは、「GitHubに何があるか？」が採用でも、仕事でも、思ってる以上に見られている。
あるリクルーターに「あなたのこのWPFのツール、UIとコード設計がしっかりしてるね」って言われた時、
「あ、これがパーソナルブランドってやつか」って思いました。
まとめ：
- アメリカでは“会社外のアウトプット”が当たり前だった
- オープンソース・副業が「技術の棚卸し」＋「自己表現」の場になる
- 小さくてもいいから“公開していく習慣”が、ポートフォリオを育てる第一歩
GitHubが名刺代わりになる世界で、どう“見せる”かを学んだ
WPFエンジニアとして、どうやってオープンソースや副業を通じてスキルを証明し、評価される存在になるか？
この問いに対して、僕が実際にやったアプローチを順を追って説明します。
1. 小さなOSS貢献からスタートした理由
まず取り組んだのは、「Issue対応」から入るオープンソース貢献。
自分が最初に挑戦したのは、HandyControlというWPF向けのUIコンポーネントライブラリ。このライブラリは、スタイリッシュなWPFアプリを作る上で便利で、日本の業務でも使ったことがありました。
貢献した内容：
- 英語でIssueを確認し、自分が直せそうな簡単なバグ修正を選ぶ
- Fix後はPull Requestを出して、レビュー対応
- READMEの翻訳・補足情報の追加にもチャレンジ
実感したこと：
- 「英語でコードを書く」だけじゃなく、「英語で議論する」ことがこんなに大事なんだと痛感
- 自分が使ってきた技術（WPF）が、国を超えて評価される実感を得られた
- 小さなPRでも、履歴が自分のポートフォリオに残るというのが最大のメリット
2. 副業案件：ニッチなWPF知識が、ちゃんと価値になる
GitHubで活動を続けるうちに、日本の知人からWPF関連の副業を紹介されました。
受けた案件の例：
- 老舗製造業の帳票アプリのUI刷新（DataGridと印刷機能が古いWPFで作られていた）
- スタートアップ企業の医療アプリUIリファクタ（MVVM未対応→分離対応へ）
工夫した点：
- コードレビューをNotion＋GitHubの形で記録し、「設計の意図」を可視化
- 旧コードの“技術的負債リスト”を英語にしてアップし、自分の視点を売りにする
- 作業時間やBefore/AfterのUI改善例をスライドにまとめて、実績として再利用可能に
このスライド、実はLinkedInに投稿して海外の同僚にも見せたところ、「WPFって今もこういうニーズあるんだね」「MVVMの実装うまいね」などの反応があり、そこから新しいコネクションも生まれました。
3. “コード＋文章＋デザイン”で、自分の技術がストーリーになる
ここで強く実感したのが、単にコードを書くだけではなく、
**“何のために”“どんな改善をして”“どう役立ったのか”を言語化できるか？**が超重要だということ。
僕が意識した3点セット：
| 項目 | 具体例 |
|---|---|
| コード | GitHubで実装＋テスト＋レビュー記録を公開 |
| 文章 | Notionで設計意図、改善点、振り返りを書く |
| デザイン | Before/Afterの画面比較をCanvaで図解 |
これらをポートフォリオページにまとめておくことで、たとえ「副業の小さな案件」でも、
“プロジェクト”としての厚みが出て、海外の採用担当にも刺さる資料になります。
4. 英語で書くのが怖い？「PerfectよりHonest」が正解
最初の頃は、READMEに書く英語がとにかく不安でした。
「文法あってるかな？」「変な英語で笑われないかな？」
でも、実際にGitHubで海外のプロジェクトに参加してみて感じたのは、
“完璧な英語”より“わかりやすい構造と意図”が大事ということ。
以下のようなテンプレを活用して、英語の敷居を下げました：
## What this tool does
This is a simple WPF application that helps users organize their image files using drag and drop.
## Why I made this
In my daily work, I needed a quick tool to move files from one folder to another with preview.
## Key features
- Thumbnail preview
- Customizable folder shortcuts
- Light and dark themes
## Technologies
- C#, WPF, MVVM Light, .NET 6
これだけで、「何を作ったのか」「何が目的か」「どんな技術を使ったか」が伝わる。
相手はエンジニアです。中身があれば、多少英語が拙くてもちゃんと伝わる。
5. 海外では「今なにをしてるか？」が、未来のチャンスを作る
アメリカでは、GitHubやLinkedInで「今こんなもの作ってます」「こういう技術を磨いてます」っていう発信が、キャリアそのものの“入口”になるという文化があります。
僕も、WPFとXAMLの設計TipsをLinkedInで何回か投稿したことで、リクルーターやCTOレベルの人から「うちのアプリのUIレビューしてくれないか？」という声をいただくようになりました。
まとめ：
- OSS貢献は「コードを書く」より「議論に参加する」が先でOK
- 副業で得た改善知識や資料を、“再利用可能な実績”に変える
- 英語が完璧じゃなくても、構造と意図がしっかりしてれば評価される
- ポートフォリオは“就活の武器”じゃなく、“日々のアウトプットの集積”
気づいたら“ポートフォリオ経由で仕事がくる側”になっていた
副業やオープンソース活動を続けていたある日、GitHubのダイレクトメッセージに通知が届いたんです。
“Hi, I saw your WPF File Organizer app. Would you be interested in working on a similar tool for our team?”
まさかこんなふうに、自分の公開ツールがきっかけで仕事の依頼が来るなんて思っていませんでした。
1. 技術＋視点が伝われば、チャンスは“向こうから来る”
連絡をくれたのは、米国の小さな教育系スタートアップ。Windows上で教育リソースを管理するアプリの内部ツールが古くなっていて、それをモダナイズしたいという相談でした。
正直、スタートアップの予算は限られていたけど、僕にとっては大きな一歩。
なぜ依頼してくれたのか？
先方が挙げた理由が印象的でした：
- 「コードがシンプルで読みやすかった」
- 「UI設計に明確な方針があった（特にMVVM構造の分離）」
- 「READMEがちゃんとプロジェクトの価値を説明してた」
つまり、“GitHub上の自分の表現”が、そのまま信頼の証拠になってたわけです。
この案件を通じて学んだのは、「小さなアウトプットの積み重ね」が未来の案件を引き寄せる力になるということ。
2. “個人の名前”で仕事をするって、どういうこと？
この経験を通して、次第に自分の中で「働く意味」が変わってきました。
以前は、
✔ 自分の価値 = 所属している会社でどれだけ成果を出せるか
だったのが、いまはこうです：
✔ 自分の価値 = 自分の名前でどれだけ信頼を得て、役に立てるか
もちろん、会社での仕事も大事。でも、それと並行して、**“hiroiwa”というGitHubアカウントや、LinkedInプロフィールそのものが、自分のブランド”**になる感覚。
たとえば：
- 「hiroiwaさんが書いたこのXAMLの設計記事、すごくわかりやすいですね」
- 「このDataTemplate使い方、ぜひうちのチームにも教えてほしい」
みたいな声が、個人あてに届くようになった。これって、日本ではなかなか得られなかった感覚です。
3. “更新されないポートフォリオ”は、存在しないのと同じ
ある程度アウトプットが貯まってくると、次に気をつけるべきなのは**“更新し続けること”**でした。
アメリカでは、採用時に「GitHubが2年間止まってる」とか「LinkedInが古いまま」だと、
それだけで**“成長が止まっている人”と見なされる**リスクがあります。
僕がやっている“継続メンテ術”：
| 工夫 | 内容 |
|---|---|
| 毎月1つ、WPF技術記事を書く | MVVM、Binding、Stylingなど1テーマで1投稿 |
| GitHubで過去プロジェクトの改善PRを出す | コードを見直し、改善記録を残す（例：async/await対応など） |
| “成長中”のプロジェクトを1つ作る | 完成しなくてもよい。現在進行形であることが大切 |
| Notionで「技術棚卸し」ドキュメントを更新 | 新しく学んだこと、失敗、成功体験を定期記録 |
これを習慣にしておくことで、「今も学び続けている人」として認識されるんです。
4. “収入より信用”を優先した判断
ちょっとお金になる案件よりも、「この技術やってみたい」「このチーム面白そう」と思える案件を優先するようにしました。
結果的に、以下のような副業／OSS機会につながりました：
- C#で書かれた古いSilverlightコードのWPF移植プロジェクト（OSS）
- .NET MAUIとWPFのUI比較レポートを英語で執筆（技術記事の仕事）
- ヨーロッパの教育NPOからのWPF UXレビュー依頼（GitHub経由）
これらはすべて、過去に公開したものの“延長線上”で見つかった機会です。
副業で数十万円を稼ぐことよりも、1つの技術で世界中に信用を積み上げる方が、結果的に長期のリターンが大きいと感じるようになりました。
5. 海外では「自分の知識を“見える化”できる人」が強い
アメリカでは、「何を知ってるか？」より、「何を公開してるか？」が評価の軸になることが多い。
つまり、「コードを知ってる」ではなく「コードを書いてる／説明してる」ことが大事なんです。
だからこそ、僕はこう考えるようになりました：
✔ いいコードを書く力
✔ それを説明する力
✔ そして公開する勇気
この3つが揃ったとき、「あなたにお願いしたい」という声が自然と届くようになる。
まとめ：
- GitHubが名刺になり、ポートフォリオが営業代行になる世界
- 「自分の名前＝信用」として仕事を受ける感覚
- 継続的な更新・可視化が、海外キャリアでの信頼を育てる鍵
- 副業もオープンソースも、“公開資産”として育てる意識が大切
C#エンジニアが“自分を世界に売る”ための戦略ガイド
ここまで読んでくださった方なら、きっとこう思っているかもしれません。
「副業もOSSもやってみたい。でも、自分に何ができるんだろう？」
「どこから始めればいいかわからない…」
心配いりません。僕も最初はそうでした。
ここからは、これまでの体験をもとに、**“ゼロからでも始められる行動プラン”**をお伝えします。
ステップ1：まずは「自分だけが欲しかったツール」を作ってみる
一番最初にやるべきことは、他人のためじゃなくて“自分の困りごと”をコードで解決することです。
たとえばこんなテーマ：
- 「CSVファイルをGUIで編集したい」
- 「画像ファイルを自動でフォルダに振り分けたい」
- 「APIレスポンスをGUIでテストしたい」
こういう小さなツールこそ、あなたの設計思想と技術力がにじみ出る最高の素材になります。
作るときのポイント：
| 項目 | 内容 |
|---|---|
| UI | WPFでシンプルかつ実用的なインターフェースを心がける |
| 構成 | MVVMでViewとLogicを分離する構成にする |
| README | 英語で「What / Why / How / Tech Stack / Screenshot」を書く |
| 公開 | GitHubでMITライセンスなどを設定し、誰でも見られる状態に |
ステップ2：技術ブログを始める（NotionでもOK）
コードだけだと伝わらない「意図」や「学び」を文章にして残す習慣をつけましょう。
英語が不安でも、以下のテンプレに沿って書けばOKです：
## Problem
Manually renaming multiple image files was too slow for my daily work.
## Solution
I created a WPF-based tool that allows drag & drop renaming using templates.
## What I learned
- How to bind a ListView to an ObservableCollection
- How to apply DataTemplateSelector for different file types
## Next step
Adding an undo feature and dark mode
Notionで書いたものをGitHubのREADMEに貼ったり、LinkedInに断片的に投稿するのも効果的です。
「成長ログを外に出す」＝信頼の蓄積につながります。
ステップ3：小さなOSSに貢献してみる（Issue解決が入口）
いきなり巨大なOSSに参加しなくても大丈夫。最初は以下のような流れでスタートできます。
- GitHubの「Good First Issue」タグ付きプロジェクトを探す
例：https://github.com/search?q=good+first+issue+c%23 - Issueを読んで、理解できそうなバグや機能提案を選ぶ
- 「I’d like to work on this issue」などとコメントして参加表明
- PRを出してレビュー対応まで完了させる
貢献先のおすすめ：
- HandyControl：WPF UIコンポーネント
- MaterialDesignInXAML
- MahApps.Metro：WPF向けのMetro UIライブラリ
ステップ4：副業を“単発タスク”から始める
アメリカでも副業（side hustle）は一般的。
ただし、まずは「小さな依頼」から入るのがコツです。
以下のようなルートがあります：
- UpworkやFreelancer：英語でプロフィールを整備しておく（GitHubリンク必須）
- 日本の知人・企業からの依頼：地道な信頼構築がキー
- LinkedInでの発信→DMで依頼が来るケースも増加中
注意点としては、副業を単なるお金稼ぎにしないこと。
「この案件が、どんな実績として再利用できるか？」という視点を持つと、ブランディングにつながります。
ステップ5：英語力は“ツールの1つ”と考える
完璧な英語を話せなくても、「伝える力」は練習で必ず伸びます。
おすすめ勉強法：
- GitHubのREADMEを書くことで、英語での技術表現を鍛える
- Notionなどで「技術メモを英語で」書くことで、発信スタイルの型ができる
- LinkedInで短文投稿を週1回続けると、海外エンジニアとの接点が増える
ポイントは、「技術に軸があれば、言語は補助になる」ということ。
英語が苦手でも、明確な構造と意図があれば相手に届きます。
最後に伝えたいこと：
副業やオープンソース活動は、“余裕のある人のもの”じゃない。
むしろ“実績がない人が実績を作るための近道”です。
アメリカで働く中で、**「会社の肩書がなくても戦える人」**が、どれだけ強いかを何度も見てきました。
GitHub、Notion、LinkedIn…どれも無料で始められるし、
自分の名前でコードを書き、説明し、届ける。それが、どんな履歴書よりも強い“信頼の証”になります。
まとめ：行動チェックリスト ✅
✅ 自分のための小さなWPFツールを1つ作る
✅ GitHubに公開し、英語でREADMEを書く
✅ Notionやブログで設計意図・学びを記録
✅ OSSのIssueから貢献を始める
✅ 副業案件を“実績のタネ”として活用する
✅ LinkedInで週1発信を習慣にする
✅ 完璧な英語より、構造と意図を意識する
最後に
もしあなたが、
- 「今はまだ、自信がない」
- 「海外なんて、自分には無理かも…」
と思っているなら、ぜひ伝えたい。
“今できることを、少しずつ外に出す”だけで、景色は変わります。
僕も、ただのWPFエンジニアでした。でも、“公開する勇気”が未来を切り開いてくれました。
コメント