作業を公開すると幸運がついてくる

 (github.com/readme)
45 ポイント 投稿者 GN⁺ 2025-12-29 | 3件のコメント | WhatsAppで共有
  • 幸運は制御不能な外部要因のように見えるが、成果物を公開することで良い機会に出会う確率を高められる
  • 幸運の表面積(Luck Surface Area) は、「何かをする(Doing Things)」ことと「人々に知らせる(Telling People)」ことの積として定義される
  • 作業の実行と公開は開発者・デザイナーなどのクリエイターにとって不可欠な過程であり、個人の好奇心と専門性を示す手段でもある
  • 完璧な成果物を待つよりも、過程や学び、試行錯誤を一緒に共有することが重要であり、それは他の人に刺激を与える行為として機能する
  • 公開された作業は、新しい仕事、協業、講演、コミュニティとのつながりなど予期しない機会を生み出し、これは単なる運ではなく、共有という行為が生んだ確率的な結果である

幸運の表面積という概念

  • 幸運は「予想していなかった良いことが起きること」と定義される
    • 例: OSSライブラリの成功、カンファレンスへの招待、新しい仕事の提案、クライアントの獲得、ポッドキャスト出演、コミュニティ内での人脈形成 など
  • Jason Robertsの定義によれば、幸運の表面積(Luck Surface Area) は、「情熱を持って何かをする度合い」と「それを効果的に伝える相手の人数」の積に比例する
    • 数式で表すと Luck = [Doing Things] × [Telling People]
    • より多くのことを行い、より多くの人に知らせるほど、幸運の表面積は大きくなる

作業をする (Doing the work)

  • 公開する前に、まず実質的な作業の遂行が必要
    • 開発者、デザイナー、クリエイターなどは本質的に何かを作る人であり、これが幸運の土台になる
  • 人には2つのタイプがある
    1. すでに多くのことをしているが、自分の作業には共有する価値がないと思っている人
    2. 何かを始めたいのに実行できない人
  • 1つ目のグループは、自分が持つ知識の価値を過小評価する傾向があり、コミュニティで共有されている事例を観察すると、自分にもすでにできることが多いと気づける
  • 2つ目のグループには、小さく始めることが必要
    • 完璧なアイデアを待たず、小さなプロジェクトや実験から始めるべき
    • 「動きは動きを生む」

好奇心と専門性の発揮

  • 個人プロジェクトは好奇心を探求するのに良い場である
    • 例: GitHub Issueを印刷するレシートプリンターの制作、組み立て式倉庫をオフィスに改造、SVG描画ツールの開発、金融インフラに関する長文ニュースレターの執筆 など
  • 業務プロジェクトは専門性を発揮するのに適した領域である
    • 仕事で解決した問題や学んだことをブログ、発表、オープンソースプロジェクトに転換できる
    • 詳細が非公開でも、概念・教訓・パターンは共有できる
    • 1か月の業務の中で興味深い問題やパターンを記録しておくと、共有できるアイデアが豊富になる

公開する (Hitting the publish button)

  • 多くの人が共有の段階で恐れを感じる
    • 理由としては、批判への恐れ、完璧主義、マーケティングへの拒否感などがある
  • しかし共有は自慢ではなく学びを広げる行為であり、他の人に刺激を与え、学習を助ける過程である
  • 公開プラットフォームはTwitter、GitHub、ブログ、ニュースレター、YouTubeなどどこでもよく、「ハードドライブ以外の場所」であればよい
  • 共有は学ぶべきスキルであり、完成した成果物だけでなく、進行過程、失敗、思考プロセスも一緒に分かち合うことが重要
    • 最初はぎこちなくても、続ければ自然になる

幸運をつかむ (Capturing the luck)

  • 作業を公開すると、予期しないポジティブな結果が起こる可能性が高まる
    • 例: 特定分野の専門家として認識される、読者からのフィードバック、求職の提案、クライアントからの問い合わせ、講演依頼、コミュニティ内での人脈形成、OSSプロジェクトの認知度向上 など
  • これらの事例は実際に著者が経験したことであり、共有によって幸運の表面積が拡張された結果である
  • 核心となる公式はシンプル
    • Do the work. Tell people.
    • 好奇心と専門性を深く掘り下げ、学んだことを公開の場で分かち合うこと
  • オンラインでの批判は避けられないが、批判する人よりも、静かに応援している人のほうがはるかに多い
    • 最終的には、そのうちの一人が人生を変える機会をもたらすかもしれない

関連記事

3件のコメント

 
wedding 2025-12-29

ジュニアたちにいつも強調していたことの一つが、
「問題を解決したら、それをきちんと整理して公開された投稿として残せ」でした。

まず、整理する過程で一連の流れをもう一度見直すことになるので思い出しやすいですし、
同じ問題にぶつかってもググれば自分の文章が出てくるので素早く解決できます（過去の自分、ありがとう！）。
さらに、誰かの役に立つこともあるので評判も上がり得る、と説明していました。
 
GN⁺ 2025-12-29
Hacker Newsのコメント

  • 私はオープンソース（OSS）業界で働いてきた人間として、自分のGitHubプロジェクトが有名にならないことを心から願っている
    50個以上のスターを獲得した実験的なプロジェクトはいくつもあるが、それらが「本物の」OSSに発展しなくてよかった
    古いプロジェクトのバグ修正依頼や、興味のないPRレビューのせいで週末を失ったこともある
    OSSメンテナンスは報酬のないパートタイムの仕事に近い。名声も限られており、優れたOSS開発者でさえ業界で適切な仕事を見つけるのに苦労している
    OSSメンテナーは、世界のソフトウェアを支える聖人のような存在だと思う

    • 私もOSSで長く働いてきたが、「メンテしない」と「子どもの誕生日も諦めてPRレビューする」の間の中間段階がもっと広く受け入れられてほしい
      GitHubのREADMEに、「PR歓迎」「セキュリティ・重大バグのみ修正」「新しいメンテナー募集中」のようなステータスバッジを追加できるとよい
    • オープンソース文化はこの数十年で大きく変わった。今ではユーザー数が貢献者よりはるかに多く、メンテナーが商用製品のエンジニアのようなサポート役を担うようになっている
      だから最近は、「なぜわざわざこんな社会契約を結ばなければならないのか？」という疑問が生まれる
      代案としては、セルフホスト型のGitコミュニティを通じた自律的なプロジェクト運営がある。こうした方式はメンテナーの努力を商品化せず、オープンソースを再び楽しいものにできる
    • GitHubはOSSメンテナーの生活を改善できる立場にあるのに、問題解決にもっと積極的でないのが残念だ
      たとえば、5年間手つかずのリポジトリにPRが来たら自動でコードレビューの要約を提供したり、無礼なコメントをフィルタリングする機能を導入したりできるはずだ
    • 私も最近、いくつかのライブラリをメンテ疲れのため非公開に切り替えた。「マネージャーを呼べ」と言わんばかりの権利意識の強いユーザーたちが体験を台無しにした
    • 新しいOSSプロジェクトを始めたが、基本はオープンソースにして、エンタープライズ向けオプションを追加する予定だ
      コードを公開しなければコミュニティの信頼形成は難しく、「メールを残せばホワイトペーパーPDFを差し上げます」式のやり方は2025年には通用しない
      0ドルの100%は相変わらず0だが、**巨大市場の0.001%**でもかなり大きなチャンスだ

  • この記事の要点を見ると、結局は誰か別の人（たいていは企業）がオープンソース公開で最大の利益を得る構造になっている
    GitHub（=Microsoft）が「無料労働の搾取装置」に見えてしまう理由もここにある
    バランスの取れた記事なら、こうした    利益相反    に警鐘を鳴らすべきだった

    • 私も同感だ。投資家が「完璧でなくても早く出せ」と助言するのも、似たような危険なアドバイスに聞こえる。彼らは資源が豊富なので、必要ならただ複製すればいい
    • （筆者）その記事を書いたのは私だ。自分のOSSプロジェクトが成功して人生が変わった。もちろん、人によって違うだろう
    • 若い世代には、なぜ私たちがGPLを作ったのかをもう一度理解してほしい
      企業は私たちの無償労働を好むが、雇用はしない。「おかげで助かりました、でも採用はしません」という感じだ
      今では私たちのコードがLLMの学習データに吸収され、名前すら残らない

  • 私は海に向かって文章を投げ込み、何の反応も返ってこないような気分だ
    プラットフォームは「もう1回投稿すれば成功するよ」とささやくが、本当にそうなのか懐疑的になる

    • Startups for the Rest of Us のインタビューを聞くと、継続こそが鍵だ
      ある人はプロダクト主導のマーケティングで3年後に成功し、別の人は5年間ブログで読者を積み上げた後にOSSを収益化した
      結局、「運を増やす」という言葉はモチベーション用のスローガンに近いが、実際には最低5〜6年の継続的な努力が必要だ
    • 私たちは今やLLMの幽霊コンテンツ生産者になりつつある
      私たちの文章は企業の学習データに吸収され、読者はその企業に金を払い、私たちは感謝の言葉すらもらえない
      人間同士の直接交流が可能なクローズドなコミュニティだけが例外だ
    • たまに、何の期待もなく書いた文章が思いがけず爆発的な反応を得て、逆に手間をかけた文章が埋もれるのがいちばん皮肉だ
    • （冗談）その記事にTikTokのダンス動画も一緒に載せたの？
    • こんにちは、仲間の人間よ

  • 私もこの記事には深く共感する
    OSSのおかげで、履歴書やコーディングテストなしで複数の会社からオファーを受けた
    GitHubカスタマーサポートで一緒にバグをデバッグしていたらMicrosoftのMDに推薦されたこともあるし、Cloudflareでも似たことがあった
    結局、OSSは信頼ベースのネットワークを作るための道具だ

    • その通り、結局はネットワーク効果の話だ。私も25年間、正式な応募をしたことはほとんどない
      本を書き、カンファレンスでサイン会をしているうちに、自然と機会が生まれた

  • 私が考えるオープンソースの段階はこうだ
    1. 自分の仕事の中で感じた痛みのポイントを見つける
    2. その問題を解決するツールを作る
    3. Reddit、HN、Blueskyなどで自然に共有する
    オープンソースはシグナル発信の手段だ。うまくいけば名刺代わりになり、コンサルや採用の機会につながる
    例として、2023年4月にLangChainを見て Langroid LLM agent framework を作り、
    さらに Claude Code Tools というCLIツール集も運営している。
    こうしたプロセスが、オープンソースを学術出版に似た信頼蓄積の手段にしてくれる

  • （風刺）「やあ、オープンソース農奴のみんな！ 私たちのAIが君たちの仕事を代替できるように、もっとデータを提供してくれ！」

    • 「バズる直前の99%のオープンソース開発者は諦めます！ だからお願い、あなたの訓練データ…じゃなくて、コードをアップしてください！」
    • （筆者）私はGitHubの社員ではない。ただ自分の個人的な経験を共有したかっただけだ
    • おそらく非公開リポジトリも学習に使われているのだろう

  • 私は数学の本を何冊か書いたが、運は少し増えたものの、1200時間の労働は最低賃金ですら回収できなかった

    • だからそれこそが**「運」の本質**なんだ。たくさん試せば確率は上がるが、保証はない
    • 私も活発なOSSコントリビューターだが、職業的な報酬にはつながらなかった

  • 私も何かを公開することで、良い仕事を何度も得てきた。金持ちにはならなかったが、キャリアには大いに役立った

    • （ユーモア）わあ、Beej's Guide to Network Programming をもう一度ありがとう！
    • 私も同じ経験をした

  • （筆者）この記事は数年前に書いたものだが、再びHNで見かけてうれしい
    当時のスレッド でも似たような議論があった
    多くの人は「機械に餌をやるための文章」だと言うが、この記事が私の人生を変えた。他の人にも役立てばと思う

    • 申し訳ないが、その記事はまったくのたわごとだと思う。本当に価値があるのは、最高水準の作品を出したときだけだ

  • 筆者の肩書きが「Aaron Francis, Marketing Engineer」らしいが、今はマーケティングもエンジニアリングと呼ぶのかという疑問が湧く

    • 実際、いろいろな分野でセールスエンジニアのような肩書きは昔からあった。技術的な助言をする役割だ
    • （筆者）当時の私はマーケティング職を担う開発者だった。質問歓迎です
    • 「DevRel」の進化形と見ることもできる。純粋なエンジニアがマーケティングに転じるとき、アイデンティティを保てる表現として気に入っている
      私のGitHubプロフィール
    • 「フルスタックエンジニア」のように、今は言葉の意味が拡張された時代なんだ
 
roxie 2026-01-01

> Luck = [Doing Things] × [Telling People]

数年前にもこの公式を見た気がしますが、うまく実践できていませんでした、この間は