Spinach Forest

/ テック社員の教科書たち   / 脊髄反射記 #8   / 音楽視聴日記   / 宿題の世話の愚痴   / Jujitsu   / Walmart Plus   / 脊髄反射記 #7   / 冴えないバイリンガル脳   / スキルと筋肉・再訪   / 考えられなさ   / 脊髄反射記 #6   / Prediction Market と電話機   / 脊髄反射記 #5   / Agentic-coding snapshot as of Feb.   / もっとアニメを見ておきたかったかもしれない   / 散財   / ... 

テック社員の教科書たち

(不定期出世できなかった中年愚痴です。)

二十年以上前に書いた自分の日記 に以下のような一節があった。

コーディング・コンベンションに相当するお仕事コンベンションのようなものが欲しい. 私が求めているのは, 金持ちになる方法でも頭がよくなる方法でもリーダーシップを発揮する方法でも出世する方法でも画家になる方法でもなく, 日々の業務のボトムラインを こういうものだ とまとめたもの. いってみれば お仕事版 “コードコンプリート” … ほど網羅的でなくていいや. “ライティングソリッドコード” のような本だ.

ゼロ年代前半に大学を卒業した頃、自分はプログラマのキャリアパスをわかっていなかった。どうも管理職というのにならないといけないらしい。それとは別にアーキテクトとかいうのがあり、それはかっこいいらしい、くらいの認識。それぞれがなんなのかはわかっていなかった。

最初に働いた会社にはたしかに管理職というのがいて、あとアーキテクトというのもいた。アーキテクトはあんまし仕事をしてなさそうで、一方の管理職は客に頭をさげたりしていた。アーキテクトの方がいいな、と感じた。

そのあと似たような、あるいは一回り小さい会社に二回くらい転職したけれど、どちらもやはりアーキテクト・エースプログラマはあまり仕事をしてなくて、管理職は頭を下げていた。エースが仕事をしてないというと語弊があるが、稼げる仕事とは別のやりたいことを好きにしているように見えた。これは客に頭をさげるよりだいぶ良さそうに見えたが、一方で下々たる身からするとオメー仕事しろという気分もあった。

プログラマのキャリアは、よくわからなかった。

達人プログラマ

「プログラマのキャリアがわからないって、おまえ達人プログラマ読んだの?」と古い読者は問うかもしれない。

達人プログラマ (1999) は、おそらく一番広く読まれたプログラマ向け自己啓発本の一つで、たしかに少しはプログラマのキャリアを議論している。その重点はプログラミングという技巧を高め続けること、移りゆくテクノロジにキャッチアップしつづけることにあったと思う。

強く影響を受けた価値観ではあるが、この「キャリア」観は振り返るとそこまで自分には当てはまらなかった。

「達人プログラマ」は、プログラマは一人のプログラマのままいつまでも生き続けていく想定がある。著者の David Thomas はオンライン出版社の Pragmatic Bookshelf を立ち上げ、その運用を通じ生涯いちプログラマを続けた(※まだ生きてます)。技術スタックも Elixir に手を出してみたり、少なくともある時期まではまあまあモダンな面はあった。有言実行でかっこいい。

ただ自分は 15 年以上も同じ会社でダラダラ働いてしまい、違う世界線を生きてしまった。直球達人プログラマにはなれなかった。そういう前提で話は進みます。テクノロジへの追従も大事だけどさ、色々めんどくさいこと多いんだよね会社員。新しいプログラミング言語もさ、Android やってると Kotlin くらいしかないじゃん?

20 世紀末からゼロ年代

さて、そのむかしプログラマのキャリアについて考えようと本屋に出向いても、自分が気にしてなかっただけの可能性はゼロではないが、プログラマのキャリアは(技術にキャッチアップする以外は)よくわからなかった。冒頭の発言もそんな戸惑いの現れだった。

ソフトウェア開発者向けに組織についての話題を扱った本はあった。「コンサルタントの秘密」 (1991), 「デスマーチ」 (1996), 「ピープルウェア」(1999) あとは超古典「人月の神話」 (1975) みたいな読み物もあったし、見積もりだとかソフトウェア工学(これはソフトウェア以前の工学から地続きのジャンルである)だとかプロジェクトマネジメントだとか、ソフトウェア開発の「ハイレベル」な側面を扱う専門書も沢山あった。アジャイルもその仲間に数えていいだろう。

ただこれらの書籍はどれも、ワインバーグは例外かもしれないが、「キャリア」が主眼の本ではなかったと思う。「いかにプロジェクトを成功させるか」に主眼がおかれていた。プログラミング指南書が「いかに良いコードを書くか」を主眼としていたのと同じ。どちらも「問題」と向き合っていた。

プログラマのキャリアの道標となった・・・かどうかはともかく、イマジネーションを掻き立てたのは、むしろ「闘うプログラマー」 (1994) や 「ハッカーと画家」 (2010) , 「Coders At Work」 (2009) あとは 「Joel On Software」 (2004) のような読み物だった。脚色されつつも実話に基づくストーリーにはリアルなキャリアを感じられた気がする。(外国の話なぶんリアルさは弱まったけれど、イマジネーションの勢いで乗り切った。)

2010 年代

自分が外資系大企業に転職した 2010 年頃から、少しずつ様子が変わり始めた。

最初に目についたのは「Being Geek」 (2012) という本。シリコンバレーで働く著者 Michael Lopp がプログラマ(「ソフトウェア開発者」)のキャリアについて書いている。著者のブログ記事を編集したエッセイ集で、転職、管理職、組織政治などについてランダムに語る。プログラマ向けでありながら「問題」ではなく「自分」に焦点を当てた当時としては珍しい本だった。

キャリア語りをセルフ・ブランディングにつなげる切り口は現代的だが、描かれている世界はゼロ年代前後の、まだ少し荒々しさを残す「シリコンバレー」の空気が閉じ込められている。語り口も良く言えばざっくばらんだが若干ラフで、オライリーの表紙と噛み合ってない。いま読み直しても役には立たないが民俗学的面白さがある。(vs. 昔読んだときの感想)

Being Geek は時代の境目に書かれた。

サブプライムの金融危機を契機に始まった アメリカのゼロ金利政策期 はテック産業に大量の資金を呼び込み、それとともに沢山の人材を呼び込んだ。まず従来は金融やコンサルティングを選んでいたエリート大卒たちがやってきて、そのあと段々と裾野が広がった。Lean To CodeCS For All のような掛け声が生まれ、大統領が太鼓判を押す。そんな時代がきた。

人が増えて、多様化した。それにあわせ “Being Geek” という書名に象徴される非コミュでおたくで中二病な伝統的プログラマ像は薄まった。

Engineering Manager

ソフトウェア開発者が存在感を増し企業社会の一級市民になると、その管理職も Dilbert の pointy haired boss (元祖 Wiki の C2 によれば “A technically-clueless master of bullshit and bureaucracy-surfing.")から開発者出身のプロフェッショナルへと姿を変えた。Being Geek の Michael Lopp も 「Managing Humans 」というマネージャ向けの本を書き、Being Geek よりずっとよく売れた。

リンク先 Amazon の関連図書リストを見ればわかるとおり、2010 年代は沢山のソフトウェア開発管理職 (Engineering Manager) 向けの本が書かれた。中でもキャリアという視点で特筆すべき一冊は Camille Fournier の 「The Manager’s Path」 (2017) だろう。章ごとに TL, 一線マネージャーから Director, VP と、肩書ごとの責務や仕草を議論している。ソフトウェア開発の管理職業務の共通理解が進んだ象徴と見ることができる。また同時期 (2019) に出版された Will Larson の 「Elegant Puzzle」 はソフトウェア開発者のキャリアに関する議論にページを割いている(ただし管理職自身のキャリアではなく、管理している下々のキャリア)。

面接対策

管理職に心配されるまでもなく、2010 年代は下々ソフトウェア開発者のキャリアについても多くの本が書かれた。まずソフトウェア開発者を目指す学生を主な読者として、2010 年代の直前 2008 に 「Cracking the Coding Interview」(2008) が出版され、バカ売れした。自分もこんなのがあると知っていたら読んだと思う。

インタビュー対策本の人気が陰ることはなく、今では 「System Design Interview 」(2020) なんてのも登場して一つのジャンルを形成している。Leetcode のようなコーディング面接過去問模試サイトは最終型の一つと言えよう。

FIRE

この時期ソフトウェア企業入社後のキャリア指南書として広く読まれた本の一冊は「Soft Skills 」(2015) ではないだろうか。ヒラ社員としてのテック勤務仕草を解説し、邦訳 もそこそこ売れたように見える。

けれど本書の本当の新しさはそこではない。 Soft Skills は技術書の体を装った FIRE の指南書だった。Soft Skills 二版の Chapter 55 のタイトルは “How I ‘retired’ at 33”. ここで著者の John Sonmez はソフトウェア開発者はその収入を元手に不動産経営してラクに暮らせと説いている。(厳密にいうと説いてはないが、俺はそうしたと謳っている。大家がプログラマよりラクとかホント・・・?)

2010 年代はソフトウェア開発者が FIRE を目指すようになった、と見ることもできるが、どちらかというと FIRE したい人々が高収入を求めソフトウェア開発者を目指すようになったという方が近い (Soft Skills の大家推しがどれほど影響力を持っていたかは疑わしい。) 高い収入を得た BigTech などのソフトウェア開発者みなが FIRE したわけではなく、スタートアップなどを始めるケースも多かった。

とはいえ FIRE とソフトウェア開発の出会いは、ファイナンスやコンサルティングファームを目指した若者たちがテックに大挙した現象の双対なのも確かだろう:多様化が進んだ結果、ソフトウェア開発をキャリアの安息の地・終点でなく、通過点とする人々が現れた。

2020 年代

COVID 期はテック企業の株価が高騰し雇用も過熱して、より沢山の人々がテックの世界にやってきた。先に紹介したインタビュー対策本にはじまり、現役社員による対人模擬面接サービスや Levels.fyi のような年収自己申告サイトまで、US テック企業入社のための方法論は日本の新卒シューカツ産業以上に整備された。

上級技術職

就職後のキャリアに目をやると、ヒラ社員でも管理職でもない上級技術職への道のりを指南する書籍が現れた。具体的には Will Larson の「Staff Engineer」(2021) が広く読まれた。その流行に Tanya Reilly の 「The Staff Engineer’s Path 」(2022) が続いた。

上級技術職の標準化は、企業による rubric の整備に足並みを揃えている。沢山の企業が出世評価基準を公開するようになった。(雰囲気を掴むには Dropbox の例が個性が薄くわかりやすい。) ソフトウェア開発者会社員のキャリアは文書化されたのみならず、公知となった。

Influencer

上級職に限らないソフトウェア開発者向けキャリアガイドも一層盛んに書かれた。たぶん一番売れているのは Gergely Orosz の「 The Software Engineer’s Guidebook」 (2024) だろう。

ソフトウェア開発者のキャリア文化を読み解く観点から興味深いのは、この書籍の内容より著者自身だ: Gergely Orosz は Substack で The Pragmatic Enginner Newsletter を発行するライター、というか influencer である。もともと Uber などのテック企業に勤めていたが、コンテンツクリエイターとして成功し独立している。

Gergely Orosz の書くものは、もとインサイダーだけあってそれなりにリアリティがあるし、ギョーカイとのコネクションも深い。とはいえ広く読まれるソフトウェア開発者向けガイドを書いたのが influencer だという事実には立ち止まりたい: ソフトウェア開発者をやるより、ソフトウェア開発者向けのコンテンツを売る方が儲かるケースが出てきた。

ソフトウェア開発という高収入の仕事に人々が大挙し、その道筋は文書化・分解された。分解された細部はコンテンツクリエイターによって解釈・再配布された。その道案内に従いより多くの人々が門戸を叩いた。循環の輪が閉じ、ソフトウェア開発者のキャリア・エコシステムが完成した。

今日

二十年前の自分が望んだ「仕事の Code Complete / Writing Solid Code」は、いまこうして眼の前にある。読みきれないくらいたくさん。時は満ちた。

でも自分の感想はというと「めんどくさいな・・・」

こんなに全てを白日の下に晒さなくてもよかったのにな・・・と後出しで落胆する。出世のできなさを言い訳しにくくなった。長いこと仕事を続けるうちいつの間にか関心を「問題」から「自分」に移してきたら、ある日突然、情けない自分の姿が照らし出されていると気づく。動揺、落胆、不安。

テック産業の雇用が民主化され、透明化され、多くの人々に門戸を開いた。それは間違いなく良いことで、文句はない。でもその反面で肩身が狭くなった自分の主観と感想(aka 愚痴)を書くくらいは許してほしいな。

二十年前の自分はこれをどう読んだろう。目を皿のようにしただろうか。Will Larson や Gergely Orosz にときめいただろうか。

脊髄反射記 #8

音楽視聴日記

あるとき YT Music のレコメンデーションに勧められて聴いた Ginger という曲、聴いた途端「わー東京ネイティブおしゃれ女子〜!!」と郊外在住中年わたくし感銘を受け、それ以来しばらく TOMOO を聴いている。他の曲も悪くないけど結局この Ginger が一番いいなあ・・・と YouTube をひやかしていたら 六年前のビデオがあり, 「ぜっっっったい有名になるこの人」というコメントに like が集まっているのをみつけほっこりしてしまった。

最近はアニソンをタイアップするなど人気を博しているらしい。みな良い曲ではあるけれどエンディングテーマとかどうしても J-POP メインストリームのメソメソシナシナした方向性に走りがち。冒頭の Ginger のような東京ネイティブ万能オシャレ感も忘れずに頑張ってほしい。田舎に住んでるとな、オシャレがないのじゃよ。ワシも昔は広尾に住んでオシャレを愛でたものじゃからな(築四十年木造 1K だったが)・・・。

TOMOO は別にアイドル出身というわけではないシンガーソングライターにも関わらず容姿端麗で美人さが人気を助けている一方、メソシナアイドル的楽曲を求める圧になっているんじゃないかと余計な心配をしてしまう。

冷静に考えるとむしろ東京オシャレ路線こそ試行錯誤の一貫にすぎず感傷過多が素である可能性もあるなか、これは我ながらいかにもアメリカリベラルに染まった考えだと思う。

米国リベラリズムはその栄華の頂点に向かう 2010 年代、外見にもとづく偏見からの解放を突き進めた。Body positivity influencer というサブカルチャーまである。

音楽に目を向けると、この体型フリーダム主義の代表選手の一人は歌手の Meghan Trainor だとされている。Meghan Trainor 自身は「ぽっちゃり」くらいで必ずしも体型フリーダムをベタ踏みとは言えないが、歌がいい。デビュー曲の All About That Bass からして Yeah, my momma, she told me, “Don’t worry about your size” とか歌ってるわけですよ。これだけでなく Me Too, Made You Look, Title, NO など Meghan の曲は多くは圧倒的自己肯定感と楽観に溢れている。こういう曲が登場し成功できたのは、アメリカリベラリズムによる「解放」の結果といえるのではないか。

そんな米国リベラリズムも最近は完全失速。それを(テックの世界で)端的に表しているのが去年 6 月の DHH のブログ記事 “The beauty of ideals” だろう。それリンクしてる広告が出たリベラル全盛 2020 にキャンセル覚悟で言ったらロックだったけど、いまどき DEI backlash に波乗りされてもなあ・・・と鼻白んでしまう。 (コミュニティの反応は “The Ruby community has a DHH problem” という記事によくまとまっていますので、もうちょっと踏み込んだ意見が欲しい人はそちらをどうぞ。)

Meghan Trainor にしても、最近はすっかりシュっとなってしまい反発を買ったり している。

これも時代だなと思う。アメリカにおける体型フリーダムの崩壊はリベラルの凋落というより糖尿病痩せ薬 GLP-1/Ozempic の発明によるところが多いと見られているが、こうした現象の同時性こそが時代の流れの象徴だよね。

アメリカリベラル、最近は全く存在感ないしろくでもないことも多かったのは反省してほしいけど、成し遂げたことも色々あるのでそれは大事にしてほしいと定期的に思う。Meghan Trainor の突き抜けた自己肯定感、かなり好きなんだよね。自分の娘もカルフォルニアの風に乗ってあのくらい突き抜けてほしい気がしている。それはそれとして TOMOO はもっと city pop 歌ってください。


追記: 最近は一部男子の間で LooksMaxxing が流行っているという podcast を聴いた: Inside Men’s Obsession Online With ‘Looksmaxxing’ - The New York Times

新聞社の podcast がこんな Reddit Slung みたいのを解説してると真顔になってしまう。

宿題の世話の愚痴

先日小学三年生の project based learning の愚痴を書いたが、その続き。

地元 Mountain View の歴史のうち、ダウンタウンの名前になっている Castro family の土地について調べ、まとめるという課題が与えられていた。Mountain View へのインパクトを説明しないといけないらしい。

がしかし、リンク先を見ればわかるように物事はさほどシンプルではない。メキシコ人である Castro 一族は、メキシコ独立戦争の結果としてメキシコ政府から土地を授与された。しかしアメリカ・メキシコ戦争の敗戦にともない California Land Act という言いがかり法案を論拠に土地を巻き上げられた。それでも土地を持っていた時期にストリートに家族由来の名前をつけ、自分が住んでいるアパートのある通りも Castro 一族命名のものである。栄枯盛衰ですね。みたいなストーリー。

なので Castro family も彼らが受け取った土地も、Mountain View には大したインパクトがない。なぜなら戦勝国アメリカが土地を巻き上げ、Mountain View を作ったのはそこに乗り込んできたアメリカ人だからである。

メキシコ人も(スペイン経由で)その土地を原住民から巻き上げたんだけどさ、だからって他人から土地をぶんどっていい理由にはなんねーよな?と思うがしかし、そういう生々しい話は Wikipedia はともかく学校推薦のサイトには書かれていない。Wikipedia の記述にしても小学三年生にわかる展開ではない。これどうリサーチさせろってんだよ。子がページをみて内容を理解しないままコピペのワードサラダを作っているのを「理解しろ」とかいいながら読ませているが、読んでもわかんねーんじゃサラダ作るしかないじゃん?なんなのこの無理ゲー?「もらった土地を取られちゃった話だよね」と説明しているものの、PC 的に角が立たないか心配。

アメリカの野蛮さにうんざりしている昨今に塩を塗るように野蛮さを隠して歴史を語ろうとする態度に辟易してしまい、もう宿題やだ、という気分です。はい。日本の三年生の社会の教科書を読むと福岡の名産「あまおう」とかの話で、心が洗われます。

Jujitsu

ここしばらく仕事で Jujitsu (JJ) という VCS を使っている。

JJ は Google が開発している新しいオープンソースの VCS. バックエンドが交換可能なので Git repo をいじるのにも使えるし、プロプリエタリな VCS もインテグレートできる。自分が使っているのは後者である。つまり Google monorepo のフロントエンドとして使っている。

割と気に入っており、もう従来の Mercurial に戻る気はない。(Mercurial も pluggable backend に対応しており、Google は monorepo をバックエンドとした魔改造 Mercurial を使っていた。というか今も使っている。) Git のフロントエンドに使うとどのくらい便利なのかは知らないが、自分の用途には良い。

自分が仕事でやっているワークフローに JJ はよく合っている。どういうワークフローかというと:

  • PR を master にマージするのではなくコミットを一個ずつ HEAD に submit していく。
  • コードレビューもブランチではなくコミット単位である。レビューが LGTM になったら、そのコミットを HEAD に submit する。
  • コードレビューは、しばしば picky である。
  • submit していないコミットをいくつも積み上げることはよくある。

雰囲気としては、まずババーっと 2-3 のコミットを重ねてやりがいことができるか確認する。それができたら、コミットを一個ずつコードレビューに送っていく(レビュアは先のコミットを見ることもできる)。レビューを待ちながら重ねたコミットを直したり、新しいコミットを書いたりする。レビューを受けて積んだコミットを直す。レビューが LG されたらそのコミットを submit し、残りのコミットを HEAD に rebase し、以下繰り返し。こういう submit 前ブランチが複数ある。

jj edit

「コードレビューを受けて直す」という flow で威力を発揮するコマンドが jj edit. このコマンドで編集したいコミットのリビジョンを指定すると、そのあとのコードの編集が自動的にそのリビジョンに直接反映される。git commit とかしなくていい。これだけ聞くと意味がわからないかもしれないが、イメージとしては背後で jj のデーモンがチェックアウトのファイル編集を見張っていて、変更があったらコミットをアップデートしていく。

コードを mess up したら困るんじゃね?という心配はあるがしかし: 1) 現実にコードレビューの反映で mess up することは少ない。 2) mess up しそうな時はだいたい事前にわかるので、そういう時は jj edit ではなく jj new という別のコマンドを使う 3) mess up した時にも、事前のスナップショットに戻すコマンドはある。

いちいちコミットしなくていい事実に最初は正気を疑ったが、慣れると快適すぎてもはや never look back となった。

jj edit のもう一つ興味深いところは、編集後も子のコミットがそのまま子にぶらさがっていること。 r1 -> r2 -> r3 とコミットしたあと r1 を 編集しても、r2 と r3 は引き続き子のままである。rebase しなくていい。

First class conflict

でも r1 への編集が r2 とコンフリクトしたらどうすんの?という疑問がある。答えは「どうもしない」である。

JJ はコンフリクトが first class citizen である。Git や Mercurial では、rebase したコミットの conflict はなんとかして解決するか、ダメなら abort しないといけない。一方で jj のコミットは、コンフリクトしてもそのままコミットとして存在しつづけている。ただし「コンフリクトしてるよ」とマークされ、そのコミットをチェックアウト (jj edit) すると conflict marker のついたファイルが現れる。そしてコンフリクトを直しマーカを消すと、自動的にコンフリクトステータスも解消される。

これは、便利。コードレビューの結果をうけ r1 をガチャガチャいじった結果 r2 がコンフリクトすることはよくある。その r1 をコミットしたあと rebase しないでおくと r2 以下の存在を忘れたりしがちだし、一方で rebase するとコンフリクトの解決という認知負荷の高い作業をすぐにやらないといけない。JJ はコンフリクトした子を見失うことなく、しかし解決を後回しにできるので目先のレビュー対応に集中できる。ちょー便利。


他にも色々おもしろコマンドがあるが、まだ使いこなしているとはいえないので割愛する。コマンドの種類だけでなく diff とか log とかの表示も、後発だけあって洗練されている。

今すぐ使わないと missing out する、という感じではないが、新しいパラダイムを試すのは面白い体験なので、未だにエーアイに任せず手でコード書いてる原始人同志におかれましては試して頂けるといいのではないでしょうか。こういうパズル遊びは手書き固有の楽しみだと思うので。

Walmart Plus

最近 grocery delivery に Walmart Plus を使い始めた。

COVID 時代に契約して以来、これまで五年くらいは Imperfect Foods を使ってきた。ただ野菜の品質にばらつきが大きいという従来の不満に加え、最近はベーシックな食材すら確実に買えない謎の在庫不足が目に付き、諦めた。牛乳が lactose free milk しかないとか勘弁してくれ。

Walmart Plus は注文した品を近所の店舗から届けてくれるというモデル。Walmart なので今の所ベーシックな品揃えに不満はない。

費用は $13/m の会費に加え、送料のチップが 10% かかる。(チップ率は選べるが、メンタルモデル的に税金なのでデフォルトにしている。)送料は高く感じるが、Walmart は商品が根本的に安めなのでトータルでは Imperfect Foods と大差ない感じ。

週に二回ぐらい配達してもらっている。数ではなく価格に比例した費用(チップ)なので、バッチにまとめる動機がない。ただし配達無料の最低ラインが $35 で、このラインがバッチ化の基準になっている。Imperfect Foods は配達が週に一回で、これはバッチ化のサイクルを保ちやすい良さがあった一方、週の後半は野菜がなくなりがちだった。

商品は grocery の紙袋に入れて配達され、保冷剤とかはない。自分のかわりに買い物して届けてくれるだけ。受け取り時に在宅である必要はあるが、かさばる保冷剤がないのは良い。配達ウィンドウは二時間単位で選べる。

Walmart Plus の配達モデルは便利だけど、効率は悪いなと思う。Imperfect Foods や日本の生協みたいに決まった日に地域を巡回して配達する方が、配達側のバッチ化がはかどり環境負荷も低いし人件費も安く、個人的には好ましい。もっとも日本の「ネットスーパー」も Walmart と似たような仕組みらしいので、日本の生協が特別なのかもしれない。アメリカの co-op は前に Seattle で観たことがあるけれどうちの近所にはない。それに宅配もなさそうな雰囲気。Imperfect Foods がもうちょっと在庫を頑張ってくれればよかったのだが。

なぜかオマケで動画ストリーミングを Peacock と Paramount のどちらかから選んで観られるらしい。Amazon Prime と戦うためにつけたオマケなのだろう。自分は使ってない。使わないつながりでいうと Burger King とも提携しているらしい。しかし近くに店舗がない。

脊髄反射記 #7

冴えないバイリンガル脳

ふと思い立ち、バイリンガルや日本語の英語教育に関する本を何冊か冷やかした。

バイリンガル教育の方法 / 新版 世界で活躍する子の<英語力>の育て方 / ほんとうに頭がよくなる 世界最高の子ども英語

子の実情と照らし合わせてなにか書こうかとも思ったが当人のプライバシーを踏まえて思いとどまり、かわりに我が身に思いを馳せる。

自分は、先の本にあるような教育は一切うけず、そもそも英語は好きでなく、高校生の頃とか発音にも一切興味がなくローマ字読みで綴りを覚えるような有様だった。ただソフトウェアの世界があまりにも英語なので大学生活の後半くらいから徐々に英語コンテンツ(主にインターネットの活字や技術書)を摂取するようになり、しかし中二病なので「英語の勉強」をすることはなかった。(自分の中で英語は「そこそこできる」ことになっていた。客観的には事実でない。)

その後社会人になり、米資企業に転職した友人の影響で英語勉強法を真似するも根性がなくて続かず、ただコンテンツの摂取はなんとなく続けた。あるとき弾みで自分も米資企業に転職し、おかげで必要に迫られ慌てて勉強し少しはマシになり、別の弾みで今度は沿岸地区に転勤して⋯しかし英語の勉強はあまりしなかった。すればよかったけれど好きじゃないんだよね多分。シャドウイングとか発音とか、ちょっとだけやったかな。

ただコンテンツ摂取はより活発になり、現地の文化等を理解したい意図もあって新聞とかも少しは読むようになり、あと移動時間などを活かせる podcast や audiobook は、特に子供が生まれたあとはかなり聴くようになり、今日に至っている。 (最近は NYT の記事も耳で聴くことが増えてきた。いつからか登場した自動音声の品質がめちゃ高いので。どこの TTS なのだろう。)

こうしてみると、自分に足りなかったのは根性だと思う。特にコーチをつけて人間相手に発音や議論の練習をしたり、仕事場やそれ以外のコミュニティに参加するなど、苦手意識克服修行をしなかった。このサボりは自分の喋れなさ、発音の悪さに直結している。

一方で、根性レベルが低いなりに低負荷でこなしたコンテンツ摂取はそれなりの成果があった気がする。語彙やスループットがある程度鍛えられた。総じて滑舌のいい人気 Podcast を聞いていても現実世界人相手の聞き取りには必ずしも直結しない。それでも第二外国語話者として「ネイティブの速度」にはまあまあ慣れた。(真の上級者は podcast とか 2x 以上で消化できるらしいけど、それはそれ。)

先に読んだ子供向け英語教育の本はどれも大量のコンテンツ消費(読書と映像 = 多聴多読)を強く推しており、子供に文法や単語の勉強はムダとしている。自分のコンテンツ消費は、たまたまこれに整合している。

そのほかの勧めとしては phonics を挙げている。自分は phonics はきちんとやったことはないけれど American Accent の教科書でちょっと読んだ気はする。(なお米国小学校も一時期 phonics を暗記的と忌避する傾向があったが、結果として識字率を下げてしまったため “science of reading” という旗印の下ここ数年で復活したらしい。子の学校も二年前にカリキュラム改定を知らされた。)

子供向け英語教育ではやらないことになっている単語帳、自分は iKnow やら Anki やらを転職後の一時期結構やった。そして効果は感じられた。こうした spaced repetition は根性ないなりに進められるし時間費用対効果が最強すぎる。これは日本語スキルが完成している大人ならではのショートカットと言えるだろう。


子供向け英語教育が多読多聴を推す理由の一つは、頭の中で英語を日本語に翻訳せず英語のまま理解するためだとしている。量を流し込み翻訳の暇を与えない。振り返ると、自分はこの「脳内翻訳」に突き進んでしまった時期があまりなかった気がする。なぜだろうね。始発点の中二マインドが「自分はそこそこ英語ができる」と勘違いしていたのがよかったのかもしれない。

この「直接英語理解」方式は、レイテンシが少ないのはいいけれど必ずしも自分の「英語脳」(メンタルモデルとして単純化された脳の機能のサブセット。LLM でいう MoE の activation みたいなもんです。)が賢いことを意味しない。つまりしょぼい「英語脳」を介した理解は浅いし、意見は幼稚だったりツメが甘かったりニュアンスがなかったりする。

昔の自分はこの知的劣化がかなり顕著だった。昔よりマシとはいえ、今でも仕事中は自分の認知能力のサブセットしか使ってない感じがある。

自分のしょぼい「英語脳」は、ロジックは扱えるけれど感情やウィットのようなリッチさがない。この未熟な英語だけで考えると物事がすごくドライになる。たとえば仕事で計画をたてるとき、自分の感情や直感を無視しがちなので後から逆火することがある。だから仕事の考え事で言語化できない不穏な気配を腹のあたりに感じたら、一旦ラップトップを持って席を離れ、日本語で気分をぶっちゃけた braindump をして自分の感情・腹感覚を確認し、それと整合性をとるように仕事を見直すことがある。

たとえば日本語を介して、必要だとはわかっているがメンドクセーみたいな作業を適当に言い訳して優先度をさげたり、上司はやれというが重要性をいまいち信じられない作業をやんわりと押し返したり、必要性は微妙だが精神衛生のためにやりたいリファクタリングをそれとなく織り込んだり、苦手な人と一緒に仕事をしないといけなそうなタスクをスルーしたり、といった本音に気づく。

「メンドクセー」「いまいち信じられない」「精神衛生」「苦手な人」みたいな概念は仕事の design doc, charter, one pager などには存在せず、テック・ビジネス・ジコケーハツに溢れる自分の摂取コンテンツでもあまり存在感がなく、したがって自分の「英語脳」が上手に扱えない。つまり本音が上手く扱えない(!)。同様に、人を説得する文章、面白い文章のためのメンタルモデルもない。これは個人の感情よりだいぶ高度なスキルなので並べるのが適切なのかはわからないが、自分にない点では共通している。

話を戻すと:子供向け英語教育の推す多読多聴は、英語を「ネイティブに」つまり翻訳レイヤなしで処理する能力を鍛える効果はあるように感じられる。ただしその「ネイティブ脳」の品質は、このままだとザルである。それをザルでない知性まで鍛えるには、自分の関心だけを頼りにした多読多聴以外の各種要根性アクティビティや、多読多聴にしてもジャンルの多様性が必要なのだろう。LLM でいうと多読多聴は pre-training, 要根性訓練は post-training みたいなかんじだろうか。

自分は、英語嫌いの中二病だったおかげで日本の伝統的な英語学習による歪みが(発音以外では)あまりなく、インターネット中毒者だったのと米国中心の情報産業従事や転職転勤からくるわかりやすい動機のおかげで多読多聴もジャンルの偏りこそあれ一定程度できた。おかげで「ネイティブ英語脳」の胚芽は、根性がないなりに獲得できた。ただそこから先は根性不足、訓練不足が祟り、未熟な英語脳を成熟させることができなかった。「英語を頭で翻訳してしまう」みたいな歪みはない一方、仕事で英語話者とガチ議論するような高い英語力は今もない。

回り道はない。根性もない。なので「こうすればよかった」という反省もない。

今まではさておき、今から要根性の post-training をやりたいか。やるならなにがいいのか。わからない。

少し前から妻が英語の ESL の学校に通いはじめ、宿題が忙しいといいつつ楽しそうなのを見て自分もなにかやりたいかもな・・・と思ったのがこの文章のきっかけの一つだった。特に結論はでなかった。

スキルと筋肉・再訪

子の学校の課題・宿題で、Mountain View の歴史(のある側面)をリサーチしてなんか書く、というものがあった。半分くらいはチームで話し合い、最終的には個々人がテキストを出すらしい。

授業の時間だけでは終わらないので宿題として持って返ってくるわけだが・・・これできんの?親の手伝いが期待されている旨の連絡をうけ、どうしたものか困ってしまう。

リサーチというのは、学校貸与の Chromebook で Google Search することである。しかしサーチしたところで出てくるのは Wikipedia や .gov サイトであり、子供向けには書かれていない。読ませても語彙が足りず理解できていない。いや native English speaker の親でないので子の語彙も平均以下かもしんないけどさ、そうでなくとも三年生にこれは厳しくね?

子のサーチの様子も興味深い。キーワードマッチではなく質問箱として Google を使っている。たとえば “why xxx is important to mountain view” とか検索する。わー CM みたい。AI Overview は無効化されてるっぽいし、そんなん答えらんえーだろ・・・と思いきや、何らかの意図を汲み取り何らかの snippet を表示してくる。子は、それをコピペし、提出物のテンプレートにあわせて書き直し、出来上がり。本文読みやしない。ページを click through しても引用箇所がハイライトされるので、Wikipedia の長い本文から自分の質問の答えを探す必要がない。生成こそしていないが LLM チャットの体験に限りなく近い。最近はみな embedding based search だろうからある意味 LLM だとはいえ・・・。

これは「リサーチ」の勉強・練習・訓練になっているのか?日常のヌルい「リサーチ」には近いかもしれないが、そういうのを学校で鍛えたいの?本文スキャンして semantic linear match-and-rank する脳細胞鍛えなくていいの? Google Search のスキルも Goolge Docs のフォントの変え方もわかんなくていいでしょ今?

自分は HOWTO としての「スキル」をあまり信じていないのかもしれない。それよりも目を泳がせず複雑なタスクを遂行できる脳の筋肉(比喩的な意味で)を鍛えてほしいと思っている。この宿題の筋トレ成分は薄い。

LLM でいうなら context engineerring や harness construction は学校、特に小学校でやらなくていいと思う。必要なのは pretraining じゃん? あと pure reasoning RL じゃん? コンテクストいじりじゃなく backprop でパラメタ鍛えてだんだん context window 広くしてやってくれよ学校!頼むよ!!うちの子の computing (brain) resource を docs の font 変えるとかの computer use overhead で浪費しないでくれよ(本題から逸れた)!!!

コンピューターリテラシーはタイピングまででいいし、インターネットリテラシーはなくていいと思うんですけどね小学生。小学生の脳なんて attention brokering な今日の商業インターネットなんてまだ処理できないと思わん?保守的過ぎ?


そんな話を百年前に書いたのを思い出したのでリンクしときます: 第5回 体力vs.スキル | gihyo.jp

考えられなさ

最近、ものを考えられない。以前からたびたびブログを書けないという話をしているが、その延長、というより要因としてこの頭の働かなさがある。なんとかしたい。

考えられない理由を考えてみる。

プライバシー。一つには、インターネットに書きたくはないプライベートな事情に影響をされる事柄が身の回りに多くなっているせいで、それについては書けない。そして書けないことはあまり時間をかけて考えない傾向がある。オフラインに書けばいいのかもしれないが・・・。

単なる筋力の低下。書かないでいると、書くための話題を記録しておいたり、そうした話題についてぼんやりと考えを巡らす、ということをしなくなる。すると書くこと、考えることがなくなる。潜在的に書きうること、考えうることに気づかなくなる。

メディア依存。本来ものを考えるのに使える時間を podcast とか YouTube とか、その他のインターネットで融かしている。とりえず YT app は disable したが他も取り締まったほうがいいのだろうか。

エーアイ。ふと気になることが合った時、以前は調べて書いたりしていたが、チャットに聞いて気が済んで終わり、みたいのが増えた。最近はちょっとした愚痴とかもエーアイに吐き出しがちである。ヤベーな(※語彙のなさの露呈)。

運動。最近、勤務日の昼休みは脂肪燃焼のために歩いていることが多い。そうすると本来書くのに使えた時間がなくなる。書くだけでなく読む時間もなくなる。

退屈さ。仕事して通勤して家事して寝る、という暮らしだと、書く題材となりうる活動を何もしてないので、書くことがない。以前はそれなりに仕事のことを書いていたが、最近は仕事についてなにか書きたい気持ちが無い。下手に書いても悪口ばかりになりそうだし。

不穏さ。プライバシーと関連し、あまり書かない方が良さそうな不穏ことを考える傾向がある。これは別に今始まったことではないかもしれないが、傾向は強まっている気がする。あとインターネット全体の不穏度が高まっているので、なにかを書いて公開したい気分が盛り上がりにくい面もある。


こうして買いだしてみると Podcast 聞きすぎが重症疑惑だな。基本的に通勤中プラス散歩中しか聞いていないが、「しか」といいつつ二時間くらいあるからね毎日。

ブログを書いていた頃は歩きながら考え事をして、それを書くことが出来た。それが今できないのは・・・筋力の低下ですかね。ただ「退屈さ」ファクターにも不安はあり、つまり時間を開けたところで、何か書くことはあるのだろうか。見通しがない。

まずは公開しない日記的なものを書くことでリハビリといいのかもしれない。

脊髄反射記 #6

Prediction Market と電話機

Insiders Are Cashing In on Prediction Markets - The Journal. - WSJ Podcasts

The Journal で Prediction market はインサイダー知識でチートする対象が広がってすごいですね、という話をしていた。

インサイダー知識、そういえば自分も電話機の中の人なのでビミョーに知ってるな・・・と思い、しかし勤務先の話題を検索するのも危ういので競合の話題を眺めてみる。

“iphone 18” と検索してみると…

思ったより細かいスペックの話はなかったが、こういう↑情報だって知ってる中の人は千人以上いるよね。

Polymarket は insider trading のような情報のリークは(パブリックな情報を増やすので)ある意味では良いと考えているらしいが、ダメじゃね?情報をリークするのがダメというのもあるし、それ以上にインサイダーに情報をリークさせる釣り餌になっているのがやばい。目先の金に釣られてリークしちゃうマシュマロ力の低い人の人生を破壊しちゃいますよ?犯罪を助長しないほうがよくないですかね電話機のリリース日とか公益性ないじゃん・・・。

Polymarket Trader Makes $1 Million on Google Search Bets, Sparking Insider Trading Fears

なお先の podcast では勤務先関係でインサイダーチートしたらしい事例が紹介されていた。DeepMind insider $150K くらいで人生危険に晒さない方がいいのではないか。あんたたち AGI つくって change the world and get rich するんでしょ?


Opinion | The Infrastructure of Jeffrey Epstein’s Power - The New York Times

Prediction market とは関係ないはずの Epstein の存在にも現象として同時代性を感じてしまう。こんな陰謀論むき出しな存在が存在している・していたアメリカ。Epstein なんてたまたま児童売春してたから問題が発覚したけれど、それナシだって私人がめちゃ公権力に介入してて全然ダメじゃん?それとも公権力への介入に児童売春は必須なのかい政治家のみなさん?まあ大統領が私益のためにフルスイングしてるのでもはやどうでもいい気さえしてしまうが・・・

ここ数年で Overton Window は宇宙の彼方に飛んでいってしまったなあ。


追記:

脊髄反射記 #5

(#4 はブランクのままだったため欠番。)

Agentic-coding snapshot as of Feb.

後年参照するため不定期でエーアイ使用状況を記録しておく試み。(前回: Claude Code - 2025-04-11, 仕事で Vibecoding してみるターン #1 - 2025-08-14)

ホビー用途。

子供の漢字練習プリントを Anki (spaced repetition) 方式で生成したいと思い、Electron アプリを作った。ウェブでなく Electron なのはセキュリティの担保がめんどくさいため(機密情報とかないけど VM を abuse されるだけで困る)。コードは数千行程度のトイプログラムだが、実用できており満足。

Claude Code に React で書かせているにも関わらず自分は React を全然わかっておらず、Road To React という本で入門した。まさかエーアイのコードを読むために React 入門するとは思わなかった。(薄くていい本でした。)

生成されたコードは、今のところ全部目を通している。コミット単位のレビューはだるいので、何個か機能を作らせたあと事後的にレビューして気に入らないところを直させている。

レビュー、全然やりたくないね。めんどくさいだけで何も楽しくない。仕事では諦めてやってるけどホビーでやるもんじゃねーわ。エーアイも human in the loop で律速されたら本気だせないだろうし、コードは見ないでなんらかの定量的な品質メトリックを最適化するのが未来なのだろう。定量的指標があれば RLVR もはかどることでしょう。

冷やかしも兼ね、人間の手間を減らすという名目でコードを gemini-cli にレビューさせ、そのフィードバックを Claude に渡し「納得したのだけ直して」といったら 10 個の指摘のうち 2 個だけ直し、あと 8 個は「やりすぎですね」とかいってスルーしており笑ってしまった。好きにしてくれや。ただウェブ素人としてレビュー結果は勉強になる瞬間もあるので今後も非定期にやらせたい。

Claude Opus の書くコードの印象は、いまいちなときもあるが、基本的にウェブプログラマとしては自分(=素人)より 100x 有能である。ついでに人間だってしょっちゅうダメなコードを書いていることを我々職業プログラマは知っている。

細部や好みを差し置くと、一万行もないトイプログラムならコンテクスト溢れのような問題があまり起きないので、単純に「わー便利」というかんじ。何も難しさがない。この問題は Sonnet 3.7 とかでも行けた可能性すらあるが、Opus 4.6 だともはやまったく危なげがない。もうちょっと大きいコードだとどうなるのか試してみたいけど、他のアプリを考えないとダメだな。

洗練の余地が大きいとはいえ特段困っていないせいもあり、プロンプト (CLAUDE.md, skills) はがんばってない。ホビーだからと心の中で言い訳している。数ヶ月待つだけでモデルが勝手に賢くなったりもするし。

そうはいっても現状の自分のやりかたは原始的でダサいとは思う。

Claude Code の中の人Gas Town のような覚醒した人々が使う並列セッションも、やってない。結果をみながら直させているので並列化できない。あと強い subscription に入ってない。沢山の部下をこき使うみたいなメタファもうんざり。

以上ホビー。以下仕事用途。

Agentic coding は、使ってない。これは Gemini 縛りで Claude を使えないからという面もあるし、それ以上に触っているコードが大規模レガシーコードだから、という面もある。以前(2.5, 3.0 時代) 試したがあまりに不毛だったので諦めた。最新版(3.1)はまだ試してない。

最近の仕事は、バグを直すついでに壊れやすいコードを時間をかけテストカバレッジを増やしつつリファクタリングしている。手で。眼の前のクソコードが自分の力いい感じになっていく満足感、もう一年だか数年だかしたら得られない体験かもしれないので、今のうちに楽しんでおきたい。

といいつつ自分の眼の前にあるこの特定のコードをさわることは、というか自分の眼の前のバグを直すのは、今はまだエーアイにはできなそうだなと思う。というか、ぶっちゃけ自分以外のチームメイトでも正しく直せる人いるのかな・・・というかんじ。なぜならレガシーコードだから。

レガシーコード、微妙な壊れやすいスレッドモデルの想定があちこちにあり、ちょっといじるとすぐデッドロックしたりレースコンディションで壊れたりする。そういうコードがアプリのあちこちにあり、壊れるとテニュアの長い自分のところに回されてくる。そもそもバグを確実に再現する方法すらなく、スタックトレースやログを睨みカンで直さないといけない。

こういうAI不可能コードはジョブセキュリティと見ることもできなくはないけれど、ダメだね。昔からクソコードはチームの velocity を下げると広く知られているわけだが、エーアイにバーっと書かせたいならコードの壊れやすさは致命的である。エーアイが周りのコードの雰囲気にあわせカンで書いてもだいたい動き、壊れたらテストが知らせてくれる、というコードベースでないとエーアイをスケールできない。別の言い方をすると、クソコードの生産性被害がエーアイによって(相対的に)増幅される。

別の言い方をするとコード品質を含む技術負債の返済・抑制はエーアイ加速時代の前提条件と言える。が、その投資判断をするのは自分ではなくもうちょっと偉い人であり、自分のような下々が「エーアイのためにコード綺麗にしましょう」とかいっても誰も信じてくれなそうので、しらね。賢い L6 L7 連れてきてがんばってください。それまで下々たるわたくしはエーアイ使わなず手工業がでがんばりますので。

仕事はさておき、ホビーとしての「エーアイに良いコードを書かせる」ゲームは割と楽しんでます。

もっとアニメを見ておきたかったかもしれない

仕事をしながら The Planets: Reimagined を聞いていたら、YT Music が COWBOY BEBOP (Original Motion Picture Soundtrack) を勧めてきた。なかなか良い。その後ルパン三世とかも流れてきて、これらもやはり良い。仕事中の気分が盛り上がる。

そういえば世の中にはサントラというジャンルがあったなと思い出し、他に聞きたいものがないかと考える。が、あまり思い当たらない。すこし思い当たるのもみな二十世紀の古典ばかりである。いやジブリとかディズニーとかでもいいといえばいいんだけどさ、アニメのサントラとはちょっと違うじゃん。感動とか興奮とか求めてないわけ仕事中に。

自分の若き日には、漫画と活字はあったけれど、映像が全然なかった。だから覚えている曲がない。もっとアニメを見ておけばよかったのかもなと思う。アニメじゃなくて映画でもいいんだけど、音楽付きの映像。そういう記憶の蓄えがあると仕事中の BGM も捗りそうじゃないですか。

普通におたくだった自分がなぜアニメを見なかったのかと記憶をたどる。まず大学時代にかなりヘビーなアニオタ同級生がおり、彼がプログラマになりたいとかいいつつまったく勉強していないのを見て「アニメは無理だな・・・」と忌諱が形成されたのはエポックの一つな気がする。録画と消化活動がすごい大変そうだったのだよね。人生賭けてた。別に人生賭けずに程よく摂取するオプションだって自分にはあったはずだけれど、やるならガチでやるべきという謎の思い込みがあった。

社会人になってからは、家にテレビがなかった。テレビを見る習慣があまりなかったので、数年で捨ててしまった。今なら PC で見る選択肢があるが、当時は Crunchroll とかなかったわけです。なんとなくテレビに邪悪さを感じていた部分もある。しかしかわりにより邪悪なインターネットに時間を溶かしていたわけで、別にアニメでも大差なかった気がする。そしてインターネットにはサントラがない。残念。

歳をとってから見たアニメ・映画のサントラは、別に悪くはないが心への浸透度が浅い。時間を溶かせる思春期・青春期に摂取しておくほうが後々染み出してきやすいと思う。

若いうちに X しておいたほうがいい論(勉強、運動、冒険など)は基本的には自分の能力を過大評価した寝言だと思っているけれど、アニメは見れたんじゃないか。才能足りなかった?


そういえば Inception はリスニングの練習という名目で一時期繰り返し観た・聴いたので、摂取年齢の割に染み込んでいる気がする。午後はコード書きながら go deepr しようかな。(追記: 緊張感ありすぎで仕事 BGM には向かなかった。残念。)

散財

去年の中頃、臨時ボーナスをもらった。プロジェクトのリリース祝いか何か。以前もらった臨時ボーナスはキャッシュで、給与と一緒に銀行に振り込まれた。そして自動的に貯蓄に回された。だから貰えた事実は嬉しくても、生活に変化はなかった。

今回のボーナスは non-cash bonus という見慣れない方式。簡単に言うと会社のクレジットカードで決まった額まで好きに買い物ができる。安易な現金化や違法行為を防ぐ制限がいくつかあるほか、特に買えるものの縛りはない。自分はそのボーナスが non-caah であることに気づいておらず、危うく使いそびれるところだった。たまたまランチの会話で指摘され気づいた。

早速家族と相談し、買おうか否か迷っていたゲーム機を買ってみたり、旅行中のレストランで思い出しデザートをつけてみたりした。散財してる実感がある。自分らは特別倹約家ではないけれど、それでも超高生活費地区に住む事実は普段の支出をやや遠慮させていると気付かされた。

たまの散財、非日常でちょっと楽しい。金持ち気分が味わえる。金融リテラシーが皆無だった時代のボーナスってこういう感じだったのかもしれない。たまにはいいね。たまにじゃないと単なる無駄遣いだからな。なお真にリテラシー高い勢はこの non-cash bonus も普段の支出に織り込んで散財はしないらしい。


そういえば昔小さな会社で働いていた頃、ボーナスというものは制度としては存在していたがまったく支給されず、現代では空想上の存在だと思っていたのを思い出した。