おこがましくオーナーシップを持つ

あの人のターニングポイント - トップエンジニアの人生の岐路 - おこがましく オーナーシップを持つ 2025-09-10 松木 雅幸 / Songmu

Profile 松木 雅幸 (@songmu) ● フルサイクル開発組織支援 / OSS作家 ○ ○ ○ 株式会社ヘンリー フェロー MOSH株式会社 技術顧問 株式会社DELTA 技術顧問 ● 200+ OSS Developer / 3 Times ISUCON Winner ● Blogger: ○ ○ 今はまだ生成AIに自分の文章を書かせたくない gopkg.in/yaml のアーカイブと乗換先やメンテナンス継承議論 ● Podcaster: ○ 趣味でOSSをやっている者だ

• https://www.google.com/url?q=https://x.com/songmu&sa=D&source=editors&ust=1757496570413053&usg=AOvVaw2D_VSgf1mgnQuFv3jFgqY9
• https://www.google.com/url?q=https://blog.song.mu/entry/cautious-attitude-toward-generative-ai&sa=D&source=editors&ust=1757496570413374&usg=AOvVaw0GMdYXuELSSefibpeOlMDz
• https://www.google.com/url?q=https://songmu.jp/riji/entry/2025-06-26-go-yaml.html&sa=D&source=editors&ust=1757496570413455&usg=AOvVaw3byP72Y4vPEkTbdl00x3Bg
• https://www.google.com/url?q=https://oss4.fun/&sa=D&source=editors&ust=1757496570413567&usg=AOvVaw34XC2OX-6F0A2WtOSVqG5s

経歴 ● ● ● ● ● ● ● ● ● 2004-2004 中国で起業 2004-2009 語学学校でシステム担当兼営業 2009-2010 SIer 2011-2014 株式会社カヤック 技術部リーダー 2014-2019 株式会社はてな チーフエンジニア・Mackerel PdM 2019-2021 Nature株式会社 取締役CTO 2021-2022 Launchable, Inc. Principal Software Engineer 2023-2025 株式会社ヘンリー VPoE 2025- フリーランス

OSS作家として 色々なOSSを作ったり、継続メンテナンスしています。 自分で作った物で1000stars超えた物はまだ残念ながら無い。 ● x-motemen/ghq (3.3k stars) ○ ソースコードリポジトリ管理ツール ● k1LoW/deck (825 stars) ○ ○ MarkdownからGoogle Slideを生成するツール このスライドはdeckで作成されています ● tagpr (248 stars) ○ GitHub上でのリリースエンジニアリング民主化のためのカスタムGitHub Action

• https://www.google.com/url?q=https://github.com/x-motemen/ghq&sa=D&source=editors&ust=1757496570481852&usg=AOvVaw35em8RLd56nt-8_HWrelIq
• https://www.google.com/url?q=https://github.com/k1LoW/deck&sa=D&source=editors&ust=1757496570481981&usg=AOvVaw1Rc_3HBTNt2MjOVwQTdhO0
• https://www.google.com/url?q=https://github.com/Songmu/tagpr&sa=D&source=editors&ust=1757496570482098&usg=AOvVaw1uecUZMr2WbUmNERS4Jf7_

最近の新作OSS AIにより捗っている。 ● chape ○ ○ MP3のチャプターやメタデータ編集ツール Podcastの編集などで便利 (使って欲しい！) ● laminate ○ ○ 文字列の画像化管理ツール deck でコード文字列の変換の際に便利 ● action-push-to-another-repository ○ あるリポジトリの内容を別リポジトリにpushするGitHub Action ● action-create-branch ○ ブランチを作成するGitHub Action

• https://www.google.com/url?q=https://github.com/Songmu/chape&sa=D&source=editors&ust=1757496570545180&usg=AOvVaw3upbkPeJERP_tv06IoTiJB
• https://www.google.com/url?q=https://github.com/Songmu/laminate&sa=D&source=editors&ust=1757496570545365&usg=AOvVaw0FYsqgFYSOQKYWfMcdOFhs
• https://www.google.com/url?q=https://github.com/Songmu/action-push-to-another-repository&sa=D&source=editors&ust=1757496570545588&usg=AOvVaw2Ap9LJcnuT09suzlwYmNZx
• https://www.google.com/url?q=https://github.com/Songmu/action-create-branch&sa=D&source=editors&ust=1757496570545718&usg=AOvVaw1IbhmqeiQyc3N6oMBq0yHq

製品の紹介

ポッドキャストやってます

「強い」エンジニアとは 8

「つよつよエンジニア」という言葉 余り好まない人もいますね ● 言葉として曖昧 ● 解像度が低い ● ふざけている 私は「強いエンジニア」というのは存在すると思う。

なんか強い人 色々な凄さがある。 ● ● ● ● ● ● ● なんかプロジェクト・プロダクト・事業が上手くいく人 その人がいると自然と周りも強くなる人 チームの生産力まで上げてしまう人 技術力が高くて何でも知っている人 作るのが速い人 問題解決が速い人 相談したら解決方法を示してくれる人

強さとは何なのか ● スポーツの世界だと ○ ○ 上手い人が勝つのではない、強い人が勝つ・勝った人が強い 勝ち続けられる人がもっと強い ● 技術力がある = 強い、ではない ○ 技術力はもちろん大事 ● 「無形の力」が大事

無形の力は有形の力に勝る 技術力というのは目に見える力、すなわち 「有形の力」と言えるが、投げる・打つ・ 走るという「有形の力」には限界がある。 しかし、観察力、洞察力、判断力、決断 力、記憶力。それからデータを収集・分析 して活用する力。さらに深い思考と確固た る哲学。これらは目に見えな「無形の力」 は、無限である。 磨けば磨くほど、突き詰めれば突き詰める ほど、鋭く、強くなる。

NPB通算ホームランランキング 1. 2. 3. 4. 5. 6. 王貞治 (868本) 野村克也 (657本) 門田博光 (567本) 山本浩二 (536本) 清原和博 (525本) 落合博満 (510本) (参考) 松井秀喜 (507本・日米通算) 選手としても当然レジェンドであり当然技術力もあった。 https://npb.jp/bis/history/ltb_hr.html より

• https://www.google.com/url?q=https://npb.jp/bis/history/ltb_hr.html&sa=D&source=editors&ust=1757496570950064&usg=AOvVaw2Iikjfzuk4LaD-9NLkoYYp

NPB歴代監督勝利数ランキング 1. 2. 3. 4. 5. 鶴岡一人 (1,773勝) 三原脩 (1,687勝) 藤本定義 (1,657勝) 水原茂 (1,586勝) 野村克也 (1565勝) ちなみに1563敗、及び平成における勝利数1053勝は歴代最多 現代野球における最も優秀な監督だったといって良い。 https://ja.wikipedia.org/wiki/日本プロ野球の監督の勝利数一覧

• https://www.google.com/url?q=https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E3%83%97%E3%83%AD%E9%87%8E%E7%90%83%E3%81%AE%E7%9B%A3%E7%9D%A3%E3%81%AE%E5%8B%9D%E5%88%A9%E6%95%B0%E4%B8%80%E8%A6%A7&sa=D&source=editors&ust=1757496570957053&usg=AOvVaw3u-kF4wVjaLtuugt-PEIIj

野球語りの年寄り 野球が(残念に思う人もいるかも知れないが)、今でも尚、日本で一番 盛んなスポーツであり、結果として一番才能が集まってくるスポーツ である以上、そこで勝ってきた人の言葉には耳を傾ける価値がある。 (ちなみに市場規模に限ると、競馬・競輪・オートレースの方が多 く、プロスポーツ選手数で言うと競輪が日本では一番多い) 同様に、昭和の高度経済成長期の経営に関する話も参考になることが 多い。

スポーツと私たちの違い ● スポーツは勝つことが目的 ● 選手の数も限られており、生き残れる人が限られている ● → ゼロサムゲーム的 スポーツ的アナロジーの落とし穴 ● 勝ち負けで考えすぎない ● ゼロサムで考えない

私たちにとっての「強さ」 勝つことが最終目的では無い。 「価値の継続的な創出」 こそが重要 それができる人が「強い」

価値とはお金ではない 「世の中に何か良い影響を与えること」 ● その対価としてお金が発生する ● それを継続する為に合理性が必要 ○ 経済合理性は大事 ● 「何か良い影響」とは…? ○ ○ ふんわりしている 人や組織によって異なる

「自分(たち)の価値はなんなのか」を考える 解釈 → 定義 → 体現 の3段階 1. 価値を解釈する a. コトの意義を理解する 2. 価値を定義する a. コトの価値を自ら言語化する 3. 価値を体現する a. コトの価値を証明するために行動し、周りに示す ここのステップを「おこがましく」踏んでいくことが大事。

ゼロサムで考えない ● 何が業界の為か・世の中に良い影響を及ぼせるか ● パイを大きくする・すそ野を広げる ● 世の中にはソフトウェアの力でより良くできる箇所が無数にある ○ 「ソフトウェアを梃子として使う」UNIXという考え方 ● エンジニアになれる人を増やす ○ ○ 勝ち残るのではなく生き残る 生き残れる人を増やす ■ AIがそれを底上げしてくれるはず ● AIが来たところでエンジニアは足りない ○ 「○○できないと生き残れない」とか言っている場合ではない

競争原理は大事 ● 切磋琢磨することでより良いものが生まれる ○ ○ 停滞の防止 成長実感 ● 健全で公正な競争が消費者の為になる ○ 腐敗の防止 ライバルとの競争を楽しむこと、ライバルの良さを認めつつ自分達の 良さをもっと信じること、信じる根拠を持つ為に行動すること。

実はプロスポーツも同じ ● 勝つことが最終目的ではない ○ その先の価値がある ● 興行として価値を出す必要もある ○ 優勝監督が解任されることも ● プレイヤーもすそ野が広がらないと、先細る ○ 排除しないこと ● 日本のプロサッカーはチーム数が増え選手になれる人が増えた ○ プロ野球も独立リーグが増えた

閑話休題 無形の力を獲得するには？ → おこがましく「オーナーシップを持つこと」を薦めたい。

オーナーシップ おこがましく持っていく為に 24

オーナーシップ ● 「自分ゴト化」などとも ● ある「コト」が「私の物だ」と思える状況 ● 私は「オーナーシップ」の方が前向き感があると思って好んで 使っている

オーナーシップは誰が持ったって良い ● 自分なんかが会社やプロダクトに対して「自分のモノだ」とか思 うのはおこがましい？ ○ ○ そんなことはない 積極的に取っていく ● そういうのは経営者やPdMの仕事では？と思うかも知れない ○ ○ 「経営者目線を持て」みたいなうさんくさいヤツ やりがい搾取になると良くない

オーナーシップ駆動開発 ● チーム全員が「これが自分のプロダクトなんだ」と思える状況が 理想状態 ○ ○ 「自分が事業を成長に導くんだ」と全員が考えられる状況が最強 ■ 自分の行動がどのように価値に繋がるかをそれぞれ意識できる この状態の完全な実現は難しいからこそ追い求める価値がある ● 個人としては自分からそう思えるように心がけられると良い ● チームとしてはそう感じてもらえるようにマネージするのが大事

オーナーシップを持つことのメリット ● タスクが完了したかだけではなく「お客様にどういう影響があっ たか」まで考えるようになる ● アウトカムやフィードバックを全部自分が受け止められる ○ アウトカムに対する満足感、その結果としての責任感の醸成 → 全部やりたくなる

Songmuの場合 以下のような経験を通じて、オーナーシップを持つことの意義を実感 してきた。 ● ● ● ● ● ● ● ソーシャルゲーム開発のリードエンジニア経験 技術部リーダーに手を上げた話 はてな社東京オフィスエンジニアリング組織立ち上げ経験 Mackerelでのプロダクトマネージャー経験 Nature社での経営者経験 ヘンリー社でのVPoE経験 OSS開発者経験

ぼくらの甲子園

• https://www.google.com/url?q=https://www.kayac.com/service/game/676&sa=D&source=editors&ust=1757496571079124&usg=AOvVaw0sbLGocIaaseu5u-1pvHAG

「ぼくらの甲子園」シリーズ カヤック社は2010年のモバゲープラットフォームオープン化の後に ゲーム開発に参入。参入初期からのヒット作が「ぼくらの甲子園」シ リーズ。 タイトル 提供期間 概要 ぼくらの甲子園 2010.08 - 2015.03 モバゲープラットフォーム リリース半年で 100万ユーザー突破 ぼくらのワールドリーグ 2010.11 - 2012? サッカー版横展開 ぼくらの甲子園 熱闘編 2011.10 - 2016.06 続編 ぼくらの甲子園 ポケット 2014.09 - 2025.01 初のスタンドアロンアプリ TV CMを打つなどスマッシュヒット

私と「ぼくらの甲子園」 ● 2011年1月カヤック入社と突然のリードエンジニアアサイン ○ ○ ○ 2010年リリースの「甲子園」が思わぬヒットをしていた その後むりくり横展開した「ワールドリーグ」も運営開始済 ■ フィーバー状態・混乱状態 私は「ワールドリーグ」のリードエンジニアとしてアサイン ■ リードエンジニアからの引継が最初の仕事だった ■ 当時の自分からするとめちゃくちゃ分不相応な仕事だった ● 「ぼくらの甲子園 熱闘編」開発 ○ 初期開発メンバー。その後リードエンジニアも ● 「ぼくらの甲子園」 ○ サービス後期に少人数運営を巻き取り ● 「ぼくらの甲子園 ポケット」 ○ 開発には直接は携わっていない

当時のチーム構成 全職種合わせて3, 4人での開発。 ● プランナー (サービス安定後は外れることも多かった) ● バックエンドエンジニア ○ ○ インフラもやる フロントエンドもやる ● Flashエンジニア ● デザイナー ○ フロントエンドもやる

全部自分たちでやる ● ゲーム内イベント含めた企画は全員でやる ● フラットではあるけど合議制みたいな感じではなかった ● 私は実は野球が好きなので、企画は楽しかった ○ ○ プレイヤーが喜んでくれる 喜んでお金を払ってくれる ● フルサイクル開発?

自分がチームを勝たせてる感 ● 数人チームで月々数千万以上の売上げ ● 特に3人チームで社内で一番売上げを上げていた時は心の支えに なった ○ ○ もちろんそれは、過去の資産や継続プレイヤーの皆様のおかげ 当時、会社事情として苦しい時期にあった ● 逆に、その後、新規タイトルの開発先年になったときに1年以上 自分の売上げがなかったときはマジで辛かった ○ 売上げは思っている以上に多くの物を癒やすが、それに依存してはいけない

「サービスは運営が大事」という気付き ● ゲーム内イベント企画 ● イベントに備えた負荷対策 ○ 効率の良いDBクエリ、キャッシュ、ミドルウェアの利用 ● Infrastructure as Code (Chef) ● スクラム・カンバン ● 仕組み化・自動処理 ○ ○ バッチ処理のフレームワーク作り 詫び石配布的な処理の仕組み化 ■ これが2次障害にならないように ● カスタマーサポート ○ カスタマーサポートを支える為の管理画面や行動履歴調査画面 ● リアルタイム売上げ分析

今で言うとSREとかフルサイクル開発とか そんな大層なものではなかったが。 ● 全部自分たちでやっていた ○ もちろん多くの人のサポートがあってのこと ● 今から見るとお遊びみたいなクオリティのものだらけ 楽しくて充実感もある。結果も出ているという手応えもあった。

オーナーシップを持てると ● 全部自分たちでやりたくなる ● 垣根を越えて必要なことに手出しする必要が出てくる ○ 幅広いスキルが身に付く ■ ちゃんと自分の血肉となる ● それと同時に自分一人ではなく、チーム全体でなんとかしようと する意識も生まれる ○ コトに向き合うため ● そういうのが楽しい

その後 チームより大きい単位へのオーナーシップを意識するように ● カヤック技術部リーダーに立候補 ● はてな東京オフィスのエンジニアリング組織の立ち上げ ○ 組織へのオーナーシップ ● Mackerel プロダクトマネージャー ○ プロダクトへのオーナーシップ ● Nature 取締役CTO ○ 会社へのオーナーシップ そういうレイヤーに行かないとオーナーシップを持てないわけではな い。意識をしていたらそういうチャンスがやってきた。持ちやすいポ ジショニングをしたというのもあります。

少人数チームの良さ 40

ピクサー流 創造するちから ピクサーのモノづくりの秘訣が詰まった本。めちゃくちゃオススメ。 ● トイストーリー2での rm -rf 事件 ● ピクサーとディズニーの合流の話 ● ジョブズの話

「ゲイリーじいさんのチェス」の逸話 革新が期待されていた小プロジェクトで別の効果があった話 ● 実験的な短編をつくることは技術革新に役立たなかった ● 監督に経験を積ませる役にも立たなかった 当初の期待がことごとく外れたにもかかわらず、それでも短編映画がピ クサーにもたらした物があった。たとえば、それに携わった人は長編映 画よりも幅広い経験を得ることができる。 単純にプロジェクトの規模と 複雑さが増せば、それだけ専門家・分業化の度合いが高くなる。 作品に は当てられるスタッフが少ないため、一人がやらなければならない仕事 が多く、そこで身につけた様々なスキルが後々有用だった、少人数での 作業を通してより深い人間関係が築かれ、長期的に将来のプロジェクト にも有益に働いた。

インターネット革命 (死語) ● 少人数で革新的なサービスが生み出せるようになった ○ インターネット・Webブラウザ・検索エンジンやOSSの登場 ● まさにGoogleがそれ ○ 1998年にラリー・ペイジとセルゲイ・ブリンの2人で始めた

イノベーションのジレンマ 過去の成功体験、重厚なプロセス、過剰な役割分担や責任分散が変化 への適応を遅くし、イノベーションを阻害する。 ● 僕らの年代のWeb業界の人はこの本が好き ● 「巨象化した大企業を自分たちで倒すぞ」という甘酸っぱい意識 があった

属人化忌避・チーム開発の落とし穴 ● ● ● ● プロセスが重厚になっていないか 役割分担が過剰になっていないか 合議制になって意思が失われていないか 誰かの意思決定を待っていないか イノベーションのジレンマに自分たちが陥っていないか。

エゴを持つことは悪いことではない ● 誰も決めようとしないなら自分で決める ○ チームで決められるように動く・促す ● 「こうしたい」という意思を持つ ○ 「意思」の力こそが差別化要因 ● 自分で決めたこと・納得して行動したことの結果を受け止めるこ とが一番成長になる ○ 自己効力感を得られて充実感がある チームや組織が大きくなるにつれて失われがちなものに気をつける。 その中でもちゃんと自分たちの意思を持ち続けること。

属人化を忌避しすぎない ● 状況が前に進むなら何でも良い ○ 属人化が問題になりそうだったら対応する ● 大事なのは硬直化を防ぎ、変化に適応できる状況を維持すること ○ ○ ○ ノウハウを独占しない 同じプロセスで停滞せず、改善し続ける → その結果として属人性が解消されることも

AIで全部やるのが簡単になっている ● 少人数で大きなものが作りやすくなっている ○ スキルが不足していても補ってくれる ● インターネット革命期を見てきた人達が興奮している ○ 当時も「危うい」サービスが山のように生まれた ● ともすれば重厚になりすぎてきた業界の破壊者としても期待され ている ○ 私は期待している

成功はガレージから始まる 歴史は繰り返す。 ● IBM (メインフレーム) → ● Microsoft (汎用PC) → ● Google (インターネット・OSS) Apple, Amazon, Facebookもガレージ的なところからスタートした

自分の作品(砂場)を持つ 自分で始めたことはオーナーシップを持ちやすい。それが仕事にも活 きる。例えば以下のような物。得意領域は人によって異なるので自分 の好みの分野で始めてみる ● ● ● ● OSS 個人サービス コミュニティ 個人事業 それらを自分の作品に留めるか、どの程度公共財にするかも自分で決 めて良い。

OSSでおこがましくオー ナーシップを持っている話 今現在のターニングポイント 51

k1LoW/deck ● https://github.com/k1LoW/deck ○ ○ MarkdownをGoogle Slideに変換するツール 3月にk1LoWさんが公開 ● めちゃくちゃ伸びている ○ 皆さんも是非使って下さい！

• https://www.google.com/url?q=https://github.com/k1LoW/deck&sa=D&source=editors&ust=1757496571530989&usg=AOvVaw35H8IxhrMUNu2mH9FUX5n4

7月に使いはじめ、すぐにpull requestを送りまくった ● 半月後にはメンテナにしてもらった ○ リポジトリのアクセス権限及びリリース権限) ● 現在はお互いアクティブな共同メンテナンス体制

自分としては「こうあるべき」だと思った 元々、Markdownをプレゼンテーションに変換する自作ツールを使っ ていたので一家言あった。 ● 既に良い物なので「自分の道具」としても完成度を高めたかった ○ ○ あくまで 私のユースケース には不十分だった k1LoWさん的にはかなり十分だったし、利用者も存在した ● Markdown対応の不十分さ ○ Markdown仕様不準拠が故に、直感的に動かないところ ● パフォーマンス問題 ○ もっと速く → まさにおこがましいオーナーシップ

取り組んだこと ● 機能追加の議論 ○ ○ Markdown仕様とGoogle Slide API仕様の調査 仕様をベースに、どうあるべきかを k1LoW さんと議論 ● 実際のコード変更 ○ ○ 100以上のpull requestのマージ 1万行以上のコードの追加 ● パフォーマンス向上 ○ 場合によっては100倍以上の高速化 ■ 15分かかっていたスライド生成が10秒以下に

今では自分でマージして随時リリース ● 好きなときにマージして好きな時にリリースしている ○ 共同メンテナ同士でお互いそうしている ● 不安や懸念事項があったら相談する ○ ○ レビューして欲しかったらお願いする 必須にはしていない

他者のオーナーシップを毀損しないこと ● もはや deck は私のOSSだというオーナーシップ感覚がある ● それと同時に、それ以上に、勿論 k1LoW さんのOSSである ○ 始めた人がエライ! ● リスペクトを持ち、オーナーシップを奪わないこと ○ ○ ○ k1LoWさんがどうしたいかを意識し、優先する k1LoWさんの意に沿わない機能は入れたくない ちゃんと議論する ● オーナーシップの総量を増やす ○ これもゼロサムではない ● とはいえ deck では大分アグレッシブにやったと思う ○ k1LoWさんの懐の深さに感謝

まとめ 58

オーナーシップ駆動のすすめ ● 今の状況に対して、おこがましく持ってみてはどうだろうか ○ ○ これは別に自分の実力とか経験とか関係なくやれる 思っているよりもリターンがあるはず ● オーナーシップを持てる場を自分で作るのも効果的 ○ 作品や砂場 ● フィードバックを受け止めることで充足感が得られる ○ ○ 楽しいよ 大変なこともあるので無理の無い範囲で

スポンサー募集 色々OSSを開発・メンテナンスしています。$1のワンショットで も嬉しいので、活動を支援してくれると嬉しいです。 ● GitHub Sponsor ○ https://github.com/sponsors/Songmu ● ghq handbook ○ ○ https://leanpub.com/ghq-handbook https://zenn.dev/songmu/books/ghq-handbook

• https://www.google.com/url?q=https://github.com/sponsors/Songmu&sa=D&source=editors&ust=1757496571744476&usg=AOvVaw2iBCR7KZEjesMPwJGlTD-m
• https://www.google.com/url?q=https://leanpub.com/ghq-handbook&sa=D&source=editors&ust=1757496571744609&usg=AOvVaw0t8P0CFuTrXuI_MN-ElmlR
• https://www.google.com/url?q=https://zenn.dev/songmu/books/ghq-handbook&sa=D&source=editors&ust=1757496571744671&usg=AOvVaw0Wkcuov6H17eOhhPMI3qlG