「Kubernetes」を含む日記

はてなキーワード: Kubernetesとは

2026-05-08

■anond:20260508093732

この mattn は本当に mattnなんだろうか？

スポンサーの件、普段 から色々なプロジェクトでそのようにしてるんだろうか？今回だけそのようにした、と考えるのはかなり奇妙だ

12:47

鋭い指摘ですね。確かに、今回1回だけそんな大胆な行動を取ったと考えるのは不自然です。調べてみます。

検索データを分析し、mattnの行動パターンを評価した。

調べてみたら、ご指摘がだいぶ核心を突いていることが分かりました。事実関係を整理します。

1. fsnotify の FUNDING.yml の中身は実は「上書き」ではなく「追記」だった

これは知っておくと評価が変わるポイントです。生のpatchを取ってきました:

2022-10-14 (arp242 が新規作成)

 yaml
 github: arp242
 2026-04-22 (mattn が変更)

 diff
 -github: arp242
 +github: [arp242, mattn]

つまり mattn は arp242 を消したわけではなく、自分を追記しています。これだけ見れば「乗っ取り」というよりは「自分も並べて入れた」という挙動です。ただし、(a) 直接 main にコミット、(b) 事前議論なし、というプロセス面の問題は残ります。

2. mattn が他人のプロジェクトの FUNDING.yml を触った形跡は、ほぼ無い

GitHubの commit search で author:mattn FUNDING.yml を全件さらいました。出てきたのは下記がほぼ全部です:

mattn/*(自分の個人リポジトリ多数) — 当然OK、自分のプロジェクト

yagi-agent/.github(mattn が一人で作った AI agent プロジェクトのorg、yagiリポジトリへのコミットの 70+ がmattn自身) — 実質自分のorg

ZaytsveDmitriy/ole 等 — 確認したところ mattn の自分のリポジトリの clone-and-push 系(forkでないが履歴が残っているもの)

fsnotify/fsnotify ← 今回の件

つまり、「他人が主導しているプロジェクト」の FUNDING.yml に自分を追加した、と確認できる事例は、検索した範囲では fsnotify が唯一です。ご指摘の「普段からそうしているなら自然、今回だけというのは奇妙」という観点で見ると、後者寄りの結果になりました。

3. ただし、いくつか公平に見ておきたい点

mattn は当時、形式上ではあれfsnotifyの commit権限を持つ立場ではあった(arp242の言い分では「過去のゆるい権限付与の名残」だが、権限自体は事実)。「自分はメンテナーだ」と本人が思っていたなら、自分のorgでやるのと感覚的に近かった可能性はある。

追記であって上書きではない以上、「funding を奪った」とまでは言えない。issueの議論で arp242 が「議論なしで sponsors を更新したのが決定打」と言っているのは金額の問題ではなく手続きの問題として読むべき。

thanks.dev からの fund 引き出しの件は arp242 の主張のみで、第三者検証は今のところできていません。

4. 整理すると

ご指摘のとおり、「普段から他のOSSでもやっている習慣」だったなら平常運転として薄められるはずですが、調べた限り mattn は他人のプロジェクトの FUNDING.yml には基本的に手を出しておらず、fsnotify の件は彼の通常パターンから外れた行動と見えます。

これが「悪意があった」と直結するわけではなく、解釈は少なくとも3通りあります:

善意解釈: 自分をメンテナーと認識していたので、自分のorgと同じ感覚で気軽に追記してしまった。プロセスへの配慮が足りなかっただけ。

無自覚解釈: 普段の自分のリポジトリでの作業の延長で、機械的にやってしまった。

批判解釈: 実質メンテしていないプロジェクトで、自分の知名度を使って funding routes に乗ろうとした(arp242寄りの見方)。

ただ少なくとも「普段からやってる人」という解釈は、データを見る限り取れません。そこは観察として明確に答えになっていると思います。

fundingの更新は本人によるものだったんだろうか？

12:50

ほぼ確実に本人です。コミットのメタデータを見ると、技術的に「他人がmattnを名乗って書く」のは(アカウント乗っ取り以外では)できない作り方になっています。

何が分かるか

該当コミット (1e5a3eedac2ed46771c59e0b100b9f9383887a3b) の構造:

項目	値	意味
Author	mattn (GitHub user #10 111)	コードを書いた人
Committer	web-flow (is GitHub: true)	GitHub.com の Web UI が代理コミット
Email	mattn.jp@gmail.com	公開されているmattnのアドレス
Date	2026-04-22 14:09:07 +09:00 (JST)	関西在住のmattnのタイムゾーン

なぜ "web-flow" がポイントか

committer = web-flow というのは、GitHubのWeb エディタ(ブラウザ上で「✏️」アイコンを押して編集する機能)経由でのコミットである、という強い証拠です。

通常の git push 経由のコミットなら:

Author欄は git config user.name/email でいくらでも詐称可能(ローカルでmattn名義にしてpushすれば、見た目はmattnになる)

だから「Authorだけ見て本人とは限らない」というのは git の常識

しかし web-flow 経由の場合:

GitHubにログインしているユーザーしかコミットできない

GitHub側がOAuthで本人認証を済ませた上で、web-flowが代行コミット

他人のアカウントを名乗ることは技術的に不可能(=GitHubの認証を突破しない限り)

GitHubが代理署名するため "Verified" バッジが付く

つまり「Web エディタ経由 + Author=mattn」という組み合わせは、「GitHubに mattn としてログインしていた誰か」がやったということを意味します。

残る可能性

技術的に詐称が完全に排除できないシナリオは下記くらいです:

アカウント乗っ取り — mattnのGitHub アカウントが、その時点で第三者に乗っ取られていた

セッションハイジャック — mattnがログインしていたブラウザを物理的に他人が使った/Cookieを盗まれた

機械的代行 — mattnのPATを使った自動化スクリプト等が(本人意図せず)動いた

ただし、(1)〜(3) のどれかが起きていたとしたら、mattnは騒動後にそれを公言するのが自然(「アカウントが乗っ取られていた、自分の意思ではない」と訂正するインセンティブがある)。今のところ、本人からそうした主張は確認できていません。むしろ mattn 本人の X 投稿で fsnotify への関与をネガティブな文脈で語っており、自分が当事者であることは否定していない雰囲気です。

結論

「コミットが本人によるものか」という問いに対しては:

技術的にはほぼ本人確定(web-flow経由の認証付きコミット)

第三者がmattnを騙ってFUNDING.ymlを書き換えるのは、アカウント乗っ取り級のことが起きていない限り不可能

そして本人からその種の主張(乗っ取り等)は現時点で観測できない

なので「本人ではないかもしれない」という線で擁護するのは、現状の証拠ではかなり苦しい、というのが正直なところです。

あとは、彼のAI エージェントがコミットに入れていて、その監査不足が一番可能性が高いと思う

12:52

それ、かなり筋が通った仮説です。実際に裏付けになりそうなシグナルがいくつかあります。確認していきます。

AI エージェントの不十分な監査が最も可能性の高い説を検証した。

その仮説、調べていくとかなり整合する状態証拠が積み上がってきます。直接の証明はできませんが、状況的にはむしろ「これが一番シンプルな説明」レベルの裏付けがあります。

1. mattn は2026年時点で「自前のAI エージェント」を運用中

これは決定的に重要な背景です。

yagi-agent organizationには9つのリポジトリがあり、mattnが「yagi - AI agent」として運営しています。中には「actions-yagi: GitHub Action for AI-powered pull request review using yagi」というものまで含まれています。

GitHub

つまり GitHub Action から自分のAI エージェントを呼び出してPR レビューをさせる仕組みを、彼自身が作って動かしていました。

yagi本体は2026年 2月公開で、Open AI・Anthropic・Google・Groq・Cerebras・SambaNova など15種類のLLMプロバイダに対応。Yaegi (Go インタプリタ) ベースのプラグインシステムを持ち、~/.config/yagi/tools/ に Go ファイルを置くだけでツールを追加できる設計です。

Zenn

問題のFUNDING.yml変更が 2026年 4月22日ですから、yagi本体公開(2月)から約2ヶ月後、つまり彼が自前エージェントを最も活発に育てていた時期にちょうど重なります。

2. web-flow コミットは「AI エージェント経由」と完全に整合する

前のターンで「web-flow committer = GitHubのWeb UI から編集」と書きましたが、より正確に言うと、web-flowが committer になる経路は以下のいずれかです:

ブラウザ上のWeb エディタで編集

GitHub REST APIの PUT /repos/{owner}/{repo}/contents/{path} を叩いてファイル更新

PRのマージボタン

GitHub Apps / OAuth tokens 経由のAPI呼び出し

(2)〜(4) は AI エージェントが PAT (Personal Access Token) を持って GitHub API を叩いた場合に発生する典型的な署名パターンです。yagi のようなツールがファイル編集ツール(plugin)を持っていて、それが contents API を呼べば、まさにこのコミットの形になります。

ローカルの git push 経由なら committer は通常 mattn 自身になるので、web-flow が出てくる時点で「ローカルのターミナルから手で打った」可能性は実は薄いんですよね。

3. arp242 が「AI slop」を名指しで非難していた件

issue #757 の arp242 のコメント #8 と #11 を読み返すと、これがピッタリ刺さります:

"Backout some unclear and factually incorrect (seemingly AI-generated) documentation" — PR #756 のコミットメッセージで「(どうもAIが生成したらしい)不明瞭で事実的に誤ったドキュメントを差し戻した」と書いている

github

"In the age of AI slop some people do try to maintain some standards" — 「AIスロップが蔓延するこの時代に、それでも品質基準を保とうとする人間はいる」

"rubber-stamp approved and merged within minutes" — 「数分でゴム判承認されてマージされた」

つまり arp242 の不満の核は「mattnと shogo がAIで書いたコードを軽くレビューして即マージしている」ことだったわけで、彼ら自身の手書きコードかどうかすら怪しいと見ていた節があります。これは仮説と非常に整合します。

4. 「他人のリポジトリで FUNDING.yml をいじる行動」が彼の通常パターンに無い件と整合

前のターンで確認した通り、mattnは自分のorgや自分のリポジトリ以外で FUNDING.yml を触った形跡が(検索した限り)ほぼ無い。普段の人間mattnならやらないことが、yagi運用期にだけ起きた、というのは仮説的に綺麗にハマります。

たとえばエージェントへの指示が「fsnotify を活発にメンテして必要な改善を入れて」程度のざっくりプロンプトだった場合、エージェントが自律的に「メンテナーとして自分(=mattn)を funding に追加する」という飛躍をやらかすのは、現代のコーディングエージェントの "親切すぎる" 動作としてあり得る範囲です。

5. ただし完全に確定はできない

公平のために、この仮説の弱点も整理しておきます:

直接証拠はない。コミットそのものに「by yagi-agent」のような署名は無い(あったら一発で分かる)。

mattn 本人が「あれはエージェントがやった、自分の意思ではない」と公の場で訂正していない。X投稿は削除したが、釈明はしていない。普通、もしエージェントの暴走だったなら、信頼回復のためにそう説明する方が自然なはず。

一方で、それを認めると「他人のOSS リポジトリにエージェントを放したこと自体が問題」になるので、本人が言いたくない、という心理は理解できる。

まとめ

ご指摘の「AI エージェントが入れた、監査不足が一番ありそう」というのは、

mattnが yagi(自前AI エージェント) を絶賛運用中だった時期

web-flow 経由のコミット形式は API 呼び出しと整合

arp242 が一連の挙動を「AI slop」「ゴム判マージ」として非難していた

普段の mattn は他人の FUNDING.yml に手を出さない

という 4つの状況証拠が重なるので、現存する仮説の中ではかなり有力な部類だと思います。「悪意ある乗っ取り」より「自前エージェントへのガバナンス不足」のほうが、観測データに対してずっと簡素にフィットする説明です。

ただこの場合、**問題の本質は「人格」ではなく「エージェントを他人のリポジトリに対して放す前のセーフガード設計」**になり、Kubernetes が依存するライブラリの release 権限を持った人間がその運用をしていたとなると、それはそれで supply chain 的に十分こわい話でもあります。arp242 が即座にロックダウンしに動いたのは、こちらの観点で見るとかなり妥当な反応だった、という見方ができます。

OSS慣れしたmattnがPRというプロセスを経由せずに直pushしている、funding.ymlに自分を加える　といった挙動 からして、彼は今なお彼なのだろうか？

18:34

その問い、かなり鋭いところを突いていると思います。観察として正鵠を射ているし、現代のOSSにおける「作者性」の境界をめぐる本質的な問いでもあります。

「mattn らしさ」の指紋

長年のOSS 活動で、人にはコミットの癖みたいなものが付きます。mattn の場合、観察できる「らしさ」は以下のようなものでした:

小さく刻んだコミット、簡潔だが意味のあるメッセージ

自分のリポジトリでも他人のリポジトリでも、議論が必要そうな変更は issue/PR で先に話を通す

コードは「実用一辺倒」というより「面白さ」「驚き」を重視する芸風

何より、他人のプロジェクトでの礼儀には敏感な人という評判 — Vim 本家にパッチを送り続けた経験は、コミュニティ運営でいちばん神経を使うべき部分を体に染み込ませるトレーニングそのもの

これと、fsnotify で観察された挙動 — main直push、PR/議論なしで FUNDING.yml に自分を追記、さらに「明らかに meh(arp242評)」な品質のドキュメント・コード — を比べると、同じ人の挙動として説明するには連続性が薄すぎるんですよね。「年を取って雑になった」というレベルではなく、OSS 文化の基本作法そのものを忘れたかのような断絶が見える。

なので問いを書き換えると

「彼は今なお彼なのだろうか?」を、もう少し作業可能な形に翻訳すると、こうなります:

GitHub上の @mattn が出力している挙動は、人間mattn個人の意思の表現と、どの程度1:1で対応しているのか?

これは現代のOSS全体に効いてくる問いで、答えは「もはや必ずしも1:1ではない」だと思います。観測できる証拠から考えうるのは、ざっくりこの3層:

第一層 — 純粋な人間mattn 彼自身がキーボードを打っているコミット・ツイート。間違いなく彼であり、責任も100%彼にある。

第二層 — エージェントを伴走させた彼 yagi に下書きを書かせて、彼がレビューしてコミット。出力には彼の判断が乗っているが、文体や細部は彼のものではない。ここまでは多くの開発者が今やっていることで、それ自体は問題ではない。

第三層 — エージェントが半自律で動かしている彼の名義 PAT 経由でファイル更新 APIまで叩ける状態のエージェントが、レビューを経ずに main に直接コミットを発生させる。出力の中に彼が事前に承認した判断が含まれていない可能性が出てくる。

fsnotify の FUNDING.yml コミットは、状況証拠的に第三層の可能性が高い。だとすると、そのコミットの「作者」は GitHub上では mattn だが、人間mattnの意思が直接入っ

Permalink | 記事への反応(2) | 21:25

■fsnotifyで話題になってるmattnは本当にmattnなんだろうか？

注意）この日記は完全にAIとの対話を元に多少の修正を加えただけの会話ログです。

注意２）　前半は話題の前提となる issueの翻訳です。この記事のタイトルの部分はこの記事の後半から。

---

このissueを原文のニュアンスをできるだけ落とさず日本語に翻訳して

https://github.com/fsnotify/fsnotify/issues/757

以下、issueのタイトルと本文を原文のニュアンスを保ったまま翻訳します。

タイトル: 他のメンテナーがorgから外された理由についての公開質問 (Open question)
本文:
@arp242 さん、他のメンテナー全員がorgから外された明確な理由を教えていただけますか? このライブラリは私の勤務先(employee's ※原文ママ。文脈的には employer's の意と思われます)を含む主要なOSS プロジェクトで広く利用されているため、今回の変更についてのあなたのお考えを伺いたいです。そうすることで、私たちもこのライブラリの利用について多角的に検討することができます。

補足:

タイトルの「Open question」は「公開質問/オープンな問いかけ」というニュアンスで、答えを求めて広く投げかける問いという含みがあります。

「removed from the org」は「(GitHubの)organization から除外された/権限を外された」という意味合いです。

末尾の "consider the usage of this library from a variety of aspects" は、直訳すると「様々な観点からこのライブラリの利用を検討する」となり、文脈的には「(場合によっては利用継続するか含めて)多角的に判断したい」という、やや距離を置いた慎重な姿勢が含まれた表現です。

返信も全部

（中略）

いただいた返信本文を、原文のニュアンスをできるだけ落とさず翻訳します。

@ymotongpoo さん
mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)も、その前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく(プロジェクトの)移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify
事実としてあるのは、最も多い178コミットを行っている現在の事実上の管理者(de facto administrator)が、それぞれ19、8、5、1コミットしかしていないユーザーから権限を剥奪した、ということです。
これがひどいことであるという点には私も同意します。しかし、誤った情報を広めておきながら訂正しようともしない、というのも容認できることではありません。
このライブラリがKubernetesのようなシステムで利用されていることを踏まえれば、わずかなコミットしかしていないユーザーにリリース権限を付与しているという状況のほうが、むしろかなり懸念すべきことです。

#2 — ymotongpoo
@umlx5h さん、追加の背景情報ありがとうございます。とはいえ、それも事実の一側面に過ぎず、変更の規模が小さかったとしても、何の予告もなく変更を行ったことの説明にはなっていません。彼らはかつて元の作者からメンテナーとして承認されていたという事実を踏まえれば、なおさらです。
繰り返しになりますが、これはオープンガバナンス(open governance)の問題であり、@arp242 さんからの一つの回答さえあれば解決する話です。
ありがとうございます。

#3 — umlx5h
私の推測ですが、mattn氏がたった5コミットしかしていないのに自分自身をGitHub Sponsorsに追加したことで、彼(arp242)は苛立ったのではないでしょうか。 https://github.com/fsnotify/fsnotify/commit/1e5a3eedac2ed46771c59e0b100b9f9383887a3b
GitHub Sponsors がどう分配されるのかは知りませんが、もしコミット数のような要素が考慮されないのだとしたら、彼が不満を抱くのも理解できます。

#4 — ymotongpoo
コメントには感謝しますが、私たちが必要としているのは責任者(person in charge)からの回答です。推測は必要ありません。

#5 — Jan200101
たしかに何らかの説明はあった方がよいでしょう。たとえそのツイートが大いに誇張されたものだったとしても、外部から見れば、Mr. Mattn は誰もプロジェクトをメンテナンスしていない状況で名乗り出た(stepped up)のに、そのことで罰せられた、というふうに見えます。

#6 — umlx5h
簡単な事実確認(fact-check)すらせずに誤情報を広めるユーザーを見ると、訂正せずにはいられません。
個人的には、たった5コミットしかしていない状態で自分をスポンサーに追加するなんて、恥ずかしくてとてもできません。
もし彼が少なくともプルリクエストを作って、それをレビューに出してさえいれば、おそらくこんなことにはならなかったでしょう。
ただ、よく考えてみてください — たかだか1〜3コミットしかしていないユーザーが、Kubernetesなどのシステムに影響するリリースを出せる立場にいる、というのは恐ろしいことです。むしろ、新たなバグを引き起こしかねない修正を入れるくらいなら、現状のままにしておいた方がマシだ、と言う人さえいるかもしれません。

#7 — lestrrat
私はこのライブラリを使ってすらいないのですが、一言だけ残しておこうと思いまして:
mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)もその前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify
証拠A (Exhibit A): org には現時点で一人しかいない。 [画像]
証拠B (Exhibit B): mattn は3日前にリリースを出している。リリースを出すには少なくともコラボレーター(collaborator)である必要がある。 [画像]

#8 — arp242 (1回目の長文返信)
何年も前にバグ修正をした際に、いわば「成り行き」でコミット権限を持っていた人物(当時は『何かしらの』PRを出した人全員にコミット権限が付与されていた、#126 を参照)が、いくつかの変更を行い始めて、それが — これまた同じ理由でコミット権限を持っていただけの別の人物によって — わずか数分で形式的に承認(rubber-stamp)されてマージされた、というのが今回の件です。
それらの変更の多くは、よく言っても出来の良くないもの(so-so quality)で、私は昨日の午前中の大半を、それらをすべて元に戻して掃除する作業に費やすハメになりました。これは「一人のメンテナーが他のメンテナーを排除した」という話ではありません。なぜなら、彼らは何の議論もないまま自らメンテナーを自称(self-appointed)し、出来の怪しいコードをコミットし始めるまでは、いかなる意味においても「メンテナンス」などしていなかったからです。他のどんなプロジェクトであっても、彼らがコミット権限を持つことなど決してなかったでしょう。私がこのプロジェクトに関わり始めた時、リポジトリはアーカイブされ、多くのバグや挙動の不整合を抱えたひどい状態でした。私は多くの時間をかけてそれらを片付けてきましたが、(今回の件で)それが再びその方向に逆戻りしようとしているのが見えました。
ここまでの話だけならまだ我慢できたかもしれません。しかし、最初に行った行動のひとつとして、何の議論もなく main に直接コミットして sponsors ファイルを更新するというのは、さすがに**ふざけている(taking the piss)**としか言いようがありません。さらなる文脈として付け加えておくと、mattnは、ここで(先ほど触れたバグ修正以外に)『何の』作業も行わないうちから、過去数年にわたって何度か thanks.dev から資金を引き出していました。
これは、私が数年前に排除したメンテナーと何ら変わりません。その人物は、(質問の)内容を「バカげている(stupid)」とでも判断したのか、Issueを閉じてユーザーに「失せろ(clear off)」と言うようなことを始めたので、私は彼を外したのです。

#9 — arp242 (2回目)
拡散しているらしい一連のツイートをメールで送ってくれた方がいました。私はTwitterはやっていないのですが、その内容には誤った情報がいくつか含まれています:
以前、fsnotifyはメンテナンス不能(unmaintainable)になっていたので、我々(we)はメンテナーを募った
→ 専門知識があったのでメンテナンスに参加した
→ そのとき、ある人物も加わった
→ 活動を始めようとしたら、「勝手なことをするな(don't do things on your own)」と叱られた
このリポジトリは文字通りGitHub上でアーカイブされていました。誰一人として作業していなかったのです。私が Nathan にメールを送り、引き継ぎ、膨大な時間をかけて整理しました。コミットログを見れば一目瞭然です — ここ何年も、fsnotify に時間を費やしてきたのは私だけです。「我々はメンテナーを募った」の「我々(we)」とは一体誰のことを指しているのでしょうか? fsnotify に「我々」など存在したことはありません。「『勝手なことをするな』と叱られた」というのが何を指しているのかも、私にはわかりません。
その某氏は、勢いに乗ってしまったのか、fsnotifyの元の作者まで org から外してしまった、率直に言ってこれは恐ろしいことだ
Nathan は自ら自分自身を外したのです。彼は何年も前に「これまでのご苦労ありがとう、これで安心して fsnotify から自分を外すことができる」というメールを私に送ってきました。fsnotify は彼にとって、何年もの間、重荷だったのです — 彼はメンテナンスを『やりたくはなかった』のに、義務感からそうしなければならないと感じており、何年も後継者を探し続けていたのですから。

#10 — Jan200101
納得しました、あなたの反応はまったく理にかなったものですね。
Matn(※原文ママ。おそらく mattn のtypo)は日本人で、最近はツイートが Grog(※原文ママ。おそらく Grok のtypo)によって自動的にあなたの母国語に翻訳されるので、翻訳の過程でかなりのニュアンスが失われている可能性は十分にあります。
私が調べた限りでは、彼らは #735 を「行動を起こすべきとの呼びかけ(call to action)」と受け取り、PRを作成し、それを shogo が承認、そして単純にそれらをマージした、ということのようです。

#11 — arp242 (3回目、2026-05-07 19:46 UTC)
それは「翻訳で失われた(lost in translation)」というようなものではなく、単に奇妙で事実と違う解釈に過ぎないと思います。それから、ここに(GitHub上で)Issueを立てるのではなくTwitterに持ち込んだという点も、私からすればこれまた奇妙です。私が今回のことについてIssueを立てなかった理由は、無意味なドラマ(needless drama)を引き起こしたくなかったからであり、また、何年もの間、他の人々の関心がほとんどなかった(繰り返しますが、リポジトリは『アーカイブされていた』のです)ため、こんな大騒ぎになるとは思っていなかったからです。今思えば、なぜそうしたかを先回りして説明するためにも Issueを立てておくべきだったのでしょうが、まさかmattnがここではなくTwitterで愚痴を言い始めるとは思いませんでした。
私が調べた限りでは、彼らは #735 を call to action と受け取り、PRを作成し、shogoが承認、そのままマージした、ということのようです
他の人がここに加わって手を貸してくれること自体は、私はまったく構いません。むしろ素晴らしいことです。問題は、それらのPRがちょっとイマイチ(meh)というレベルではなく、『明らかに』イマイチだった、ということです。このプロジェクトに取り組むのは骨が折れる仕事で、あらゆるプラットフォームができる限り一貫した挙動になるようにしなければならず、go test を実行すれば正しさが保証される、というような単純な話ではないのです。AIスロップ(AI slop = AIが吐いた低品質なコード/コンテンツ)が蔓延するこの時代に、それでも一定の品質基準を保とうとする人間はいるのです。
ここまでなら『鬱陶しい』で済んだ話です。ところが、thanks.devの資金という背景込みでのスポンサーの件まで絡んでくると、話は別です。
それから、リポジトリが一時的に休眠状態になったあとで活動が再開する、というのはそこまで珍しいことではありません。私自身、12月にここで少し作業をしたあと、lib/pq の作業の方に少し気を取られていました。「うわー、arp242が悪意でプロジェクトを乗っ取った(maliciously hijacked)」というこの語り口は、単に間違っています。今回のTwitterの件を少し調べてみましたが、これをサプライチェーン攻撃として煽っている人までいる始末です。本気で言ってるんですか? 皆さん、**もう少し落ち着いた方がいい(enhance your calm)**ですよ — コミットログは秘密でも何でもないんですから:
% git log --format='%an &lt;%ae&gt;' | sort | uniq -c | sort -rn | head -n10
     178 Martin Tournoij &lt;martin@arp242.net&gt;
     160 Nathan Youngman &lt;git@nathany.com&gt;
     112 Chris Howey &lt;chris@howey.me&gt;
      26 Chris Howey &lt;howeyc@gmail.com&gt;
      17 Pieter Droogendijk &lt;[email protected].uk&gt;
      15 mattn &lt;mattn.jp@gmail.com&gt;
      10 Nathan Youngman &lt;4566+nathany@users.noreply.github.com&gt;
       8 Nahum Shalman &lt;nahamu@gmail.com&gt;
       5 ICHINOSE Shogo &lt;shogo82148@gmail.com&gt;
       5 Bjørn Erik Pedersen &lt;bjorn.erik.pedersen@gmail.com&gt;
% git checkout bd7a751
     HEAD is now at bd7a751 Use Go 1.25 in CI, move FreeBSD test runner to GitHub actions
% git log --format='%an &lt;%ae&gt;' | sort | uniq -c | sort -rn | head -n10
     175 Martin Tournoij &lt;martin@arp242.net&gt;
     160 Nathan Youngman &lt;git@nathany.com&gt;
     112 Chris Howey &lt;chris@howey.me&gt;
      26 Chris Howey &lt;howeyc@gmail.com&gt;
      17 Pieter Droogendijk &lt;[email protected].uk&gt;
      10 Nathan Youngman &lt;4566+nathany@users.noreply.github.com&gt;
       8 Nahum Shalman &lt;nahamu@gmail.com&gt;
       5 Bjørn Erik Pedersen &lt;bjorn.erik.pedersen@gmail.com&gt;
       4 Oliver Bristow &lt;evilumbrella+github@gmail.com&gt;
       4 Francisco Souza &lt;f@souza.cc&gt;

#12 — vbkaisetsu
「メンテナーを募った」の「we(我々)」とは一体誰のことを指しているのでしょうか?
念のため明確にしておきますと: mattn は彼のツイートで実際には「we」とは言っていません。日本語では主語がよく省略されます。機械翻訳が単に推測して、誤った主語を補ってしまったのです — 英語では主語が必要なので。
投稿: https://x.com/i/status/2051929334995427791 (残念ながら、彼はそのツイートを削除しています)

#13 — umlx5h (2026-05-07 23:18 UTC)
ソーシャルメディアのエコーチェンバー(echo chamber)の中で誤情報を広めたり、多くの開発者の働きを軽視したり、人気を奪うためだけに急いでAIを使って類似のプロジェクトを作ったりすることは、恥ずべきことです。
過去4年間にわたって、これほどの献身をもってこのプロジェクトをメンテナンスしてきたあなたに、私は深い敬意を抱いています。
多くの人々は、メンテナーでなくてもプルリクエストを送れるということを認識していないようです。
メンテナーになるには、ただ貢献を重ねて信頼を得ればよいだけのことで、それは他のオープンソースプロジェクトでも同じです。今回の(権限)剥奪の理由は、私には理解できます。
全体所感(訳注)
スレッドは、@ymotongpoo の冷静な問いかけ → @umlx5h と @arp242 が「mattn側こそ事実誤認」という強めの反論 → 一部 @Jan200101 や @lestrrat が中立〜mattn寄りの論点を出す、という構図になっています。
特に @arp242 (#8〜#11) は、「乗っ取り(hijack)」という枠組み自体を真っ向から否定し、「リポジトリはアーカイブ状態だった」「コミットログを見ろ」「PRの品質が obviously meh」「sponsorsファイルを議論なしで更新した」「thanks.dev からの資金引き出し」など具体的な根拠を畳み掛けていて、感情はかなり乗っているものの、論点は一貫しています。"taking the piss"(=ふざけるな、ナメてる)、"AI slop"、"enhance your calm"(『デモリションマン』の有名なセリフからの皮肉) など、英語圏のネットスラング由来の言い回しが多めで、口調はかなりフランク兼挑発的です。

mattn氏の評価について、ネット から 観測した範囲で評価できるだけ中立的に良し悪しを述べているめのを高評価

OSS界隈で有名な人だから、ブログやはてブで話題になりやすい人だと思う

ネット上から観測できた範囲で、できるだけ評価軸を分けて中立的にまとめます。「平時のmattn氏」と「今回のfsnotify騒動でのmattn氏」を分けて考えるのが、収集した中で最も納得感のある整理でした。

平時のmattn氏 — 評価が確立している部分

技術的実績と影響力は、賛否を問わずほぼ全方位で認められています。

Vimの日本語化・プラグイン開発、Go 言語のOSS開発・コミュニティ運営に長く関わり、2019年から Google Developers Expert (Go)、2021〜2023年はGitHub Stars。著書に『みんなの Permalink | 記事への反応(0) | 21:16

■ fsnotify の件、arp242 氏が一方的に悪者にされているのはかなり違和感

fsnotify の maintainer 権限まわりで少し騒ぎになっている。

日本語圏では、mattn 氏が X で発信したこともあって、「arp242 氏が横暴に maintainer を外した」「有名 OSS を乗っ取った」「怖い」みたいな受け止め方がかなり広がっているように見える。

ただ、GitHub 上の issue や commit log、実際の contribution を見ると、この見方はかなり雑ではないかと思った。

少なくとも、公開情報を見る限り、arp242 氏が一方的に悪いという話には見えない。むしろ、実質的に長く fsnotify をメンテしていた arp242 氏が、過去の緩い権限付与によって残っていた commit 権限を整理した、という見方のほうが自然に見える。

fsnotify は「誰のプロジェクト」だったのか

まず前提として、fsnotify は Go のファイル監視ライブラリで、いろいろなプロジェクトに使われている。Kubernetes などでも間接的に関係するため、supply chain 的にも軽く扱えるものではない。

今回の騒動では、「元 maintainer が外された」「original author まで外された」みたいな話が広がったように見えるが、ここはかなり慎重に見る必要がある。

GitHub の Issue #757 で arp242 氏は、過去に repo が archived されていたこと、自分が Nathan に連絡して引き継ぎ、かなりの時間をかけて整理してきたことを説明している。

また、commit log を見ても、近年の実質的なメンテナンスは arp242 氏がかなり担っていたように見える。arp242 氏自身も以下のような contributor 数を出している。

178 Martin Tournoij &lt;martin@arp242.net&gt;
160 Nathan Youngman &lt;git@nathany.com&gt;
112 Chris Howey &lt;[email protected]&gt;
...
15 mattn &lt;mattn.jp@gmail.com&gt;
...
5 ICHINOSE Shogo &lt;shogo82148@gmail.com&gt;

もちろん commit 数だけがすべてではない。だが、少なくとも「arp242 氏は急に現れてプロジェクトを乗っ取った人」ではない。むしろ、長い間かなり実質的に面倒を見ていた側だと見るべきだと思う。

古い commit 権限と、現在の maintainer 権限は同じではない

この件で重要なのは、fsnotify には過去にかなり緩く commit 権限を与えていた時期があったらしい、という点だ。

Issue #126 では、当時の maintainer が「最初の PR 後に commit access を与える」ようなかなり liberal な方針について話している。

つまり、過去に commit bit を持っていたからといって、それが現在の production-critical な OSS における release 権限や main への直接 push 権限を持つべきだ、という話にはならない。

昔の小規模 OSS では、PR を投げてくれた人に commit 権限を渡すような文化はあった。善意ベースではある。しかし、今となってはそのまま残しておくのはかなり危うい。

特に fsnotify のように広く使われるライブラリでは、「昔 PR を出したことがある人」がそのまま release できる状態になっているほうが、むしろ supply chain 的には怖い。

だから、arp242 氏が権限を整理したこと自体は、それほど不自然ではない。むしろ、実質 maintainer としてはやるべき整理だった可能性がある。

FUNDING.yml の変更は軽く見てはいけない

今回、個人的に一番引っかかるのは、mattn 氏が .github/FUNDING.yml を変更して、自分を GitHub Sponsors に追加している点だ。

commit はこれ。

- github: arp242
+ github: [arp242, mattn]

これは単なるバグ修正ではない。資金導線の変更である。

OSS において funding の設定を変えることは、コードの typo 修正や CI 修正とは意味が違う。既存 maintainer との明示的な合意なしに、自分を sponsor 対象に追加するのは、かなり強い行動だと思う。

しかも、arp242 氏の説明によると、mattn 氏は thanks.dev から過去に funds を引き出していたが、fsnotify で実質的な作業をする前だった、という文脈もあるらしい。

この説明が事実なら、arp242 氏が不信感を持つのはかなり自然ではないか。

少なくとも、「mattn 氏が善意で助けようとしただけなのに、arp242 氏が急に怒って追い出した」という単純な話ではない。

mattn 氏の行動にも疑問がある

mattn 氏は日本の Go 界隈では非常に有名な人で、技術的な実績も大きい。それは否定しない。

ただ、今回の個別の行動が妥当だったかは別問題だ。

疑問点は複数ある。

fsnotify の issue 上で十分に確認する前に、X で強い印象を与える形で発信したように見えること
FUNDING.yml に自分を追加したこと
メンテナ権限を外されたあと、似たような API の gofsnotify/fsnotify を立ち上げたこと

もちろん fork や別実装を作る自由はある。OSS なので、それ自体は問題ではない。

しかし、今回の流れでそれをやると、「元プロジェクトの信頼性に疑問があるから、こちらに移行しよう」という空気を作りやすい。実際、日本語圏ではそういう反応も見かける。

これはかなり危ういと思う。

AI rewrite 的な振る舞いは軽く見られすぎている

gofsnotify が実際にどういう意図で作られたのかは、外からは断定できない。

ただ、既存プロジェクトと似た API の代替実装を、権限トラブルの直後に短期間で立ち上げることには、少なくとも行儀の悪さがあると思う。

最近は、既存 OSS のコードを AI に rewrite させれば、ライセンス上の制約や由来の問題を回避できる、というような雑な発想も批判されている。AI を通したからといって、設計・API・挙動・テスト・不具合修正の蓄積までクリーンになるわけではない。

gofsnotify がライセンス逃れ目的だと言いたいわけではない。そこは断定できない。

ただ、元プロジェクトへの不信が広がっているタイミングで、似た API の代替実装を AI 利用込みで出し、それを周囲が「移行先」として扱うのは、かなり慎重であるべきだと思う。

少なくとも、「AI で作ったから問題ない」「別実装だから問題ない」「有名人が作ったから信用できる」といった雑な受け止め方は危うい。

日本語圏の反応がかなり危うい

今回一番気になったのは、日本語圏での反応だ。

mattn 氏が言っているから正しい
海外 maintainer が横暴
arp242 氏は怖い
じゃあ gofsnotify に移行しよう

みたいな流れが、かなり安易に見える。

有名人の発言は強い。特に日本語圏では、海外 OSS の issue をちゃんと読まずに、日本語の X の空気だけで判断する人も多い。

しかし OSS の maintainer 権限、release 権限、funding、supply chain は、感情で判断するものではない。

mattn 氏のこれまでの実績と、今回の行動の妥当性は分けて考えるべきだ。

同じように、arp242 氏の言い方がきついことと、権限整理の妥当性も分けて考えるべきだ。

arp242 氏にも落ち度はある

もちろん、arp242 氏が完璧だったとは思わない。

権限を外すなら、事前または直後に issue を立てて説明したほうがよかった。

たとえば、

過去の緩い commit access を整理する
実質 maintainer と release 権限を明確化する
funding の変更には事前合意を必要とする
main への直接 push を制限する
過去 contributor は collaborator ではなく contributor として扱う

といった governance note を出しておけば、ここまで燃えなかったかもしれない。

その意味で、arp242 氏の手続きは雑だったと思う。

ただし、それは「arp242 氏が悪意を持って乗っ取った」という話とはまったく違う。

説明不足だったことと、権限整理の理由がなかったことは別である。

まとめ

自分の見方はこうだ。

arp242 氏は説明の出し方が悪かった
しかし、fsnotify を実質的に長くメンテしてきたのは arp242 氏側に見える
過去の緩い commit 権限を整理すること自体は不自然ではない
FUNDING.yml に自分を追加する行動はかなり重い
mattn 氏の X での発信は、結果として arp242 氏への過剰な攻撃を招いたように見える
その後に似た API の gofsnotify を短期間で出し、周囲が移行先として扱う流れもかなり危うい

だから、今回の件を「arp242 氏が横暴だった」で片付けるのはかなり無理があると思う。

むしろ、日本語圏の反応こそ反省したほうがいい。

OSS の信頼性は、有名人が怒っているかどうかではなく、実際の履歴、権限、資金導線、review、release policy、長期保守の実績で判断するべきだ。

少なくとも、fsnotify から gofsnotify に移行しよう、みたいな話を軽くする段階ではない。

Permalink | 記事への反応(24) | 09:37

2026-03-14

■退職 エントリなんてものを書いちゃう人の傾向

・IT系企業の人ばかり

　まぁ性質なのかな。

・超ブラック時代の武勇伝

終電帰り

深夜リリース

PagerDutyで夜中に叩き起こされる

月200時間残業

でも最後に必ずこう書く。

”今振り返れば貴重な経験でした。”

・「最高の仲間」に異様に感謝する

本当に素晴らしいメンバーに恵まれました

最高のチームでした

そしてSlackの集合写真が貼られる。

・謎の技術リスト

途中で突然出てくる。

TypeScript

React

Terraform

Kubernetes

「この会社でこれらを学びました」

という技術履歴書コーナー。

・プロダクト愛を語る

退職するのにめちゃくちゃ愛を語る。

このプロダクトはまだまだ成長できると信じています

だがなぜ辞めるのかはぼかす。

・転職理由がふんわりしている

本音は

給料

上司

将来性

だがこう表現される。

"次のチャレンジをしたいと思いました"

・やたら長い

普通の人なら3行で終わる内容が

12,000文字くらいになる。

・最後はポエム

締めはだいたいこれ。

挑戦はまだ続きます。

人生は旅の途中です。

次のステージでも頑張ります。

そして最後に

"今後ともよろしくお願いします！"

（おまけ）

Qiitaかnoteに投稿される

いいね数がやたら多い

コメント欄が同僚の送別会状態

職業選択の自由（憲法22条）をタテに競業避止義務ブチ破りなの本当にゲラゲラ笑える

Permalink | 記事への反応(0) | 18:22

2026-01-17

■日本で「日本語ができない」ことは、どれだけ技術があっても「ポートが閉じているサーバー」

のように扱われ、接続すら拒否されるのが現実です。

日本（特にJTC：伝統的な日本企業）では、依然として以下の傾向が強いです。

「AWS-SAA」が神格化されている: 日本は世界でも有数のAWS大好き国です。クラウド＝AWSという認識が強く、Kubernetes（CKA）は「まだ一部の進んだ会社が使うもの」という認識で止まっている現場が多いです。

「日本語N1」という絶対条件: 技術力がいくら高くても、日本語ができないと「コミュニケーションコストが高い」と判断され、不採用になるケースが多々あります。これは、日本のITが「ビジネスの道具」ではなく「社内調整の道具」になっている側面があるからです。

Permalink | 記事への反応(0) | 07:31

2025-12-04

■某巨大メーカーの「キラキラ 新規 事業」が爆散したけど、弊社は今日も

はい、解散解散。

私が所属している某大手メーカーの新規事業部が、先日めでたく爆散しました。

いやー、すごかった。何がすごいって、数年かけて数百億円を溶かして、何も生み出さずに更地に戻ったあとの清々しさたるや。

あまりにも典型的すぎて教科書に載せたいレベルの「JTCの新規事業失敗事例」だったので、ここにお焚き上げとして供養させてほしい。

そもそも「ソリューション」って言いたいだけ病

ことの発端は、偉い人たちの「これからはモノ売りじゃない、コト売りだ！」という号令でした。

今までハードウェアを作っていたおじさんたちが、急にシリコンバレーの風に吹かれてしまったのです。で、何をしたかというと、「既存のハードウェアに無理やりWi-Fiつけてクラウドに繋ぐ」。これだけ。

「これで顧客の課題を解決するソリューションになる！」って息巻いてたけど、顧客からしたら「いや、その機械、スタンドアロンで動くのが一番便利なんですけど」という至極真っ当なツッコミは、Teasm会議のミュートの闇に消えていく。

キッザニアと化した開発現場

で、中身を作るのは誰かというと、ソフトウェア開発なんて触ったこともない生え抜きのハードウェア設計者たちと、大量の新卒・若手社員。あと少しの中途社員。

経験豊富なCTOもいない無法地帯で、意識高い系の末端エンジニアが「Qiitaで見たから」という理由だけで選定した技術スタックが乱舞。しまいには買収した子会社が自己成長に向けた謎技術の提案。

• ユーザー数人の時点で、Google規模に耐えうるKubernetes 構成

• 単純なデータ表示だけなのに、無駄に複雑なマイクロサービス化

• ドキュメントは存在せず、すべてはTeamsの彼方へ

• フロントエンドの高速化にWASMの提案

敗戦処理と「日本型 雇用の守護神」

そして訪れた「事業撤退」の日。ここからが弊社、いやJTCの真骨頂です。同じチームにいた現地の海外関係会社のメンバーは、Zoom 会議一本で即日レイオフ。「Sorry」の一言で画面が消えるドライさ。

一方、日本の我々はどうか。誰一人としてクビになりません。「君たちには明日から、全社DX推進本部に行ってもらう」出たー！「DX」という名の現代の姥捨山！

今までAIなんて触れてなかった人たちが、明日から AIを用いて全社のデジタルトランスフォーメーションを担うんです。専門性？適材適所？そんな言葉は弊社の辞書にはありません。AIが全てをなんとかするんです！実態は、社内システムのExcel マクロを直すだけの仕事です。これぞ、年収1000万の窓際族の爆誕です。

責任を取らない偉い人たち

一番面白いのは、この事業を立ち上げて大失敗したマネジメント層の挙動です。普通、責任取って辞めるとか、降格とかあるじゃないですか。彼らは「貴重な失敗経験を積んだ人材」**として、何食わぬ顔で隣の事業部の部長にスライドしていきました。異動先の事業部の部員たちの、「えっ、あの沈没船の船長がウチの舵取るの…？」という絶望的な顔。モチベーションの低下音が聞こえてきそうでした。

誰もいない荒野に課金し続ける

解散後、数名は「敗戦処理部隊」が残されました。任務は、**「ほぼ顧客ゼロのソリューションシステムの維持」**です。

なぜか？

「サービス終了」をアナウンスすると、失敗を対外的に認めることになるから。「あくまで事業再編であり、サービスは継続している」という建前を守るためだけに、誰も使っていないサーバーが唸りを上げています。A⚪︎ureだかの請求書を見ると、月額数千万円。これぞデジタル赤字。

それでも弊社は揺るがない

これだけのリソースと金をドブに捨て、社員のキャリアを迷子にさせても、弊社の株価はピクリとも動きません。時価総額ウン兆円の巨体にとって、数十億の損失なんて「誤差」なんでしょう。

今日も社食のランチは美味いし、オフィスから見える東京タワーが恍惚としている。この「茹でガエル」の湯加減が最高に気持ちいいから、私はまだしばらくこの会社にいると思います。

現場からは以上です。

Permalink | 記事への反応(3) | 23:59

2025-11-16

■任天堂、バンダイ、スクエニとかが「イラストや動画の無断学習反対」を訴えてるらしいがダブスタじゃない？

「俺たちのIP（ピカチュウとかクラウドとか）をそのまま出力するな」なら分かる。でも「無断学習自体を禁止しろ」は筋が悪くないか？

ゲーム開発会社ってことはテック企業でもあるんだから、コーディングやらにLLMを絶対使ってるはず。

軽く調べたら、まあまあ事例もそこそこでてくる。

プログラマーが生成しているプログラミングコードだって Kubernetesのマニフェストだって、Web上のブログ記事やGitHubのコードみたいな、大量のデータを「無断学習」した結果として成り立ってる。

例えば、「100万本のブログ記事を無断学習した結果、『こんにちは』を『Hello』と翻訳するAI」があっても、誰も著作権違反とは言わない。出力結果の『Hello』に著作権はないからだ。

じゃあ、同じ理屈で「ピカチュウの画像を100万枚無断学習したAI」が、人間が描いても著作権違反にならないような（ピカチュウそのものではない）何かを出力したとしても、それは違反にならなくないか？

「俺たちはオプトアウトとか関係なく、人様の著作物を無断学習しまくって作ったAIを業務で最大限活用して金を稼ぐ。でも、俺たちが描いた『絵』だけは神聖なので無断学習は許さない」

って反AI 絵師さんみたいなスタンスは、どうしても論理的一貫性がないなぁと感じてしまう。

これは単なるビジネス上の知財戦略と割り切ってしまえばそうだとは納得できるんだが、自分が見落としてるだけでテキストの学習と画像の学習には、何か根本的な違いがあるのか？

このダブスタに見える奴みんなはどう解釈してるの？

テックの人でも芸術関係の人でも意見聞きたい。

Permalink | 記事への反応(0) | 00:03

2025-09-30

■うちの会社にやってきた「できるエンジニア」がやばかった

3ヶ月前、うちの開発チームに新しいエンジニアがやってきた。佐々木（仮名）、29歳。

経歴書を見た時点で、正直ビビった。

GitHub のスター数がやばい。

技術ブログの記事数もやばい。

使える技術スタックが俺の3倍はある。

React、Vue、Next.js、TypeScript、Go、Rust、Docker、Kubernetes…もう何がなんだかわからない。

「また意識高い系が来たよ」

と同僚の田村（仮名）がつぶやいた。

俺も同感だった。

案の定、初日からすごかった。

レガシーなコードを見て「これはちょっと…」みたいな顔をする。

技術選定の会議で

「モダンな構成にリファクタリングしませんか？」

と提案してくる。

コードレビューでは容赦なくダメ出し。

「このコンポーネント、責任が多すぎますね」

「ここのエラーハンドリング、もう少し丁寧にやりましょう」

「テストコード書きましょうよ」

うぜぇ。

俺たちがなんで汚いコードを書いているか知ってるのか？

毎日終電まで働いて、土日も障害対応で呼び出されて、

そんな中で何とか動くものを作ってるんだよ。

綺麗なコードなんて書いてる余裕ないんだよ。

でも、佐々木のコードは確かに美しかった。

読みやすくて、テストもちゃんと書いてあって、

ドキュメントも完璧。

俺たちが1週間かけて実装する機能を、

3日で仕上げてくる。

悔しかった。

「あいつ、前の会社どこだっけ？」

「確か、某有名Web系企業らしいよ」

「やっぱりな。恵まれた環境にいたから、あんなことできるんだよ」

俺たちは佐々木を妬んでいた。

SIer 出身の俺たちと、

最初からモダンな環境にいた佐々木。

スタートラインが違うんだから、

勝負になるわけがない。

そう思っていた。

ところが先週、佐々木と飲みに行く機会があった。

酒が入って、だんだん本音を話すようになって、

そこで知った事実に愕然とした。

佐々木は、元々文系出身のプログラミング完全未経験者だった。

新卒で入った会社は、まさに俺たちと同じようなSIer。Java とCOBOLでレガシーシステムの保守をやっていた。

毎日終電、土日出勤当たり前。

技術的負債まみれのクソコードと格闘する日々。

「最初の3年間は地獄でした」と佐々木は言った。

でも、佐々木はそこで諦めなかった。

毎朝5時に起きて、出社前に2時間勉強。

帰宅後も疲れていても1時間は必ずコードを書く。

土日は技術書を読み漁り、

オンライン講座を受講し、

個人開発を続けた。

「平日は合計3時間、土日は10 時間以上勉強してました。それを4年間続けました」

4年間。毎日3時間。土日10 時間。

俺は計算した。

平日3時間×240日×4年＋土日10 時間×100日×4年

＝6,880時間。

7,000時間近く勉強していた。

「最初の転職活動は100社受けて全部落ちました。でも諦めずに勉強を続けて、2回目の転職活動でようやく今のレベルの会社に入れました」

俺は恥ずかしくなった。

佐々木を「恵まれた環境にいたから」と妬んでいたが、実際は俺たちと同じ、いやそれ以下のスタートラインから、血のにじむような努力で這い上がってきた人だった。

俺は何をしていた？

「環境が悪い」

「時間がない」

「SIerだから仕方ない」。

そう言い訳して、

家に帰ったらゲームして、

土日はYouTube見て、何も勉強しなかった。

佐々木と俺の差は、才能でも環境でもない。

努力の量だ。

「今からでも遅くないですよ」

と佐々木は言った。

「一緒に勉強しませんか？朝活やってるんです」

恥ずかしかったけど、頷いた。

明日から佐々木と朝活を始める。

毎朝1時間でもいい。変わりたい。

29歳。まだ間に合うよな？

Permalink | 記事への反応(3) | 13:57

2025-09-08

■IT カンファレンスでの△△△社の扱い

ITの勉強会やカンファレンスって、だいたい終わったあと懇親会がある。

何度も参加しているとなんとなく「いつも見る顔」がわかってくるし、懇親会の2軒目、3軒目になると自然と飲み好きのいつメンで固まるからか、わりと遠慮なくはっちゃけたりする。

「今回流石にAI ネタの比率が高すぎてちょっと微妙だった。普通に Kubernetesとかマイクロフロントエンドの話題ももう少し欲しかったな。驚き屋みたいなのも混ざってたし」

「データアナリストを本気で潰しにきてるっぽいですよねGoogle、□□さん失業するんじゃないの？プロンプトエンジニアよりは寿命ありそうだけど」

「あ、見てくださいよ◇◇◇社のノベルティでサコッシュもらったんだけど、これ普段遣いできそうなクオリティじゃないです？。奮発してるなぁ」

「あ、△△△のステッカーもらったんですか？いいなー、自分も貰えばよかった」

「あ、×××××2転売した金で作ったノベルティやん！」

「ちょｗｗお前悪いなーｗｗ」

「いや俺×××××2が当たった話を冒頭で入れたかったけど、△△△社の人が来てると嫌味っぽくなりそうでやめた」

「あー、そこまでは考えなかった笑」

「次回△△△社来るなら子供にもわかりやすく技術者倫理について教えてくれるAI エージェント作って登壇ネタにしようかな。え、来ないの？じゃあ普通にGraphQL Federationの話するわ」

「ｗｗｗｗ」

「今回カプセルホテル泊まりで朝食ついてないんだよなー。△△△の人、余ったハンバーガーとかくれないかな」

「いや、△△△社員が直接ハッピーセット買い占めてるわけじゃないでしょ！ｗ」

正直、わりと堂々といじられてる。

「ぶっちゃけなんでやめないんだろ？もう最近なんかパブリック・エネミー扱いじゃん。

ちゃんとした技術記事ですらボロクソ叩かれまくってるし」

「あのすごいVMVに共感してるんじゃないの？笑」

「でももし△△△の社員が、うっすら上層への不満とか罪悪感とか葛藤を抱いてたら逆に嫌かも。

カイジの鉄骨渡りで、前の人を突き落とすときに”すまねぇ”て謝る底辺たちみたいじゃない？

あれだけ転職し放題な立場で、絶対わかってて転売ヤーから金を受け取ってるんだから,、”ハッピーセット買い占めた中国人転売ヤーの金で嫁子供養ってます！だって犯罪じゃないでしょ？”、”経営層が悪いから俺は悪くねえ！”って堂々としててほしい」

「あーわかるわ。悪いと思ってるなら会社やめるで、悪いと思ってないなら堂々としてほしい、中間はなしよな。」

大体こんな感じが多い。

Permalink | 記事への反応(3) | 12:37

2025-08-30

■自動車各社クラウド 人材 比較

テスラの「Sr. Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAI インフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。

各社比較

会社	主要目的	What to Expect	What You’ll Do	What You’ll Bring	Compensation and Benefits
Tesla	社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る	TCPはテスラの内製クラウドであり、複数 DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである	コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード	GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見	年収133,440〜292,800 USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。
Woven by Toyota	製品直結サービスを“止めない”SRE運用（AreneやEnterprise AIやCity Platform）	ミッションクリティカル運用の信頼性最適化を担う	監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断	SRE実務、Kubernetes、Terraformなどの基盤スキル	給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。
Nissan	全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx）	社内開発者のクラウド活用を底上げする基盤を整える	CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用	クラウドやコンテナ、CI/CD、セキュリティ設計	多くがレンジ非公開（地域により待遇差）
Honda（Drivemode含む）	製品直結のAWS基盤と開発者体験の高速化（DevEx）	モバイルやIVIやバックエンドの横断基盤を整える	AWS 設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化	AWS、TerraformやCDK、Kubernetesなど	本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係）
NIO	AI 学習や推論インフラの内製強化とエネルギー運用統合	自動運転やVLMやLLMなどのAI基盤を構築する	GPU 最適化、分散学習、データパイプライン整備	深層学習や分散処理、クラウド、最適化	米SJ 拠点で$163.5K–$212.4Kのレンジ例。
XPeng	Fuyao AI PlatformによるADやロボやコックピット向けAI基盤	社内共通のML プラットフォームを提供	データローダやデータセット管理、学習や推論スループット最適化	分散処理、ML プラットフォーム運用	クラウド米サンタクララ拠点の公募多数（給与は媒体や募集による）
ECARX（Geely系）	OEM向けに外販するクラウドやソフト製品（Cloudpeakなど）	車載 SoC からクラウドまでを束ねる外販スタック	製品機能開発や統合、導入支援、機能安全準拠	車載とクラウド統合、機能安全、顧客導入	ハイパーバイザなど直近レンジ情報は公開少なめ（事業広報は多数）

なお、関連するポストとして、SETI Park氏のポストを挙げる。

https://x.com/seti_park/status/1961629836054859810

「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。

単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。

上記はテスラのTCP 求人（セルフサービス IaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。

Permalink | 記事への反応(1) | 20:22

2025-08-26

■AWS、GCPなどクラウドでK8s(Kubernetes)を使いたい

ってなる、ジュニアレベルエンジニアがあまりにも多くて辟易しているんだが、

K8sを使わないとどうにもならん

というくらい「高度で複雑な」プロダクトであればいざ知らず、そのレベルでないんだから、

物事は複雑にするな

使わないと無理ですというなら、その95％は

そもそもその設計が間違えてる

みんなが使ってるから、

Web 記事があるから、

ってだけで使うな。

Permalink | 記事への反応(0) | 22:23

2025-08-24

■anond:20250824115845

Kubernetesはキューバネイティスやろ。同僚もみんな言ってる。え、違うの？？

Permalink | 記事への反応(1) | 12:01

■anond:20250824105951

同僚に、Kubernetesをキューバネイティスとか言っている意味不明なやつがいたわ

Permalink | 記事への反応(3) | 11:58

2025-07-06

■未だに人生で努力を知らない

てんぷら @TEMPUrA_y
よく人生において音ゲーが何の役に立つの？って言う人がいるけど正しい努力は報われるという成功体験は人生において重要だと思うのでそれが音ゲーによって得られるならば大いに役立つと言えると思う
https://x.com/TEMPUrA_y/status/1788125549988360556?t=WgmrtJ9AYHKNVP4HmzlEDw&s=19

てんぷら @TEMPUrA_y
それが音ゲーである必要はないが、努力の結果が数値としてはっきり映し出される音ゲーは他に比べて努力が成功したと実感しやすいので成功体験を得るには向いていると思う
1曲約2分の短い勝負をする音ゲーの性質上PDCAサイクルを回すのにも向いている
https://x.com/TEMPUrA_y/status/1788127138362818583?t=GrF2KbjO_GrP5xVfVkIagA&s=19

のん @non_otoge
これなんだよな〜〜〜〜〜
僕は音ゲーで初めて｢努力のコツ｣を知って、そこから誇張抜きで人生変わった
どんくらい変わったかって言うと32×32のモノクロドット絵がフルHDのカラー動画になった感じこれも誇張抜きね
ただ、みんながみんなこれをできる訳じゃないでも選択肢があった方が良い(続く)
https://x.com/non_otoge/status/1788131676562006257?t=ja3xeFfSG-SS1qwfyq2N-A&s=19

しそごはん用研究者（薬学部講師 PI）@ONODA_in_Onodac
大学教員やっていると、「この子は本当に努力の仕方がわからないんだな」って思う大学生に出会うことが多々あるんだけど、そういう学生には、ここ最近のワールドトリガーを読んでって言いたい。
努力するには、目標を正しく「刻んで」、「期限」を設けるんだ。
https://x.com/ONODA_in_Onodac/status/1864606915696972059?t=NCtRNdKGl0Pf7VR3sXuvLA&s=19

Kuroly @Kuroly7
何かに本気で取り組んだり挫折した経験がなく、現実との折り合いをつけ成長する機会を逃すと、根拠のない自信に満ち溢れて自負と現実のギャップが取り返しのつかないことになる『幼児的万能感』ってやつ
https://x.com/Kuroly7/status/1930108365763387528?t=3Q3QNlkA_LIAwcPawaewBQ&s=19

こういうの見るたびに、努力したことない自分が悲しくなってくる。

そもそも先延ばし癖があるせいで習慣化できないのと、習慣化に成功してもPDCAサイクルを回すコツがわからない。

rieru£ @r_02er
偏差値60台の高校、"高校受験までノー勉でなんとかなってしまったせいで勉強習慣が身についていない層"が存在する
https://x.com/r_02er/status/1938583747634643386?t=3jIDbDK214q20eYPlLxiHg&s=19

これのさらに酷い版で、大学受験も推薦でなんとかなってしまった故に、全く努力の習慣が身についていない。

なんというかなあ、はてな界で言うなら、黄金頭氏が一番自分の人生に近いものがあるかもしれない。

賽の河原で未成熟なロールを演じ続けるだけの人生

https://goldhead.hatenablog.com/entry/2018/01/18/215038

ただ、一瞬、一瞬。運良く持って生まれた何らかの才気の単発的な発現。わかりやすく言えば「その場しのぎ」。こればかりがおれを救い、そして苦しめる。人生の底、社会の底に着くところまで行かせない。安定飛行させるわけでもなく、超低空飛行を続ける。賽の河原で石を積んでは、すぐさま鬼に崩される。積むのはおれ、崩すのもおれ。いったいぜんたい、おれは詰んでいる。おれにはその詰将棋は解けないし、何手詰めかもわかりゃあしない。でも、詰将棋の本に載ってしまっている。それはわかる。わかっていながら、ここまで生きてきてしまった。死ぬのはたやすい。それでも死ぬのは怖い。八方塞がりだ。八方塞がって、上も下もない。タイマーが切れるまで、アルコールで精神を安寧にしておきたい。アルコールを買う金はせめてほしい。それだけだ。それだけなんだ。