ハクソク

世界を動かす技術を、日本語で。

作品を発表することで運が向いてくる

111日前原文(github.com)

概要

  • 努力だけではなく、運も成功には必要不可欠
  • **運を引き寄せる面積（Luck Surface Area）**を増やすことで、チャンスを広げる方法
  • 自分の活動を公開し、共有することが運を引き寄せるコツ
  • 恐れや不安を乗り越えて、積極的に発信する重要性
  • 成果を発表することで新たなチャンスや出会いが生まれる

運を引き寄せるための考え方

  • どれだけ努力しても、成功には少しの運が必要という現実
  • 運とは「予想外で良いことが起こる」現象
  • OSSライブラリの成功、カンファレンス登壇、転職、クライアント獲得、ポッドキャスト出演、コミュニティでの新しい友人などが運の一例
  • これらは完全に自分でコントロールできない事象
  • 運を引き寄せる確率を上げる方法として「パブリックに活動する」ことが有効

Luck Surface Area（運を引き寄せる面積）

  • Jason Robertsによる概念
  • Luck Surface Area = [行動量] × [伝える人数] というシンプルな公式
  • 情熱を持って何かを行い、それを多くの人に伝えるほど運を引き寄せやすくなる
  • 行動と発信の掛け算でチャンスが広がる

まずは「やる」ことが大事

  • 実際に手を動かすことが全ての出発点
  • すでに何か作っているのに「共有する価値がない」と思い込んでいる人が多い
  • 自分の知識や経験が他人にとって価値があることを忘れてはいけない
  • 何も始められない人は、とにかく小さなことから手を付けることが重要
  • 行動が次の行動を生むという好循環

好奇心や専門性を活かしたプロジェクト

  • 仕事外のプロジェクトで好奇心を追求
    • GitHub issueを印刷するレシートプリンター作成
    • プレハブ小屋をオフィスに改造
    • SVGドローイングツールの開発
    • 金融インフラについての長文ニュースレター
  • 仕事での経験を活かして知見を共有
    • ブログ、カンファレンス、ミートアップ、ポッドキャスト、OSSプロジェクトなど
  • 具体的な内容が公開できなくても、学びや気づき、考え方は共有可能

発信（パブリッシュ）の重要性

  • 多くの人は発信に抵抗を感じる（恐れ、恥ずかしさ、自己防衛、マーケティング嫌いなど）
  • 自分の活動を共有することは自慢ではなく、他人の学びや刺激になる
  • 発信はスキルであり、繰り返すことで上達
  • 完璧を求めず、途中経過も含めて発信することで共感や応援が生まれる
  • どこで発信しても良い（Twitter, GitHub, newsletter, podcast, forum, blog, YouTubeなど）

発信から生まれるチャンス

  • 自分の分野で認知される存在になる
  • 読者やフォロワーから直接連絡が来る
  • 仕事やクライアント、登壇のオファー、業界の友人が増える
  • OSSプロジェクトの注目度向上
  • これらは実際に著者自身が経験した具体例

まとめ：シンプルな公式と実践のすすめ

  • 「やること」＋「伝えること」の公式はシンプルだが、実践は簡単ではない
  • 批判や不安もあるが、それ以上に多くの人が応援してくれる
  • 発信を続ければ、思いがけない幸運が舞い込む瞬間がやってくる
  • 「運が良かった」と思える出来事は、行動と発信の積み重ねの結果

要点

  • 行動と発信の両輪で運を引き寄せる
  • 自分の知識・経験を惜しみなく共有する姿勢
  • 批判を恐れず、まずはやってみる勇気
  • 運を待つのではなく、運を呼び込む体質作り

Hackerたちの意見

これは確実に私には効果があったよ。何かを発信して一攫千金は無理だったけど、いい仕事をいくつか得ることができた。
└
同じく。
└
おお、ビーさん、ネットワーキングガイドをありがとう！
マーケティング用語からの翻訳: > こんにちは、みんな！あ、すみません、大切なオープンソースの貢献者の皆さん！ > 皆さんがトレーニングデータを提供してくれないと、私たちのAIを訓練して、あなたたちの仕事を奪うことができないんですよ！ > さあ、仕事に戻ってください。
└
プライベートリポジトリでも訓練してるんじゃないかな。
└
オープンソースの著者の99%がバイラルになる直前で辞めちゃうんだって!! ぜひ、あなたのトレーニングデータをアップロードしてほしいな…あ、素敵なオープンソースコードのことね？
オープンな海に発信しても、何の反応もない。どのプラットフォームからも「あと一つの投稿で夢が叶う」って言われ続けてるけど、いつかは本当になるよね？
└
こんにちは、仲間の人間！
└
もっと目標を持った方がいいかも。もしただ虚空に発信して、何かが起こるのを期待しているだけなら、私はインフルエンサーじゃないけど、成功している人たちは具体的な目標に向かって動いていて、虚空に叫んでいるわけじゃないよ。ここで私のために答えてほしいわけじゃないけど、自分に問いかけてみて。具体的にその夢は何なの？そこに到達するためにどんな具体的なステップを踏んできたの？それをどうやって達成するつもり？どれくらい時間がかかる？成功の基準は何？リスクは？失敗のパターンは？
└
一番面白いのは、何の前触れもなくランダムな投稿がバズることだよね。自分が良いと思っていることは全然反応がないのに！
└
でも、補完的なTikTokダンスは録画したの？
└
今、https://www.startupsfortherestofus.com/で創業者とのインタビューを見てるんだけど、確かにそういうことが起こるんだよね。ただ、簡単ではないけど。一人の男性は、製品主導のマーケティングだけで3年間かかって、やっとSaaSがいい数字を出すようになったんだ。彼は多分例外的な存在で、番組にも出てるしね。それから、別の男性は5年間Rubyについてブログを書いて、その5年後にそのオーディエンスを使ってOSSプロジェクトを作って収益化したんだ。彼ができたのは、アイデアについてオーディエンスと話していたから。インタビューを聞いてると、自分が何をしているか分かっていれば、2〜3年で利益を出せるSaaSを作れる印象がある。でも、そうなるためには、少なくともさらに3年は誠実に努力し続ける必要があると思う。そこで「運を増やす」っていうのが出てくるんだろうね。モチベーショナルスピーキングの一環としてちょっと浅い感じがするけど、こういうコンテンツが好きな人も多いし、憧れを持ちたいんだろうね。ロブ・ウォーリングやアーロン・フランシスみたいなネット起業家が売ってる本も、実際には読まれずに買われるだけのことが多いし。
> あなたのOSSライブラリが成功することについて 他のポイントはかなり妥当だけど、OSSの仕事をしてきた経験から言うと、私のGHプロジェクトがOSSの世界で成功することは本当に望んでないんだ。50スター以上のプロジェクトがいくつかあるけど、他の人の興味には感謝してるし、どれも本物のOSSプロジェクトになることはなくてホッとしてる。面白い実験をシェアするのは好きだけど、OSSソフトウェアのメンテナンスに何年も縛られたくない。小さなプロジェクトでも、5年前のプロジェクトのバグ修正をしなきゃいけない時があって、どう動くかすら覚えてないし、興味のない問題を解決する熱心なPRをレビューしてマージしなきゃいけない時もあった。週末がいくつか潰れたけど、比較的小さな煩わしさだった。でも、OSSの仕事がどんなものかを味わうことができた。OSSの会社で働くことで、さらに多くの洞察を得た。OSSのメンテナンスは本当に大変で、これを選んでやってる人には感謝してもしきれない。人気のOSSライブラリを運営することは、賞ではない。少なくとも報酬のないパートタイムの仕事みたいなもんだ。メリットは薄いし、「名声」部分（あなたの好きなOSSツールトップ10を挙げて、今そのメンテナーを挙げてみて）も限られてる。OSSライブラリの素晴らしいクリエイターたちが、自分のスキルに見合った仕事を見つけるのが難しいっていうのも知ってる。実際、成功したOSSプロジェクトを運営しながらフルタイムの仕事（特に高給で頭や時間をたくさん使う仕事）を持つのは本当に難しい。OSSプロジェクトをフルタイムの仕事にできない限り…それでも、OSSプロジェクトを収益化する方法を見つけるプレッシャーが常にかかるし（それは結局、その仕事を失ったり、OSSユーザーコミュニティの利益に反する決定をすることにつながる）。私にとって、OSSのメンテナーは聖人だよ。世界中のソフトウェアの多くが彼らに依存してるし（LLMの時代ではさらにそう）、ほとんどの人は平均的なFAANGエンジニアよりもずっと少ない報酬しか受け取ってない。
└
オープンソースの文化はここ数十年で大きく変わったから、今や新しいメンテナーが全体を疑問視するのは全く合理的だよね。スケールがすべてを変えた。初期のOSSと比べて、ユーザーと貢献者の数が桁違いに増えて、感謝しているエンドユーザーと権利を主張するエンドユーザーのバランスが、メンテナーに対する期待を商業世界のプロダクトエンジニアと同じような責任を持つサポート役として偏らせてしまった。今、その社会契約に入る理由は何だろう？ライブラリが成功するリスクと、それに伴うコスト（そして利益）を冒す理由は何だろう？OSSの別の進化的な道は、開発者やコミュニティが自分たちのgitプロジェクトを自己ホストすることだ。プロジェクトは自分たちの倫理観やワークフローを定義できる。発見は高い摩擦があり、メンテナーの努力のコモディティ化を防いでいる。こういうことをサポートするためのカスタムツールを書くハードルがかなり下がったから、過去よりも意味が出てくるかもしれない（ここにはプッシュとプルの両方の力が働いている）。もしかしたら、OSSが再び楽しくなるかもしれないね。
└
最近、いくつかのライブラリを公開停止にしたんだ。メンテナンスが面倒で仕方なかったから。権利を主張する「マネージャーと話したい」みたいな人たちが本当にうんざりさせてくれた。
└
まさにその通り。言葉通りに。俺のOSSプロジェクトのいくつかは偶然人気になったけど、マジで面倒くさいことこの上ない。自分にとってのメリットはほとんどないし。HNのフロントページやr/programmingに載るのはちょっとした自尊心には良かったけど、それだけだね。
└
驚くべきことに、TFAはGH出身で、OSSのメンテナーの生活の質に本当に影響を与える立場にいるんだよね。もし彼らがもっと多くの人にコンテンツを公開させたり、AIがどれだけ素晴らしいかを示したいなら、権利を主張するコメントを事前にチェックして、投稿できないようにすることもできるんじゃない？5年間リポジトリに触れていないことを見て、PRが来たときにコードレビューのサマリーでサポートしてくれるとか。馬鹿な人たちがプレッシャーをかけてくるのを止めるために、彼らのPRがすぐには見られない理由を説明することもできるかも。もしかしたら、GitHubは自分たちが作り出した問題に責任を持って、解決に向けて何か行動を起こすことができるかもしれないね。
└
> 5年前のプロジェクトでバグ修正をしなきゃいけないプレッシャーを感じたことがあるけど、そのプロジェクトがどう動いてたかすら覚えてないし、実際には気にしてない問題を解決する熱心なPRをレビューしてマージすることもある。OSSの分野で何年も働いてきたけど、「全くメンテされていない」と「メンテナーが子供の誕生日を逃してまでPRをレビューする」っていう間にもっとニュアンスがあればいいのにと思う。GHのREADMEにはいろんなバッジがあるけど、「アクティブにメンテされてます、PR歓迎」とか「セキュリティと重要なバグ修正のみ」とか「新しいメンテナー募集中」みたいなバッジもあってもいいんじゃない？
└
あなたの立場にちょっと共鳴するTFAの対になるものがあるよ：https://contraptions.venkateshrao.com/p/semicolon-shaped-peo... これは、優れた人たちが公共の視点や議論に関わる仕事を、非常に些細な形でやったり、全く関わらなかったり（あるいはその両方）することについての記事だよ。もっと明確に説明するのは難しいけど、私にとっては大きな影響を与えた。
└
その通りだね。OSSのメンテナーって仕事だと思うし、簡単にフルタイムの仕事になっちゃう。しかも報酬がほとんどないことが多い。もし別のフルタイムの仕事があるなら、選ばなきゃいけないよね。1. 燃え尽きるまで二つの仕事をする。2. 給料の仕事を辞めて、破産しないことを願う。3. OSSプロジェクトのメンテを減らすか辞める。企業や政府、社会がこの仕事にもっと資金を出してくれればいいのに。でも、これは「共有地の悲劇」問題だから、公共がもっと痛みを経験する前にこれが実現するとは思えないな。
└
それをエクスプロイトのために売ることもできるよ？OSSの報酬の価格は（事件 -1ドル）だね。
└
何年も続けているサイドプロジェクトがあって、主にソフトウェアを書くのが楽しいからやってるんだ。データ管理システムが市場の他のものよりも良く、または早く動くときは、アドレナリンが出るよ。これについて記事を書いたり、バイナリを自分のウェブサイトで「オープンベータ」として無料で公開したりしてる。みんなに、もし本気で成功させたいならオープンソースにすべきだって言われるけど、今のところは、君が挙げた理由のいくつかでそれを避けてる。
私たちがLLMのためのゴーストコンテンツプロデューサーになると、あなたの投稿や本、他の作品に対して何か返事があるべきではない。ほとんどの場合、あなたの作品は数社によってトレーニングデータとして取り込まれ、その作品から利益を得る読者はこれらの会社にお金を払う。そしてその見返りに、これらの会社はあなたが助けた人々から感謝されることを徹底的に遮断し、保護する。これらの会社は、彼らのLLMが自分たちの出力で窒息しないように、あなたが誠実なコンテンツを作り続けるように動機づけるために最善を尽くす。例外は、閉じられた（または半閉じられた）コミュニティやフォーラムで、人間と直接やり取りする場合だ。大規模な人間のユーザーベースによる慣性や（新しい小さなコミュニティの場合は）参加者の個人的な審査を通じて。
└
これをもっと上手く表現できるコメントを探してた。投資家からの「悪いものを早くリリースしろ」ってアドバイスに対しても同じ気持ち。彼らはあなたと話せないなら、クローンを作るリソースを持ってるから、その立場でのコメントは明らかに怪しいよね。
記事は「アーロン・フランシス、マーケティングエンジニア」が書いたんだ。俺は言語の純粋主義者じゃないけど、今の時代にマーケティングで働いてる人を「マーケティングエンジニア」って呼ぶのはどうなの？エンジニアリングの意味をちょっと超えてる気がするんだけど…。
└
まあ、「ソフトウェア」の人たちが始めたことだし、最近フルスタックエンジニアに会ったけど、その言葉にも昔はちゃんとした意味があったよね。
└
「Devrel」という言葉の進化だと思うけど、まだちょっとダサい感じがする。実際にエンジニアとしてキャリアを築いてきた人が、その言葉を急に捨てて「マーケティング」の一般的な誰かになるのは望ましくないよね。彼らはそれ以上の存在なんだから。考えれば考えるほど、この用語が好きになってきたよ。 https://github.com/aarondfrancis
└
エンジニアリングのいくつかの分野では、昔からそんな役割があったよね。モーターに関わることをしたいけど、モーター、ギアボックス、ブレーキ、エンコーダー、コントローラーの正しい組み合わせを計算する方法が分からない？マクソンの営業エンジニアが計算を手伝ってくれるよ。
これには色々共感できる。OSSのおかげで、実際に仕事に応募したことも、Leetcodeの面接を受けたこともないんだ。TwitterのDMで直接オファーを何度ももらったし（投稿はしないけど）、偶然の出会いからの紹介も何度かあった。例えば、GitHubのカスタマーサポートで面白い問題をデバッグしてたら、MDからマイクロソフトの紹介をもらったり。Cloudflareでも似たような話がある。OSSに限った話じゃないけど、CVやCLのプロセスを経ずに名前に信頼性があれば、最初から「事前スクリーニング」されるから、たくさんのチャンスが開けるんだよね。
└
あなたが接続を始めるか、会社の誰かが接続を始めるかに関わらず、ネットワークをもっと広く説明してる感じだね。最近の25年間、普通の意味で応募はしてなかったし。あまりコードは書かないけど、本を書いて、そのおかげでカンファレンスでサイン会を開くことになって、もしかしたら他の機会につながったかもしれない。
これ、オープンソースについて考えてることと響くね。私のステップはこんな感じかな：1. 自分の仕事での痛みを特定する。それは他の多くの人にとっても痛みになる可能性が高い。2. その痛みを解決するためのソリューションを作る。3. フォーラムで自然に話す — 私の場合は最近はRedditやHN、少しBlueskyでも。オープンソースを作る理由を聞かれたら、シグナリングのためだって言ってる。他のコメントでも言われてるけど、運良く traction を得られたら、それが名刺になってコンサルティングや仕事につながることもある。学術出版に似てるけど、ダイナミクスは違う。私が痛みを解決するためにやったことの例は： [A] 2023年4月にLangChainを見てからLangroid LLMエージェントフレームワークを作り始めた。LLMエージェントについてほとんど話題がなかった時期だった。目的は、LLMアプリケーションを作るための原則に基づいた、ハック可能で軽量なライブラリを作ることだった。エージェントは良い抽象化だったんだ：https://github.com/langroid/langroid [B] Claude Codeや似たようなCLIコーディングエージェントの爆発で、自分のために解決すべき面白い問題がいくつかあって、ここに集め始めた：https://github.com/pchalasani/claude-code-tools その中の一つはロスレスな圧縮の代替で、CLIエージェントが他のエージェントとやりとりするためのTmux-CLIツール/スキルだよ。
数冊の数学の本を書いたけど、それで運が良くなるかな？ちょっとだけ、あちこちで。プロジェクトに1200時間以上かけた分を取り戻して、最低賃金でももらえるかな？それは無理だね。
└
私も結構な数のOSS貢献をしてきた経験があるけど、プロとしては悪くない印象だけど、雇用にはつながってないな。
└
これが運の理由なんだよね。もっと出していけば報酬を得る確率は上がるけど、保証はないんだ。
運の表面積の概念が大好き。読んでみる価値ありだよ。