面接の終盤では、候補者にオープンソースプロジェクトのリーダー経験や参加経験があるかどうかを尋ねるのが私の習慣です。もし経験があれば、プロジェクトのアドレスを尋ねます。プロジェクトの質を慎重に審査し、履歴書を飾り立てるための土壇場での試みや、最後に記載された例外事項のいずれかに該当しない限り、合意した報酬の増額を検討します。

オープンソースプロジェクトに取り組むと通常の業務に支障が出ると考える人もいるかもしれません。しかし、むしろ、仕事面でも個人面でも、オープンソースプロジェクトは良いことです。これは感傷的な話ではなく、最も現実的な視点に基づいています。

まず、オープンソース プロジェクトに参加することで、技術的な能力が証明されます。

今日の熾烈な競争が繰り広げられる中国のインターネット業界では、長時間労働は当たり前のことです。しかし、彼はそのような状況下でもオープンソースプロジェクトに参加し、卓越した能力を発揮しています。彼はコードを効果的に構造化・モジュール化することで、プロダクトマネージャーの要件変更による時間のロスを最小限に抑え、熟練したユニットテストによってさらに時間を節約しています。「怠惰」はエンジニアにとって美徳と言えるでしょう。

「世界最大のゲイ出会い系コミュニティ」であるGitHubに自分のコードを載せる勇気のある人は、そう多くない。

質の悪いプロジェクトは注目されませんが、質の悪いコードは多くの批判を受けます。コピペしかできないプログラマーは投稿する勇気がありません。しかし、GitHubに投稿されたプロジェクトは誰もが目にし、世界中のエンジニアによる精査の対象となります。あなたのコードは様々な類似プロジェクトと比較され、継続的な最適化と改善を促されます。GitHubは、技術力を判断する一種のフィルターとなっています。

第二に、オープンソース プロジェクトをリードすることで、製品の能力が実証されます。

実際には、プロダクトマネージャーと開発者の視点の違いから衝突するのはごく自然なことです。開発者がプロ​​ダクトマネージャーの視点から機能を検討し、その目的を真に理解し、より良い実装方法を見つけるために協力し合えれば、プロダクトマネージャーは間違いなく感激するでしょう。機能はより完成度が高くなり、プロジェクトは大幅に加速するでしょう。

この製品開発能力はどこから来るのでしょうか？オープンソースプロジェクトのリーダーとしての経験がその一つです。オープンソースプロジェクトに携わる際、彼は人々が何を求めているのかを分析し、実際にその機能を必要としている人がどれくらいいるのかを見極め、自ら開発を進め、プロジェクトをフォローする人々と連携しながら、継続的に機能の最適化とバグの排除に努めます。これはまさに三段階プロダクト開発手法と言えるでしょう。もし彼がこの能力を自然に身につけているなら、会社はコミュニケーションコストを大幅に削減できるはずです。

さらに、オープンソース プロジェクトに参加することはライフスタイルを表します。

仕事があまりにも暇で、他にやることがないからオープンソースプロジェクトを立ち上げる、という状況もあるかもしれません。例えば「董年明月」は「明代之事」を執筆しています。こんなに暇な仕事をしている人はたくさんいるのに、なぜ「董年明月」のような人だけが現れるのでしょうか？ゲームをしたり、微博や微信を閲覧したり、冗談を言ったり、暇な時間にインターネットを閲覧したりする以外に、積極的に自分のスキルを向上させたいという願望はありますか？

この「積極的」な姿勢は、本質的に生き方そのものと言えるでしょう。未知への好奇心からであれ、将来の生活水準への期待からであれ、彼らは外部からのプレッシャーを必要としません。自ら成長しようと意欲的に取り組み、オープンソースプロジェクトに参加してスキルを向上させます。このような人材は技術力に優れ、情報共有を積極的に行うため、どの企業にとってもかけがえのない存在です。チーム全体の士気を高める力があります。つまり、彼らは「ポジティブなエネルギー」を発散していると言えるでしょう。

残念ながら、私自身は100%の成功を達成できませんでした。期待が少し高すぎたのかもしれません。

例外

例外は常に存在しますが、特に次の 2 つが挙げられます。

• 彼はリーダーの同意を得ずに、会社の機密コードを個人的に取得し、オープンソース プロジェクトに貼り付けました。
• 他人のオープンソース コードから著作権情報を削除し、自分のものとして主張すること。

これは個人的な行動の問題です。一度発見したら、何もせずに立ち去るのが最善です。