誤解だらけのOSS参加と、僕らが直面する「見えない壁」
異国の地で感じた「孤独」と「焦り」
今、僕はこのブログをオフィスの近くにあるカフェで書いています。窓の外は少し曇り空。エスプレッソの香りと、周りから聞こえる英語（と、たまに聞こえる多国籍な言葉）の雑音の中で、Visual Studioを開くのが日課です。
C# WPFエンジニアとして海外で働く。
響きはいいかもしれませんが、現実は結構シビアです。WPF（Windows Presentation Foundation）という技術は、素晴らしいけれど、どうしても「デスクトップアプリ」「社内システム」「Windows専用」という閉じた世界になりがちです。
日本にいた頃はそれでも良かった。「仕様通りに動くものを作る」ことが正義だったから。でも、海外に来て痛感したのは、「自分のスキルが世界で通用するのか？」という強烈な不安です。
こっちのエンジニアたちは、履歴書（CV）やLinkedInに平気で「GitHubのプロフィール」を載せてきます。「俺はこんなプロジェクトに関わってるぜ」とアピールしてくる。一方で、僕の手元にあるのは、守秘義務（NDA）でガチガチに固められた、誰にも見せられない社内システムのソースコードだけ。
「あれ？ もしかして僕、エンジニアとしての証明書を持ってないのと同じじゃね？」
この焦りが、僕をOSS（オープンソース・ソフトウェア）の世界へと突き動かした最初のきっかけでした。
「OSSはスーパーマンの遊び場」という大誤解
多くの日本人エンジニア、特に業務系アプリを作っている人たち（僕も含めて）は、OSSに対してこんな勘違いをしていませんか？
- 「Linuxカーネルとか、Reactとか、超有名なフレームワークのコア部分をガリガリ書ける天才たちの場所でしょ？」
- 「英語で高度な議論ができないと、参加する資格なんてない」
- 「自分の書くコードなんて汚すぎて、世界に公開したら笑われる」
これ、全部間違いでした。いや、間違いというよりは、「ハードルを自分で勝手に上げすぎている」と言ったほうがいいかもしれません。
僕も最初はそう思っていました。「WPFのOSSなんてあるの？」レベルの認識でしたから。でも、GitHubを漁ってみると、そこには宝の山があったんです。
Prism, MaterialDesignInXamlToolkit, MahApps.Metro… 僕らが普段お世話になっているライブラリたち。それらのリポジトリを覗いたとき、僕は衝撃を受けました。
そこにあったのは、神々の記述ではなく、**「普通の人たちが、泥臭くバグ報告をし合い、小さな修正を積み重ねている現場」**だったんです。
自分に合った「インパクトのあるプロジェクト」を見つける
今回のテーマである「The Untapped Power of Open Source（オープンソースの未開の力）」を解き放つための第一歩は、**「自分にとって意味のあるプロジェクトを見つけること」**です。
ここで重要なのは、「有名なプロジェクト」ではなく、「自分の専門性に合致した（Aligned with your expertise）プロジェクト」を選ぶこと。
例えば、C# WPFエンジニアの僕が、いきなり流行りのPythonのAIライブラリに貢献しようとしても、学習コストが高すぎて挫折します。それは「貢献」ではなくただの「勉強」です。もちろん勉強も大事ですが、海外で働くエンジニアとしての「生存戦略」としては効率が悪い。
僕がとった戦略はこうです。
**「業務で使っていて、不便だと感じたことがあるライブラリ」**をターゲットにする。
これなら、ユーザーとしての知見がすでにあります。「このDataGridの挙動、なんかおかしくない？」とか「ここのドキュメント、分かりにくいな」という、「ユーザーとしての不満」こそが、実は最強の貢献の種になるんです。
僕が見つけたのは、あるマイナーなWPFのUIコンポーネントライブラリでした。スター数はそこそこだけど、メンテナーが忙しそうで、Issue（課題）が溜まっている。
「これだ！」と思いました。
なぜ今、OSSなのか？ 得られる「3つの資産」
このブログを読んでいるあなたが、これから海外を目指す、あるいは既に海外にいるなら、OSS活動は単なるボランティアではありません。それは、以下の3つの資産を築くための投資です。
- 「世界共通のポートフォリオ」国境を超えて、あなたのコードの品質、コミュニケーション能力、問題解決能力を証明する唯一無二の証拠になります。面接で「英語は苦手ですがコードは書けます」と言うより、マージされたPull Requestを一つ見せるほうが100倍説得力があります。
- 「生きた技術英語」教科書の英語ではありません。変数名の付け方、コミットメッセージのニュアンス、Issueでの丁寧な反論の仕方。これらは、現場でしか学べない「エンジニアのための実戦英語」です。これをタダで、しかもネイティブのレビュー付きで学べるなんて、英会話スクールよりコスパが良いと思いませんか？
- 「心理的な安全性（居場所）」これが一番意外な効果でした。異国の職場で孤立感を感じていても、GitHub上のコミュニティでは、コードという共通言語で対等に扱われます。「Thank you for your contribution!」というたった一言が、どれだけ異国の地で働くエンジニアの心を救うか。
「コードを書く」だけが貢献じゃない
さて、ここまで読んで「よし、じゃあバリバリコードを書くぞ！」と意気込んだあなた。ちょっと待ってください。
実は、OSSのパワーを最大化する鍵は、**「いきなりコードを書かないこと」**にあるんです。
多くの人がここで挫折します。環境構築に手間取り、コードの全容を理解しようとして沼にハマり、結局何もできずにフェードアウトする…。
そうならないための戦略があります。それが、次回のテーマである**「Beyond just coding: identifying non-code contributions（コード以外での貢献）」**です。
実は、メンテナーたちが一番喉から手が出るほど欲しがっているのは、洗練されたアルゴリズムのコードよりも、もっと地味で、でも不可欠な「ある作業」だったりするんです。
C#エンジニアとして、論理的に、かつ戦略的にOSS攻略を進める方法。
次回【承】では、僕が実際にどうやって最初の一歩を踏み出し、メンテナーの信頼を勝ち取っていったのか。その具体的な「裏ルート」についてお話しします。
キーボードの準備はいいですか？
世界はあなたのコミットを待っていますが、まずは焦らず、深呼吸。
コードを書くだけが能じゃない！「非コード貢献」という裏ルート
「いきなりプルリク」は死亡フラグ
前回、「OSSはスーパーマンの遊び場じゃない」と言いましたが、それでも他人の家の敷居をまたぐのは緊張しますよね。
特に僕らC#使いがOSSのリポジトリ（例えば、大規模なWPFコントロールライブラリなど）をクローンした直後に直面する絶望感、分かりますか？
git clone して、Visual Studioで .sln ファイルを開いた瞬間。
ソリューションエクスプローラーにずらりと並ぶ、50個以上のプロジェクト。
「ビルド」ボタンを押した途端に吹き出す、大量の赤いエラー。
「NuGetパッケージのバージョンが合わない」「SDKが足りない」「証明書エラー」……。
「あ、これ無理なやつだ」
そうやって、そっとVisual Studioを閉じた経験、僕にはあります。あなたにもあるはずです。
他人の書いた、しかも歴史のある巨大なコードベースをいきなり理解して、機能追加やバグ修正のコードを書くなんて、ハッキリ言って難易度が高すぎます。それは、RPGでレベル1のままラスボスの城に突撃するようなものです。
そこで提案したいのが、正面突破ではなく、「裏ルート」からの攻略です。
それが、今回のテーマである**「Non-code contributions（コード以外の貢献）」**です。
これは「逃げ」ではありません。むしろ、海外のエンジニアとして賢く立ち回るための、最も効率的な**「信頼構築フェーズ」**なのです。
ターゲット1：ドキュメントの「バグ」を修正せよ
エンジニアなら誰でも共感してくれると思いますが、**「世界中のエンジニアは、ドキュメントを書くのが嫌い」**です。
コードを書くのは大好きだけど、説明文を書くのは後回し。更新されずに放置された README.md や、リンク切れだらけのWiki。これがOSSの日常です。
ここに、僕らの勝機があります。
僕が最初にやった貢献は、あるMVVMライブラリの「Getting Started」の修正でした。
そこに書いてある通りにコマンドを打っても動かなかったんです。理由は単純、ライブラリのバージョンが上がって、メソッド名が変わっていたから。
僕はコードを一行も書き換えませんでした。ただ、ドキュメントの古いメソッド名を新しいものに書き換え、英語の誤字を一つ直して、Pull Request（PR）を送っただけです。
所要時間、15分。
翌朝、メンテナーからこんな返信が来ました。
“Thanks! I totally forgot to update this section. You saved me time.” （ありがとう！更新するのを完全に忘れてたよ。助かった。）
この瞬間、僕は「外野の人間」から「プロジェクトの協力者」になりました。
特にWPFの場合、XAMLの記述例（Snippet）が間違っていることがよくあります。Binding のパスが間違っているとか、Converter の指定が抜けているとか。
これらは、ソースコードの深いロジックを理解していなくても、「使ってみた人間」なら誰でも気づけるバグです。
英語に自信がない？ 大丈夫です。技術ドキュメントの英語なんて、文法より事実が大事です。それに、タイポ（誤字）修正のような些細なことでも、コミットログにあなたの名前が残ることに変わりはありません。
ターゲット2：「再現手順」という名のプレゼント
次に効果的なのが、Issue（バグ報告）のトリアージです。
OSSのIssue欄を見てみてください。「動かない」「クラッシュした」という、情報不足の悲鳴で溢れかえっています。メンテナーたちはこれを見てため息をついています。「環境は？ 再現コードは？ エラーログは？」
ここで、あなたが助け舟を出すのです。
誰かが報告したバグを、自分の手元で検証してみる。
「僕の環境（Windows 11, .NET 8）でも再現したよ。最小限の再現コード（Minimal Reproduction Code）を作ったから貼っておくね」
これをやるだけで、メンテナーからの好感度は爆上がりです。
特にWPFのバグは、UIの階層構造やデータコンテキストの複雑さが絡むので、**「最小構成のプロジェクト（MainWindow.xamlとViewModel一つだけ）」**でバグを再現させてあげることは、神業に近い貢献になります。
これには、「製品コードを汚すリスク」がゼロというメリットがあります。
自分のGit操作ミスで本流のコードを壊す心配がない。リラックスして、純粋に技術的な検証スキルだけで貢献できる。しかも、他人のバグを検証する過程で、そのライブラリの挙動に詳しくなれます。一石二鳥どころではありません。
ターゲット3：ローカリゼーション（翻訳）の罠とチャンス
「日本人なんだから、日本語翻訳（i18n）をやればいいじゃん」
と思うかもしれません。もちろん、リソースファイル（.resx）を追加して日本語対応するのは立派な貢献です。
でも、あえて言います。まずは英語のドキュメントやIssueに関わることをお勧めします。
なぜなら、日本語訳の貢献は、メンテナー（多くの場合は英語話者）にとって「中身が正しいか検証できない」からです。
「ありがとう、マージしておくよ（何書いてあるか分からんけど）」で終わってしまうことが多い。
それよりも、英語のドキュメントの不備を指摘したり、英語のIssueコメントで技術的な補足をしたりする方が、**「こいつは技術が分かっている」**という認識を相手に植え付けることができます。
海外で働くエンジニアとしてのプレゼンスを上げるなら、ここは避けて通れない道です。
「あ、あの時の君か」を目指す戦略
これらの「非コード貢献」を積み重ねると、何が起きるか。
メンテナーやコミュニティの中に、あなたのアイコンと名前が刷り込まれていきます。
「いつもドキュメントを綺麗にしてくれる人」
「Issueの検証を手伝ってくれる丁寧な人」
この**「信用残高（Trust Credit）」**が貯まった状態で、初めてコードの修正（機能追加やロジック変更）のPRを送るのです。
するとどうでしょう。
「あ、彼が出してきたコードなら、まあ変なことはしてないだろう」というバイアスがかかり、レビューが驚くほどスムーズに通ります。
いきなり知らない外国人が家に上がり込んでくるのは怖いけど、いつも庭の掃除を手伝ってくれている隣人なら、笑顔でドアを開けてくれる。OSSも人間関係で動いているんです。
僕はこの「裏ルート」を使って、あるプロジェクトではコミッター権限をもらうまでになりました。
最初は、READMEの誤字修正から始まったんですよ？ 信じられますか？
さて、こうしてOSSコミュニティの中に「居場所」を作った僕ですが、実はこの活動、単なるボランティアや自己満足では終わりませんでした。
次の章では、このOSS活動が、いかにして僕の**「本業（現地の会社での仕事）」に直接的なメリットをもたらしたか**、そして予想もしなかったキャリアへの波及効果についてお話しします。
「OSSやってると残業減るよ」って言ったら、興味ありますか？
次回【転】で、その秘密を明かします。
本業への「即効性」と、予想外の「副作用」
「OSS活動は、休日のボランティア」だと思っていませんか？
もしあなたが、上司から「業務時間外に何をしてるんだ？」と聞かれて、「いや、ちょっとOSSのメンテを…」と答えるとき、少し後ろめたい気持ちになりますか？
まるで、仕事をサボって趣味に没頭しているような。
僕も最初はそうでした。週末にカフェでGitHubの通知を消化するのは、完全に「趣味」の領域だと思っていました。
でも、ある日、オフィスのデスクでその認識が覆る瞬間が訪れました。
それは、WPFエンジニアなら誰もが一度は発狂する、あの瞬間です。
「DataGridのBindingが、特定の操作でなぜか外れる」
同僚のマーク（仮名）が頭を抱えていました。
「おい、このグリッド、スクロールするとチェックボックスの状態が消えるぞ。Virtualization（仮想化）の問題か？ それともViewModelのバグか？」
チーム全員でデバッガーを走らせ、OutputウィンドウのBindingエラーを睨みつけるも、原因不明。納期は迫っている。空気は最悪。
その時、僕の脳内でシナプスが繋がりました。
「あ、これ、先週あのOSSライブラリのIssue #402で議論されてたやつだ」
まるで「進研ゼミ」現象！ 仕事が劇的に速くなる
僕は即座に言いました。
「マーク、それ多分WPF標準の仮想化バグじゃないよ。DataTemplateの中でバインディングの UpdateSourceTrigger を明示的に指定してないから、スクロールでリサイクルされた時にロストしてるんだ。ここをこう書き換えてみて」
修正にかかった時間は30秒。
マークの画面からバグは消え去りました。
「マジかよ？ なんでお前そんなこと知ってるんだ？ 魔術師か？」
魔術師ではありません。ただ、**「現場の最前線で交わされている会話」**を見ていただけです。
これが、OSS活動が本業にもたらす最大のメリット、**「トラブルシューティング能力の爆発的な向上」**です。
OSSのイシュー（Issue）欄は、世界中のエンジニアが踏んだ「地雷」の展示場です。
「この環境だとクラッシュする」「このプロパティを併用すると動かない」
そういった情報を日常的に浴びていると、いざ自分の仕事で同じエラーに出くわした時、デジャヴが起きます。「これ、知ってる！」と。
Stack Overflowで検索するよりも速い。なぜなら、検索キーワードすら思いつかないようなニッチなバグの「文脈」を、既に知っているからです。
この一件以来、僕はチーム内で「WPFの挙動で困ったらあいつに聞け」というポジション（The Guy）を確立しました。
海外の現場では、この**「Expertise（専門性）の証明」**こそが、リストラ候補から遠ざかる最強の盾になります。
ブラックボックスの中身が見える「透視能力」
もう一つの即効性は、ライブラリやフレームワークに対する恐怖心がなくなることです。
多くのエンジニアにとって、NuGetで落としてきたライブラリは「ブラックボックス」です。入力に対して出力が返ってくるだけの魔法の箱。だから、意図しない挙動をするとお手上げになる。
でも、OSS活動を通じて「人の書いたコード」を読むことに慣れると、この魔法の箱が**「ただのC#のクラスファイル」**に見えてきます。
「このメソッド、中で何やってるんだ？」
そう思ったら、GitHubでソースコードを検索し、実装を読みに行く。
「あー、ここで Dispatcher.Invoke してるから重いのか」「ここで例外を握りつぶしてるからエラーが出ないのか」
この**「ソースコードまで降りていって原因を突き止める力」**は、実務において圧倒的なアドバンテージになります。
ドキュメントに書いていない仕様を、コードから逆算して理解する。
これは、英語ドキュメントの読解力が低い（かもしれない）僕ら非ネイティブにとって、言語の壁を突破する強力な武器になります。C#という共通言語で会話できるわけですから。
予想外の副作用：英語力が「エンジニア特化型」に進化する
OSS活動を続けていると、英語力にも変化が起きました。
TOEICの点数が上がったわけではありません。でも、**「GitHub英語」**がペラペラになったのです。
- “LGTM” (Looks Good To Me)
- “Nit” (Nitpick: 細かい指摘だけど)
- “AFAIK” (As Far As I Know)
- “PR welcome”
こうした略語や、技術的な議論特有の言い回し（「この変更はBreaking Changeになるリスクがある」とか「この実装だとエッジケースで死ぬ」とか）が、自然と口から出るようになりました。
すると、本業のコードレビューや設計ミーティングでも、発言の鋭さが増します。
以前は「I think this is bad…」としか言えなかったのが、
“I’m concerned about the thread safety here. This pattern might cause a race condition, similar to what we saw in [Library Name].”
（ここのスレッドセーフ性が心配です。このパターンは[ライブラリ名]で見かけた競合状態を引き起こすかもしれません。）
と、具体例を交えて説得できるようになりました。
OSSという「社外の道場」で組手（議論）を繰り返していたおかげで、本業という「試合」でも物怖じしなくなったのです。
そして、世界は繋がる ― リクルーターからの予期せぬDM
【転】のクライマックスとして、僕に起きた一番の驚きをお話しします。
ある日、LinkedInに一通のメッセージが届きました。
差出人は、現地のそこそこ有名なテック企業のリクルーター。
“Hi! I saw your contributions to [Project Name] on GitHub. We are looking for a Senior WPF Engineer who understands the internals of MVVM frameworks…”
（やあ！君がGitHubで[プロジェクト名]に貢献しているのを見たよ。我々はMVVMフレームワークの内部構造を理解しているシニアWPFエンジニアを探していてね…）
震えました。
僕は、自分の履歴書を送ったわけでもない。転職活動をしていたわけでもない。
ただ、自分が業務で困って修正したPRや、英語の勉強がてら書いたドキュメント修正が、巡り巡って「ヘッドハンティング」という形で自分に返ってきたのです。
海外では、”Show, Don’t Tell”（語るな、見せろ）が鉄則です。
「私はWPFが得意です」と履歴書に書く100人より、具体的なコミットログを1つ持っている1人が選ばれる。
OSS活動は、僕が寝ている間も、仕事をしている間も、24時間365日、世界中に僕のスキルを宣伝し続けてくれる**「最高の営業マン」**だったのです。
孤独からの解放
【起】で書いた「孤独感」を覚えていますか？
今の僕に、その感覚はありません。
オフィスの窓から見える曇り空は相変わらずですが、ディスプレイの向こう側には、ドイツのメンテナー、インドのレビュアー、アメリカのユーザーたちがいます。
彼らと共にコードを磨き、議論し、時には「ビール奢るよ（絵文字）」と言い合う。
会社という狭い枠組みを超えて、**「世界のエンジニアコミュニティの一員である」**という確かな実感が、異国の地で働く僕の自尊心を支えています。
さて、OSSがキャリアにとっていかに「美味しい」か、お分かりいただけたでしょうか。
でも、ここまで読んで「よし、やるぞ！」と思ったあなた。最後に一つだけ、伝えたいことがあります。
それは、**「これから最初の一歩を踏み出すあなたへの、具体的なアクションプラン」**です。
気持ちが熱いうちに、何をすべきか。明日から、いや、今からできること。
最終章【結】では、僕からあなたへ送る、C# WPFエンジニアのための「OSS参入・虎の巻」をお届けします。
今日から始める、世界へのコミットメント
旅の終わりに：OSSは「生存戦略」であり「パスポート」だ
ここまで、僕の実体験にお付き合いいただきありがとうございました。
長々と語ってきましたが、僕が伝えたかった核心はたった一つです。
「海外でエンジニアとして生きるなら、会社の壁の中に引きこもるな」
言葉も文化も違う国で、僕らのような「外国人エンジニア」が対等に、あるいはそれ以上に評価されるための武器。それがオープンソースでした。
それは、スーパーハッカーのための遊び場ではなく、僕らのような日々の業務アプリ開発に勤しむエンジニアが、**「世界と接続するためのインターフェース」**なのです。
ドキュメントの誤字を直すことが、誰かの時間を救う。
バグの再現手順を書くことが、開発者の助けになる。
そして、その積み重ねが、いつしか「信頼」という名の、どの国でも通用する最強のパスポートに変わる。
この感覚を知ってしまうと、もう「怖い」と思っていた頃には戻れません。
具体的なアクションプラン：C# WPFエンジニアのための「虎の巻」
「いい話だったな」でブラウザを閉じてしまっては意味がありません。
このブログを読み終えた瞬間から、あなたが踏み出すべき「最初の一歩」を具体的なチェックリストにしました。
特に、WPF/C#界隈に特化した戦略です。
Step 1: GitHubプロフィールを「履歴書」に変える
まず、自分のGitHubアカウントを見てください。デフォルトのアイコンのままではありませんか？
- アイコン: 清潔感のある写真か、認識しやすいアバターにする。
- Bio: “C# WPF Developer based in [都市名/国名]” と明確に書く。
- Pinned Repositories: 自分が学習で作った小さなWPFアプリでもいいので、コードが綺麗なものをピン留めする。
Step 2: 「お気に入り」ではなく「依存先」をウォッチする
いきなり知らないプロジェクトを探す必要はありません。Visual Studioを開き、今の仕事で使っているライブラリをリストアップしてください。
- Newtonsoft.Json
- Prism / MVVM Light / CommunityToolkit.Mvvm
- MaterialDesignInXamlToolkit
- MahApps.Metro
- LiveCharts
これらの中に、必ずGitHubでホストされているものがあります。まずはそれらを「Star（お気に入り）」することから始めてください。これだけで、タイムラインに彼らの活動が流れてくるようになります。
Step 3: 「Issue」を朝のニュースにする
毎朝、通勤電車や始業前のコーヒータイムに、Step 2で登録したリポジトリの「Issues」タブを開く癖をつけてください。
解決する必要はありません。「読むだけ」でいいのです。
「へー、世界ではこんなバグで困ってる人がいるんだ」「あ、メンテナーのこの英語の返し方、カッコいいな」
これを1週間続けるだけで、OSSの空気に慣れてきます。これがいわゆる「ROM（Read Only Member）」からの卒業準備です。
Step 4: 最初の「Give」を行う
目が慣れてきたら、チャンスは突然訪れます。
「ドキュメントのリンクが切れている」「サンプルコードのXAMLのタグが閉じられていない」
見つけたら、心臓がバクバクするのを抑えて、修正し、Pull Requestボタンを押してください。
震える手で書くコメントは、シンプルな英語で大丈夫です。
“Fixed a broken link in README. Thanks for the great library!”
これだけでいい。
「レビュー」を恐れるな、それは「無料の教育」だ
最後に、多くの人が足踏みする最大の理由について触れておきます。
「変なコードを送って、批判されるのが怖い」
分かります。僕も初めてコードのPRを送った時、メンテナーから大量のコメント（Review）がつきました。
「命名規則が違う」「このLINQはパフォーマンスが悪い」「単体テストが足りない」
一瞬、人格否定されたような気持ちになりました。
でも、冷静に考えてみてください。
現役の、世界トップレベルのエンジニアが、見ず知らずの僕のコードを真剣に読み、時間を割いて、より良くするためのアドバイスをくれているのです。
これ、普通にお願いしたら、1時間数百ドルのコンサルティング料が取られるレベルの話ですよ？
OSSの世界では、厳しいレビューこそが**「最高の歓迎」であり「無料の教育」**なのです。
「Thank you for the review! I’ll fix it right away.（レビューありがとう！すぐ直すよ）」
そう返信して、コードを直すたびに、あなたはエンジニアとして確実にレベルアップしています。
結びに代えて：あなたのコードは、海を越える
今、僕が書いた（あるいは修正した）数行のコードは、地球の裏側の誰かのPCで、WPFアプリの一部として動いています。
ブラジルの物流システムかもしれないし、ドイツの工場の制御盤かもしれない。
僕の体はここにあるけれど、僕の仕事（コード）は国境を越えて、世界のどこかで誰かの役に立っている。
これほどロマンのある仕事が、他にあるでしょうか？
海外で働くエンジニアの皆さん、そしてこれから世界を目指す皆さん。
WPFという、一見地味でドメスティックに見える技術でも、扉は世界に開かれています。
必要なのは、英語力でも、天才的なアルゴリズムの知識でもありません。
「Join」ボタンを押す、ほんの少しの勇気だけです。
さあ、Visual Studioの準備はいいですか？
GitHubを開いてください。世界はあなたのコミットを待っています。
Let’s code together, globally.
コメント