会社という「看板」を捨てて、裸の王様にならないために
異国の地で感じた「強烈な心細さ」の正体
正直に言いますね。私が初めて海外のオフィスに足を踏み入れた時、最初に感じたのは高揚感ではなく、「透明人間になったような恐怖」でした。
日本では、それなりに名の通ったSIerで働いていました。「〇〇社のエンジニアです」と言えば、相手は「ああ、あのしっかりした会社の」と勝手に信用してくれたものです。でも、一歩国境を越えると、その日本の会社の看板なんて、悲しいくらい誰も知りません。
私の目の前にあったのは、英語で書かれた膨大な仕様書と、見たこともない規模のレガシーコード、そして「お前は何ができるんだ？」という同僚たちのシビアな視線だけ。
C#やWPFのスキルには自信がありました。MVVMパターンも理解しているし、非同期処理もお手の物。でも、ふと気づいたんです。
「もし明日、この会社が倒産したり、ビザのトラブルで解雇されたら、私には何が残るんだろう？」
日本なら転職エージェントに登録すれば何とかなるかもしれない。でもここは海外です。現地のネットワークも弱い、言葉の壁もある。その時、私は「会社の看板」に守られていただけで、自分という個人のブランド力は「ゼロ」に等しいという現実に打ちのめされました。
「履歴書」は過去しか語らない
海外での就職活動やプロジェクトへの参加において、私たちはよくLinkedInのプロフィールやResume（履歴書）を必死に磨き上げますよね。
「〇〇プロジェクトでWPFを使用してUIパフォーマンスを20%改善」
「〇〇システムのリアーキテクチャを担当」
もちろん、これは大事です。でも、これらはすべて**「過去の栄光」であり、しかも「閉じた世界での出来事」**なんです。採用する側からすれば、「本当に？ 君がやったの？ それともチームの手柄？」という疑念が常に残ります。
特に私たちのような外国人エンジニアを採用するのは、企業にとってリスクです。コミュニケーションコストがかかるかもしれないし、文化的な摩擦があるかもしれない。そのリスクを乗り越えて「こいつと一緒に働きたい」と思わせるには、紙切れ一枚の履歴書では弱すぎるんです。
そこで私が出会った概念、それが**「Your Open Source Empire（あなたのオープンソース帝国）」**という考え方でした。
雇用主を超越した「個人のブランド」
ある日、私が技術的な調査でGitHub上の有名なC#ライブラリ（仮にPrismやMvvmToolkitのようなものとしましょう）のIssueを眺めていた時のことです。
そこには、世界中のエンジニアが議論を交わしていました。その中で、特定の個人の発言が、メンテナ（管理者）からも、他のユーザーからも絶大な信頼を得ていることに気づきました。
彼のプロフィールを見てみると、彼は特定の巨大テック企業の社員ではありませんでした。どこかの国の、小さな開発会社のエンジニア。でも、そのライブラリのコミュニティにおいて、彼は「王」のような影響力を持っていました。
彼が「この実装なら、こっちのパターンの方がメモリ効率がいいよ」とコメントすれば、誰もが耳を傾ける。
彼が「新しい職を探している」とつぶやけば、世界中からオファーが殺到する（実際にそんな場面を見ました）。
これだ、と思いました。
彼は、会社という狭い枠組みの中で評価されるのではなく、「コード」という世界共通言語を通じて、自分の価値を証明し、自分だけの「帝国（＝影響圏）」を築いていたのです。
これが「Future-Proof Career（未来に通用するキャリア）」の本質だと確信しました。会社がつぶれようが、国が変わろうが、GitHub上の草（コミットログ）と、そこで築いた信頼関係は誰にも奪えません。
なぜ今、C#エンジニアにOSSなのか？
「OSS活動なんて、Web系のキラキラした言語（JavaScriptやPython）の話でしょ？ Windowsデスクトップアプリ開発の私たちには関係ないよ」
そう思っているC#エンジニアがいれば、それは大きな間違いであり、同時に巨大なチャンスを逃しています。
かつてMicrosoftはクローズドな文化でしたが、今は違います。.NET Core以降、Microsoftは世界最大級のOSS企業に変貌しました。WPFも、WinUIも、Mauiも、主要なフレームワークはオープンソース化されています。
しかし、Web系に比べて、デスクトップアプリ開発の領域は、まだまだOSSへのコントリビューター（貢献者）が少ないのが現状です。
つまり、**「競合が少ない」**のです。
ニッチなバグ修正、ドキュメントの翻訳、サンプルの作成。こういった地味な作業の一つ一つが、Web界隈よりもはるかに目立ちやすく、コアな開発者（Microsoftの中の人など）に認知されやすい環境が整っています。
私が実際に体験したことですが、あるWPF関連のライブラリの小さなバグを修正してプルリクエストを送ったところ、そのライブラリを使っている世界中の企業から「君、WPF詳しいね」と認識されるきっかけになりました。
社内の評価面談で「頑張りました」と言うより、GitHubのURLを一つ送る方が、海外では100倍の説得力を持つのです。
「帝国」を築くことの本当の意味
ここで言う「帝国」とは、決して傲慢な意味ではありません。
それは、**「自分がコントロールできる信頼の領域」**のことです。
会社員である以上、私たちは常に他人の作った城（会社）の石垣を積む作業をしています。それは給料をもらう対価として当然のことです。
でも、それと並行して、自分の城の基礎も作っておかなければなりません。
OSS活動を通じて築く「帝国」には、以下の要素が含まれます：
- Technical Proof（技術の証明）：口先だけではない、動くコードとしての実力証明。
- Global Network（世界的な繋がり）：会社の同僚以外の、利害関係のない技術者仲間。
- Reputation Portability（評判の可搬性）：どの国、どの会社に行っても持ち運べる「あの人はできる」という評判。
これから海外を目指す人、あるいは今海外で戦っている人。
会社に依存する「駐在員マインド」や「出稼ぎマインド」を捨てましょう。私たちは、会社というパトロンを利用して、自分自身の最高傑作（＝キャリア）を作り上げるアーティストであるべきです。
このブログシリーズでは、具体的にどうやってその「帝国」を築き上げていくのか。
英語に自信がなくても、超絶ハイスキルなハッカーでなくてもできる、泥臭くも確実なステップを次回（承）から解説していきます。
ただの「意識高い系」の話にするつもりはありません。私が実際に手を動かし、恥をかき、そして手に入れた「実利」の話をします。
準備はいいですか？
次回は、C#エンジニアが具体的にどこのリポジトリを狙い、どうやって最初のプルリクエストを投げるか、その戦術論に入っていきます。
C# エンジニアがOSSで「帝国」を築く具体的なロードマップ
「天才ハッカー」である必要はない
まず、OSS（オープンソースソフトウェア）活動を始めるにあたって、最大の勘違いを解消しておきましょう。
多くの人が「OSSに貢献するなんて、Linuxのカーネルをいじるような天才か、コンパイラの構造を熟知しているようなスーパーハッカーしかできない」と思い込んでいます。
断言します。それは間違いです。
むしろ、私たちが目指す「帝国づくり」において、天才的なコードを書く必要は全くありません。
私が海外に来て実際に目にしたOSSの現場は、もっと泥臭く、そして「人手不足」でした。メンテナ（管理者）たちは、日々の仕事に追われながら、ボランティアでライブラリを保守しています。彼らが求めているのは、魔法のようなアルゴリズムを提案してくる魔法使いではなく、**「散らかった部屋を片付けてくれる掃除人」であり、「壊れた窓ガラスを直してくれる修理屋」**なのです。
ここに、凡人である私たちが入り込む巨大な隙間があります。
Step 1: 戦場を選べ（WPF / .NET 界隈のニッチ戦略）
これからOSSを始めるなら、いきなり「Microsoft/dotnet/runtime」のような超巨大リポジトリや、Web系の流行りのライブラリ（ReactやVue周辺）に飛び込むのはお勧めしません。
あそこはレッドオーシャンです。コメントの流れが速すぎて、初心者のプルリクエスト（PR）なんて波にのまれて消えてしまいます。
私たちが狙うべきは、**「中規模かつ、企業の業務システムでよく使われているC#ライブラリ」**です。
例えば、WPFをやっているなら：
- MaterialDesignInXamlToolkit
- MahApps.Metro
- Prism
- CommunityToolkit.Mvvm
このあたりが狙い目です。これらは世界中の業務アプリで使われていますが、メンテナの数は意外と少ない。
特にWPFのようなデスクトップアプリ技術は、Webに比べて枯れている技術（成熟している技術）と見なされがちで、新規参入者が少ないんです。だからこそ、ここで活動すると**「めちゃくちゃ目立ちます」**。
私が最初に目をつけたのは、業務で使っていたあるUIライブラリの「DataGridのスクロール時の挙動がおかしい」という小さなバグでした。
競合が少ない場所で戦う。これが弱者の戦略であり、帝国の第一歩です。
Step 2: 「英語力」ではなく「再現力」で殴れ
海外で働く、あるいはOSSに参加する際、最大の壁になるのが「英語」ですよね。
「Issue（バグ報告や機能提案）を書きたいけど、文法が間違っていたら恥ずかしい…」
わかります。私も最初は翻訳サイトの画面とにらめっこして、送信ボタンを押すのに1時間かかりました。
でも、メンテナの立場になって気づいたんです。「流暢なポエム」よりも「動く再現コード」の方が100倍ありがたいということに。
私の英語は今でも中学生レベルですが、それでも信頼されている理由はただ一つ。
**「Reproduction Steps（再現手順）」と「Minimal Reproduction Repo（最小限の再現リポジトリ）」**を徹底的に作り込んでいるからです。
「なんか動かないんだけど」と長文の英語で愚痴ってくるネイティブスピーカーより、
「このリポジトリをCloneしてF5を押すと、例外が落ちる。ここをこう直すと動く」と、拙い英語とコードで示してくれる外国人（私たち）の方が、エンジニアの世界では圧倒的に「Communicative（話が通じる）」と評価されます。
英語はツールに過ぎません。C#という共通言語がある限り、私たちは対等以上に渡り合えます。
「I found a bug. Here is the reproduction code.」
これだけで十分。これが私の最初の武器でした。
Step 3: ドキュメントという「トロイの木馬」
いきなりコードを修正するのが怖いなら、最強の裏口入学ルートがあります。
それが**「ドキュメントの修正と翻訳」**です。
多くのOSSはドキュメントが古かったり、サンプルコードが間違っていたりします。
「WPFのBindingの説明、これ古くないか？」
「ここのリンク切れしてるぞ」
これを見つけて修正するだけで、立派なコントリビューターです。
さらに効果的なのが、**「日本語化（Localization）」**です。
「この素晴らしいライブラリを日本の開発者にも広めたいから、日本語のREADMEを追加させてくれ」と提案して断るメンテナはいません。
これをやると何が起きるか。
あなたの名前がリポジトリの「Contributors」リストに載ります。そして、メンテナとの直接の会話が発生します。
「Thanks for your work!」と言われたら、もうあなたは「外野」ではありません。そのコミュニティの「内側の人」です。
この「小さな信頼」を積み重ねておくと、いざコードの変更（PR）を送った時に、「ああ、あのドキュメントを直してくれた彼か。なら変なコードじゃないだろう」と、レビューのハードルが下がります。
まさに、信頼を得るためのトロイの木馬戦法です。
Step 4: 会社の業務をOSSに還元する（Win-Winの構築）
これが最も「得する」フェーズです。
私は普段の業務で、C#でWPFの設計開発をしています。当然、使っているOSSライブラリのバグに遭遇したり、「ここにこういうプロパティがあれば便利なのに」と思うことがあります。
以前の私は、その場しのぎの回避策（ワークアラウンド）を自社のコードに埋め込んでやり過ごしていました。
でも今は違います。
**「業務時間中に、OSS本体を直しに行く」**のです。
もちろん会社には許可を取りますが、説得は簡単です。
「このバグを放置すると将来的に負債になります。回避策を作るより、ライブラリ本体を直してマージさせた方が、アップデート時も安心ですし、何より当社の技術力を世界にアピールできます」
こうして、会社の金（給料）でOSS活動をし、自分のアカウントに「草（コミットログ）」を生やす。
修正がマージされれば、会社の問題も解決し、世界中のユーザーも助かり、自分の評価（GitHub上のプロフィール）も上がる。
**「三方よし」**の状態です。
これを繰り返すと、面白いことが起きます。
そのライブラリを使っている他の海外企業のエンジニアから、GitHub上でメンションが飛んでくるようになるのです。
「Hey, 君のあの修正、助かったよ。ところでこっちの問題についてはどう思う？」
これです。これこそが、前回の記事で話した**「会社を超えたネットワーク」**の始まりです。
LinkedInで知らない人にメッセージを送るより、GitHubのIssueスレッドで技術的な議論を戦わせた相手の方が、はるかに濃い「戦友」になれるのです。
継続は力なり、ただし「低空飛行」でいい
最後に、最も重要なのは「続けること」です。
でも、毎日深夜までコードを書く必要はありません。そんなことをしたら燃え尽きます。
私も平日は忙しいので、OSS活動は「週末の朝、コーヒーを飲む間の1時間だけ」と決めています。
それでも、1年続ければ50時間以上の貢献になります。
GitHubのプロフィールには、まばらでも確実に緑色の草が生え続けます。
海外の採用担当者（リクルーター）が見ているのは、爆発的な活動量ではなく、**「この人は何年にもわたって、コンスタントに技術に関わり続けているか」**という継続性です。
それが、技術への情熱の証明になるからです。
さて、ここまでで「どうやって帝国への足掛かりを作るか」はお話ししました。
でも、実際に活動を始めると、必ずぶつかる壁があります。
理不尽なリジェクト（却下）、放置されるPR、文化的な摩擦。
次回の**「転」では、そういったトラブルや、OSS活動を通じて実際に私が体験した「予期せぬドラマ（良くも悪くも）」**についてお話しします。
ただコードを書くだけでは終わらない、人間臭いコネクションと、そこから生まれた驚きのキャリア展開について。
準備はいいですか？
まだリポジトリをForkしていなくても大丈夫。まずはGitHubのトレンドページを眺めることから始めましょう。
コードの向こう側にある、予期せぬ「コネクション」と「信頼」
深夜のDMが告げた「逆求人」の衝撃
OSS活動（私の場合はWPF系のライブラリへの細かな貢献）を続けて半年ほど経ったある日のことでした。
時差ボケと戦いながら仕事を終え、何気なくLinkedInを開くと、見知らぬ外国人からダイレクトメッセージ（DM）が届いていました。
「Hey, GitHubで君のPRを見たよ。あのDataGridのメモリリーク、僕らも数ヶ月悩まされていたんだ。素晴らしい修正だった。ところで、今仕事探してたりしない？ もしよかったら、うちのCTOと話さないか？」
送り主は、私が貢献していたライブラリを使っている、アメリカ西海岸のスタートアップ企業のエンジニアでした。
衝撃でした。
今まで私は、「仕事とは、求人サイトを血眼になって探し、履歴書を何十通も送りつけ、面接官に媚びを売って手に入れるもの」だと思っていました。
しかし、この時は違いました。仕事の方から、私を探し当ててやってきたのです。
彼らにとって、私の学歴も、年齢も、居住地もどうでもよかった。
ただ、「自分たちが困っている問題を解決できるコードを書ける人間である」という、GitHub上の事実だけが全ての信頼の源泉でした。
これが「Empire（帝国）」の最初の恩恵でした。
自分のスキルを可視化して置いておくだけで、私が寝ている間にも、私のコードが勝手に営業活動をしてくれていたのです。
「就職活動」という概念が、「自分が必要とされる場所とのマッチング」に変わった瞬間でした。
炎上と和解：GitHubは「技術の法廷」である
もちろん、良いことばかりではありません。OSSの世界は残酷なまでに実力主義であり、時には議論が紛糾することもあります。
ある時、私は自信満々で大規模なリファクタリングのPRを送りました。「これでコードが綺麗になる！」と信じて疑いませんでした。
しかし、返ってきたのはメンテナからの冷ややかなコメントでした。
「君の変更は破壊的すぎる。既存のユーザーへの影響を考えていない。却下（Close）。」
正直、カチンときました。「良かれと思ってやったのに！」と。
PCの前で顔を真っ赤にして、反論のコメントを書き殴りそうになりました。
でも、ここで感情的になったら「扱いにくい面倒なやつ」というレッテルを貼られて終わりです。これは全世界に公開されている「法廷」なのだと思い直しました。
私は深呼吸をして、Google翻訳を使いながら冷静に返信しました。
「フィードバックありがとう。破壊的な変更であることは理解した。では、既存のAPIを維持したまま、内部ロジックだけをこのように変更するアプローチはどうだろうか？ これなら互換性を保てるはずだ」
数回のラリー（議論）の後、メンテナの態度が軟化しました。
「なるほど、そのアプローチなら理にかなっている。君は粘り強いな。マージしよう」
この経験で得たものは、コードがマージされた実績以上のものです。
**「対立が起きても、建設的な議論で解決できるプロフェッショナルである」**という証明です。
実はこれ、海外で働く上で最も重視される「Soft Skill（ソフトスキル）」なんです。
英語がペラペラであることよりも、技術的な意見の相違があった時に、感情的にならずに解決策を模索できる能力。
GitHubのIssue上でのやり取りは、そのまま最強の「性格証明書」になります。
「オフライン」で回収される伏線
OSS活動を始めて数年後、私はアメリカで開催された技術カンファレンス（Microsoft Buildのようなものと考えてください）に参加する機会を得ました。
会場のホールでビールを飲んでいると、名札を見たある男が声をかけてきました。
「おい、そのハンドルネーム…まさか、あの『MemoryLeakFixer（仮名）』か？」
それは、私がよく貢献していたWPFコントロールのライブラリの作者でした。
私たちは一度も会ったことがないのに、まるで10年来の親友のようにハグを交わしました。
「あの時の非同期処理のバグ、君のおかげで助かったよ！」
「いやいや、君のライブラリのおかげで今の仕事ができているんだ」
その夜、彼とその周辺のエンジニアたちと飲みに行きました。
そこには、有名なテック企業のリードエンジニアや、著名な本の著者もいました。
通常なら、名刺交換すらさせてもらえないような雲の上の人たちです。
しかし、私は「彼らのコミュニティに貢献している仲間」として、その輪の中心にいました。
そこで飛び交う情報は、ブログやニュースサイトには絶対に出てこない「一次情報」ばかり。
「次の.NETのバージョンでは、実はここのAPIがこう変わるらしい」
「あそこの会社、今度大規模なレイオフがあるから、優秀なエンジニアが流出してくるぞ」
これが**「Networking（ネットワーキング）」の真髄**だと痛感しました。
異業種交流会で配る名刺の数なんて無意味です。
「コード」という共通の価値観で繋がった信頼関係は、国境も会社の壁も軽々と超えていきます。
この時できたコネクションは、その後の私のキャリアで、困った時に相談できる最強の「顧問団」となりました。
「看板」がなくても、私は私であるという自信
「起」で話した、あの「会社という看板を失う恐怖」は、もう完全に消えていました。
今の私には、会社の肩書きがなくても、世界中に私のコードを知っている人がいます。
何かあれば助けてくれる仲間がいます。
そして何より、「どの国に行っても、どの会社に行っても、自分はこの手とコードで信頼を勝ち取ることができる」という、**揺るぎない自己効力感（Self-Efficacy）**がありました。
これこそが、私が目指していた「Future-Proof Career（未来に通用するキャリア）」の正体だったのです。
お金や地位は後からついてきます。
先に手に入れるべきは、**「誰にも奪われない、自分だけの信頼経済圏（エンパイア）」**でした。
しかし、ここで一つ疑問が生まれます。
「そんなにOSSにのめり込んで、本業はおろそかにならないのか？」
「会社から独立してフリーランスになるのがゴールなのか？」
実は、そうではありません。
OSSで帝国を築くことは、会社員としてのキャリアを終わらせることではなく、むしろ**「会社員としての価値を極限まで高め、自由を手に入れる」**ための手段なのです。
次回の最終回**「結」**では、この長い旅の結論として、
OSSで築いた「帝国」を維持しながら、どうやって現実のキャリア（給与、ポジション、ライフスタイル）に還元し、10年後も笑ってエンジニアを続けていくか。
その「出口戦略」と、これから海外を目指すあなたへの最後のメッセージをお届けします。
物語は、いよいよクライマックスへ。
コードの先に見つけた「自由」の話をしましょう。
10年後、どこでも生きていける「自分」という最強の資産
「会社を辞めるため」ではなく「会社で自由に振る舞うため」の帝国
まず、最大の誤解を解いておきたいことがあります。
私が「自分の帝国を築け」と声を大にして言ってきたのは、全員にフリーランスになれとか、起業しろと言いたいからではありません。
むしろ逆です。
**「会社員として、最強に心地よく働くため」**にこそ、外の世界（OSS）での評価が必要なのです。
OSS活動で「社外での市場価値」が確立されると、社内での立ち位置が劇的に変わります。
以前の私は、理不尽な仕様変更や、無意味なレガシー保守の命令に対して、「No」と言えませんでした。クビになったら終わりだと思っていたからです。ビザのスポンサーを失う恐怖に怯えていました。
しかし、OSSで「帝国」を築いた今は違います。
「その技術選定は古いです。今のトレンドやコミュニティの動向から見て、こちらのライブラリを採用すべきです。なぜなら私はそのメンテナと直接話ができるからです」
こう言えるようになった途端、上司や経営陣は私を一人の作業員としてではなく、**「技術的なパートナー」**として扱うようになりました。
「あいつが言うなら間違いないだろう」
「あいつにご機嫌に働いてもらった方が、会社にとっても得だ」
「いつでも辞められる（他に行ける）」というカードをポケットに持っている人間こそが、結果的に会社に残り続け、最も自由に、最も良い条件で働くことができる。
これが、私が海外生活で手に入れた最大の逆説的真理です。
C# / .NET エンジニアこその「複利効果」
Web系のフロントエンド技術は移り変わりが激しく、3年前の知識が役に立たないことも珍しくありません。
しかし、私たちが主戦場としている C# / .NET / Windows Desktop (WPF/WinUI) の世界は違います。ここは、技術の寿命が長い「ロングテール」な市場です。
だからこそ、OSS活動の**「複利効果（Compound Interest）」**が効きます。
私が3年前に書いたWPFのBehavior（振る舞い）のコードは、今でも世界中の業務アプリで動いています。5年前に翻訳したドキュメントは、今でも新人の学習に使われています。
一度コミットしたコードは、私が寝ている間も、遊んでいる間も、GitHub上でずっと働き続け、私の名前を売り続けてくれます。
これは、労働集約型の「仕事」ではなく、資産蓄積型の**「投資」**です。
毎週末の1時間のコード書きは、銀行預金よりも遥かに確実な、キャリアへの積立投資だったのです。
海外でエンジニアとして生き残るためには、瞬発的なスピード勝負よりも、この**「信頼の残高」**をどれだけ積み上げられるかが勝負を分けます。
10年後、体力が落ちて徹夜ができなくなっても、この「残高」があれば、私たちはアーキテクトとして、あるいは技術顧問として、余裕を持って生きていけます。
言葉の壁を超えた「ギバー（Giver）」の特権
日本人はよく「英語ができないから…」と萎縮します。
でも、ここまで読んでくれたあなたならもう分かるはずです。OSSの世界では、流暢な英語よりも**「有用なコード」と「誠実な態度」**が共通言語です。
そして、日本人のエンジニアが持つ「細部へのこだわり」「丁寧な検証」「バグを許さない責任感」。これらは海外、特に欧米のエンジニアコミュニティにおいて、驚くほど高く評価されます。大雑把なプルリクエストが多い中で、日本人の緻密な仕事は輝いて見えるのです。
私たちは「言葉のハンデ」を「技術の質」で埋めることができます。
そして、OSS活動を通じて世界中に「恩（Give）」を売っておくこと。
誰かのバグを直し、誰かの質問に答え、誰かのライブラリを改善する。
この「Giver」としての活動は、必ず巡り巡って自分に返ってきます。
それは、突然のヘッドハンティングメールかもしれないし、困った時に助けてくれる神のようなアドバイスかもしれない。あるいは、ふと訪れた国で「一杯奢らせてくれ」と言ってくれる友人かもしれない。
孤独な海外生活において、この**「世界中に味方がいる感覚」**は、何億円積んでも買えない心の安定剤になります。
最後の一歩：今日、草を生やそう
これから海外を目指すあなた。
あるいは、今まさに異国の地で、自分のキャリアに不安を感じているあなた。
履歴書を磨くのを一旦やめて、GitHubを開いてみませんか？
完璧なコードでなくていい。
世界を驚かせるようなアルゴリズムでなくていい。
あなたが今日業務で苦労して解決したその「WPFのコンボボックスの変な挙動の回避策」。
それを汎用化して、Gistに貼り付けるだけでもいい。
使っているライブラリのREADMEの誤字を一つ直すだけでもいい。
その小さな「Commit」ボタンのクリックが、あなたの帝国の最初のレンガになります。
私は、C#が好きです。WPFが好きです。
そして、コードを通じて世界と繋がれるこの職業を、心から誇りに思っています。
会社という枠を超えて、一人の「個」として世界に立った時、見える景色は本当に広くて美しいですよ。
Your Open Source Empire.
あなたの帝国を築き始めましょう。
GitHubのどこかのIssueスレッドで、あなたに会えるのを楽しみにしています。
それでは、Happy Coding!
コメント