今年のはじめに自分の書き物について検討した。そのアップデート。主にツール関係。

Blog

つまりこれ。WP 新エディタのイマイチさは未だに払拭できない。

あと Fragments のように日々の細かいことを書く場所は、やはり欲しいなあと思ってしまう。これは欲しかったり止めてみたりしているのでたぶん結論は出ない類のものなのだろうけれど。

あと、最近はもう年一回 publish じゃなくてリアルタイムに出しても良いかな、という気もしている。なぜなら数年の撤退を経て自分のブログのコンテンツとしての価値は無事(?)ほぼゼロになったからである。ただ RSS はインターネット中毒者にフィードしてしまうので、無い方がいいかなと思う。読んでほしい人には今のようにメールすればよい。もし広く読んでほしいなら tweet でもすればいいし。

Wiki

色々試した結果 Confluence を使いはじめた。

良いところ: まあ、なんかメモしておく場所があるのは良いね。どうでもいい細かいコマンドとか Linux の設定とかさ。そういうやつ。

悪いところ: とにかくクソ遅い。どうにもならないレベルで遅い。編集が遅いのは百歩譲って許すとして、閲覧も遅いのはどうなんだ。

その他の発見: 書いてみると、自分のメモはコンテンツとしての価値は特にないが別に秘匿する必要がないものが大半だった。プライベートなメモはないではないが、そういうのはあまり書いていない。あと Wiki 的な hypelink は目次くらいにしか使っていないので、blog.kyanny.me 的に blog に書いても良い気はしている。特に人に読んでもらう気のない自分のような身にとってはね。

試したが板につかなかったツール:

• Notion: 複雑すぎるのとアプリ感が強すぎブラウザで閲覧するのが Confluence 以上に向いていないので諦めた。
• Obsidian: ウェブでないので Chromebook で仕事している身には厳しかった。あとコンテンツが URL を持ってないのもいまいち。

日記, Braindump

Docs につけていた日記は、結局書かなくなった。読み直してみると書いたほうがいいなと思うが、なんかいたに付かないのだよね。早寝するようになったせいかもしれないし、単に根気がないのかもしれない。まあ後者だろうな。というわけで未解決問題。

DuckDB 活動の記録をつける縦書日記は割と書いていて、満足している。ただ Github Issues で書く必要は、たぶん無い。

日記のバリエーションである Braindump は Confluence に書いているが、やはり遅いのがいまいち。まだ WP の方がマシ。ただこの letters をつけている WP は若干 messed up されている。WP を各種 writing の backend に使うというアイデアは、結果としてはイマイチだったね。なぜかは上手く説明できないけど。

Writing Platform

書く場所が WP / Confluence / Docs に散らばっており、かつどちらも遅い (Docs は編集は遅くないけど閲覧が弱い) のは、イマイチだなと思う。「考え事はここに書く」と決めて置けないのは、サッと書く意欲を下げている。

あと仕事や Message Passing で markdown を書いていると、まあ色々なものを md で書くのはもう受け入れてもいいかなという気がしてきた。WYSIWIG 環境である WP/Confluence/Docs のイマイチさのせいもある。

その点で GitHub Codespaces のようなブラウザ内 vscode で色々なものを書く実験をしてもいいのかもしれない。ブラウザ内 vscode は GH Codespaces に限らず色々イノベーションがおきており、Emacs 脱退以来諦めていた「なんでも書く場所」候補に期待できる。

仕事で試していた foam と組み合わせて public な書き物は vscode / markdown/ netlify に統一するのもアリかなという気がしており、仕事がヒマなうちに調査したいところ。

週一通勤を初めて一ヶ月くらい。

同僚、あまり来てない。２割くらいだろうか。若者も来てない。若者は寂しいから会社にきたがるとか、幻想だったね。まあ来ても対して人がないから鶏と卵ではあるけれど。

対人コミュニケーションがどうとかいうけど、自分にとってのオフィスの良さはハードだよな。空間の広さ、ネットワークの速さ。割り込みの無さ(これは今だけだが)、無限メシ、無限スナック。今も会社の中庭のソファでスマホからブログしてる。こういう空間は、自宅にはない。

オフィスの最大のピュアなネガティブは、オフィスそのものではなく通勤である。完全な無駄で、しかも割とでかい。自分とか通勤インパクトを最小化してるけどそれでもやなので、車で往復２時間とかだとちょうイヤに違いない。

もう一つのネガティブは居場所を制約されるという事実だが、これは自宅で働いていても寝室に制約されているので大差ない。

こういうネガティブの総和がポジティブに勝たないと、会社来たくないよな。

対面コミュニケーションがどうとか周りからの割り込みがどうとかいうのは、今振り返ってみると相対的にはどうでもいい、とは言わないけれどより nuanced だったなと思う。VC そんなに悪くないし、たぶんリモートにコミットして環境改善に投資すればもっと良くなる。(リモートに振るなら VC じゃなくて非同期にしてほしいがそれはさておく。)割り込みは、家でもある。そして自分は割り込みがどうであれどのみち割と気が散っている。

組織はともかく個人のレベルでは、リモートライフが長引けば長引くほど適応が進んで、オフィスに行く意欲は薄れるだろう。一年前、半年前と比べたら、戻りたい人どんどん減ってるんじゃないか。そんな中オフィスを開けても、全然盛り上がらなそうだよね。ホントに来年初頭に開けるんだろうか。開けるんだろうなあ。全然現実感が無い。

会社の Chromebook を四年目の Pixelbook から HP C1030 というやつに乗り換える。4k の Chromebook というのは現存しないらしく、これも 1920x1280. ねえわーと思ったが、Pixelbook からハードウェア的な不調を感じるのでやむなく乗り換え。

画面が 4k でない以外は悪くはない。CPU もだいぶ速くなったらしく、スクロール、タブ切り替えなど色々と速やかになった。指紋認証もついている。

"HD" モニタは残念で、ダウンスケールして画面の情報量を増やすと普通に字が滲む。仕事で使うときは外部モニタに出すか VC するかなので許容できるけど、自分で買うのはナシだなあ。

VC といえば、ビデオ（カメラ）の品質は前より悪い。

Pixelbook は Slate がよほど大失敗だったのか後続機種が続かず、そういうことしてるからブランドの信頼度を築けないんだよ・・・と残念。さっさと新しいの出してくれー。

ラップトップ探しをしていたら Intel がもうすぐ次の世代の CPU (Alder Lake) を出すというニュースを見かける。しかも Big / Little っぽい構成になるらしい。まじで。

ついに EAS 的なのが Linux の mainline に入るのだろうか・・・と更にニュースを眺めると、この asymmetry 構成にあわせ CPU がスケジューラのために色々なカウンタとかを提供する Thread Director というのが入るらしい。ではどんなシグナルが読めるようになるのかとワクワクしながら資料を探すが・・・。どこにも全然書いてない！"Hardware Feedback Interface" という機能の一部であることまでは文章化されているが、具体的なシグナルがマニュアルにまったく載っていない。まじか。

そんでは Intel の人が Linux にパッチ書いたりしてないかなとマニュアルに出てきた定数名などを頼りに検索すると、影も形もナシ。ほんとに？しかしよく考えると Intel にとって（というか世間の大多数の人にとって) Linux というのはデータセンターなり組み込み機器なりの OS であり、そいつら的に big-little 的な構成はあんまし意味ない。（データセンター向け CPU も同構成になるのだろうか？ならない気がするが、よくわからない。）

では誰がこの Thread Director を使ってくれるのかと言うと、Windows 11 らしい。つまり 12 世代の Intel CPU は Windows じゃないとちゃんと動かないじゃん！ええー・・・。今の所公には文書化されていない Hardware Feedback Interface の詳細も Microsoft には Intel から提供されているのだろうね。まあそうだよね。

このままドキュメントも現れず誰も Linux の Intel-Big-Little 対応をやらないままだと、Linux laptop / desktop はほんとに終了のお知らせという感じがする。まあ現状すでに終わっている（というか始まってもいない）わけだけど、バッテリーが全然もたないとはいえ少なくとも CPU 性能はちゃんと出た。しかし今後はそれも怪しくなる・・・とまではいかなくて、たぶん常に big core が優先的にタスクを受け取るのでスループットは大丈夫な気がするけど、バッテリーは今まで以上に持たなくなるであろう。

Mac OS が Intel CPU を真面目にサポートしてた頃は Darin/XNU 経由で実装の細部が漏れ出し、それを Linux が真似すればよかったかもしれない。が、それももうおこらない。

はー次の laptop は Windows か Mac かー・・・ Windows 11 使ってみたかったけどあまりに評判悪すぎだし Mac かな。いずれにせよかったりーなー・・・。

ところでふと気づいたけど Chromebook すごい困りそうじゃないこれ。Chromebook 人材が Linux をなんとかしてくれる、というのが個人的には夢展開だけど、それよりは Android の資産を持ってきて ARM に降る方が常識的だよな。どうするのかね。

人事考課の季節。特に変化なし。まあ下がらないならいいです。というか一段階くらいなら下がってもいいです。

マネージャがかわり、評価の自然言語が変わった。なぜ +1 の評価ではないのか、なぜ -1 の評価ではないのか、というサブセクションが追加されている。こういうテンプレが推奨されているのだろうか。個人的には何も考えず全員に 3 (of 5) を配っているマネージャが一番ラクでいいんだけど、今のチームのマネージャはみな真面目に評価してくるねえ。やっぱ 10 人くらいぶらさげて雑にしたほうがよくね？

そういえば少し前に勤務先関係者の退職エントリが HN を賑わせていたが、入社直後のチームのマネージャが 25 人も抱えていてキツかった、というネガティブな評価をしており興味深かった。いいじゃん。同時に PM が超絶 micromanage なのがキツかったと書いており、マネージャがどうこうよりそれが主要な問題なのではなかろうか。ここで書かれている入社時のチームは地獄プロジェクト感があり、よく辞めずに生き延びたね、よかったね・・・と思いました。

ダメな PM とかダメな隣接チームなどから身を守るためにマネージャの権力と外交リソースが必要になり、マネジメントが厚くなることはあるだろうか。

たとえば、モバイル部門のマネジメントが厚いのは、そういう組織の歪みのシグナルなのだろうか。そういう面はありそうだね。別に激しい権力闘争とかがあるとは特に思わないが、プロセスのありえないレベルのダサさの皺寄せはある。

逆に言うと、組織がフラットでいいと主張するのはそうした組織の歪みがないことを暗に売り込んでいるのかもしれない。売り込むというと語弊があるが、マネージメントの薄さは組織の歪みのない健全さの一つのシグナルとして機能している。

因果関係はあるのだろうか。つまり、マネージメントの厚さは組織を不健全にするのだろうか。直感的というか心情としては真だけれど、まあ、どうかね。

Macbook Pro の新しいやつが良さそうで羨ましい。自分の laptop はまだ買い替え時ではないが、現実逃避に今ならどれがほしいかなと眺める。

最近、事情により朝の課外活動を bedroom でなく living room でやることが増えたため、デスクトップを買ってでかい画面を使う野望は叶わなくなってきた。やはり次かうなら画面がでかくて速い laptop が良い気がするなあ。

個人的には XPS 17 がほしいと思っていたが、XPS のお約束で Linux で問題が多いらしい。Dell が並列して売っている企業向けモデルの Precision は大丈夫なことが多い。しかしなんと最新のラインからは 4K ディスプレイが姿を消していた！正気か？なんのための 17 inch なんだ・・・がっかりすぎ・・・。

Linux laptop という制限は厳しすぎると割り切り、Linux mini PC を買ってそこに non-Linux の laptop をリモートで使うくらいが良いのかもしれない。どんな Laptop が欲しいかは知らないが、別にすぐ買うわけでもないので市況を見ておく必要もあるまい。まあこの調べ物からして完全に不要な現実逃避なのだが。

はー XPS 17 系列に全力で速い CPU を載せて終了にできるのが一番ラクなんだけどなあ。残念。次の Ubuntu LTS までに誰かがなんとかしてくれると信じておく。世の中的には ThinkPad とかも人気あるけど、個人的にはあんまし興味もないしどうせでかい画面もないのでスコープ外。

なんでこんなことに時間を溶かしているのか自分でも不可思議だけど、まあほしいコンピュータがあるといのは自分のようなパソコン世代のおっさんには生きる希望、というと大げさだけど、ある種の楽しみなのだろうねえ。

衆院選があるというので各党の政策などを冷やかす。しかし日頃の無関心がたたって良くわからん。

野党は連立で政策を揃えている、というが、そんなことできるん？なんとなく維新の会が保守で、それ以外はだいたいリベラルっぽいことを言っているように見えるが、それがあってるのだろうか。

あとアメリカの Dem に一番近いのは日本共産党のように見えるが、なんか間違える？日本は socialism の国だとなんとなく思っていたが、政策だけ見ると別にそんなことない気がするなあ。

自民党は保守だと思っていたが、Republican 的な意味で保守なのかと言われると、よくわからない。古臭いというか、現状維持っぽい主張が多いのは事実ではある（現状の政権なんだから当たり前だけど。）

野党共通政策は減税するが支出は色々増やしたそうで、財源をどうしたいのかナゾ。累進課税を強めて金持ちから巻き上げるのは別にいいんだけど、足りんのかね。よくわからん。

維新の会は色々と節約するという話を前面に持ってきており、そこには意思を感じる。でも議員の減俸とか茶番だよね。そんな数百人しかいない人の給料いじっても全然インパクトないんだから、むしろきっちり貰って汚職モチベーションを減らしてくれやと思ってし合う。

政策の PDF はどこも箇条書きみたいのばっかりでいまいち説得力というか実現可能性がよくわからんねえ。どっかに予実をどうするかの見通しみたいのも書いておいてほしいが、カネの話をする割に実際の金額があまり出てこない・・・。政策提言とか公約とか、いちおう実績について議論できる自民党はそのへんは強みがあるよな。新聞社には fact check をしてほしいが、そういうのどっかにないのかねえ・・・。

などなど、日本の政治はよくわかんないね。自分が日本の政治を理解するために使っている資源はニアゼロなのであまり偉そうなことは言えないけれど、アメリカの赤青分断は、アホにでもわかる（というか、side を決められる）というわかりやすさはあるよな。

特にオチはない。

添い寝の終わりに向け週に三回子供が一人で寝る日を導入しはじめたので、夫婦で Movie Night でもするかと金曜の夜は映画を見ることにする（自宅）。

何が見たいかなと考えるが、映像メディアから距離を置いて暮らす時間が長すぎたせいで特に見たいものが思いつかない。うーむ・・・と Google TV app をつついていたらアニメが出てきて、そうえば最近アニメとかマンガとかゼロだな、自分の日々に足りてないのはそういうどうでもいいおたくメディアなのではないか奥様と一緒には見れないけど・・・と recommendation を surf して trailer を眺めつつ watch list を構築する。

というわけで記念すべき一本目は Ride Your Wave (2019). サーファーの女の子がイケメンの消防士に恋をするがイケメンが死んでしまい、しかし主人公があまりに自立心がなく心配すぎてイケメンは成仏できず、最終的になんとか成仏してもらう、というような話。限りなくどうでもいい少女漫画映画化的ストーリーだったが、こういうどうでも良さを求めていた気もする。いま調べたら漫画原作ではないのだね。そして評判悪いね。そんな期待値の高いアニメだったのか？かなりどうでもよかったよ？

うはーどうでもいいーーーという気持ちとエキゾチックな日本の風景に心が洗われてだいぶストレス解消にはなった。なお寝ながらスマホでみる閲覧方式を試している。あまりにどうでもよすぎて奥様にはチラリとも見せたくない。

マンガを読むのに比べると(rental が多いので)費用は控えめだし、ダラダラと読み直して時間を溶かす恐れもないのが安心。一方、こんなどうでもいいことでガンと二時間も無くなってしまうと課外活動に差し支えるなあと思う。週に一本見るとしたら、Movie Night とわせて 4 時間。課外活動の上限が 2x7 = 14 時間であることを考えると、塊がでかすぎる。そういう意味では隙間時間で消化できるマンガの方がいいのかもしれない。たが買うのが面倒くさいね。同様にテレビシリーズの方が小さい時間単位で扱いやすい気がする一方、さすがに時間を溶かしすぎる恐れがあるのでパス。週に一回が多すぎるだけで、隔週くらいでいいのかもしれない。いくら 10 年分のバックログがあるとはいえ、北米で閲覧可能というバーもあるし年間 40 本も見たいものがあるとは思えない。(watchlist をみたら 25 本くらいだった。)

というわけで次回は再来週。

2019. 2020 はなかった。パンデミックで参っており、それどころではなかったらしい。

なんとなく会社に行ってみたら、やはり人は少なかったがいちおう部屋が押さえられており、cupcake が振る舞われていた。相変わらずリークしまくりで、発表会も muted だし store は相変わらずよく落ちるしで雑、だが、それは全体としての「品質」とは整合しているので個人的にはそういうもんだろうという感想。完成度が高い flashy なのが欲しい人は隣町の電話を買えば良いし、買ってるだろうから。

自社製の SoC, といってもどこかの参照実装を改造したものだと思うけれど、に乗り換えるというのは会社的には big deal で、電話機部門としてはまあまあ historic な出荷となった。SoC とか作る人員を抱えた以上会社としての社運賭けちゃってる度も増したはずで、そういう意味ではもうちょっとなんとかしたら・・・と思わなくもない。

SoC が自社製になるの、戦略的にはフルスタックでコントロールできるのがよいという話だと理解している。ソフトウェア的には、SoC と自分のコードの間にわけのわからない SoC メーカーのコードが挟まらないのが良い。

SoC というのはハードウェアと一緒に SDK とかドライバみたいのがついてくる。そのコードは Android 無関係にかかれたナゾの独自ワールドで書かれた部分が多くアブストラクションとかに無駄が多く、ソースがないバイナリだけの部分もあり、ソースがあってもライセンスの縛りで限られた人員にしか読めない部分もあり（たとえば自分はカメラの ISP にアクセスするコードは読めない）、読めるコードも毎年 SoC と一緒にバーンと降ってくるので毎年インテグレートし直さねばならず、upstream もままならないのでバーンと降ってくるたびに同じバグがあったりして、こいう hoops をくぐるだけで仕事が終わってしまい価値のある仕事をする時間がない・・・とレイヤが下の方の人はいつも文句を言っていた。それを今は自分たちで書いたコードで置き換え「毎年降ってくる」ようなものはなくなったため、ハードウェアの bring-up が終わればすぐに価値を生む仕事ができる。ので下の方 (HAL, kernel) の人たちは張り切っている。

HAL のコードというのはソフトウェアエンジニアリング的にみると本当にヤバい。チップセットごとに完全にツリーがわかれていて、コードが全然共有されていない（共有する部分は基本的には OS の側に入っている。) 新しいチップセットが来ると前の世代のコードをコピーして、それをいじる。チップセットごとにディレクトリがわかれている。だから新しい世代でハードウェアに関係ないバグを直しても古い世代のバグは (cherrypick しない限り) 直らない。地獄。電話機メーカーもそれが地獄なのはわかっているので、HAL であっても世代間で再利用できるコードはなるべく世代非依存なモジュールに押し出して共有したりするが、なにせ自分でコントロールできない部分も多いので、限度がある。だから古い電話機の HAL は、出荷されたらもう良くならないのが基本。

自社でぜんぶソフトウェアを書くとこういう狂ったしきたりから決別できる。決別するのかは知らないが、常識的に考えるとすると思う。そうなると、出荷された電話機も OS の上の方と同じように出荷後もコードが進化していく、かもしれない。さすがに kernel のバージョンを上げたりはしないだろうけれど。

というわけで、ソフトウェアのチーム的にも SoC 獲得は big deal で、worth a デスマーチだと解釈されている。が、こういう苦労とその解放は HAL から下の話で、アプリのように OS 提供の API の上で暮らしている身には関係ない。なので、自分の実感としての感慨はない。近隣の人たちへ労いの気持ちはある。

アプリの速度担当としてみると、細かいトラブルはあったものの CPU/GPU は速くなっているし HAL のレイヤもそんなかんじで人々が張り切っており性能についても初期から専属で見る人々がいたので過去のような問題はなく、拍子抜けだった。自分の担当範囲外では色々大変なこともあったようだけれど、自分に火の粉は来なかった。

思い返すと、なんとなく Blink が WebKit を fork したときにちょっと似てるかもしれない。自分で全部コントロール出来るぞヤッホイみたいな excitement がある。

そういう組織・製品としての盛り上がりに自分を同期できるとよかったが、個人的にはそういうのとは関係ない様々にミクロな理由で、限りなく意欲の低い年だった。電話機の仕事を終わりにしたい気分が強い。それはなかなか叶わない願いなので、気分を盛り上げていく方が良いのはわかっているんだけど、なかなかね。

Netflix Hires Paul Debevec: USC Researcher to Lead AI, Graphics R&D - Variety

あら、いなくなっちゃったのか・・・。グラフィクスまわりのスーパースターがどんどんいなくなるねえ。

• Paul Debevec Home Page
• ‪Paul Debevec‬ - ‪Google Scholar‬

近年はヒット作がないのでやになっちゃったのかな？

物理的なアイテムの引き渡しが必要になったため、一年半ぶりくらいに出社。

• Procrastinate していた自転車購入を決行。片道 20-25 分くらいの模様。
• せっかくなので東京仲間を呼びつけて雑談ランチ。メシ食いながら雑談できるのいいよな。
• メシがあるぞ！と食べすぎる。おやつがあるぞ！と食べすぎる。炭酸水があるぞ！と飲みすぎる。
• Workstation の電源がつけっぱなしだった。何百ドルの電気代を浪費したのだろうか・・・。
• Laptop をでかい画面につなごうとしたが USB-HDMI ケーブルがない。次回は家で余ってるのを持っていくべし。
• 同僚は 3 人くらい来ていた。人と話すために来ているというよりは逆で、家での割り込みを避けるために来ていたり、ミーティングが多い人は会議室で VC をするために来ていたりする。確かにラップトップの画面よりはソファとテレビで VC する方がラク。つまり remote 人材になるには書斎だけでなく VC 部屋・・・までいかなくても VC 用のテレビとソファみたいのはあったほうが潤うだろうね・・・田舎で空間が許すなら。
• オフィスは広くて、天井も高くて、あちこち座るところがあって良いねえ。まあ出勤している人が少ない今だけかもしれないけれど。
• 会社きてたとき、そういえばそんなに働いてなかったなと思い出す。ラップトップ持ってウロウロしたり、おやつ食べたりコーヒー飲んだりしてばっかりで。トイレにいくだけでも 5 分くらいかかるし。家で働くのが生産的とは思わないが、会社も別に・・・というかんじ。環境よりは自分の問題。

などなど。

久しぶりの出勤は、割と楽しかった。週に一回くらいなら割と喜んで出勤する気がする。二回も別にいい。でも三回はちょっとな・・・。来年１月にむけて少しは出社というものに体を慣らしたほうが良い気がするので、来週から週に一回は出社してみる予定。

あと通勤片道 25 分、往復 50 分の時間が消える。この時間は家事子守に充てられているわけだが、それを奥様に押し付けることになり、厳しい。加えて今は一日子が家にいる日があり、その日に出勤されるのは負担らしい。そんなこと言われてもな・・・というかんじだけれど、当分その日の出勤は止めておく。個人的にはその日が一番割り込み多いので脱出したいんだけど。

WFH 終了に伴う家事負担の変化、に伴う家庭内/夫婦間での摩擦を想像するとかなり憂鬱な気分になる。が、考えてもストレスばかりあって無駄なので今は思考に蓋しておくべし。

私物の Pixel 2 XL には Android 12 が来ないのでどうしようかなあと思っていたら新しい電話機を dogfood するなら一台あげるよ、というのでもらうことに（貸与ね）。Pro じゃない方。まだ出てない電話機なので感想は差し控えますが Pixel 2 XL よりはだいぶ速いね。当たり前ですね。

ではこのブログはなんなのかというとインストール忘備録です。なお Dogfood = 開発中 OS が降ってくるので、それとは別に lifelife アプリを入れて会社アカウントは紐付けないデバイスも持ち歩く、というかこの新しい電話機は発売されるまでは持ち歩かない。(しかも設定の途中で間違えて Fi の data sim を無効化してしまったのでどのみち外では使えなくなってしまった・・・。) そっちもやはり会社貸与の Pixel 4a. ほんとはこれも dogfood しないといけないんだけど、会社アカウントに紐付いてない安定版 OS の電話機がないと精神衛生に差し支えるのですみませんが私用させていただきます。今のチーム辞めるときは返さないといけないわけだが、まあそういう先の話はその時に考えるべし。

でインストール記録。いちおう dogfood 用途なのでストイックにはせずぼちぼち色々入れてあげる。

• デフォルトのものども (Gmail, Calendar, Chrome, Google, Camera, Photos, Fi, Home, GPay, Drive, YT, etc.)
  • Play Movies はガチで使わないので無効化. ちなみに無効化すると update が降ってこなくなるのでディスク容量を節約できるよ。
• Docs, YT Music, Keep, Podcast は抱き合わせで降ってきたので一応残してあげる。というか Docs と YT Music は普通に使ってる。Keep もたまに使う.
• その他の G
  • Play Books
  • Google Find My Device
  • Google Voice
  • Google Fit
  • Fitbit - きみたち合体しないの? 別にいいけど。
• ツール、細かいアプリ
  • OTP App - だいたい YubiKey に移行したが一個だけのこっている :-(
  • Password Manager
  • WeightFit
  • Medito
• チャット
  • Discord
  • Messenger Lite
• インターネット閲覧
  • Pocket Casts
  • Instapaper ... は Android 12 に対応してないないらしく出てこない。正気か。
• Web のガワ
  • Todoist
  • Dropbox Paper
  • GitHub - 別に出来よくないので Web でいい気もするけど。
• メディア
  • Audible
  • NY Times
  • NYT Cooking なんてのあるのか。ついでに入れてみる。
  • Disney+
  • O'Reilly
• 商業系
  • Hello Fresh
  • Jack-In-The-Box
  • Wells Fargo

なんかもうちょっと活用してあげたい気もすれど、アプリを入れないよう行動を訓練してしまったので必要性を感じないのだった。

DuckDB の中の人から「おめえなかなかいいコード書くな。ちょっと話しようぜ」という誘いがあったので Zoom. 見る目があるじゃんか (うそです)。T-shrits を送ってくれるというのでありがたく頂くことにする。

なんか助けになることある？というので、Checks は常時 green にしてちょうだい、古くていらないバグは閉じてちょうだい、などとお願いする。しかし我ながら大企業病なお願いであるなと思ったので、 ちょっと breaucratic かもしれないね、などと言い訳する。

割と良い人々であった。オープンソース、中の人の気が良いというのは、パッチを送る側としてはけっこう重要な要素だよね。コードが良くてもジャークな人を相手に議論とかしたくないから。

Duckdb へのコード書きは自分の日々の潤いになっているので、ぼちぼちやっていきたいものです。今はぼちぼちとかいうレベルじゃなくて自分の余暇をぜんぶ突っ込んでるけど、それでも高々一日二時間とかなわけで、切ないもんだわ。

HTTPFS を引き取ってほしそうな雰囲気だったが、どうかねえ。そういう重要機能をうかつに own してしまうと仕事っぽさが増してしまう気がする。まあ、いずれにせよ特定のなにかにコミットする段階ではないね。パッチ修行優先。

前の続き。

社内求人で「リモート可」という検索ができるようになったので眺めているが・・・よくわからん。そして数が少ない。リモートに限ると、ただでさえ少ない（自分にできる）職の選択肢が更に狭まってしまう。

あと冷静になって考えるに、リモートで新しいチームに入るってすごい難しそうじゃない？チームの側も remote で onboarding する体制ができてないといけないし、自分にしてもがんばって顔を売らないといけない。東京の頃はそういう "visibility" 対策を色々考えないといけない雰囲気があった。せっかく引っ越してそういうくだらいことをしなくてよくなったのに、やりたくないだよ。

たぶん現状の勤務先の remote というのは、チームでの tenure の長い人が同じチームにいる前提でやるものなのだろうな。ある種の「上がり」ステータスで、キャリアを前に進めていきたい人がやるものではない。別に自分はキャリアを「前に」進めたいわけではないが、なんか違うことをしたいわけで、結局は同じ問題がある。

むしろキャリアを「前に」進めたい人は、同じチームではなくてもそれなりに縁のある近接チームに移りがちで（たとえば OS の中の人が OS の他の部門にいくなど) 、そういう距離の近い異動だと onboarding も少しはラクだろう。でも全然違う組織にいくのは大変。

その点で OS, 検索, ブラウザのような巨大製品は壁の内側で動き回れる範囲が広くて少し羨ましい。カメラはチームの大きさが不十分。そのうえ仕事もニッチで専門的なもの（画質の改善とか CV とか）が多く、自分のスキルセットでできることがあまりない。

チームを移るなら、来年早々に子がワクチンを打ち、オフィスの再開が確定したありでやるのが良いのだろうね。それまでは heads down. 別にほんとにオフィスがあくまでまたなくてもいいと思うけど、最初数ヶ月ずっとリモートとかだとキツそう。

ちょっと前に manager にならないまま出世した同僚が・・・TLM になってしまった！なんでやねん！いやいいんだけどさ、やりたいのほんとに・・・？ふとその人のマネージャ、つまり自分のマネージャのマネージャをみると、もはやほとんど IC がぶらさがっておらず「マネージャのマネージャ」になっている。しかしそのマネージャたち、だいたい部下が 3-4 人とかしかいない。この余分な階層いらなくね？

最近感じている仕事のイヤさ、息苦しさは、直接的には今の TLM がイヤなわけだが、TLM というのはどうしても micromanage がちになると思うんだよね。部下が少ないと尚更。なので 3-4 人が下についた TLM ばかりのチームは micromanage 地獄となる可能性が高い。

その TLM がある意味真面目に仕事をして laser-focused なビジョンとかを決めてしまうのもイヤで、すごい狭い範囲の仕事しかできなくなってしまう。なんかもうちょっと広い範囲からやることを探せないと解空間狭すぎ。息苦しさの一つはここにある。もともともアプリとかってのはそれだけでずいぶんスコープが狭いんだから、その中くらい自由に動かせてちょ・・・。

自分が会社に入って最初の五年くらいは、東京でも MV でもマネージャは 20 人くらい reports がぶらさがっていた。前のチームでもマネージャの下は 10+ 人はいたはず。これだと、たとえば細かい問題への対処とかは遅れがちだったり、キャリアの相談にのってくれないとかいう問題は起きうるが、かわりに micromanage にはなり得なかった。個人的には、トレードオフとしては全然この方が良い。

マネージャのマネージャ仕事さぼりすぎじゃね？とか文句もいいたくなるが、必ずしもそうとは言えない。バグをたらい回したりつついたり、それ以外にもやたら他のチームとのミーティングとかをしていて、渉外が多いように見える。これなんか受託開発の管理職が事実上マネージメントしてなくて渉外やってる昔々の記憶にあるマネージャの姿に近いのでは。

などと思いつつふと旧チームメイトなど面識のある社員たちの組織をランダムに冷やかすと・・・ 10 人以上 direct report のいるマネージャって随分少ないね。前からそうだったのか、最近こうなったのか客観的な証拠はないが、傾向としてはツリーの幅が狭くなっている気がする。自分のマネージャのマネージャだって二年くらい前はもうちょっと下にぶら下げていたわけだし。ツリーの深さが増えるのは会社の規模拡大のせいだと思っていたが、それだけでもなかくツリーの形が変わっていた。なんなのだろうね。下っ端的にはいいことなし。TLM もそんなにいいことないとおもうんだけどね。M 大変じゃん。TL でよくね？

はーどうしたものか。まあ他のチームにいくのが正解なのだろうが、いちおうそれ以外の選択肢も列挙してみる。

偉くなる。偉くなるほどツリーの上の方にぶら下げられがちなので。しかし TLM にならないまま偉くなる難しさが顕になってしまった今、ますます出世は期待できない。出世はどのみち諦めたのでこの選択肢はないが、偉くなって得られるものの一つに TLM を避ける魔除けの力があることを理解した。

マネージャのマネージャにゴネてみる。これは可能かもしれないが、貸しができてしまうし、現在のマネージャとの関係も微妙になってしまうなあ。引き続き一緒に仕事をする必要があるわけで、あまり摩擦を生みたくない。そこまでして続けたい仕事ではないからね。それらしい口実を捏造すればいいのかもしれないあ。

我慢しておく。これは・・・特にいいことないな。ただタイミングを選ぶ上である程度の我慢は必要。

はー他にうつるにしても、今までとは違う考え方をしないとなあ。

まず今議論したように、人数少ない TLM の下につくような仕事は避け TL じゃない report の多そうな M の下につけるチームを探す方が良い、これは案外難しい。なぜなら hiring は新しくマネージャになった人の下につける誰かを探しているケースが多く、そういうマネージャは report が少ないからである。求人情報から不完全に推測するしかない。

あとはオフィスの場所ね。遠くに引っ越す予定のチームは避けたい。ただこれと↑だとオフィスの場所は妥協が必要かもしれないねえ。

リモートフレンドリさ。なるべく隣接チームが地理的に散らばってるところを狙う。優先度としては nice to have である。

現在の仕事との近接度。カメラ部門の他のチーム。となると HAL だろうけれど、あの人たちはガチで締切がきつそうなのでやだな・・・。同様に OS 部門もイヤ。OS はバグのスループットも高いから尚更イヤ度高し。モバイルをやるなら何らかのめんどくさくなさそうなアプリがいいなあ。ただモバイルだと OS 部門が一番職が多いので、あまり贅沢は言えないかもしれない。モバイル以外。新 OS? Dart はやだな・・・。出戻りでブラウザ？は今更やりたくない。景気でいうとクラウドなんだろうけど、できる仕事なさそー。電子書籍？は頼りにしていたマネージャが亡くなってしまったので不安。求人があるのか知らんし。

まあ、なんらかのアプリ仕事で、なるべく規模の小さいやつを中心に探すのが妥当なのだろうね。もうモバイルやりたくないけど、脱出がゴールなので贅沢は言うまい。

タイミング。別に harassment とかの強いストレスがあるわけでないので、急ぐ必要はない。電話機の締切が過ぎたら仕事のイヤさレベルの低い時期になるし。今のチームにはそれなりに恩があることだから、overdue になっている地味な自動化とかの仕事をきちんと終わらせつつ行き先について考えるのが良いのだろうね。

とはいえ良さそうな求人は応募しないとすぐ消えてしまう問題もある。いまから求人を眺めはじめ、しかし応募はしないというのはそれはそれでストレスそうなので、異動先探し自体も電話機のあとだな。今は heads down の時期なり。

人は会社ではなく上司を見限るというのはよく言ったものである。

仕事のストレスの出どころについて考える。

と、やはり最大のストレスはバグだよなあ。自分が書いたのとはしばしば無関係な、しかもぜんぜん再現しないバグを、アサインされる。この hot potato をなんとかしないといけない。あるいは、やはり再現しない、そして再現しても直せるわけではない「遅い」苦情バグを、アサインされる。

「遅い」バグについては分析プロセスを自動化するスクリプトを書くことである程度は心的負担を減らせる見込みがある（これは去年くらいからやっておくべきだったが、late is better than never.）が、前者についてはどうしょうもない。自分なんてもうバグの相手ばかりであんましコード書いてないのに、なんかたらい回されてくる。そして問題は、しばしば platform なり HAL なり下の方のレイヤーのせいだったりする。そういう時は担当者を探してきてアサインしたり、場合によってはしつこく nudge したりで直してもらわないといけない。前はこういうのも自分で直そうとしていたが、本業がまったく進まなくなるので諦めた。この他人にたらい回す仕事がまず嫌。

しかもこういうバグは大半は再現できないのでログをひとしきり眺めた後「再現できませんでした。似たような報告が他にないか目を配っておくね」とかいって閉じることも多い。この「ログを眺めてごめんと言う」プロセスもまた、心が消耗する。バグの notification がメールで来るたびに、胃のあたりがチクリとする。心が休まらない。

このイヤさは時間とともに軽減されるかと思ったが、慣れによる減少をチームでの seniority に伴うバグ流量の増加が打ち負かしていて、楽になってない。むしろ仕事で裏方的な本体コード以外の割合が増えるにつれ、俺のバグじゃねーストレスが募るばかり。

ふと見ると三年前にほぼ同じこと書いてるな。三年前との違い:

• 自分にとっての「シニアなチームメイト」というのはもはや存在しない。自分が担当者を見つけてたらい回さないといけない。
• ロギングが改善され、広い時間軸をカバーするようになった。

まあなんていうか、進歩してないね。たらい回しスキルは上がったかな。クソスキルすぎてうんざり。これを改善しない限り自分のしごとの QoL は低いままで、しかし改善する気はしないので、なんとかしたいなら他にいくのが妥当なのだろうなあ・・・。

AQ が悪くてもできる運動という口実で Oculus Quest 2 を購入。Supernatural に sign up する。

Oculus Quest 2 は、さすがによく出来ている。メガネが邪魔なので外してやってみたが、さすがにないと厳しい。光学的に補正してくれればいいのにと思わないでもない。あとスマホアプリとの pairing が若干かったるい。アプリいらないじゃん。あんた中身 Android でしょ・・・。

Supernatural の sign up flow などは会費がすげえ高い割に全然よく出来ておらず、アカウントも課金も独自で、なぜかアプリ内で pairing も求められ、かったるい。Oculus は in-app purchase の縛りとかないのだろうか・・・。

想定していたより広い場所が必要で、リビングルームの子の遊び場がギリギリ（というかちょっと足りない）くらいだった。アパート一人暮らしで Oculus とか可能なのだろうか。NYT Columnist の Kevin Roose は裏庭でやってると書いているが、Wifi はいんねえよ。というか、それは色々厳しいだろう・・・（厳しいががんばってると書いている）。あと音漏れすると奥様に怒られたのでイヤホンは必須。

プレイ中の awkwardness は相当のもので、家族が寝ている早朝にしかできない。こんなものに有り金全部つっこんでいる FB 大丈夫なのか。ぜんぜん people を closer にできる感じしないというか、視界遮って他人を隔離してませんかこれ・・・。

運動としての Supernatural は、activity level をあげようとすると難しいステージをプレイせねばならず、してみると、難しい。熟達が必要。熟達の必要なく汗のかける筋トレとかジョギングとか素晴らしいね・・・。トレーナーがずーっとしゃべっていて、うっとおしい・・・かと思いきや普通に励まされて良い。この in-app trainer がコンテンツの価値の 1/3 くらいだと思うので、I18N できないね。国外で売らないのわかるわ。なお風光明媚なパノラマビデオが 1/3, 有名楽曲が 1/3 くらいとおもわれる。有名楽曲イラネーとかおもっていたが、曲にあわせて棒を振り回すので割と重要だった。

$20/m の価値は自分にはなさそうだけど無料体験が一ヶ月あるので、しばらくプレイしてみます。

なお本日は珍しく素晴らしい AQ で、Supernatural やるより外で走るほうが良かった。

気がつくと体重が 6kg 増えている。やばい。去年は WFH なら食事もスナックも有限だし心配ないわとか思っていたが、欲深さに負けた模様。

前回の記録を読み直す。攻めてんな・・・。

子がいると「食事しない」は色々都合が悪いので、前回のように攻めることはできない。ではどうするか。

• 朝食はパンは食べず、野菜とプロテインのみ。
• 昼飯はナシ。
• 夕食は普通にたべる。おかわりはナシ。
• 週末外出時は普通にたべる。
• 当然間食はナシ。

この空腹感、ひさしぶりだなー。最初の一ヶ月で 3kg 減らせるとして、だんだん減速するから 3 ヶ月くらいかかるかなねえ。長い。

アロケーション直後のメモリアクセスで page fault が起こるため超遅い（俺のせいじゃねー）のをなんとかしたい。

素朴なアイデア: 事前に巨大なメモリを確保し、そいつを pre-fault し、その後リリースすれば、そのメモリが再利用されてめでたしめでたしじゃね？

が、これはダメっぽい。

まず pre-fault だが、madvise にはそういうオプションがない。mmap() には MAP_POPULATE があるのに！MADV_POPULATE を入れたいぞ、というパッチがあるが今年のはじめとかで、どう考えても Android には入っていない。そもそも merge されているのだろうか。(されてはいるらしい。)まあこれは最悪 page を traverse すれば良い（ほんとに？）。

問題はアロケータ。Android は少し前から scudo というアロケータを使っている。

• Scudo  |  Android Open Source Project
• Scudo Hardened Allocator — LLVM 13 documentation

が、こいつのコードをみると・・・

• でかいメモリブロックはキャッシュされない！
• キャッシュされるときも releasePagesToOs という関数が madvise(...MADV_DONTNEED) してしまう！世知辛いねえ完全に正しいが・・・。

ところでメモリアロケータってなんとなく連続領域を確保してそいつからメモリを切り売りする、足りなくなったら brk() で伸ばす、みたいなメンタルモデルだったけど、全然違うね。普通に mmap() でインクリメンタルにページ/ブロックを確保していく。使い終わったら unmap() で返す。まあこれが正しいよなあ。

自分の冒頭の素朴なアイデアは完全に 20 世紀のメモリアロケータに依存していたと反省。

冒頭の問題を解決するにはアロケータ差し替えとかが必要な気がするが、それは現実的にはぜんぜん無理なのでなんとか scudo に抜け穴を作って欲しいが、上流が llvm じゃあそれも難しそうだなあ・・・。なんかパラメタいじって乗り切るとかする必要があるのかもしれない・・・。

また早寝早起きをするようにしている。二年前はやっていたのだが、よく覚えてないけど WFH 移行とかのタイミングで中断したのだろうか。あるいはやってる作業がつまらなくなって途絶えたのかもしれない。上の日記にも PyTorch のチュートリアルが面白くないとか書いてあるし。

今は 20-21 時に寝て 4 時に起きており、これだとまったく睡眠不足はない。が、WFH 移行は朝にジョギングしているので、6 時過ぎくらいには切り上げないといけず、そうすると 2 時間しかない。もう一時間前倒ししても良い気はする。そんで必要に応じて昼寝する。WFH, 昼寝のしやすさはオフィスより圧倒的に上だからね。

明日から一週間くらい 3 時に起きてみようかなあ。

仕事のやる気がない、というかストレスが高いので、なんか現実逃避的な余暇プロジェクトが必要だなと思い、以前から気になっていた duckdb のコードを読むことにした。せっかくなのでコード読み日記をつける。場所は、ブログというほどでもないなということで karino2 の真似で githbub issues を使ってみている。columnar database なので縦書日記。ブログへの export とかはしない。

どういう milestone にするかは悩ましいが、とりあえず 30 日やってみるとかだろうか。あと現実逃避というか pure fun なのであまり生産性とかは気にせず雑にやりたい。

職業プログラマ的には ML とかやった方がいいんだろうけど、自分にとって ML はやってない宿題的なイヤさが高まりすぎて考えただけで憂鬱になってしまう。ストレスから離れるための場で別のストレスを受けてはたまらないので、有用性は追求しない方向。

仕事、なんか細かいタスクでしかも他人に確認したり調整したりブロックされたりブロックされたりするものが色々あって、しんどい。というか完全に気が散りまくって生産性どん底。こういうのちゃんとできないのだよ・・・。

これまでは Deep Work 的な集中力ばかり気にしていたが、こういう細かいタスクを juggle するスキルというのは存在するはずで、なんか軽くレビューしたい気がする。しかしそういうのあまりに興味がなさすぎたのでまったくリテラシーがない。マルチタスク力みたいな。マルチタスクとかダメですよ、終了、という立場だったわけで・・・。

でもチームのエラ目の人達はこういうの自分よりよっぽど大量に抱えており、かつそれをこなしていて、なんというか、あまり自分の立場に文句をいう気になれない。こうして愚痴るくらいがせいぜい。しかし偉くなると雑用（というと怒られそうだけど）が増えるばかりというのはマジ夢がないぜ。

自分のチームの TPM とか超絶マルチタスク雑用マシーンという感じで、完全に人間離れした仕事をしている。しかし正直あまりハッピーという感じはない。季節性もあるのだろうが。なんというか責任感だけが彼を支えている感じがして、しかも必ずしも抱え込むタイプではなく自動化とか文書化とか超絶ちゃんとしており、本来ならもうちょっとスケールされてしかるべきなのだが、なんかその手の仕事ができすぎて頼りにされちゃうんだろうな。

そういう TPM を burn out させないために、そして自分も burn out しないために、ある程度の雑用力はつけたい気がしている。しかしそういうのは一体どうすれば身につくのか、根本的な部分で興味がないせいもありまったくわからない。Productivity Porn の世界ではこういうんはアンチパターンとされているわけじゃん？しかし現実にはそういう仕事は個人の力では撲滅できないわけじゃん。あの人たちどうしてんの？なんとなく「過労している」が答えな気がしているが、怖くて確認できない。

• Opinion | It Is Every American’s Right to Curse the President - The New York Times
  裁判所が言論統制的な判決を下したことに苦言。アメリカ的。
• The future of flashing custom ROMs will be through a web browser
  会社の Android 開発はブラウザから電話に OS イメージを焼けて便利なのだが、世間はどうしてるのかな・・・と調べたら、やってる mod もあるらしい。Lineage OS にもがんばってほしいもんだわ。
• I'd like to note, donning my #2 at amzn hat again, that when the idea for affili... | Hacker News
  Amazon affiliate のせいで検索スパムがひどい・・・という話のスレに Amazon 社員番号 #2 がでてきて made my day.
• How to Combine Multiple Subreddits with Multireddits
  Reddit に複数の subreddits を連結してみる機能があることを知る。
• Distill Hiatus
  Distill 中断のおしらせ。残念。G AI 部門のキナ臭さと coincident なかんじがしなくもない。
• Can InnerSource bring open source practices to closed corporate bureaucracies? - Stack Overflow Blog
  社内オープンソースとか 15 年くらい前の流行だとおもっていたが、まだ推してる人がいた。
• Don’t Feed the Thought Leaders - Earthly Blog
  何にでもナツメグをいれたがるおばさん・・・って見に覚えがあるな（最近割となんにでも入れてる）
• Cold weather virus in summer baffles docs, worries parents
  夏に冬の風邪が流行っているという話。
• The Tyranny of Spreadsheets | Tim Harford
  Excel の自動補完でおきた色々な問題に関する逸話。
• Graphics Rendering: What’s New and What’s in it for Architects? (Part II) | SIGARCH
  GPU はレイトレとかテンソルとか入ってるけど、もうひと工夫すると色々できそうだよね、というような話。
• Reverse-engineering the Mali G78
  モバイル GPU の仕様解析ストーリー。Collabora がんばってるな。
• A History of American Girl Dolls | History | Smithsonian Magazine
  アメリカでたぶん一番人気の人形 American Girl, 実は時代考証とかが凝っている（一部モデル）という話。

自分が Google の良心と目していた Sridhar 氏、二年前に会社をやめてプライベート検索エンジンのスタートアップをはじめていたのは知っていたが、昨日 podcast でインタビューにこたえていた。その Neeva という検索エンジンが既にサービスを開始していたと知る。

せっかくなので sign up して使ってみる。$5 / month だが最初の 3 months は無料で、入門セットアップをやると更に 3 months ぶん延長、合計 6 months 無料になる。

他の代替検索サービス同様、ウェブ検索は Bing を使っているらしい。ただ自分でも多少はインデクスをもっているのか、ランキングと表示だけいじっているのか、ニュースとかショッピングとかの検索はそれなりに専用の UI がある。あと Google にはない細々とした設定がある（一方で Google にある機能も色々無い気はする）。

プライベートサーチならではの機能として、Google, Dropbox, Notion などにリンクして Gmail なりノートなりのテキストも検索できるようになる。

モバイルアプリはなくて、ウェブのみ。ただ求人をみたらモバイルも募集してたので、やる気はあるらしい。

せっかくサインアップしたのでデフォルトのサーチにして使っているが、今のところ出来が良いというわけではないね。

個人的に検索は広告やプライバシー以前にスパムが問題だと感じていて、そこに何か答えがあるわけではない。たとえば「電子タバコ」の検索結果とかやばいじゃん。これが "e-cigarette" だと随分マシになるので、労働集約的な解決しかないのではないかという気がしている。

プライベート検索として Gmail が対象になるの、便利といえば便利な一方で脱 Google したい人のサービスで Google アカウントのデータを検索するというのはなんとも皮肉。今後色々なものに対応していくのだろうけれど・・・。ただ世の中の多くの「プライベート」なデータって API ないよね。特にメッセージングの類。Twitter のようなソーシャルメディアも API には制限があるし。

人々はプライベートで ads free というところにどれだけ価値を見出すのだろうね。たとえば Apple / iPhone はプライバシー重視とされているが、人々べつにプライバシーのために iPhone 買ってるわけじゃないよね。出来が良いから買っている。プライバシーは cherry on top of cake というかんじで、大半の人にとってキラー機能ではない。Apple が strategy credit を生かした付加価値としてプライバシーをやるのは正しいが、Neeva どうなのだろうか・・・。Podcast の中でホストが "Apple に買収されるしかないんじゃ?" と突っ込んでいたけど、そういうかんじだよな。

たとえば世の中には VPN のサービスが色々あり、人々は luxury としてそこそこ金を払っている。だからプライバシーに金を払う人はいる。一方で VPN は利便性は損ねない。

プライバシーを気にする人が、DDG のような匿名志向の検索ではなく色々データを預ける必要のある Neeva を選ぶのか、というのも気になる。Ads を介して個人情報を売られるのを気にする勢と、データを預けたらそれが breach される可能性を気にする勢がいるはずで、Neeva は後者の問題を解決していない。

と書いてみると、自分は人類のなかでもかなり pro-Google なバイアスがある身分なので、Neeva の価値をちゃんと判断できる気はしないなあ。まあ無料期間のあいだしばらくは使ってみます。

左傾の強さを示すゴタゴタに嫌気が差し 2 月におためしで NYT 購読を切ってみたが、また再開することにした。半年しか続かず。

不購読期間中、他のニュースサイトなどを見てみた。

まず paywall のない AP News. 大きなニュースのヘッドラインを眺めるにはいいが、圧倒的なつまらなさがある。文脈の解説とか全然ないし、ガンと取材した厚い記事、社会面的な記事もない（あるが、面白くない）。自分は別に最新ニュースとか興味ないということがわかった。左傾のウザさはなし。

普通だったら高すぎてまず購読しないがなぜか会社が sub してくれている FT. 割と良いが、方向性としては日経新聞なので社会の動向的な記事は少なめ。あとイギリスの会社なのでアメリカと微妙に距離がある。社会面みたいな記事を読む時はどっちの国の話をしているのか気にしないといけない。やや左寄りではあるが NYT のような暑苦しさはなく、ウザさは低め。Paywall が高すぎて free tier ゼロなので、誰にもシェアできないのは若干盛り上がらない。あと仕事ラップトップでしか読めないのは不便。

The Guardian. Paywall がないのはいいが・・・暑苦しい。こんなら NYT でいいやという感じ。最初はぼちぼち見ていたが、すぐ見なくなった。

CNN. テレビ的すぎて辛いのですぐ脱落。

Google News. ひさしぶりに unblock してみたが、やはりパーソナライズの結果としてしょうもないガジェット情報ばかり集まってくるのですぐブロックした。わたくしのしょうもなさを学ばないでいただきたい。ニュースも、結局 paywall がないサイトはいまいちなのが多い。自分はテック以外の興味深いテキストが読みたいのであって必ずしも最新ニュースが読みたいわけではないのだなと再確認した。

興味深いテキストという意味で、たとえば The Atlantic や The New Yorker あたりの雑誌を購読しようかとも思ったが、改めて冷やかすと話が長い割に情報量が少なく、そういえば雑誌ってこういう感じだったな・・・と我に返る。本題を薄く引き伸ばす "eloquent writing" は non-native reader からすると単なる負担。

で NYT. 自分のアメリカ感は NYT によって構築されている部分が多いので、読まずにいるとなんとなくアメリカがよくわからなくなり、落ち着かなかった。FOMO と言われればそれまでだけど、外国人としての所在なさを緩和するため自分に必要な所作なのだと思う。ニュースをガン無視して暮らすとか、その土地で生まれ育って社会に根付いている人にだけ許される贅沢・・・はいいすぎだけども。

あと book review とか parenting とか cooking とか割と見てるな。そういえば。安定した活字源としての期待ってあるよね。こんなに知的に依存しちゃっていいのか不安はあるけど、英語話者としての自分の知性はそんなもんということでしょう・・・。

閑話休題。

色々なニュースサイトをつまみ食いした結果、複数の新聞を購読する人の気持ちがわかった。あれは必ずしも全紙くまなく目を通したいのではなく、各紙の良い記事だけを読みたいのだね。どの新聞にも程度の差はあれよく書けた記事というのが存在する。渾身のスクープかもしれないし、思わぬ切り口の社会面の記事かもしれないし、特別なゲストの op-ed かもしれない。ただ、そういうのは数が多くない。だから複数紙購読しておき、それぞれで話題になっているやつを読む。あるいはソーシャルメディアとかで流れてきた記事を paywall に邪魔されず読む。そういう贅沢 (?) が複数紙購読というものなのだろう。自分ももうちょっとヒマとカネがあったら WP と WSJ あたりも sub したいけど、さすがに高すぎ。それに良い記事だけに限っても読むヒマなさそう。

日本語のウェブサイトを見ていたら電子タバコの広告が出ていた。

ちょっと前に JUUL がすごい勢いで駆逐されたアメリカの事例を思い出し、日本ではどうなってるのかと軽く調べると・・・日本の電子タバコはニコチン入ってないのね。どこが嬉しいんだそれは・・・。JUUL で問題視された電子タバコの被害はニコチン自体でなくその他の成分の毒性だった気がするが、ニコチンないと依存物質がないのにその他の害だけを被ってしまう気がする。CDC のガイドをみるとニコチン以外の害の記述はいまいち曖昧。

軽く検索すると日本でも JUUL を買えるっぽいサイトがあり、それは個人輸入代行業者らしい。いいのかそれは。まあタバコを所持していいのに JUUL がダメと主張するのは難しい気はする。

ニコチンの入ってない電子タバコ、どうして吸いたいのかまったく理解できないけれどこういうのが JUUL 同様「かっこいいもの」になってしまうと面倒くさそうだなー。ニコチンが入ってないおかげで無放地帯らしく JUUL が廃止を余儀なくされた甘いフレーバーもバリバリ売ってるし。

しかし自分が目下気にすべきなのは子が 10 年後とかに JUUL とかのより危険度の高いアメリカ電子タバコに手をださないことなので、日本の電子タバコは厚生省あたりにがんばって睨んでおいていただきたく思います。

などと調べ物をしていたら少し前に JUUL の本が出ていたと知る。Audible してみようかな。

Eric Seidel と Adam Barth が YouTube で Fuchsia の解説をしていると向井さんが教えてくれた。

Eric と Adam はもともと Chrome の WebKit チームを率いていた二人で、ある時から Flutter や Fuchsia に移っていった。自分もこの二人がなんか新しいことをやるというのでヒョコヒョコついていったはいいが、まさかの Dart Runtime と OS 再発明だったので逃げ出したのが 5-6 年前。自分がしょぼしょぼ Android のコードを書いている間に彼らは OS を出荷したのだった。

・・・という回想はいいとして、このビデオは RubberDuckEng という YouTube Channel がホストしている。RubberDuckEng は Eric Seidel と Adam Barth がペアプロで live coding するという番組で、いまみたらもう 50 回以上やっている。そして各話の再生回数は 100 回前後、というかもっと少ない。Karino2 のプログラム雑談と変わらん。無職ならともかく会社員がそんな再生回数で YouTube とかやっている場合なのか・・・

と疑問を抱きかけるが、見ると続いている理由がわかる: 楽しいからに違いない。

楽しそうなのだよね。Eric と Adam のこの噛み合っているようないないような感じ、よく覚えている。自分が転勤してきた最初の席はこの二人の机のそばで、この人たちはいつもペアプロしていた。HTML Parser を off thread にしたり、Polymer のスクロールを速くしたり。自分の中では Jeff + Sanjay に通じる部分がある。すごいプログラマが成果を出すとき、そこにはしばしば別のすごいプログラマがいるのである。

二人ともえらくなって守備範囲も微妙に違うっぽいから、たぶん二人とももうそんなにコードは書いてない・・・というか Adam Barth は書いているだろうけれど、すくなくとも昔のようにペアプロはしてない。Jeff + Sanjay はそれでも月曜の朝にペアプロをしていた。Eric と Adam はそれを YouTube でやることにしたんだな・・・と勝手に解釈している。

書いているのは仕事のコードではなく、小さなトイプログラムがほとんど。Live coding も (リンクした Fuchsia 紹介ビデオは別にすると）特に前準備もしておらず、毎回一時間くらいモタモタやってる。仕事ってかんじじゃない。目立ちたいとかでもない。ただ週に一回、ペアプロすることにした。そして様子を YouTube で流すことにした。それだけ。それがいい。その友情がいい。

こういうの、なんかできないかなあと考える。

Misreading Chat も Message Passing も、特に後者は友達づきあいの vehicle という面があるけれど、production に重きをおきすぎているせいで継続性や頻度が犠牲になっている。一方で Rebuild.fm 派生 podcast みたいなピュア雑談は自分がやるとエゴによって俗悪化するのが目に見えている。やっぱりなんか作業が伴うのが健全で良いよなあ。Live coding は個人的には気が向かないが、もうちょっとコード的なものが中心にあるのが良い、気がする。たとえば・・・なんだろうね。

コードレビュー Podcast. 相手の書いたコードをターン制でレビューする。ただコードレビューだとあまり楽しさがないので、何らかのひねりは必要な気はする。たとえば相手のコードを勝手に添削するとか、あるいは全然知らない言語でコードを書いてみたり。RubberDuckEng でも (Dart な Flutter の founder である Eric が) Rust を書いてみたりしている

Weekly Standup Podcast. 先週の進捗を報告する Stand-up meeting を番組にする。なんとなく良い良いと思っている。参加者が同じ共同プロジェクトをやっていたりすると楽しいだろうけれど、趣味プログラムだとなかなか難しい気がするね。一方で互いにまったく関係のないプロジェクトの進捗を話し合っても、会話が成り立つのかよくわからない。

Today I Learned Podcast. なんか調べたことについて相手に説明する。これは (pragmatic programmer 的な意味での意味での) rubber duck に近い。論文縛りを外した Misreading Chat といえなくもない。

こう考えるにつけ、Podcast にしろ Blog にしろ説教やら時事ネタへの感想やら書くよりは何らの action や motion が伴う方が健全で好きなのだろうね。自分は。Message Passing はその点がやや残念。そういう残念さを通じた venting もたまには良いものだけれど、それだけだと不健康に感じてしまう。

ふとしばらく課外活動時間（子の就寝後 2-3 時間くらい）で仕事したらどうなるかな、と一ヶ月ほど試してみた。Boox 向けに書いていた課外活動が失速してしまったり、日中の仕事が雑事に追われて捗らなかったりしたため。つまり残業だな。

結論からいうと、全然ダメだった。

最初の数日は、捗らなかった仕事が進み初めてこりゃいいじゃんとか思ったが、すぐに「雑事」が夜の時間も侵食してしまった。雑事、すなわち性能バグの分析や修正。これらは夜の残業枠ではやらず、もうちょっと生産的な作業、つまり自動化の強化に使いたいと思っていたが、いざ眼の前にバグが積み上がってみるとそれを無視して他の仕事をやる気にはなれなかった。バグ修正の重要性はわかっているだけに、その優先度を無視するのは難しい。

そして時間がない！というと語弊があるけれども、他のことがガチで何もできなくなる。仕事、やることが自明な上に無限にタスクがあるため、いくらでも時間をつっこめてしまう。無限にタスクがあること自体は必ずしも悪いことではないはずだが、眼の前にあるタスク、つまりバグの分析・修正を生産的と感じるのは難しかった。この不毛な時間を減らすべく各種自動化を強化したいという動機で残業実験をはじめたわけだし。生産的ではないが重要とかわけわかんないけど、でもそういうのあるでしょ。

失われるのが課外活動プロジェクトの時間だけならまだマシで、実際にはやるべき家の仕事が後回しになってしまう。家庭崩壊リスクが高まり、良くない。

精神衛生が急速に悪化した。仕事というのはストレスがある。締切のストレスがあるし、それだけでなく性能バグ分析という作業の不毛さも課外活動時間では特に精神を削られる。他人にバグをたらい回すとかさ、やりたくないわけ。勤務時間中にこういうストレスがあるのはさすがに慣れたが、本来それを回復するための課外活動時間で更に心を削られてしまうと厳しい。残業をするまでは自分がここまでストレスに晒されているとは気づいていなかった。

これはいま時期的にチーム全体の仕事の忙しさが高まっているせいでもある（じっさいミーティングすると TPM が死にそうに不機嫌な顔をしている。）あとは仕事以外の家の細事にもいま若干のストレスファクターがあり、それも負担になっている。皮肉なことだが、仕事（や家）が忙しいときほどストレス対策には気をつけねばならず、すなわち残業するのは危険。

なおストレスと言っても、いわゆる「仕事をデタッチできないストレス」つまり仕事以外の時間でも仕事のことを考えてしまうは問題は、多少はあるがそれほどでもなかった。どちらかというと 1. 何も新しい情報に触れられないストレス 2. この時間がない状態で新しい危機が(仕事でも家でも)発生したら積んでしまうという恐怖 3. やりたいことが全然できないフラストレーション 4. 心の余力がないせいでしょうもないインターネットに時間を使ってしまう罪悪感 ... とかそういうかんじ。

そんなかんじでストレスが高まりすぎ、一ヶ月の後半は残業したくなさから子を寝かせた後にそのまま寝てしまう日が増え、結局そんなに働けなかった。ただし寝てるので課外活動もなし。寝て起きたくないとか鬱病みたいでやばくね？まあ朝は普通に起きるんだけど。

ただ自主的な残業を通じた発見もあった。

まず、WFH での残業はだいぶ違うね。家にいるので、会社で残業するより家族へのインパクトがない。家のことをする時間がなくなるとはいえ、すくなくとも夕方の家のルーティン（子の風呂、炊事など）は犠牲にならない。子が寝た後に画面のスイッチを入れればすぐ仕事ができるのは便利。去年もやむにやまれぬ事情から残業した時期があったから知ってたはずだけど、あのときは色々グロッキーすぎて気づいていなかった。

逆に言うと、辛くないな残業ならアリかもしれないとも思った。そういえば去年の年末に仕事のハカソンでスクリプト言語を作ってた時はちょっと残業したけど特に問題なかった。ああいう楽しい要素のある残業ならしてやらんでもない気がする。ただ今はそういうのができる時期でもないし、そういうプロジェクトを考える心の余裕もない。なので残業とかしないでやりすごした方がよい。

一歩さがると、残業してやってもよいと思えるくらい意義のある仕事を考えることには、もっと頭を使ってよいのではないか。「意義」というと社会的価値みたいな話になりがちだけどかならずしもそうではなく、例えば自分にとって学びのある仕事ならやってもよいでしょう。Kotlin 使ってなんかファンシーなものを書くとか、ふだん触れないデータ周りでなんかできるとか。いまはやってるのが性能バグの相手だから苦痛なわけで。

ただ新しいテクノロジを触れるだけだと別に仕事の外でもできるから、そこには仕事ならではのチャレンジがあるとか、認知されやすい成果に繋がるとか、そういう「仕事としての価値」が必要。

今のチームは忙しすぎで自明なやるべきことが無限にあり、あまり深く考えなくても目先の仕事をやっていれば最低限の成果はでる。なのでやることを考えるのをさぼりがち。一方でそういう仕事ばっかりしてると燃え尽きてしまう気がする。なので残業するかどうかはともかく、自分から積極的にやりたいと思える仕事を考えるのにはもうちょっと時間を使って良い気がする。もっというと、残業をするならまず時間を使うべきはそういう「やるべきことを考えること」なのかもしれない。今月はあまりに心が摩耗しててムリだけど、しばらくしたらまた考えてみたい。

ところでさ。新卒で働いてた会社とか「見込み残業」というナゾ制度があり、毎月 60 時間分の残業代が自動的についていた。そして、そんな制度があるくらいなので当然のように 60 時間は残業していた。たぶん 100 時間くらいはコンスタントに残業してたとおもう。

でもさ、60 時間とかすごくね？どうなってんの? 今月の自分、たぶん 2-3 hours x 10-15 days とかでたぶん 30 時間くらい残業したとおもうけど、それでこんなに疲弊してるわけ。60 時間とか到底不可能。まして 100 時間とは・・・。

当時のことを遠くから振り返ってみると・・・。まず、会社にはいたがいうほど働いてなかったね。同僚とだべったりインターネットしたりしていた。まあインターネットは今でもしてるけど、よりアグレッシブだった気がする。今思うとやばいレベルで働いていなかった。限りなく好意的に解釈すると、会社というのは金を稼ぐ以上にソーシャルな空間だった。今はそもそもだべる相手とかいない。自宅勤務がそれに輪をかけている。

あと独身なので残業しまくったあとも時間があった・・・いや、さすがに無い気がするが・・・。たぶん睡眠を削ってなんかやって、会社で居眠りとかしてたな。独身とかいう以前に若さとブラック企業勤務への適応の結果だった気がする。

仕事内容がもうちょっと TL 的にデザインしてコード書くみたいな内容で、自分が熱心だった面もある。仕事のことを、仕事以外の時間もずーっと考えていた・・・時期ばかりではないが、そういう面はけっこうあった。それと比べると今の自分の仕事への熱意のなさよ。

こう考えてみると、残業するしないはさておき今の自分の仕事へのやる気の無さは、会社員を続けていく上で問題な気がする。そりゃ出世もできんわ。

一方でやる気はでないがやるべき仕事が眼の前には山ほどあり、こいつらを無視して「楽しさ」を追求しても成果にはならない感触がある。本来はこういうのはチームとして挑むべき話なのだろうけれど、PM とは音楽性があわない・・・という最近の悩みに帰り着くのだった。そういえば PM との音楽性を乗り切るする手段として残業してみようと思った面もあったのだよな。やれやれ・・・。

まあこの先数ヶ月はやる気ないなりに働きつつ、電話機が出た後の余裕のある時期にやるべきことを課外時間で少しずつ考えるのがよいのでしょう。

まあぱっとしないながら残業への理解が深まったので、それなりに意味のある一ヶ月でした。はい。

• re:Work - The Roofshot Manifesto
  PM がよく "roofshot" というので何かと思ったら、地味だが地味すぎない改善、みたいな話だった。
• A VR Frame’s Life | Oculus
  Android とはだいぶ違うね。あたりまえか。
• Uber's Crazy YOLO App Rewrite, From the Front Seat - The Pragmatic Engineer
  完全なブラックデスマだが成功してしまうあたりに Susan Fowler 事件以前の Uber の勢いを垣間見る。
• Caught in the Study Web - Cybernaut - Every
  受験勉強みたいのもインターネットのしょうもなさにやられているという話。きびしい。しかしここで紹介されていた lofi は割と気に入って聴いているのだった。
• Donating My Time to Grow a VC-Funded Company: Why I Quit Mentoring at Plato - The Pragmatic Engineer Mentring SNS みたいので mentor 側が無償で気に入らないという話。主張はどうでもいいが、そんなんあるのね・・・というきおち。
• An Unbelievable Demo Sun しょうもなさストーリー。そういえば Brendan Greg は最近オーストリアに帰ったらしい。実力者は自由でいいねえ。
• A Project of One's Own 最近ぱっとしない PG のエッセイ。なんか段々説教臭さが増しているよな。How to Work Hard も。
• Load Testing with Koi Pond - Slack Engineering Slack の負荷試験。一時期は headless browser を使っていたがカネがかかりすぎるのでやめたという下りが良い。
• Opinion | Is Education No Longer the ‘Great Equalizer’? - The New York Times 教育って結局持てるものの子を持てるものにしているのが現実ですよね、というような話。
• The Document Culture of Amazon 6-pager 読みもの。
• DSHR's Blog: Unreliability At Scale CPU のバグというのは今や普通に存在する、という論文の紹介。
• The Lightness of Windows – Stratechery by Ben Thompson Ben Thompson, Windows がクールな時代が来るのでは、みたいな話。気持ちはわかるが、こういう話は Windows 実際に使ってから書いてほしいもんだわ。
• #162: Minimum Viable Self - by Drew Austin - Kneeling Bus ソーシャルメディアとかで発言しないとインターネットから存在が消えてしまうし、オンラインとオフラインが融合した現代では世の中から存在が消えてしまうよね、という指摘。"Digitally homeless" というこの現象、困ったもんだわ・・・。

一日一回、時間を決めて日記を書いてみている。一ヶ月続いた。夜、子が寝た後に書く。開きっぱなしのでかい Docs に日付を書き足していく。インターネットに公開はしない。

前は notion に時間を問わずダラダラと箇条書きしていたが、それだと impulsive な呪詛ばかりになりがちなのでやめた。Tweet 的なダメさがある。

久しぶりにいわゆる「日記」を書こうとすると何を書いていいかわからなかったので、適当な日記の本を探して読んだ。そうそう、こういう淡々とした感じだよな・・・。

あまり書くことがない。平日は仕事の話が主で、週末は家族でどこ行った、みたいな。考え事とか愚痴とか、あんまりない。いや、あるにはあるが、別に他人に説明するわけではないので一行くらいで終わる。でも、こんなもんでいいんじゃないかな。概ね気は済んでいる。

いよいよブログを書かなくなるが、それは時間や気力の無さが問題なのであって、それでも日記なら書けるので、むしろ精神衛生を助けているとも言える。

そいえば一時期 WordPress で日記をつけていたことがあるけれど、ひとつの Docs に書いていく方が軽くて良いね。WP 重すぎ。Day One を買収したところをみると、日記としての WP は諦めたのだろうな。残念。

向井さんが転職してしまったので仕事中に雑談する相手が減ってしまった。自分は向井さんともう一人 Y 氏との三人、東京から転勤してきた仲間で社内チャットを持っていて、WFH 前はランチとかもよく食べていた。それが割と息抜きになっていたのだが、二人だといまいち話すことがない。そしてオフィスが開くというのに WFH が気に入った Y 氏は会社に来そうにない。会社いってどうすんだ。まあ同僚とランチ食べればいいんだけど、日本語でクダ巻きたいときもあるじゃん。オンラインにせよオフラインにせよ。英語で管を巻くにしても、ちゃんとした人たちが相手だと毒づいたりしにくいのだよね。ニュアンスも制御できないから下手すると Grumpy Non-PC Jerk 発言になってしまうし。

とはいえ同僚は同僚。物理的に出勤し隣席の仲間たちと雑談するくらいがいいのかもしれないという気もする。

オフラインは品行方正にすればいいとして、オンラインではもうちょっと管巻場所が欲しい。チームのチャットは上に書いたような理由でいまいちだし、そのうえ人数が多すぎる。Twitter とかをやればいいかもと思わなくもないが、精神衛生によくないので躊躇してしまう。あと日本に住んでる人とチャットすると意識の重心が日本に近づいてしまって良くない。一方 Twitter にいるベイエリア, US の人はあれはあれでなんともいえない厳しさがあって混じれない。

Facebook はそのへん意外とマシで、最近は週に一回くらい当たり障りのないことを書いてみている。Japanese Parenting Neighborhood みたいの、個人的な趣味という意味では特に接点がない人たちだけれど、そこは生活、親バカねたでも書いておけば良いということにしている。そういうのはあまり blog に書く気にならない。読んでる人の関心とズレすぎるので。FB as a parenting SNS.

個人的な趣味という意味では最近ぼちぼちと HN にコメントを書いており、いま数えたら過去 3-4 ヶ月で 100 件くらいコメントしていた。なお HN のアカウントありユーザ数はぜんぶで 40 万くらい、うち 100 件以上の投稿があるのはおよそ 40,000 件である。つまり 10%-tile くらいはコメントしている(だからなんだ。BQ 調べ。) - HN では自分のことを識別している人は誰もおらず、ただの mob として気楽に雑なことを書けるのが良い。それなりにスレが伸びることもあるし。人としてクソリプは書かないようにしている。といいつつ downvote されたこともあるのでたぶんクソリプしてるんだろうな。

FB も HN もあまり友達と話しているかんじじゃないね。良くも悪くも。

そういえば Message Passing の backstage GitHub repo もたまに会話があり、それは気に入っている。ただ雑談ブログとはいえそれなりに生産の場で、無駄話をする空間ではない。

ただ、こういう限られた目的の場所をいくつも持ち、それぞれのコンテキストに応じて話をすることで、総体としての雑談が達成される・・・というのが健全なオンラインの会話のあり方のようにも思える。雑談のためだけに集うって、Twitter になっちゃうじゃん。そうではなく、まず目的をもったコミュニティがあり、そこに人が集って雑談が生まれる。友達をつくるってそういうことなんじゃないの。Message Passing から新しい人間関係は生まれていないが、方向性としては後一歩な気がしないでもない。そういえばひげぽんは Kaggle をやって交友関係を広げている。ああいうの健全だよな。

誰かと一緒にできる趣味が必要かねえ。

会社のリモート方針が明確になってきた。おもったよりだいぶ柔軟で、たとえばリモートの選択肢を公式に用意してきた。リモートだけでなく、オフィス選択の柔軟さも増した。改めてどう身を振るべきかと考える。

給料。Bay Area を離れると下がる。下がる幅は行き先による。自分たちが良いなと思っていた街、すなわち Boston や Seattle は、下げ幅は一番小さい。とはいえ家賃が安くなって節約できる額よりはだいぶ下がる。というか減俸を CoL 低下で補填できるエリアはほとんどない。一方 Seattle とかは州税がないのでトータルの手取りはプラスになるであろう。街の良さと金銭的な都合良さのバランスが良いのは自分の選択肢の中だと Washington 方面 (Kirkland) である。

まあしかし、引っ越しとか全然やる気がおきない。引っ越の瞬間的な面倒くささに加え、新しい土地で街を知って、子の学校を選んで、新しい人間関係を築いて・・・とかさ。大変すぎ。Seattle とか客観的には Bay Area より住み良い可能性が高いが、それはゼロから比較した場合の話。自分たちはもう何年もかけて Bay Area に適応している。新しい街に適応しなおしてその良さを引き出せるまでに何年かかるやらわかりゃしない。

この大変さは子がいることで増幅され、許容範囲を越えている気がする。夫婦で大人だけならちょっと寂しいとか別にいいけど、子が遊び相手がいなくて荒れたり、学校に適応できなかったり、その影響で家の中が荒んだり、みたいのを心配しだすともう胃が痛くて思考停止してしまう。

世の中のリモートシフトを考えるとこれは残念な現状と言わざるを得ない。Bay Area の優位というのは職の多さだったわけだが、世の中の企業がリモートを受け入れるにつれ他の街でも職探しの幅が広がる見通しが出てきた。だから Bay Area にいる必要性は下がった。むしろ CoL が高い分不利。この傾向はおそらく新しい企業ほど顕著であろう。そんな時代に自分は Bay Area で根を下ろしてしまった。

まあ Bay Area なんだかんだで外国人には住み良いのも事実。いっそ Bay Area 近隣でリモートして海のそばなり森のそばに暮らすのはどうか、と考えるが・・・海(太平洋)のそばまでいくと給料が下がってしまうことがわかった。残念。森のそばは・・・どうかね。Los Gatos くらいなら高給圏内な気もするけれど、Los Gatos に住みたいかと言われると、どうかねえ。森だけでなく海も近くなるな。アリなのかもしれない。

でもねー。めんどさくさいわ・・・。また引っ越しとかいうとすごいカネもかかるし行き先探すのも大変だし・・・。ついでにいうと Mountain View だって別にそんなに悪いところではない。会社への近さが無駄っぽく感じるだけで。

引っ越しに感じるこの億劫さがどこから来ているかと考えると、三月に引っ越したばかりで疲弊・散財しているのが一番の理由に思える。自分だけではなく家族として消耗した。あの次点では引っ越さず、会社のポリシーが固まるまで待つべきだったのかもしれない。

一方、ポリシーは固まったが運用がどのくらいうまくいくのかは未知数。結局「リモートで働くのはキャリア的にいまいち」という結論になる可能性も割とある。職住近接を選んだ自分は事実上そっちの可能性に賭けている。

ただ今にして思うと、良い判断をしたとは言えないね。結果がどうなるかはともかく、自分は内心ではリモートに勝ってほしいと思っていたし、今も思っている。けれど会社の適応力を信じられずリモートの負けを見越し、そっちに身を振った。でもさ、自分が良いと信じていない方に肩入れするのって、腰が引けすぎで楽しくない。盛り上がらない。どっちが勝っても嬉しくない。

子の進学という何年もに一度しかないタイミングをのがしてしまうので、もうしばらく引っ越しはないだろう。臆病さの対価。まあ仕方なし。

それはさておき運用・現実はどうなるのだろうね。会社の発表を踏まえた個人的な予想としては：チーム次第。会社はリモートを（注釈付きとはいえ）認めている。会社のトップレベルの文化はオンサイト寄りのままかもしれないけれど、多国籍企業としてオフィス分散には馴染みがある。

一方で個々のチームのオンサイト志向には差がある。

比較的規模が小さく、地理的な局所性が高いチームはオンサイト志向が強い。自分の今いるチームはこれで、それは当初望んでいたことである一方、自分のリモート悲観の根拠となっている。

前いた電子書籍のチームは TL プラス一人が東海岸にいて、コードレビューとか仕事はリモートっぽい感じだった。そしてマネージャとほか数名が SoCal にいた。だから Bay Area は必ずしもメインではなかったし、チームも割とリモートっぽさがあった。その前のブラウザ部門なんてもっと世界中に分散していて、しかもオープンソースなので昔から家で普通に仕事ができた。こういうチームにいると、リモートへの移行はスムーズに行きそうな気がする。

つまり自分は勤務先がオンサイト志向である以上にチームがオンサイト志向で、そのせいで過剰にリモート化を悲観していた、ような気がする。

そして今のチームがオンサイト志向である事実を考えると、自分の職住近接がまずい判断だったとは必ずも言えない。場所を変えてリモートで働きたいなら、そういうチームに行かないとよろしくない。それがどのチームなのかは現段階ではわからない。リモート志向でない点を除けば今のチームはそれほど悪くないので、リモートを求めてチームを変えるのが良い判断とは、必ずしも言えない。

こういうところでバンと未来志向な博打を打つ身軽さがないのはダサい。でも保守的な家族持ちといたしましては心意気ある若者が未来を切り拓いて会社を良い方に引っ張ってくれるまで待たせていただきますわ。若者たちが会社に愛想つかさないと良いなあ。

読んだもののリンクをブログにしておく試み。最初は substack にしていたけれどあまりに使い勝手が悪いので諦めて WP に帰ってきました・・・。なお今回は Instapaper に溜め込んで放流してなかった分を含むため、量が多め。

• Poor in Tech | Meg Elison
  文章が良い。自分はカネはあるが文化資本が足りてないので、そのへんの poor に共感がないではない。共感されたくないだろうけど。
• Notion API
  ようやく来たが、やはり Markdown を簡単にひっこぬけるような親切デザインではないので足を洗って正解だった感。Export では MD を選べるのに・・・。
• ServiceNow to Acquire Lightstep - ServiceNow Press
  Dapper の親分の会社がよくわかんないサンタクララの会社に買収されていた。
• Mobile Apps at Scale: 39 Engineering Challenges
  よさそうかな・・・と思ってダウンロードしたが、薄かった。
• 'It's a Crazy Issue' – The Bizarre World of Scam Audiobooks
  Audible にはびこるスパムの世界。クレジットが目当てしい。読者的には実害ないけど、奇妙な話ではある。
• The Lure of H Mart, Where the Shelves Can Seem as Wide as Asia - The New York Times
  ベイエリアでも最近人気の韓国スーパー。東海岸発だったのか。なお自分は言ったこと無い。ちょっと遠いので。
• Things you can’t do in Rust (and what to do instead) - LogRocket Blog
  特に新しい話はなかったが、色々ライブラリがのっていてふーんと眺めるなど。
• Half a million lines of Go
  地味にいい話。
• Fierce Nerds
  やたら攻撃的なおたくっているけど、あれは大事なものだよね、みたいな話。そういう攻撃性は野心的なプロジェクトに向けると良いよ、とか若者向けの話だな。
• 🚨 How Basecamp blew up - Platformer
  Basecamp の後光、だいぶ陰っていたけどこれで完全に失われた感。
• Code Reading Club
  こういうのやってみたら面白そうだよねえ。やる気出すにも良さそうだし。
• Eliminating Data Races in Firefox - A Technical Report - Mozilla Hacks - the Web developer blog
  TSAN.... が Rust でも動くとか、すごいね。
• Protocol | Policy: Big Tech whistleblowers can’t just ‘move on’
  やはり告発とかしちゃうと人生かかってしまうよな・・・
• The Child Care Industry Was Collapsing. Mrs. Jackie Bet Everything on an Impossible Dream to Save It. — ProPublica
  つらい話。
• Diving Deep on S3 Consistency
  強い話。
• Crazy New Ideas
  それなりの専門家が一件ヘンな話をしていたら信じてみて良い、というような話。最近よく書いてるな pg.
• Staying on the path to high performing teams. | Irrational Exuberance
  色々断言しているがそんなに根拠を感じない eng management 論。
• When Hackers Were Heroes | April 2021 | Communications of the ACM
  Steven Levy ラブな話と、関連書籍たち。よいが、長い。
• Networking i/o with virtual threads - under the hood – Inside.java
  Java の blocking network IO, virtual thread 導入に向けて nonblocking の syscall ベースで書き直されたらしい。本気だな。
• Editorial: There is no drought - Los Angeles Times
  直視したくないカルフォルニアの現実。
• The 10 Best Practices for Remote Software Engineering | Opinion | Communications of the ACM
  仕事が楽しい (happiness) とか自律的だとか責任感が重要という主張で、そうですね。あんましリモート関係ない気もするが。
• How Jeff Bezos Beat the National Enquirer: Amazon Unbound Book Excerpt - Bloomberg
  Bezos の浮気もろくでもないが、登場人物がぜんぶそれ以上にろくでもなく、ゴシップかくあるべしといった内容。この抜粋から判断するに Amazon Unbound というのはクソのような本っぽいのでやさぐれた気分の時にちょっと読みたい気もする。
• Why I Work on Ads
  なんか HN ですごい bassing されていたが、こうやって自分を説得できないなら ads の仕事とかできなくない？
• A Brief History of Fish Sticks | Innovation | Smithsonian Magazine
  あのジャンクフードの出自。なんか日本にないよね、とかいうクソコメを HN にしたら盛り上がった。
• What Color is Your Function? – journal.stuffwithstuff.com
  async / await をひっそりディスる話。（古い）
• The Things They Won’t Believe – Ryan Moulton's Articles
  文章が良い。
• Software infrastructure 2.0: a wishlist
  開発者向けの UX が重要なんだよ！といわれ、フーン・・・みたいなきもち。（他人事のため）
• 2020 Letter to Shareholders
  ベゾスのお手紙、最終盤。雑に景気のいい話をするという姿勢が貫かれており良い。
• Self-supervised learning: The dark matter of intelligence
  FB の AI の親分による。

ふと、若者のメンターとかしてみたら世間の役にも立つし面白いのかな・・・と想像してみる。まえ karino2 が暇つぶしでプログラミング言語を教えていた。そこまでの時間的コミットは自分には全然ムリだけど、たまにメールとか VC とかでお悩み相談にのってあげるくらいでいいなら、どうなのだろうね。

とおもいそういうメンターコミュニティみたいのないのかなとインターネットを探すと・・・ MENTA といサイトがあり、人々は課金していた！いや、課金とかいいんで・・・もうちょっと low key なやつないのだろうか・・・。よくわかってないが bootcamp 的なやつ周辺に通じるキナ臭さに逃げ出したくなる。

社内にもなんかあるっぽいが、そっちはそっちですごい structured な上にテック企業に入ってくるような人べつにチームの外にメンターとかいらないでしょ・・・という気分もあり、英語はかったるいし、まったくやる気にならない。

プラットフォームはさておいて誰を何故メンターしたいのか・・・と考えると、たぶん業界の歪みみたいなのを矯正する手助けをちょっとくらいできないかと思っているからだろうね。アメリカだとマイノリティを支援するコミュニティとかあるけど、そういうかんじで。日本だと人種的弱者というのは目立つ形ではいないから、女性とかの社会的弱者を支援するのがよいのだろうねえ。となると、何らかの女性向けソフトウェア開発コミュニティの中の人に相談してメンターさせてもらう、とかが良いのかもしれない。なんとなく中年おっさんが女性メンターするとか世間の目がきびしそうだけど、日本相手なら物理的距離のおかげでいかがわしさから守られ、無駄に睨まれることもないでしょう・・・。女性以外の構造的弱者、どういうのがあるかねえ日本。貧困とかはあるな。

しかし女性にしろ貧困者にしろ、そういうコミュニティとかどこにあるのかまったく不明。知り合いのそういうの詳しそうな人とか東京オフィスで仕事でそういう系のをやってる人とかに相談するのが良いのかねえ。あんまし会社と接点のあるところでやりたくないけど、自分の専門性とかどうしても勤務先に紐付きがちなので、避けがたい気もする。

もう一つは普段話しているのとは違う人と話すと発見があるのではないかという期待。ただランダムに話し相手を得るのは難しいのでメンターシップという形でならいいかもなという。しかしいざ文字で書いてみると傲慢な発想だね。おまえはツイッターでもしてろという自己批判が頭をよぎってしまう。

とか具体的に考えると段々腰が引けてくる・・・。お前は人のことをメンターするヒマとかあるのか的な・・・。メンターとか気のせいではないか・・・・。

なんとなく自分がいちおう形式的にメンターっぽいことをした現勤務先のことを思い出してみる・・・と、別にメンターとかいらなかったよねあのひとたち。一人はもはや自分より三段階くらい偉くなっており、もう一人はさっさと会社をやめてスタートアップで CTO とかやってる。

自分がなにをメンターしたのかほとんど思い出せないしたぶんほとんどメンターしていないが、たぶん当時の仕事である WebKit なり Chromium なりの残念エリアで時間や体力を無駄にしないように「それは単に残念なだけだよ」的な指摘をしていたのだろうな。それすら必要だったのか怪しいが、ただ眼の前のコードやプロジェクトの残念さを「それは単に残念なんですよ」と教えてあげるのは、その場所に前からいた人ができる数少ない意味のあることに思える。「残念だからほっといたほうが良いよ」ではなく「残念だからなんとか出来たら良いね」といいたいものだけど。前者を言われてもイラっとするだけだったりするじゃん。実力者であれば特に。

更にさかのぼり新卒で入った会社ではすごいメンタリング行為をしていた気がするが、ひたすら謎の偉そうな説教をしていたやんわりとした記憶が・・・黒歴史フィルターによってぼかされてよく見えないですね。たぶんすごい残念なことをしていた気がするけど、若さということでひとつ・・・。

本題にもどると、自分はコミュニティでのメンターシップみたいなものをまったく理解していないので、やるにしてもそういう話について書いたものを読むとかが最初のステップなのかもしれない。

Message Passing Blog の GitHub で進捗がない記事 (issue) をみつけてコメントする bot を作った。こういうのをささっと作れるようになっておきたいもんです。使ったものメモ:

• Python で書いた。好き嫌いではなく慣れの都合。
• 型がないと辛いので pytype を入れた。他の type checker と比べて特段出来が良いわけではないが、仕事で同じのを使ってるので。
• Cloud Run に deploy し, Cloud Scheduler で週に一回つつく構成。
• Dockerfile のことを考えたくないので Buildpack にした。
• GCP のページをみたら "CICD できるよ" というので設定した。Cloud Build, 前は GitHub から引っ張る支援とか一ミリもなくてすげえ苦労した記憶があるが、今は勝手にやってくれる模様。ポチポチするだけでコミットから deploy されるようになる。

Scheduler の設定に Terraform を使おうかと一瞬おもったが、めんどいので諦めた。次はやります・・・。

こういうのをさくっとできる静的型言語が欲しいが GCP の buildpack は対応言語が限られすぎだわ・・・・。Kotlin を動かしている人がいるので、これを真似するのがいいのかもしれない。ただこんなこまっちい 200 行くらいのコードに IDE 使いたくないなあ。

最近の人事考課でチームの二人が Staff というレベルに promote された。自分のチームは TLM (TL+manager) になって下に人がつかないとえらくなれないと思っていたが、この二人はピンのまま出世。できたのか！まあ二人とも良い仕事をしている。一人はサーバサイドからきたひとで、ある時期からアプリのコードを書くのをやめてデータエンジニア仕事をするようになり、SQL を書きまくって野ざらしになっていた user stats の立て直しをほぼ一人でやってのけた。めちゃパイプライン持ってる。もう一人は TL"M" ではないがリサーチ部門のアルゴリズムや新機種のカメラ構成をアプリにインテグレートする仕事の TL. 事実上二人ぐらい引き連れている。

なにはともあれ頑張ればこのチームでも部下なしで出世できるのかと感心した。出世というのはチームの勢いとかも関係あるので、勢いあるうちに出世すべく遊んでないで仕事頑張ったほうがいいのかな・・・などと考えつつ Amazon をぶらぶら(悪癖)していたら Staff Engineer: Leadership beyond the management track という本が目についたので読んでみた。

Stripe とかで働いていたテック企業文化圏の著者。割とよく書けており、自分の知っている Staff のイメージに合致しつつ理解を深める役に立った。まず Staff というのがどういう仕事をしているかを俯瞰する章があり、そのあといかに Staff に出世するかの章があり、最後に著者知り合いの現役 Staff (Staff-plus) たちにインタビューしている。インタビューは数が多すぎてダレたが、ほかはそこそこ興味深く読めた。(根本的にダイヤモンド社的な本である点には目をぶつられたし。)

一方で, そんながんばってまで Staff になりたいのだろうかと改めて考えてしまった。

自分がなぜ Staff になりたいのかと考えると、大きな理由は二つある。一番の理由は金銭的なもの: 出世すれば給料があがる。Sony のミラーレスが買えるし家も買える、かもしれない、みたいな。付随的な理由としては人々から認められたいという見栄。つまり「カネと名声のため」みたいな話なわけで、プログラマとしてどうなんだそれは。オンナがないだけマシかもしれないが...

文中では、もうちょっと高尚(?)な動機としてたとえば重要な意思決定に関与したいとか、影響力の大きな仕事をしたいとか、チームや組織の成長や文化に寄与したいとか、そういうのが挙げられている。そういうの・・・あんまし興味ないね・・・。

興味ないというと言い過ぎだが、肩書を通じて仕事したくないじゃん？重要なコードを書けば自然と影響力が増えてしまうというものじゃん？ちがうの？著者は肩書によって呼ばれるミーティングもあるし、周りからの視線も変わるのだよ、と書いている。そうかもしらんけど、別にミーティング呼ばれなくていいですよ・・・そして視線も変わんなくていいですよ・・・こっちくんな・・・。

いまいる部署、ある時期から各種ミーティングの議事録がチームのリストに流れてくるようになった。そして最近も重要性の高そうな緊急プロジェクトのミーティング議事録が流れてきた。そこにはたしかにチームの Staff-plus たちが召喚され意思決定している。が、緊急度高すぎて近づきたくねー。しかも AI (action item) がひたすら stakeholder に話をして合意を得るだとか実際に実装する担当者を探すだとか、そんなのばっかり。やだよ・・・。この本にも "Present to executives" というセクションがあるけど、そんなの上司や PM に押し付けて逃げる以外にどうしろというんだ。

書籍は冒頭の章で 4 つの Staff archetypes を列挙している: TL, Architect, Solver, Right Hand. そしてそれぞれのありがちな一週間のカレンダー(時間割) みたいのが載っている。ミーティングだらけ。そしてこれは自分の知っている Staff-plus のカレンダーとよく似ている。つまり偉くなるとミーティングが増える。ミーティング以外もレビューとかが増える。コードを書く量は減る。でもコードを書かないと肌感覚がなくなってしまうので、無理やり重要じゃないコードを書いたりする。カレンダーに "coding" とかいってミーティング避けのエントリを入れたりしちゃう。そういう TL よくいえるよねー。大変そうだねー。週に4-5 回のミーティングで既にイヤさが上限に達しているわたくし、これ務まるのか。

閑話休題。

出世の章では "Staff-Projects" の重要性 (の真偽) を議論している。Staff-Projects というのはその人の Staff 力を示すような難しくてインパクトのあるプロジェクトで、そういうのを完遂してレジュメに載せることで出世審議会をパスできる、と信じられているもの。

著者は、Staff Project は very nice to have だが会社によっては必須でなく、チーム間の顔を繋ぎつつ意思決定に関与する glue work みたいな成果を評価される場合もあるとしている。そういうのは・・・あるかもしれないけどそこまでして出世してどうすんだ。部下のついてないマネージャみたいなもんじゃん。

Staff-plus は "leadership role" なのでチームを牽引する必要があり、コードよりは対人関係の能力が重要だという。だからそういう code-less な Staff もありうる。とはいえ個人的にはやりたくない仕事の集合に見える。一方で自分はいまなぜか窓口業務を評価されてしまっているので、下手に仕事をがんばるとそういう code-less 路線に近づいてしまう。やばい。コードを書かなければ！

ところでたまにやたらコードを書いてる Staff-plus とかいるけど、なんつうか、明らかに残業してるね。自分も独身若者だったらコード書きつつ出世の一つもしたいところだが、妻子あると課外活動とかできないのだった。ブログとか書いてますがそれはいいのかというと・・・残業に値する仕事というのはなかなかないということです。クビになりそうか、運命の天職か。後者でないのは残念だが、前者でないことへの感謝を強調したい。

Leadership はさておき、自分は日々の firefighting および procrastination に忙殺され (後者は忙殺じゃないですね) 「よく考えてインパクトのでかい成果を出す」というのに失敗しており、これはよくないなと改めて思った。出世はさておき、きちんとデザインして書いたものをバーンとキメないと、なんというか、面白くない。本来は余裕があるはずの年末年始前後も、結局 procrastination と distraction と poor judgement を積み重ねて何も成果を出せないまま過ごしてしまい、また丸腰で火消しに追われる季節に突入してしまった。本来は冬の間に武器を揃え、打ち寄せる火種を瞬殺できるようにしておかないといけなかった。

一年くらい前はそういう火消しインフラの整備とさらなる高速化とどちらを優先すべきか迷いがあったが、その後の経験や、この本のインパクトに関する議論などを照らし合わせ火消しインフラ整備をやる方が明らかに正しいと納得した。そういうインフラが出来てこのクソのような火消しの日々から開放されるならいいじゃん。出世は無関係に。

火消しインフラはしょぼい気もするが、とにかくプログラマとしてなんらかのまとまった成果をだし、その成果をスケールするために人を巻き込む必要がうまれたら、税金として自分の成果を advocate するのはやぶさかではない（気がする）。そして税金を払った暁には給料に還元していただきたいので、出世を目論んでもいいかもしれない。ただ他人のためにそういうのをやってあげるのは、英語苦手なアジアン中年の仕事じゃねーわ。得意な人に任せたい。

つまり日々の雑事に追われすぎず大局観をもってバーンとクールなコードをキメる。これがプライオリティ。出世に惑わされてはいけない。これは何度も道を外れては立ち戻る同じ結論なわけだが、カネの力は強いのでこうして繰り返し自分に言い聞かせないといけない。

一歩さがって、なぜ自分は重要な意思決定とか影響力とかに興味がないのか考える。

一つは、組織がそこそこまともなおかげで肩書とかなくても行動を通じて影響力を行使できると信じているからかもしれない。自分以外の人手を借りようとすると多少は権力いるかもだが、自分自身の仕事についてはエラくならなくてもそこそこ autonomy がある。むしろいまのチームだと偉くなると duty 発生しまくりで、期待する autonomy があるのか怪しい。すっぱい葡萄ならいいんだけど。

二つ目は、英語できないからだろうね。自然言語を通じて影響力を行使するみたいな自分の不得意分野にわざわざ踏み込んでいく気が起きない。苦痛とフラストレーションしかなさそう。そういうのがパリっとできるならやる気も起きるのかもしれないが。

そういえば東京オフィスを脱出したいと思った動機の一つは、下手に東京に長居していると自分より英語やコミュニケーションが苦手な人（いるのだよこれが・・・）のかわりに窓口業務 TL をやることになりそうな予感があったせいもある。当時の東京にはそういう窓口 TL が多かったのだった。今は知らないけど。

更にさかのぼり、東京の中小零細で働いていた頃はというと、別に特段意識しなくても leadership とか influence とかが発生した。それを taken for granted で生きていた。その傲慢さは反省してしかるべきだがそれは宿題にするとしてなぜ、勝手に発生したのだろうね、権力。日本語のためだけとも思えない。そういえば零細で働く前の中小企業二つでは権力なかったわ・・・と考えると英語のためだけでなく大企業だから権力を志向しづらい面もあるのだろうなあ。大企業、偉くなるの大変。そして下っ端はラク。給料上がらないのは残念だけど、ボンクラのトレードオフとしてはまあまあ妥当。

Caveat として勤務先の Staff は先の本にでてくる Staff-plus ほどエラくはない気がする。バーンのいい仕事を決めた暁に出世できるなら別にそんなに困らないかもしれない。

あーあ、いい仕事をして責任や影響力は据え置きで給料だけ増えないかなー。

今週は Teacher Appreciation Week というやつで、一週間かけ teacher に感謝の意を表明することになっているのだった。ようやく終わった。

例年だと room parent という学校指名の TL 的な親が取り仕切るのだが、今年は COVID の混乱のせいで指名がなされておらず、奥様は group gift に contribute いたいが自分で取り仕切るには忙しすぎる・・・とかいうので仕方なく取り仕切りを引き取った。プリスクール同級生の親にメールして、集金やら何やらを募ったりする。

しかし出遅れてしまったのでもう個人的にギフトを買ってしまったという親も多く、集金を締め切った後に「今週忙しくてメール読んでなかったわ間に合う？」という親も数名おり、当然返事のない親もおり、そういうのに色々返事をしたり、group gift の収支などを報告したり、はー。ただでさえ socially awkward な上に cheer する語彙にも乏しく、そのほか fairness などで気を使う判断も多く、メールを一通書くたびに精神力を削られた。親としての図太さを鍛える練習だと思ってやったけど、もう来年はやりたくない。そして一週間とかやめてほしいわ。Teacher Appreciation Day くらいにしてちょ。

集金する側に周ることで、この手の contribution に関する額（のばらつき）を理解できたのはよかった。

なおインターネット調べによると公立学校では一人あたり $50, グループからだと $150 が cap らしいが、一次資料は発見できず。そしていかにも誰も気にしてなさそうである。資本主義よ。

Working Backwards: Insights, Stories, and Secrets from Inside Amazon

Amazon の初期の偉い人が The Amazon Way を逸話混じりで語る本。The Amazon Way も各種エピソードも面白かった。

Working Backwards という慎重さはソフトウェアだけでなく流通とか手戻りコストの高い部分がビジネスにあるからこそ有効だと思うが、一方ででかい会社はどこもなにかしらそういう部分があるので、会社がでかくなった時にきちんと機能する慎重さを持っているのは強い。ふつう慎重になると麻痺してしまいがち。あと single threaded leader とかも面白かった。片手間で仕事進まないとかあるあるすぎる。スライド禁止の話も、ほんと勤務先の連中に言ってやってくれと思う。ただ下々には six-paper の大げささが必要な場面はそんなにないだろうと思う。重要なビジネス意思決定のための決闘資料だな。Output でなく Input を見るというメトリクスの話はなんともすごい先進的で、はー・・・というかんじであった。そういう proxy で大丈夫と言えるのは、なんかあるよなあ。

こういうプロセスを敷けば Amazon じゃなくても成果が出せる、というわけだが、そこはんなわけねーというかんじ。一方で ex-Amazon の人というのはいっぱいいるはずで、そういう人が牛耳ってる会社だと似たような感じになる気もして、どうなのだろうね。Seattle の方にいけばそういう会社いっぱいあるのあろうか。Bay area だとそれこそ ex-G なり ex-F なりの会社はいっぱいあって、そういう人は程度の差はあれ元勤務先-way を持ち込むものだが。

それにしても Amazon ちゃんとしてんなーと思う。たとえば Google について書かれた本を読むと、こいつら楽しくやってんなと思うことこそあれこいつら儲かりそうだなという感じはない。従業員体験は重視してるが株主利益や顧客利益についてはあまり話がでてこない。そういうのがいいと思っていたこともあったが、すくなくとも現状を見る限りでは Amazon Way の方がだいぶ上手く行っている。

なぜなのだろうね・・・と考えるに、ゼロ年代というのはインターネット黄金時代で、掘れば掘るほどあたりが出た。だから熟考して手を打つより色々やってみる方が良い面があった。でもその黄金時代は 10 年前に終わってしまい、真面目に考えてやらないといけないという（普通の）世界になった。Google Way はゴールドラッシュに乗るのには向いていたが、そのあとは厳しかった。

あるいは DHH のいうように産油国だった、ということなのかもしれない・・・と書いたが、金を石油に置き換えればだいたい同じ話だな。関係ないけど DHH, Hey の宣伝もかねてぼちぼち blog 書いてるじゃん、ということで sub しておく。

Never Split the Difference: Negotiating As If Your Life Depended On It

引越しに際し大家とのメールでだいぶ消耗したので、そういうのに消耗しないようになりたいなと読む。Crucial Conversations みたいな話だが、FBI の身代金交渉人という著者のバックグランドにバイアスされたツイストとポップカルチャー的な雑さが新鮮だった。交渉テクニックの話以前にでてくるエピソードがぜんぶ凶悪犯との身代金交渉なのでめちゃ面白い。

読んだあと、自分が日々面している交渉相手は大家より我が子だなと気づいた。そして子供との会話は理不尽さとか感情的っぷりが身代金交渉に通じるものがある。心を落ち着けて挑みたいものでありますな・・・。

Insight: The Surprising Truth About How Others See Us, How We See Ourselves, and Why the Answers Matter More Than We Think

内省ってあんまし役に立たないよね、というような話。日記をながなが書くとか無意味な自己非難で鬱っぽくなってしまうよねとか。そういえば CBP とかそういう話だったな・・・と思い出す。そんではどうしればいいかというと、信頼できる相手に的を絞った問いを投げかけなさいね、という話をしている。自己啓発ジャーゴンでいうところの Personal Board Of Directors というやつに近い。（このジャーゴンどこ発祥なのだろうな・・・）

Caffeine

カフェインに関する雑談。Audible Original というやつで、Audible にしかない。割とどうでもいい内容だけど二時間くらいなので、長い podcast だと思えば悪くはなかった。

The Tyranny of Merit: What's Become of the Common Good?

実力主義がはびこってしまったせいで、世の中ずいぶん生きづらくなっちゃったよね、というような話。実力主義の高学歴者が回りにいる身としては、そうですね、と思う。アカデミアの哲学者だけあって・・・というか Sandel は名が知られてるだけあって書き手として優秀で、過去の哲学的解釈とかもレビューされており、よくかけてる。説得された。

The Enchanted Hour: The Miraculous Power of Reading Aloud in the Age of Distraction

読み聞かせの意義を説く本。巻末の子供の本リストは参考にして何冊か買った。

カフェインをやめて半年以上たつ。Why We Sleep を読んでやめて、WFH のストレスで再開し、しかしまた caffeine crash がおきたのでやめ、今日に至る。厳し目のドライブ（山道、長距離）がある日は一杯だけ飲むことにしている。

しばらく厳し目のドライブがなかったあと、こないだ Yosemite に行った折に行き帰りに一杯づつ飲んだところその威力を痛感。もうちょっと仕事の足しになるよう使えないかなーと考え始める。

うかつに再開しても crash するだけだしなすこし調査でもするかとまず Caffeine という薄い audiobook を聞く。これは単なるうんちく本で意思決定の役には立たなかったが、著者がカフェイン断ちをしてみる下りが長々書かれていて微笑ましかった。もうちょっとなんか本ないのかな・・・と探すも、よさそうな本が見当たらない。辞めたい人向けの話はあるのだが、こっちはもうやめてんだよ。

そんななかふと Confessions of a Caffeine Addict というカフェイン中毒者互助団体談話集みたいな本が目に入ったので気まぐれに読んでみた。が・・・やべえー！カフェイン中毒やばい！アル中とか他人事すぎてあまり共感がないが、カフェイン中毒は他人事じゃないエピソードもある。コーヒーがぶがぶ飲みながら働いてたら病院運ばれた、とかプログラマそういう人いそう。そして副作用。腹痛、下痢、胃潰瘍、頻尿、不眠、不安、短気、手の震え、などなど一時期の自分として身に覚えあるわ！おまえだったのかカフェイン！たぶん濡れ衣も混じっているけどいま全部ないもんな。

そのほか Soda (Coke) 依存や Caffeine Pill, energy drink 依存の人もでてきて、これもプログラマにいそう。というか一時期 soda addict 手前だったことがあるような自分・・・。

やっぱりカフェイン復帰とか気の迷いすぎるのでは？と思う一方、さすがにこの談話集は極端すぎるだろうと気を取り直し、本は諦めてインターネットを探す。コーヒー屋などカフェイン業界の息のかかったサイトに SEO されまくっておりいまいちいい情報がないなか、なんとか Mayo Clinic, Science Direct, NIH とかまともっぽいサイトの記事に一通り目を通してざっくりと理解を正す。

とりすぎのダメージなしに向精神作用を仕事に活かせるようカフェインを摂取することは可能なのか？どういうメンタルモデルで考えればよいのか？

• カフェインは addiction (reward system への介入) はないが dependence (withdrawal symptom) はある。この区別に実用上どのくらい意味があるのかわからないが、ざっくりいえば他の薬物よりハマり度は低いがハマることはある。
• Withdrawal symptom はカフェイン摂取を三日続けたあたりで発生する。
• Tolerance があり、日常的に飲んでると段々効かなくなる。つまり効き目を維持しようとすると段々量が増えていく。ただし安全な量の範囲であれば完全に効かなくなることはない。
• 「安全な量」の目安は 400mg/day 以下で、これはいわゆる "4 cup ぶん" だが、ここでいう 1cup は 150ml くらいなのでふつうのマグ (300ml) だと二杯。まあそんなものだろう。そして個人差はあるという。
• Tolerance ができるので、心拍への影響などは長期的には無い、らしい。はっきりしないこと: 全ての作用・症状に tolerance があるのか。つまり副作用も体が慣れて小さくなるのか？というと、たぶん tolerance ができるものもあるしできないものもあるのだろう。つまり徐々に摂取量を増やし続けていくのは、バーンと急激に増やすよりは安全だが、完全に安全ではなさそう。
• Tolerance の獲得にかかる時間は・・・よくわからないが一日から数日とされている模様。
• 副作用の中でも睡眠へのインパクトが一番懸念されている。なので tolerance があろうがなかろうが午後は飲まない方が良い。
  • カフェインのせいで寝不足になり、その眠さを誤魔化すためにまたカフェインをとる、とか悪循環。
• Withdrawal symptom は最後のカフェイン摂取から 12-24 時間後くらいに出てくる。つまり・・・ランチの時にカフェインをキメると寝不足じゃなくても翌朝は厳しいのでは？
  • はっきりしないこと: Withdrawal symptoms と Tolerance は関係があるのか、つまりたまに一杯飲むだけの人も withdrawal symptoms があるのか？Anecdotal には withdrawal symptoms と tolerance の強さは相関するように見える。
• 徐々に量を減らしていけば Withdrawal symptoms は回避しつつ quit できる。

といった前提でいくつかの摂取パターンについて考えていく。

• 一日コーヒー一杯 (カフェイン 200mg) 摂取
  • Pro: Tolerance はできるので最大の効果が得られるわけではないが、何らかの効果は得られる。
  • Pro: 午後は飲まないことにすると睡眠へのインパクトは、ゼロではないが控えめ（ほんとに？）
  • Con: 最大の効果が得られるわけではない。
  • Con: 翌朝が withdrawal symptoms で厳しい。
  • Con: 同様に withdrawal symptoms を防ぐために毎日飲まないといけない。
  • Con: 午前中のみ、所定量のみという決まりを毎日守り続ける規律が必要。
• 期間限定で Tolerance を上書きしつつ毎日飲む:
  • Pro: Tolerance を overdose で克服できるため、効能が最大化される。
  • Pro: 期間が済んだら quit できる。
  • Con: 睡眠へのインパクトは、所定量で飲むより多そう。心配。
  • Con: 副作用も避けられるか不安、というかたぶん副作用あるね。
  • Con: Quit するのはそれなりに大変。
  • Con: 「期間」をどう定めるかが不明。なんとなく一ヶ月くらいなら乗り切れる気がするが、あんま根拠なし。
• 週に一回、コーヒー一杯 (カフェイン 200mg) を摂取。(今やってることに近い)
  • Pro: Tolerance ができにくいので、いつも最大に近い効果が得られる。
  • Pro: 睡眠の問題もほぼなさそう。
  • Con: 効き目を得られるのが週に一回だけ。
• 週に三回くらい、コーヒー一杯 (カフェイン 200mg) を摂取。
  • Pro: Tolerance は、週一回よりはできそうだが隔日ならたぶん under control にできる。Withdrawal syndrome も同様。
  • Pro: 週に三回効き目が得られる。
  • Con: Tolerance / Withdrawal Symptom 獲得までのマージンが薄い
  • Con: 週三回というリズムは週一回とくらべ実施がトリッキー。

とすると・・・

• 一日一杯モデルは、規律を守るのが自分にはきびしそう。
• 期間限定モデルは、基本的にはダメだがたとえばクビになって就職活動するから LeetCode をやる、みたいな時にはいいかもしれない。というかクビに限らず仕事のオフシーズンにそういう短期集中トレーニング系をやるにはいいかもしれないな。魂削りそうだけど。
• 週に一回モデルは、今やってることをもうちょっと explicit にするかんじ。週末きびしいドライブがなかったら月曜日に一杯キメて良いことにすると、今よりもうちょっと恩恵を受けられる。
• 週に三回モデルは、これより多くキメられる。しかし週一回よりは意思の強さを要する。危うさに近づいていく漠然とした不安ある。

何事も節度を持って楽しめる人とそうでない人がおり、色々な事例から自分は節度を保てないサイドであることがわかっている。攻めないほうが良い。週一回が無難。もうちょっと踏み込んで週三回。あいだをとると平日一回週末一回で、週末のまなかったら月曜に一回、とかそういうかんじかなあ。あるいは子と添い寝をした翌日のみ、とかだろうか。子と添い寝した翌朝はジョギング実施に失敗しがちで脳内麻薬不足気味だし、これがいいかもしれないなあ。

ところでプログラマというのはコーヒーをコードに変換する機械と自称することがあるくらいカフェインキメキメな職種である。先の中毒者談話集を読んで思ったこととして、ステレオタイプ的プログラマの生態や言動は、実はカフェインの副作用として説明できるものも多いのではないだろか。Night owl で朝おきられないみたいなわかりやすい例だけでなく、いわゆるイキリオタク的なヒステリック会話スタイルみたいのも、妙に集中してコード書いてて話かけても反応ないとかも、カフェインキメ過ぎによる narrow-focus, short-temper で説明できる・・・ときもあるんじゃないの？そういうのは personality として済まさずとりあえず一旦カフェインを止めてみると明らかになることもあるのではなかろうか。余計なお世話だが。

まあキメキメ勢を横目に見つつしばらく自分は週に 2-3 杯で暮らしていこうと思います。なお今日は山道ドライブがあったのでランチのときに一杯キメているが、案の定眠くならない。やっぱ睡眠への影響あるんじゃね？

最近日本語のウェブを見すぎて精神衛生を損ねてよくなかったと反省し、ずるずる見るようになっていた日本語のウェブを見るのをやめた。ただ英語圏は見ているだけだとなんか寂しいというか、あまりに盛り上がらない。ので HN にコメントを書く試みをはじめている。

最初のきっかけは NYT をやめたついでに読むもの探しをしようと Ask HN したのがきっかけ。これがまあまあよかった。

英語のウェブは言語障壁のおかげで感情を害しにくいのが良い。勤務先の残念事例、および逆に不当なディスられ、はそれなりに心が傷まないではないが、そういうのはスルーしてもっとどうでもいい話にどうでもいいコメントをつけていきたい。カルマ貯めるぞ、みたいな。

しかしブラウザネタしかコメントすることがない現実はだいぶイマイチだなあ。もうちょっと乗っかれるテックな土俵を増やしていきたいもんである。Android ネタとかまったくないね HN.

追記

その後もチマチマとコメント活動を続けた結果カルマが 100 を超えた！というあたりで我に返る。なにやってんだ自分。いつの間にかカルマを稼ぐ gamification にハマっていた。なにか言いたいときにだけ書くようにします。たまに雑なこと書きすぎて downvote されたりもするけれどあたしはげんきです。

ただまあ、会話に参加する楽しさってあるよね。HN は follower とかいないし自分も存在感ゼロだし、Twitter よりこっちの方がいいな。時間の無駄であることに代わりはないが。

追記 (11 月)

その後もたまになんか書いたりしていたらカルマが 700 を越えました。hahaha.

雑談できる小さい group chat か何かがほしいなと思っていたので、それについてもうちょっと braindump してみる。

結論としては: Facebook が一番近いが Facebook だと自分はダメだな。これは FB 嫌いとかそういう話ではなく、単に欲しているものと違う。（自分は Twitter とくらべると FB はそんなに嫌いでないし。)

自分が欲しいのは group chat 的な private communication channel だが、チャットは同期的すぎてよくないと思っている。すぐ反応しなきゃいけないのストレスだし、暗に自分がそれを期待してしまうのも嫌。

あとテキストも一行ではなくちょっと長いのを書きたいときがある。このテキストとか。

Group chats の対称性もなんとなくスケールしない気がしている。つまり、自分が気兼ねなく話せる相手と、その相手（たとえば向井さんとしよう）が気兼ねなく話せる相手の集合は完全一致ではない。つまり自分が誰かを group chat に invite するというのは、相手にとっては observe しなければいけない channel が一個増えるだけである。FB Messenger の group chat とか、どの channel/room に誰がいるのか割と混乱しがちで、投稿するとき投稿先を間違えないか若干ストレス。自分の FB group chat なんて３つしかないのに annoying なのだから、これまともに社会性ある人だったらもっと沢山あるわけでしょ。そこに一つ増やしてとか言えないわ。ある種の人々はそういうのストレスじゃないんだろうけど、自分が嫌なことを他人にやりたくない。

Facebook はその点おおむね private で、チャットよりは非同期で、コミュニケーションは非対称で、チャットよりは長文もかける。

ただ現実問題として自分の Facebook にいる人々は特別気兼ねなく雑談したい相手ではない。もうちょっと他人の方が多い。つまり public ではないが private というほどでもない。あと自分の closed friends はそんなに FB にアクティブでない感じがする。投稿してないだけで見てはいるのかもだが。ついでにテキストもそんなに得意じゃないよね。ブログとかに out source する前提だから。

そして Facebook に滞在する時間を長くするのは不安。他のどうでもいいものに lure されてしまいそうだから。

Twitter で protected な sub-account をつくり、知り合いに follow を求めるのはどうか。Twitter やってない勢というのもいるが、そういう人はどのみち雑談とかで時間を無駄にしたくないでしょう。その態度は尊重したい。長めのテキストはスレッドを使えばいいというのが時代の選択ぽいのでそれを受け入れる。そして知り合いを follow はするが mute しておくことで traffic は少なくできる。

これは、自分が雑談したい相手にとってはたぶんベストな選択だが、自分の Twitter 近づきたくない instinct と相性がよくない。もっというと、良識ある人々がソーシャルメディアから離れつつある今日にノコノコ入っていくとか、なんかすごい間違ったことをしている感じしない？むしろその態度こそが groupthink であり、ツールとして Twitter を使えるならその方がいいのではないか。

たぶんそういうアカウントをつくると自分の箇条書きブログ "Fragments" は用済みになる。いま Notion で書いている Fragments はどのみち公開しないつもりだったので別に Twitter に乗り換えても自分の発言アーカイブとして劣化はしない。むしろ時系列データに不向きな Notion よりマシな可能性すらある。

Twitter の UI は根本的に気を散らしに来るので、それも問題。これは 適当な Chrome extension を使えば解決するかな？もちろんモバイルはナシ。

あ。でも Twitter は自分以外が protected じゃないから雑談できないじゃん。はい解散・・・。

強い心を持って public Twitter で雑談するのはどうか。俺はソーシャルメディアの圧力に負けない無敵の人になる！そして誰もフォローしない！みたいな。でもこれは仮に自分が無敵の人になれても（この仮定からして Big If だが）自分の話したい相手がそうなれるわけではないからねえ。若者ならいざしらず、おっさんの気兼ねない会話には privacy 必須。

メールはどうか・・・というと、今のお手紙活動が概ねそれである。ただ一週間に一度だとちょっと雑談としては物足りない気がしませんかね。しかし粒度を上げるとうざいのも事実。

何らかの新しいアプリなりプラットフォームを使うのは避けたい。みんなそんなに暇じゃない。既に人々が使っているであろうメディアに便乗させていただき、かつなんらかの工夫によってそうしたメディアに自分が感じている問題を mitigate したい。

ふつうにブログはどうか。kzys のブログとかはまあまあ雑談できているように見える（対話あがるのかはわからないが、内容としては。）パブリックなブログは、自分が無敵の人になれば返信のメディアは自由なので割となんとかなる面がある。

ただ Twitter とかで会話されても参加したくない。もうちょっとプライベートな場所で会話したい。そういう意味で newsletter はいいのかもしれない。そして substack がいつの間にか private mode をサポートしていた。Newsletter は頻度の高いメールのウザさを完全には解決できないが、直接送られてくるメールに比べると押し付けがましさは低い（無視すするのに抵抗がない。）それだとみんなで雑談する感じにはならないが、お手紙活動の経験によるとそれは許容して良い面もあるし、privacy という意味での良さもある。つまり自分のお手紙送付相手同士が等しく親密なわけではないから、内容によっては 1:1 の方が会話がやりやすい。

箇条書きブログ Fragments およびこのブログとの棲み分けはどうするのか。わからない。まあ自分のブログとかガチで誰も読んでいないのでほっとくというのが一つの選択肢である。あと substack はいちおうコンテンツの export はできるようなので、公開するものについては何らかの形でタグをつけておきがんばってインポートすることもできなくはない。現状だって WP からインポートしているわけだし。箇条書きの方は・・・どうだろうね。書き溜めておきコピペするとかだろうか。あと substack editor とかちょう使いにくいのだよねー・・・。

Substack はさておき、なんらかの private blog から newsletter-ish なメールを送るというのは一つの切り口かもしれない。

Blog / newsletter の問題点は、会話が非対称だということ。つまり、他の人の雑談も聞きたいのだけどなーという。しかしこれは概ね phantom problem である。つまり誰もそういう問題を抱えていない。みんな普通に Twitter なり Blog なりしている。

ただ完全に phantom というわけでもなく、private group chat ほしいねという人がまわりに一人いた。パブリックになんか書く敷居が高い知り合いだけを集めてすごく小さい group chat を作るのは、いいのかもしれない。なぜならそういう人は自分の周りに沢山はいないので、場が増えすぎる問題はない気がするから。

結論としては:

• 今のお手紙活動をもうちょっと普通の newsletter-ish にできないか調べる/考える。
  • これはほんとうに雑談につながるのだろうか・・・。
• Private-focused な知り合い数名と Discord あたりで chat できないか、誰が興味ありそうか考える。

それにしてもこうやって自分の communication channel を tuning するのに時間や神経を使うのはどうなのだろうね。もうちょっと雑に生きたほうが良いのではという気もする・・・。

今月はコードを書くプロジェクトだったが、実質的には何も成果はないまま終わった。要素技術をつついたりはできて、それはまあ進捗といえば進捗。あと当初考えていたデザインは大げさすぎることにきづいたので、ずっと単純化して作るよう考え直した。が、そこでおしまい。

この進捗のなさは無能さと呼んで良い。そして自分が無能なエリアでなんかして無能さを実感するのは余暇プロジェクトの機能のうちなので、がっかりを受け入れておく。

このプロジェクト自体は継続したい一方、税金とか引っ越しとかで余暇に割ける時間も精神的余裕もなかった。税金はおわったが引っ越しは来月前半まで食い込むし、仕事もデスマフラグが立ってしまったし、来月もコードを書くのは難しそう。三月は一時停止で、かわりに本なりなんらかのまとまった資料なりを読むことにしたい。手を動かして進まないのはいいが、動かしたい手を動かせないのはストレス。

むかいさんとかずよしが F# を触っているのを見て、天の邪鬼的にもうすぐリリースされるという Scala 3 をやってみたくなり本を冷やかす。なおこの本よりは本家サイトのドキュメントの方が簡潔でよかった。

言語は、シンタックスも型システムもけっこう大胆にいじって Python 2 -> 3 どころではない大改造ぶり。資料を読む限りでは良い変更に思える。これならあと 10 年戦えるかも、という気にさせられる。

が、オンラインで Scala 3 の話題を探すと全く盛り上がっていない。Dotty とかいってプロジェクトが始まった頃はもうちょっと人々が話題にしていた気がするが、今となってはちょこちょこ新しい言語機能を紹介してる人がいるくらい。

そもそも Scala 自体の話題を見なくなった気がする。HN とかテック全体の話題を扱うフィルタを通すとまったく目につかない。たぶん Scala の Reddit なりなんなりを見ればそれなりに進展はあるのだろうが・・・。10 年くらい前に Twitter が Scala 使うぞ、Spark も Scala だ！とかいってた頃と比べるとまったく盛り上がっていない。

いま余暇でやろうとしているプロジェクトに HTTP のエントリポイントが欲しいので、勢い余って Scala で書いてみようかな・・・とフレームワークを探すと、全然新しいのがない。未だに Play とか言ってるのはどうなの・・・。全然 Microservices / Cloud / Serverless みたいな路線にキャッチアップしてない。いや Akka あるけどさ、Akka で Microservices をキャッチアップとみなすなら Erlang でもいいわけで、そうじゃないでしょ・・・。Docker とかにサクっと詰めて Cloud Run でポイと動かせてもらえないと困る。同路線に出遅れがちと見なされている Java の方が Spring Boot なり Micronaut なりがあって、ずっとマシ。

とか思っていたら久々に HN に Scala の話題: From First Principles: Why Scala? | Hacker News しかしコメント欄のネガティブさたるや・・・。しかも割とわかるわーという話が多い。そしてここで議論されている Scala のダメさを Scala 3 がなんとかしてくれる気はまったくしない。更にこの記事自体も Swift, Kotlin, Rust, TS とかの最近の "Hybrid Language" に対して Scala がどういいのかをまったく説得できていない。もう C# とか JS とか Python とか Ruby を引き合いに出してなんか語る時代じゃねーだろ。ついでに Scala 3 の話も全然ない。

記事を書いている Haoyi という人は Scala 界隈では一定程度有名人らしく、色々と気の利いたライブラリとかを作っている。それらは良さそうだが、ちょっと冷やかした範囲では言語を立て直せるような勢いは感じない。R における Hadley Wickham や Ruby の DHH ほどの影響力はなさそうというか・・・。

これはしょうじき高すぎるバーだと思うが, Scala はそういう言語より上のレイヤの革命のがないと返り咲きはなさそうだな、と思ってしまった。Scala 3, 良い言語っぽいのに残念。

そういう実用性はさておくなら、FP Playground としての Scala にはそれなりの存在感を感じる。引き続き色々と FP なライブラリが書かれている。こういうのを通じて教養としての Modern FP を勉強する言語としての Scala というのはアリかな、と思う。Haskell やるみたいなかんじで。メイン言語に据える気にはまったくなれないにしろ、Haskell よりはまだ馴染みがあるし、実用もしやすそうだからね。

といいつつそうしたモダン FP ライブラリたちが Scala 3 に移行してくれるには時間がかかりそう。Scala でモダン FP 入門は、するとしても来年以降かなあ。言語仕様とかライブラリの進捗を暇なときに冷やかしつつ気長に待ちたい。

１月のプロジェクトは SWE At Google を読むだった。まあ、読んだ。この手の本を一冊読むくらいなら達成はそんな難しくないね。どのくらい足しになるかはわからんけど。

２月のプロジェクトはコードを書く系をやる予定。

Software Engineering at Google: Lessons Learned from Programming Over Time: Winters, Titus, Manshreck, Tom, Wright, Hyrum: 9781492082798: Amazon.com: Books

今月のプロジェクト。いちおう読み通した。が、しょうじきだいぶ読み飛ばした。面白くなかったので・・・。

まず最初にこの面白く無さについて分析したのち読みどころを振り返りたい。

• 面白く無さの一旦が自分にとっての新規性の無さなのは間違いない。仕事でやらされていることの話なわけで。これは自分の問題だから、まあいい。
• とはいえ内容の新規性のなさはある。たとえば "Chapter 2. How to Work Well on Teams” とかさ、あなたそれ本一冊書いてるじゃん既に。読んだよ。
• リーダーシップの話とかも、ここで書かずに自分で本書いてくれ、という気分になる。内容が悪いとは言わないけど、ミスマッチ。
• 自動テストの話に四章割いているが、それも世の中にたくさん本出てますから。十年以上前に。もういいよ。
• 基本的に Part 2. Culture と Part 3. Process はこの「もうその話は聴きたくない」食傷気味の話がおおくて厳しい。Part 4. の Tools は割と良い。
• 書き手によってばらつきがあるが、文章が読みにくい。冗長だったり、いいわけがおおかったり、大仰だったり。読ませる文章(!=正しい文章)を書く力はソフトウェア・エンジニア能力のメインではないので仕方ないが、こっちは金を払って業務外の時間で本をよんでるので退屈だと辛い。仕事じゃないんだからさ、面白くないと読みたくないよ。

結局のところ、ソフトウェアエンジニアリングの原則みたいのは会社固有の部分はなく、あるとしても理不尽なスケールや時系列といった大企業税由来のうんざりするものばかりで、面白くない。面白いのはそういうのと戦うための具体的な工夫。だから Part 4 Tools は相対的には面白いのだと思う。説教はいいからお前らのやったことを教えろ！という。

とう点で面白かったのは ...

• Part 4 Tools. 特に Code Search (Ch 17), Build System (Ch 18), Code Review (Ch 19), Static Analysis (Ch 20), Large-Scale Changes (Ch 22) はよい。
• 賛否はさておくと Version Control (Ch 16), Dependency Management (Ch 21) はまあ、そういう結論になっちゃったんですよね・・・みたいな感想戦的読みごたえはる。
• CI の話は特に面白くない.
• Borg の話もなぜか面白くない。Kubernetes でも勉強したほうが良いわ、みたいな気分になる。

そのほか面白いというか、ふーんという気持ちになったのは

• What is Software Engineering (Ch 1). 例の "Software Engineering はプログラミングの時間積分である" という話。この定義は Russ Cox も引用しているので、まあ知っといて良いかなと。
• しかしこの定義の説得力ある、かつ新規性のある application というのはぶっちゃけそんなにない気がする。（保守性大事ですねはいはい、みたいな。）そんななか Deprecation (Ch 15) はまさに時間積分の連続性を実現するプラクティスで、割とよかた。コードサーチして依存箇所を洗い出せとかいわれても困るけど、まあ我々そうやってますよ、そうですか、という腑落ち感はある。
• Knowledge Sharing (Ch 3). Google の knowledge sharing がどのくらい機能しているのかはさておき、go-link とか社内 SO もどきがあるみたいな話は Tools 枠として面白い。
• CD の章。やばい。YT は Python の monolith です、こういうプロジェクトのリリースは担当者がどんどん burn out していなくなります、と書いてあるが解決したとは書いていない。サーチのバイナリは週一回のリリースも危うくなったけれど著者ががんばって２日に一回まで持っていきました、と書いてあるがどうがんばったか書いてない。というか手動の QA が挟まってるとか全然 C に D してない。そのへんのダサさはまあ生々しさとして楽しむとしても、リリースの話でプロセスの章にいれておきツールの節にいれる話じゃないべ。なんかフラグツール自慢とかしてくれよせめて・・・。

一歩下がって、プログラミングの時間積分としてのソフトウェア工学というメタファについて考える。

15-20 年前くらいのソフトウェア工学って、こういうのではなかったよなあ、と思う。要件定義みたいのがあって、それと実装の関係をどうトラックするかとか、工数をどう見積もるかみたいな話があって・・・みたいなのだった。この大仰なソフトウェア工学は agile movement の台頭によりだいたい滅んだわけだが、一方で agile も割と宗教なのでいまいち工学的な力は弱く、結局 The Lean Startup のような要件探索のための business skill と、Devops movement のようなそれを支える operational skill に収束していった。そのあとに残されたものがこの「時間積分としてのプログラミング」なのではなかろうか。

要するに、CD/CI でばんばんコードを出していく時代に持続可能なプログラミングとはこういうものですよ、という。その結論の説得力は議論の余地があるとおもうけれども、そういう時代を前提にソフトウェア工学を議論しているのは、まあ意義があるんじゃないかな。ただやはり説得力が乏しいというか、あまりに大企業ウェイだなあと思う。

そして時間積分して角を丸めてしまうとプログラミングは過去 10 年くらいあまり進歩してなくて、新しいことは operational skill すなわち Devops とかそっちの方で起きているのだろうなあと、仕事に opts 成分のない身としてはやや残念な気持ちになる。同じ Google 本でも SRE のやつは広く読まれ、話題になった。

ただ時間積分しなければプログラミングの世界にもエキサイティングな瞬間はあり、それは React / GraphQL なのかもしれないし TypeScript / Rust / Wasm なのかもしれないし async / await なのかもしれないし Kotlin/Swift なのかもしれない。こういう流行りものは時間積分しながら 10 年保守するコードベースの番人には興味のない話かもしれないけれど、日々の刹那を楽しみたいプログラマにとっては興味の中心である。この関心のズレが自分にとっての面白く無さの理由の一面に思える。

なので、この人たちががんばって世界の秩序を保ってくれているのに感謝しつつ、自分は日々の積分じゃないプログラミングを楽しませていただこうと思います。まあコードレビューもするし static analysis の warning もちゃんと直すから許してちょ。

自分も体裁として肩書は Software Engineer なので出世という観点でみるとたぶんこういう "Software Engineering" は必要なのだと思うけれども、なんとなくこの integral bureaucracy を受け入れるのは違う気がするので、もうちょっと違う視点を探求していきたい。なんちゅうか、こういう「伝統的」ソフトウェア工学よりはクラウドとかデータサイエンスとか、あっち方面の発展に目を向ける方が発見がありそうじゃん？

去年はストレスと雑用に負け仕事でコードを書かなすぎた反省があり、ここ一ヶ月くらい「午前中は他のすべてをほっぽらかしてコードを書く」という方針を試している。

コードを書かないのは、バグを睨んだり人のコードをレビューしたりメールを書いたりバグを睨んだりしていたから。プラスそういう盛り上がらない仕事によって procrastination が倍増したからな気がする。

コードを書くようにするという方針にして以来、仕事は捗るしプログラマとしての満足度も高い。よい。続けたい。

が、続けようとすると問題もある。つまり、ある種のコードを書くには割と準備が必要である。その準備は API や既存コードベースの調査かもしれないし、でかめのプロジェクトなら計画みたいのもある程度は必要だし、他人のコードをいじるならそれなりに話を通す必要がある。ざっくりいうと「考える」必要がある。コード書くのは考えないのかといわれると困るけど、コードを書きながら試行錯誤をして考えられる問題と、もうちょっと違う次元で考えないといけない問題がある気がする。特にドキュメントや既存コードを読んで理解するというのは本質的に何も生産してない。

今はそういう問題は後回しにしてコードを書けそうな仕事を優先的に片付けている。それは、ここ一ヶ月くらいは機能してきた。ぼんやりめんどくせーな、とおもっていた仕事もいざコードを書いてみれば一瞬だったりで、成果には満足している。ただ昨年から持ち越した小物はさすがにだいたい片付いてきて、大物ばかりが目に付き始めた。どうしたものか。

一つのアプローチは、諦めて朝から準備作業をする路線。これは会社員的には正しい気もするが、「毎日コードを書く」というルールが失われ、もとの状態にもどってしまう気がして気が乗らない。

逆に「コードを書く」というしばりを優先し、低優先度の小物でも半趣味的コードでも書くものをさがしてがんばる、という路線もある。ただこれをやってると大物のために考える時間がとれない気もする。

午前中の「コードを書く」しばりを残しつつ、午後に計画などの準備作業をすることはできるか。やや不安がある。まず日々のルーチン的雑用を無視できるのか。コードレビューとかバグ分析とか、ほっとくのは気が引けるし、待ってる人から直接つつると現実的に無視できないじゃん。あと午後はミーティングから子供まで割り込みの発生頻度が高く、時間の枠として立ち入った考え事をするのに向いていない面もある。

妥協案として「午前中」はあきらめ、コード書きタイムをたとえば「十時半まで」とかにしてみる。あるいは「月水金の午前中はコード」とか？まあ、アリかもしれない。

「小物でも半趣味的コードでも」という部分への不安もある。ちゃんと成果の出るコードを書かないとだめじゃね？仕事すすんでなくね？そして成果を出そうとするならコードの前に頭つかう時間は必要なのではないか。

計画や準備のような「頭を使う」作業を、プログラミングの支援を通じて進められないか。よく「高級言語のプログラミングはデザイン」みたいな話あるじゃん。あるいはプロトタイピング重要みたいな。そういうノリで進められる仕事はないのか。

手元のプロジェクトリストをみると・・・上から順に: なんかのトレースをとって分析する、なんかの proposal を書く、自動テストの機能追加に向けて他人のコードのリファクタリング。うーむ割と本質的に paperwork だな・・・。リストの先にいくともうちょっとコード書けるっぽいやつもある。うーむ。

一歩さがると、ここでいう paperwork とはコード仕事を「作る」作業といえる。

• トレースを睨めば遅いところが見つかって、それを治す仕事が発生するかもれない。
• ある proposal を書けば、そのアイデアは PM の後ろ盾や関係各所からのインプットにより大きなプロジェクトすなわちコードを書く機会につながるかもしれない。
• リファクタリングを構想して話をつける作業は、そのコードの ownership を獲得してその後のコード書きをやりやすくするかもしれない。

理想的には、自分の仕事が「コード書き」と「仕事生成」からできているのが望ましい。これは、Cal Newport 用語でいう Deep Work である。しかし現実は「雑用」と「雑用以外」というカテゴリわけになっており、「雑用以外」すなわち deep work の時間がに少ないのが本質的な問題である。

と考えると、ひとつの方向性はこの「雑用」すなわちバグ睨みなどをへらすためにコードを書き、雑用の負荷を下げることではないか。これは第三の方向性といえる。

雑用負荷の軽減は前からぼんやり考えているんだけれど、こういう生産性改善プログラミングってすごい投機的で失敗するとほんとに何も残らないのが厳しい。本業じゃないから仕事をしたフリにすらならない。そしてしばしば技術的官僚性が手強すぎて倒せなかったりする。EngProd (世間でいう DX) が専門職になってるのは理由があるわけ。あんまり近づきたくない。リスク高すぎ。

うーん。こういう抽象的な議論は目先の問題を片付ける役には立たないね。まずは時間割を妥協し、かつ prep work の中にコードを探すというかんじかなあ。

ついでに Message Passing で聞いてみるかなあ。

向井さんが書いていたものの続き。これはどっか別のところ (note とか) に書こうと思っていたが、Note 使おうと思うたびに心理障壁が邪魔をするのでとりあえずここに書いておく。

Podcast をはじめたきっかけは、もともと ATP とかの podcast を聴いていてフォーマットには親近感があったのと、話相手がいれば何か話すことはあるものだと Rebuild に読んでもらって感じたため。Anchor とマイク一本で始めれば編集とかもがんばらなくてよくね？という読みがあった。（この読みはどちらも外れた。）

運用。

パンデミック期の今は Zencastr で録っている。もともとは会議室に集まってスマホにマイクつないで Anchor でとればいいじゃん、そんなら負担も少ないし、と思っていたのだが、二人でマイクをシェアするアイデアはまったく機能せず、聴いてみると Anchor のような無編集も厳しいな・・・ということで、まずは一人一本マイク＋ミキサー形式に落ち着いた。トラックを別にせずアナログで mix したのはトラック間の音のズレを懸念したから。この問題 ATP でよく言及されていたが、いざ Zencastr を使ってみるとそんなズレはまったく観測されなかった。

後処理は、基本的には Zencastr デノイザ(有償)を使うだけ。Kzys に来てもらったターンはちょっと空白除去をしたが、まあしなくてもよかったかな。なお Zencastr のデノイザの実体は Auphonic で、会議室で録っていた頃はこのサービスを直に使っていた。たぶん Rui-san に教えてもらったんだった気がする。

空白除去は、やるとマージナルには良くなるのだがめんどくさい。Podcast 開始直後は手動で削っていた。途中から Audacity の空白除去機能で削るようになった。そして最終的にはやらなくなった。後処理はカメラの RAW 現像みたいなかんじで、やればよくなるがヒマながないと無理。Podcast の音質がどうとかいう Twitter コメントをたまに見るけど、音質気にする人はほか聴いてちょ。

開始直後は無編集を厳しいと感じたのにいま編集していないのは、期待値の低下と話す側の慣れによるもたつきの減り、両方の結果だと思う。

フォーマット。

いくつか考えていた。最初はぼんやりと Rebuild みたいな対談を想像していたが、冷静に考えるとゲスト呼ぶとか人徳ない自分には無理だわ・・・と気づいた。

そんじゃ ATP のようにホスト固定でニュースやブログ記事についてコメントするのはどうかとおもったが、Podcast のためにウェブを読むというのも本末転倒だし、いかにもコンテンツ逆輸入出羽守ドヤり展開になりそうなイヤな予感がしてやめた。

今ふりかえると、それに加えて自分のホストとして話力が論外だったなと思う。Rebuild にしろ ATP にしろ一見 banal な対談形式が成り立っているのはホストが社会性や話術など特異な芸人的能力を発揮しているからだというのは、その後生えてきた日本語テック podcast や、ATP 周辺にある似たような雑談 podcast を聴くとわかる。普通の人の雑談は、退屈。

Podcast をはじめたころは今よりもうちょっと意識が高かったので、やるならプログラマとして糧になるようなことをやりたいと思った。自分はプログラマとしては書くよりは読む方が得意だし好きなので、読む活動の足しに出来ないか。ブログ・・・はイージーすぎるのでパスし、最初は本はどうかと思ったが、毎回違う本を紹介するのは厳しいしコンテンツ流用のグレー感もある。コード・・・は、やはり長すぎるのと、口頭で伝えるのは難しそう。というわけで論文を読むことにした。読みたいものは結構あるし、長さも丁度いいし、大概は open access で、著者は読まれたいと思っている。The Morning Paper や Linear Digression のような先駆者もいる。

結果としては悪くない選択だった。論文を読む行為は、腰は重いがやると満足度が高い。Podcast という活動に後押しされて腰が上がるのは良い。思ったより聴く人がいたのは、やっている最中はわからなかったが再開のアナウンスをしたらわかった。

ただ負担が高すぎて家庭の obligation に差し支えてしまった。これはフォーマットの問題というより自分の管理能力の問題だと思う。向井さんに誘われなかったらもう再開はなかったと思うが、せっかく再開したので sustainable なラインを模索しながらやっていきたい。

あと盲点だったのは人々はきほんまったく論文を読まないということ。「理解できるまで頑張って何度も聞いた」みたいなコメントをみるとびっくりする。時々間違ってるから一次資料当たるほうが良いよ・・・そういえば文章とか読まない人って結構いたね特に英語・・・。意図せずコンテンツ逆輸入業者になってしまったのは不覚だが、やむなし。いちおう自分の中の「英語でやっても恥ずかしくない」という逆輸入の閾値は守れている・・・と信じてる。

準備。

まず論文をハイライトとかしながらざっと読む。次に話す構成を考えつつ読み直しつつノートを書く。必要に応じて周辺の論文とかも読む場合もある。追加で読むのは大変なのでやらずに済むに越したことはないが、論文は本質的に hyperlinked media なので読まないとわからないこともぼちぼちある。

ノートは箇条書きで、話すことを基本的には全部書き出してある。最初はもっと普通の自分用 reading note みたいな内容だったが、それだと話の流れが論文の構成そのままになってダレるし、話すときに考えることが多くもたつく。そしてもたつくのは聴く方のみならず話す側としても割とストレスがある。

話すことを事前に全部決めると、論文の構成ではなく話して伝わりやすい構成に直せるし、話す時も淀まなくて済むし、ラク。結果としてノートは、当初の倍くらいに長くなっている。準備の時間は増えたが、ただ読むより話すことを考えながら読むほうが論文読みの体験自体が engaging になって楽しい面もある。アドリブの余地がなくなるが、どうせ即興して面白いこと言えるわけでもないのでいいです。

シリーズ。

あるジャンルの論文を続けて読むのは本人は満足度が高くて良い。ただ似たような話が続くので聴いている方はヒマだろうなと遠慮してしまう。収録頻度を減らすとこの傾向は顕著になるので、やるなら方法を工夫しないといけない。まとめて読みたいジャンル、いくつかあるんだけどねえ。まとめて読んで、まとめて紹介すれば良いのかもしれないが・・・。

ゲスト。

もうちょっと色々な人を呼べたら良いのにと夢想するが、社会性が低すぎて実現してない。ただ向井さんも今後は忙しくなるので真面目に考えたほうが良い気がしている。自分の友達とか同僚を呼んでもいいけど、それよりはオンラインで論文読み podcast をやっている人にお願いしてみるのも手かなと思っている。ただいくつか問題があるのですぐにはできないな・・・・。

まずゲストを呼ぶ場合は聞き手は二人でなく一人が良い。三人いると互いに間合いを測るのが難しい。そして聞き手としては自分より向井さんの方が二桁くらい良いので、向井さんにやってほしいが、ロジスティクスとかどうすんねん。不明。これが１つ目。

２つ目は、自分がそれらの podcast を聴いていないこと。失礼すぎる。自分は今は podcast は一つも聴いていないし、聴いていた時も日本語のは聴いていない。こういうのってよくないよね・・・。社会性を発揮し日本語の他の podcast を聴かせていただく必要がある。もうちょっと社会的やる気が高まったらがんばります。

メタな話: 対話形式というフォーマット。

世の中の日本語 tech podcast は Rebuild まねっこ雑談形式が多すぎて退屈だと思っているが、一方で雑談対談すなわちダベリと音声メディアの相性の良さは否めない。自分たちの番組は、もともとテキスト・・・どころか場合によっては数式やコード・・・みたいのを音声化しているため、音声メディアとの相性は必ずしも良くない。そこをブリッジしてあげるという趣旨といえばそうだけど、別にそういうトレーニングを受けてるでもなし。

音声とテキストの相性の悪さ、別の例として Audm がある。たとえば The Atlantic のサイトにある Audm 再録の読み上げオーディオ、聴いてみると期待に反し厳しい。Magazine writing は書き言葉のギミックに頼るうえに内容が薄いので、テキストにするとダメなのだった。Audiobook が大丈夫なのはなぜかよくわからないが、magazine articles ほど中身が薄くないのかな。ジャンル次第か。（なお Audm はいつの間にか NYT に買収されていた。だから The Daily に Audm の録音が降ってくるようになったのか。）

音声メディアの古株ラジオはなんか参考にならないかとあるとき NPR Training のガイドをいくつかひやかしたが、逆にこいつらはガチ勢すぎた。ただ対談形式をとりつつアドリブ少なめでちゃんとラジオ好きな誰かが台本を書くようにすれば、tech podcast にはまだブレイクスルーはあるだろうなと思っている。そんなブレイクスルーしてもプログラマ的にはなんにもならないが。

一人がたりだと台本書いてる人いそうだけど「一人がたり」というフォーマットの不利を覆すのは難しいと思う。対談形式は話者が切り替わるプロンプトで脳が刺激されるので、内容の boredom が和らげられている気がする。脳の反応をハックしてるとも言える。科学的根拠は無い。

こんな Podcast が聴きたい/やりたい。

雑談対談ではない Podcast, ちゃんと準備に時間をかけると決めればまだできることは色々あるはずで、人々やらないかなーと思いながらちらちら見ている。

他人はさておき自分が Misreading Chat に飽きたらやりたいこととしては:

• コード読み podcast. どうやるのかは割と未知数だけど、やると決めればなんかはある気がする。
• ドキュメント読み podcast. 最近のオープンソースプロジェクトはドキュメントがよく書けてるので、そういうのを次々に冷やかしていく。これは Misreading の枠組みでできる気もする。
• Postmortem podcast. 古今東西の outage 資料をもってきて読む。これは自分がやっても感じ悪いだけだな。SRE 方面の人がやるとよい。
• Stand-up Podcast. 最近書いたコードの話をする。たぶんそんなに長く話すことないけど、それが良いのではないか。一人 5-10 分くらいを 4 人くらい、Scrum の daily stand-up みたいなかんじでぱぱっとやる。リアリティショウ的楽しみを作りつ、コードを書く動機づけにならないか。

書き出してみると最後のやつが一番やりたいな。コードを書くきっかけとしての podcast. いいじゃん。一方でこれは Message Passing に fit する書式にも思える。

まあ読みたい論文も溜まっているので、しばらくは Misreading Chat やります。

追記

と思ったら向井さんちに子供ができて流石に忙しいらしく（向井さんちは共働きなのでなおさらである）さすがに継続はできなそう。ま、いつかそのうち、またね。

WP.com を使いたくなくなった最大の理由はこのバグで、ありえねーとおもって逃げ出した。ただ改めて調べたらリンク先のバグがみつかり、問題が theme 固有なのだとわかった。Theme setting を変えることで問題を回避し、ようやく使い物になった。編集画面が theme 依存のバグを持っているとかわけがわからないが・・・・。

改めて Wordpress.com のテーマ一覧をみると (この UI ではわかりにくいがログインユーザ向けの画面では) "Block editor (すなわち Gutenberg) 対応 theme" とそれ以外にわかれており、対応 theme は随分すくない。Gutenberg 意向で theme というブログエコシステムの重要資産を切り捨てているあたりにヤバさを感じる。自分が使っていた WP 謹製のテーマも Gutenberg 対応リストに含まれていなかった。だからバグったのだな・・・。

そして Gutenberg 対応 theme にいわゆる "blog" 向けのテーマは少ない。対応していても昔からあるやつだけで、新しい theme はどれも "business site" や "portfolio site" みたいのを対象にしている。要するに CMS 用途の theme になっている。Gutenberg もその視点でみると動機を理解できる。要するにこれは "homepage builder" の編集画面なのだな。執筆画面ではなくて。

パンデミックの影響で CMS 業者は特需があったらしく、そのための注力という面もあるのだろう。けどなんか、寂しいね。最大手の blog サービスに blog のやる気がないという・・・。

とおもったら向井さんが５年前に同じようなことを書いていた。

仕事、課外活動、家庭、運用の順で。

仕事。

• 引き続き性能仕事。
  OS/HAL 側も必要に応じてさわれるよう手元のビルド環境はがんばってつくっておく。
• 去年はコードを書かなすぎたので、コードを書くようがんばる。
  • 午前中はメール処理やバグ解析はせずコード書きにあてる。（これは 11-12 月に試して色々工夫が必要だとわかっている。それは別に議論する。）
• 今年のデバイスが出た後は性能仕事をラップアップし、アプリのアーキテクチャとかに舵を切りたい。そのために事前にじりじりと準備をする。（方針は要検討）
  • 性能仕事の自動化を今よりずっとがんばる必要があるだろうが、色々 mess なのであまり近づきたくないなあ・・・。

課外活動。

• 毎月「プロジェクト」を決めてやる。月末にレビューして、翌月のプロジェクトを決める。プロジェクトは別に大したものでなくて「この本を読む」とかもプロジェクト。１月は Software Engineering at Google を読む。（今の所そんなに面白くない。）
• Podcast は slowdown しつつ止めずにやる。月一回くらい目標。
• 雑談ブログを始める予定なので、これも月 1-2 回くらいは出したい。品質はがんばらず、継続的に雑談するのを優先する。

家庭。

• 学区の見定めと引っ越し。はやいところやる。
• 子守は academic preparedness を主導する。子の成長にあわせた moving target なので年始に具体的な目標をたてる感じではない。
• 家計簿 (Tiller) 再開し、一年継続する。予算目標はなしで出費傾向の把握に集中する。

運用。

• 運動。WFH 中はひきつづきランニング。筋トレもしたいが目標としてコミットするかんじではない。WFH おわったら自転車欲しいかもしれないが、未定。
• GTD 継続。
• Weekly review は、今やっている以外に snippet train を引退したのでかわりに Fragments に snippets を書いてみるのはどうかね。大変で続かないかな。
• 課外活動は monthly review をする。

主にプログラマとしてどうするかという話。

ここ 1, 2 年で、自分の将来はもはや望んだようにはならないことがわかってきた。次の世代のテクノロジを仕事にすることはできない。ML のみならずデータ・・・どころかサーバサイドに舵を切るとか、全然無理。今の仕事を維持するので精一杯。

これはひどく残念なことで、考えるほど憂鬱な気持ちになる。一方で、その憂鬱さに負けてしまうと物事は悪化する一方だとも思う。

業務外活動を通じてキャリアを新しい時代に進められないのがなぜかというと、資源が全然足りないからである。時間もないし、とれるリスクもない。（というか、リスクをとりたくない。具体的には収入減、超過労働したくない。）

持っている資源だけでなにかやろうとすると、自分の持ち札を生かしつつ投機的な手を打つことになる。具体的には、たとえば自分の立場から一番近い ML 系の仕事として on-device CV 系のインテグレーションをするモバイルエンジニア、みたいなのを目指して TF Lite で MobileNet なりなんなりをつなぎこむ練習をしておく、みたいな話になる。

が・・・別に CV もモバイルも TF Lite も興味ないのだよね。いや仕事の糧にはなると思うけど、自分の中から湧き上がる関心がない。なぜならモバイルも画像もあんまし興味ないし、TF ダサいな・・・みたいな中二心があるからである。これは例だが、他のパターンも似たような感じ。たとえばサーバサイドいいなと思うも社内インフラ興味ねー、みたいな。関心と必要性が一致しない。そして興味ないけど生存のために頑張るみ根性がない。必要があるのはわかってるけどやりたくない気持ちで麻痺してしまう。

ついでにいうと、そうした投資が実る見通しもそんなに高くない。それっぽいチームに移れる可能性はあるにしても、結局仕事は今と似たようなものになるんじゃないか。要するにエーアイ製品でエーアイじゃない部分のアプリを書く人になってしまう恐れ、というか、そうなるでしょという諦念。心を殺しやりたくない努力をした結末がそれじゃ、うっかり辞表だしたり自殺したりしちゃいそうじゃん。妻子あるとそういうの困るのだよ。

結局、自分のワナビー的願望と現実はあまりにかけ離れていて、それを繋ぐ道筋は見えない。無理に繋ごうとすると特攻や博打になってしまう。

それよりは、自分の残念な現実を受け入れた上である種の健全さを目指すほうが・・・健全なのではないか。プログラマとしても、人としても。絶望に歯を食いしばりながら戦うのドラマチックだけど、家族はそういうの迷惑だからね。かっこいいとか完全に自己都合な幻想。

ある種の、というのはつまり、プログラマとしての、健全さとは何か。まずコードを書いていること。業務でも業務外でもいいが、それなりに自分でデザインして何かを書いていること。新しいことを勉強していること。難しい理論でもいいし流行りのフレームワークみたな軽薄なのでもいい。本でも Coursera でもいいし hands-on でもいい。プログラミングとラーニングが常に並列している必要はないが、ある程度の時系列でみたときは両方あってほしい。そしてこうした行為を楽しんでいること。

つまり趣味としてプログラマっぽいなにかをしていること。

そういう趣味がキャリアを先に勧める役にたったりカネになったりすれば素晴らしいが、そういう実利がないからやらないのは本末転倒である。

なので業務外活動は、しょぼくても趣味性を優先したプログラマ的活動を継続していくのが良い、気がする。「やるべきこと」のやりたくなさに麻痺していると時間も無駄になるし精神性も損ねてしまう。既にだいぶ損ねている。

キャリアの足しにならないしょぼいコードを書いたり本を読んだりに余暇を使う先には何があるのか。キャリアという意味では直接には何もない。ただプログラマ・ソフトウェア開発者としての基礎体力みたいなものへの寄与はある程度期待できる。仕事でしかコードを書いてない大企業下っ端というのは危うすぎる。

あと楽しい趣味があるのは人生にとって良いことだと思う。職業生存の努力がその楽しさを殺してしまったら、これは実際に起きていることだが、人生が辛くなる。そして人生が辛いと家族との関係が損なわれてしまうなど悪循環になる。

キャリアに投資しないでレイオフとかされたらどうすんの、という話。レイオフされてもビクとしもない強いキャリアを作るのはどのみち無理というのが話の出発点だった。レイオフされて困った時、会社に希望を全部つっこんだ末に絶望するよりは仕事は残念だけどプログラマって楽しいもんだよね、と思えたほうがマシ。クビになったら・・・妻子には悪いけど日本に逃げ帰って知り合いにでも匿ってもらおうではないか。

我ながら根性がない。キャリアを進めるために努力できる人と自分は何が違うのか。現時点での瞬間風速的な根性の差というよりは、キャリアを進める努力を楽しい・実りあると感じられるよう人生を舵取り出来なかった差だと思う。継続的根性の差と言っても良い。これは残念だが、既に起きてしまったことなので仕方ない。

なおこれは別に業務を頑張らないという話ではない。仕事は業務時間の範囲でちゃんとやる。ただ業務外の時間は「仕事」の価値観に支配させず楽しくやる。「仕事は仕事、趣味は趣味」というやつだな。

この結論が具体的に何を意味するかは、つづく。というか今から考えます。

Looking back を書いてみて、家のことにだいぶ労力を書いた一年だったと思い至ったので、どういうかんじだったか記録しておく。

まずパンデミックはさておいた家事子守のロードがどういうかんじかというと、子が寝ておらず、かつ自分が仕事をしていない時間は、子守か家事をしている。子は 20 時くらいに寝る。なので可処分時間は 20:00 - 22:30 とか、そういうかんじ。仕事中はこまごまちょろまかしてインターネットみたりできるけど、週末とかはそれもなし。夏休みや年末の休暇も同様。夜の可処分時間も厳密には全部が可処分なわけではなく、家の調べものとかで消える割合もそれなりにある。そういえば朝にも可処分時間があるな。6:00 - 7:00 とかで、今は眠気覚ましにちょっとインターネットしたあとストレッチしてジョギングして消える。可処分時間は早寝早起きして朝にもってくることもあるし、夜ふかしして夜に持ってくることもある。

パンデミック で何が変わったか。

まず childcare が復活する 8 月までは、仕事を削って追加の家事子守をしていた。平日２日は 3h 減、残り３日は 1h 減。今でも子が preschool から返ってきた午後は勤務時間中に子が部屋に入ってくることがよくある。すると強制的に break time となる。仕事も 9-17 で 8 時間働くのは難しく、特に夕方は奥様からの子守要求で 30 分くらい削られがち。（これは給料もらうための前提に反しているのでなんとかしたいと思っている。)

通勤がなくなった。往復で 1-1.5h / day. この時間は家事子守に充てられている。通勤は自分にとってはある種の精神の自由を得られる時間だったので、多少の息苦しさに繋がっている。あと通勤にともなう運動がなくなったので朝走るようになった。

週末（に限らないが）、子をつれて出かける先に大きく制限がついている。水族館、博物館の類は全滅。遊戯施設も全滅。従来、こういうのは月に数回は使っていた。State park, County park の類は概ね開いているので、結果としてこういう野外に行く頻度はすごく増えた。ほぼ毎週末 outdoor しているし、preschool から帰ってきた平日の午後は週に 2-3 回は奥様が連れ出している。これが田舎の helicopter parenting か・・・みたいな気分。とはいえ平日午後に子を連れ出してくれると仕事をしやすいので助かるのだった。連れて行く場所の選定に奥様は毎日苦労していた。あまり遠くにはいけない一方、人との接触が少ないところを探す必要があったので。

他の家の子供と遊べない。夏の間は屋外でなら許されていたが、せいぜい一家族相手とかで、大人数で集まれなかった。子は他の子供と遊ぶのが一番の楽しみなので、これができないのは大きなフラストレーション。親も複数世帯で集まって childcare load を share することができない。最近は一人遊び/親との遊びにもだいぶなれてきたとはいえ。

一方 preschool peers の birthday party というできれば避けたいイベントが完全になくなったのはよかった。クラス中の子を全部呼ぶ BD は狂った習慣だと思っている。月に一回くらいは invitation がきていた。

Preschool 再開後、クラスの人数が従来より少なく設定された。これは preschool 的には打撃だろうけれど自分の子にとっては teacher の attention も得やすいしぼっちになりにくいのでむしろ良かった。子の通う preschool は normal を保つことにかなりの労力を割いてくれており、それもよかった。

家の中の子の遊ぶ場所が大きく拡充された。殺風景な patio に人工芝風シートを敷いて playground っぽくしたりとか。これは奥様ががんばった。室内の遊具も少し増えた。

スクリーンタイムは思ったより増えなかった。週に 1 回 Disney Movie をみるくらい。これはがんばって少なくしているわけではなく、親にテレビをみる習慣がないためだと思う。あと物理的にテレビがなくて、ポータブルプロジェクタを設置する fraction が機能している。個人的には別にもうちょっとscreen timeがあっても問題ないとおもうけど、積極的に増やす必要性も感じていない。

パンデミックと関係ない記録。

絵本は惜しまず買うようにしている。とはいえ選んで買うのは割とめんどくさい作業なので、その手間がボトルネックでそれほど増えない。図書館の絵本はぼちぼち借りている (by 奥様)。近隣との貸し借りは少しだけある。子のためのメディア選定は、可処分時間を費やす必要がある作業のひとつ。読み聞かせは毎日している。ちょっとさぼっていた時期もあるが、ここ一ヶ月くらいはがんばっている。読み聞かせなら多少字が多い本もいけるとわかって以来捗るようになった。

ひらがなの読み書き。読むのは一通りできるが、まだ怪しい。ちょっと練習するとよくなることがわかっているので練習させたいが、時間をつくれていない（outdoor 優先しすぎなため。) 英語は、すこしずつ workbook みたいのをやっている。その workbook の出来がよいおかげで、短い時間で少しずつできる。日本語も良い workbook を探すべきなのかもしれない。アカデミックなスキルや日本語についてはどのくらいやればいいのか見当がついておらず不安。時間をとって調査し見通しを立てるべきだとわかっているが、やってない。

傾向としてはデスクワークより outdoor activity と sleep を優先している。Outdoor activity は奥様の意向だが、運動した日は目に見えて健やかなので正しい判断だと思っている。それより子は着替えや食事が super distracted でまったくはかどらず、そのせいで色々な activity の時間がとれないのが問題。これはどうしたらいいのかわからない。

何の話を書きたいのかわからなくなってきた。こうやって家のことや子のことばかりに脳の bandwidth を使っていてプログラミングとかキャリアとか考える帯域が残ってない感じを書き残せればと思ったが、うまくいかないのでここまで。

振り返る気力すらない・・・と思っていたが、人々の振り返りが RSS で降ってきたのを見て少しやる気を取り戻す。

今年はコロナで childcare が崩壊した 3-7 月に自分の色々も崩壊し、そのあと立て直し切れず今日に至っている。立て直し切れないというのが適切なのかわからないが、キャリアの先行きとか割とどうでもいいわという気分が支配的になり、そういうことをちゃんと考えられなくなってしまった。

ブレイクダウンして振り返る。

まず健康。概ね問題なし。

通勤の消失に伴い運動量は減っているが、早朝に軽くジョギングして最低限の脳内麻薬は賄えている。通勤の強制力がないので頻度は下がり、週に 3-5 回くらいかな。筋トレは一時期ジョギングの代替にやっていたが、いまはやってない。定着しなかった。たぶんジョギングしない日にやった方がよいのだろうが。

自宅勤務化に伴い過食がなくなり、体重は何もしてないのに安定している。いかに会社で食べすぎていたかわかる。食事関係では秋くらいにカフェインをやめた。これは今もやめたまま。たまにコーヒーを飲むと効果に驚くが、あっという間に耐性ができるとわかっているのであまり復帰する気にならない。安全な付き合い方については研究したいと思っている。

睡眠時間はまちまちで、精神衛生を守るために長くしていた時期もあるし、今は夜にインターネットしたりで割と短め。睡眠を確保すると一人の時間が減ってそれはそれで wellness を損ねるため、すこし規律を緩め不定期な睡眠不足を自分に許している。寝不足だなとおもったらその日は早く寝るくらい。

精神衛生。物理的な支援（運動とか）の力でギリギリなんとかなってる。和良推薦の Medito は仕事のある日はぼちぼち使っている。

色々な思考を麻痺させて乗り切ってる感があり、込み入った考え事ができなくなった。なんというか、鈍くなった。それはもしかしたら単に WP という文章を書く場を失っていたせいかもしれないし（これは取り戻せそう）、会社やスタバのように普段のコンテクストから切り離された空間を失ったせいかもしれない（これは取り戻せていない）。時間のなさかもしれない。

メディア消費。

パンデミック開始直後はニュースに多くの時間を割いていたが、精神衛生によくないので段々と絞り、またぶり返したりで、今はニュースは NYT だけぼちぼち眺めている。選挙以降は紙面も少しヒステリー度が下がり、マシになった気がしている。

それ以外のインターネットは、あまり控えられていない。上の鈍くなったのと関連かどうかはわからないが、長い文章を読めなくなった気がしていて、これはどうにかしたいと年末にちょっと実験したりもした。e-Ink tablet を買って長文を読みたいような気もするが、単に時間がないだけな気もする。

RSS は知人関係とそれ以外でリーダーを分離した。これはよかった。友人の日記とかをよむと、どんな内容であれ心が和む。そういうときに engineering blog みたいのを目にしたくない。友人 RSS は、自分にとってのソーシャルメディアになっている。たまに感想をメールしたりしている。

Podcast はジョギング中に聴いていたが、段々と聴く量が減り、秋くらいから聴くのを辞めた。ニュースと同じで、なんとなく精神の安定に悪影響がある気がしたため。今は Audiobook を聴いている。Audibook は本と同じでいまいち気乗りしないときもあるけど、総体としては podcast よりは実りあるように感じている。単なるバイアスかもしれないが。

インターネット芸人活動。

秋くらいから気分転換に blog でも書くかと準備していたら向井さんから podcast を再開しようと誘いがあり、結果として Q4 ではけっこう時間を使った。気分転換になってよかった。まったく持続可能性は感じないが、そんなに持続する気もないので別にいいです。

Podcast は再開するよと言ったら歓迎のコメントが散見され、おもったより聴いてる人が多く驚いた。公開したものも聴かれているようで、それなりに嬉しい。

Blog はレビューとかをしてもらった割にインターネット上では想像を超えてまったく反応がなく、人々の労力に報えなかった申し訳なさがある。Blog というのは貯めて出すものではないのだなと思う一方で、どのくらい書けるかわからないのに新しいブログを公開するのも気が引け、どうすべきだったのかはよくわからない。

仕事。アプリ本体ではなく OS との相性みたいのとか HAL だとかに振り回され、非生産的な時間を多く費やした。そのせいでコードを書かない時間も長く、アプリのコードと距離ができてしまった。非生産的なリクエストの波が去った後も若干 burn-out 気味で、本来なら大きな仕事を片付けるチャンスの電話機発売後の凪の時期を無駄にしてしまった。上司的にはそれで OK だったらしく評定にインパクトがなかったのは幸いだが、自分的にはあまり OK でない。あと相変わらずバグの triage の負担が多いのも辛い。

あと夏までの childcare 崩壊期は目先のなにかを押し続けるのが精一杯で、一歩下がってなにをすべきか考える心の余裕がなかった。危機的状況下でちゃんと振る舞えないのは仕方ないといえば仕方ないが、そのせいでダメージが後を引いて、よくなかった。

課外活動。ゼロ。機械学習とか、完全に遠い世界のものになってしまった。悲しい。

家庭。問題なし。他の全てを犠牲にしてこれを優先したわけで、その甲斐はあった。奥さんががんばったおかげが大きいが、まあ力を合わせてがんばったと言って良い程度には参加したと思う。あと子が就学前だったおかげで夏から childcare が復活したのに救われた。これが小学生でずっと virtual class とかだったら一年中ずっと辛かったと思う。そういう家庭は周囲に散見される。

もちろん問題ナシはいいすぎで、子があるべき形で社会に expose されない副作用はあると思う。ただそれはがんばっても解決できる問題ではないので、自分の評価にしても仕方ない。

自分自身をもっと世間に expose すべきでなかったか、つまりもっと知り合いと zoom/vc とかすべきじゃなかったの？という指摘はありうる。そうかもしれない。無精だった。

出費は荒くなった。今は外出がない分でマスクされているが、back to normal になったら inflate するだろうと思う。困ったものだが、そういうのを気にする余裕なし。今は給料いっぱいもらってるのでこれでいいです。会社の景気が悪くなったら考えます。

生産性ハック。

12 月からは昼食を食べるのをやめた。これは摂取カロリーも減らせるし時間も削れるしすばらしい。来年も続けたい。

GTD. 崩壊した仕事と生活を立て直そうと９月くらいに本を読んで、やってる。自分にとっては Inbox と Weekly Review をセットで真面目にやるというのが新しい取り組み。仕事と個人で別のリストを管理している。細かい雑用を漏れなく片付ける役に立っている。雑用が片付くと心的負荷が下がるのは良い。あと bottom-up に色々やるほうが現実的には機能するというのは、そうだなと思う。

大局的に物事に取り組むのにも GTD が役立つという件の本の主張は信じていない（というか、他によい方法があると思う）が、別にそういうのなしでも有用なのでいいです。GTD についてはなんかもうちょっと書きたい気がしていたが、また今度。

Gutenberg エディタが苦痛でしばらく日記は Notion で書いていたが、どうも長めの文書を書く気にならなかった。結果として個々半年くらいものをよく考えなくなっていた。これはよくないと思い、2021 からはこの新しいエディタに体を慣らしていこうと考えを改めた。

方針の変更として、自分が Fragments と読んでいる箇条書きのテキストは引き続き Notion で書き、公開しないことにする。あれは Twitter みたいなもので、自分が脊髄反射を吐き捨てたりリンクを記録したりする役には立っているが、長期的にインターネットに晒しておきたいものではない。引き続き友人たちにはソーシャルメディアとして送りつけさせてもらうけれど、それで終わりにしたい。

それはさておき anemone.dodgson.org はいよいよ本格的に誰にも読まれなくなっており、それは自分の私生活から tech blog を分離した以上 by design なのだが、いざ目の当たりにすると若干の寂しさもある。ただこれは公開方法の問題ではなく読まれるに値するものを書いていないせいな気もする。

エゴへの執着で自分の行動や思考を歪めてしまうことにはいまだ抵抗があるので、まあそういう寂しさはおいておいて文章を書いていきたい。ひと目につくところに置きたければ、あとから置いても良いでしょう。

人生最大級に時間がない。朝から子供の相手して、仕事して、家事して、仕事して、寝る。以上。みたいな毎日。一方で「忙しさ」は特に感じない。

忙しさというのはたぶん、予期しない問題や割り込みが起きて、もともとの予定が乱れてしまったときに感じるのだろう。課外活動ゼロの現実が期待値に織り込まれると、何もできないのは別に予定通り。だから忙しいとは思わない。ただ時間がないだけで。

時間がないとも実のところ感じておらず、というのは手持ちの時間 (24h/day) は変わっていない。単に優先度順にやることを積んでいくと課外活動が予算からはみ出てしまうだけ。「時間がない」というのはたぶん、気がついたら一日が終わっているみたいな時間が「どこかに行ってしまう」感覚に紐付いているのだろう。自分は時間がどこにいったかはわかっているので、そういう「溶けてしまう」ような時間のなさは感じない。「課外活動の時間がない」とは感じるが、あるわけがない。だって childcare してるんだから。

仕事の時間が所定の労働時間に届かない事実には frustration や pain がある。これは究極的には失業の恐れである。つまり childcare という目先の obligation と、金を稼ぐという前提の obligation が衝突している。課外活動も潜在的には将来の雇用に寄与するはずだから失われることに恐れはあるはずだが、その寄与の不透明さは目先の obligation にかき消されている。

一方で、これでいいのかと不安はある。疫病は仕方ないが、一方で「仕方なさ」を理由に必要以上にいろいろなことを諦めすぎてはいないか。もうちょっと無理していろいろやった方がよくはないか。「忙しさ」を感じるくらいまで日常にストレスをかけてもいいのでは？

それをやりたくない理由はいくつもある。睡眠を削るなりなんらかの形で時間をちょろまかそうとすると、他のことにしわ寄せるのが目に見えている。それは仕事の成果が減る、ということかもしれないし、妻子の期限が悪くなり関係を損ねることかもしれない。「しれない」というか、このどちらも確実に起こるのが目に見えている。

最近、睡眠を削るという行為は一体なんなのだろうなとたまに考える。いいことなくね？みたいな。ただし場合によっては睡眠を削りたい人もいるのだろうと想像はできた。

• 昼の仕事が世を忍ぶ仮の姿である場合。昼はウェイターだがよるは歌手みたいな。昼の仕事がどうでもいいなら睡眠を削って自分の時間を確保する意味はある。
• このバリエーションとして、自分にとって重要な趣味が脳のフル機能を必要としない場合。たとえばテレビシリーズを binge するみたいのは、割と寝不足でも気にせずやられているように見える。

自分はこれらには該当していないので、睡眠時間は削れない。ただまあ、睡眠削って眠気と戦いながら生きることに意味のある人生もあるにはあるのだろう。

話題がそれたが、睡眠を削れないなら何を削るべきか。

ニュースかなあ。ここ二ヶ月は世の動向が割と actionable な consequence を持っている場合もあったので熱心にニュースを読んできたが、もうそろそろいいかなとも思う。ほんとにいいのはわからないが、ニュースをやめるときには常についてまわる不安なのでこれは「やめてみる」が正解に思える・・・平時であれば。今はどうかねえ。まあいいんじゃね、という気はしているが、やけくそだろうか。

仕事の時間にもうちょっと紛れ込ませる。これも望ましくはないが、ちょっとくらいいかなと思う (Towards (A Bit) More Procrastination)。

相変わらず意味のあることができる気はしないが、小さなところからはじめていくほかなさそう。

課外活動以外にも考えることはある気がして、それをさしおいて自分のやりたいことをやっていいのかという逡巡もある。たとえば子の home schooling をどのように執り行うべきか、きちんと考えたほうがいいのではないか。こういう後ろめたさもなにかをやる妨げになっている。

課外活動にせよこうした問題について考えるにせよ考えていることを書き出して整理する必要があり、そのために今は細かい時間を縫って画面なり紙なりと向かい合う時間がほしい。やはりニュースはしばらくおやすみだな。

会社支給の Pixelbook で仕事をするようになりはや二ヶ月。このラップトップはもともと事実上の procrastination 端末だったが本業に使うようになった結果仕事から procrastination が消えた。基本的にいいことなのだが、なんというか、息苦しい。なにしろ家事育児睡眠以外はほとんど仕事しかしていないので、もうちょっとこう、インターネットとかしたいのだよ。Pixelbook のマルチプロファイルにより個人アカウントのブラウザもあるにはあるのだけれど、リモート開発ゆえの環境の不安定さもあり、あまりプロファイルの往復とかをしたくない。メモリも足りなくなりがちだし。

というわけでデスクの上を整理し、このところすっかり使っていなかった私物の Dell laptop をひっぱりだしてきた。ラップトップを二台並べる滑稽さにもなんとなく抵抗があったが、もうそれはいいです。ついでに勢いで Ubuntu 20.04 もインストール。ブラウザを使えるようにするところまでは 1-2 時間でたどり着いた。他はおいおい揃えていきます。もともと手元にデータを置かない主義なのでバックアップなどの手間がないのに救われた。

やはり画面は二枚ある方が気を散らすには良い。というわけで procrastinate してくぞ！というと仕事中もはやそんな余裕はない気もするが、すくなくとも寝る前ちょこっとゴソゴソするのに仕事環境を mess する心配のない私物 laptop を使えるようになったのは良かった。

ところで Ubuntu 20.04 ゴミのように遅いけど正気なのかなこれ。Crostini なり WSL なりがマトモになったら、もうほんとに Ubuntu とはおさらばかもしれないなあ、と思う。まあ GUI といのは金かけて真面目に人をつけてやらないとすぐゴミのように遅くなるわけで、それ自体は理由はわからないが今となっては驚きもない。ソフトウェア・どうしてすぐに・おそくなる？

とはいえ Chromebook には 15 インチ HDPI 高速 CPU モデルとかでてこなそうだし Windows に適応しなおすガッツもないのでしばらく Ubuntu で暮らすけれど、頃合いをみて Macbook に出戻るほうがいいのかねえ。あとやはり卓上に二台ラップトップがあるだめな人っぽさを軽減するべく速い Chromebox が欲しいなあ。いっそもう自腹でもいいから・・・と思ったが目一杯積んだモデルは $900 か。安くはないな・・・。

とか物欲の distraction をにわかにたのしんだあと、正気に戻って暮らすものなり。

夜シフトに慣れてきたのは良いが、結果として就寝直前まで仕事・・・みたいになっておりほんとに何も他のことができない。昼はジリジリと侵食され、月水は 3.5h, 火木金は 5.5h みたいなかんじ。そこに夜プラス 2 時間。たまに夜にヒマがあっても(仕事の気力がなくても)私用のラップトップがすぐに見当たららないみたいな体たらく。厳しい。仕事のラップトップで私用をしてもいいんだけど、デバイスが差してあるとかの都合で机から持ち歩くのが億劫なのだった。

いつか時間ができた暁にやりたいことを記録しておく。

• Ubuntu 20.04 インストール。OS 入れ直しとかなんだかんだで半日くらいかかるので今は無理。しかしいつまでも 18.04 を使っているわけには行かないのだよ。
• 仕事関係だが直接の依存はない調べもの。色々ある。
• 読書。もう読みたい本をリストアップする気力すらない。
• お手紙活動の見直し。今は虫の息。
• Podcast するなりテクニカルな文章をするなりの課外芸能活動。
• そういえば論文も読みたいな・・・。何かを学ぶことなしに芸能活動だけしても仕方ない。
• RSS の消化。

なんちゅうか、たいしたことない人生だな我ながら。別にいいけど。

そしてやはり child care ナシは厳しいよ。そこに金を払うことで時間を買い、その時間で金を稼いでいたわけじゃん。あまりこれについて考えても憂鬱になるだけだが、一方で書き出さずに置くのも鬱積なので、書き捨ててゆきたい所存。

Reopening Business みたいな議論が世間でも盛り上がっており、勤務先もうっすらとそういう気配がある。しかし social distance つきのオフィス、どれだけ意味があるのだろうね。

まずチームミーティング。できないよね。互いに 6ft 離すとか無理じゃん。上司との 1:1 くらいならでかい部屋でやればいいかもしれないが、1:1 なら別に VC でいい気がするし。出社が解禁される頃には small scale gathering も解禁されているのだろうか。それは・・・いいの？

個人のデスクの間を 6ft 離す・・・ことはできるかもしれない（というか、個人が移動しないという想定なら既にそのくらい隙間はある）。しかし人のデスクに立ち止まって一緒に画面を眺めて作業とかはできない。そして、たとえ 6ft 離れていても人がいっぱいいる室内に長時間 (八時間!) いるとか、微細飛沫防ぐ余地なし。イヤすぎる。

テラスやソファなどの休憩スペース。そういう shared surface は disinfect しないとさわれないわけだが、考え事でウロウロして腰を下ろす度にそのへん拭くわけ？そんなかったるいことするなら共有空間使うの諦めるわ・・・。

食事。6ft 離れた座席の cafe じゃ team lunch も成立せず、そうなるとタダメシを提供する動機/口実が失われる。そもそも空間が足りない。自席でサンドイッチを囓るのが合理的な選択肢になってしまう。つらい。せめて散歩しながら囓るか・・・。間食も、青果やドライフルーツは消えてパッケージされた乾き物くらいしか供されなくなりそう。

特別なハードウェアが必要な人はともかく、自分のようなプログラマに会社という空間の良さは：話す相手がいて、おやつやコーヒー片手にぶらぶら歩いて座って考える場所があって、腹が減ったらタダメシがあって・・・ということなわけじゃん。早い計算機とか広い机とかってのは、家でも（ある程度は）揃えられるわけだから。

けれどワクチンがない世界の socially distant な会社空間にそうした良さがあるとは全く思えない。多少制限があっても WFH の方がマシ。

とか思っていたら, Amazon は早々と 10 月まで WFH 期間の延長を決めたらしい。自分の勤務先も見習ってほしいもんだわ。6 月とかさ。無理でしょ。

一方で WFH の受容は中長期的に福利厚生の削減に繋がるとも自分は思っていて、そこに悲しさはある。

勤務先の手厚い福利厚生の多くは、人々がオフィスで働くことを前提にしている。人々がオフィスに来ないなら、オフィスの厚生を薄くすること自体は理にかなっている。一方で、そこでの削減が自宅ワーカーに還元されるとはどうにも思えない。

オフィス厚生の過剰さは多くが景気のよい成長期の名残であり、良く言えば文化の一部である。WFH に同じような厚生が実現されるためには WFH が文化の一部になる必要があり、しかもその文化が形成されるにあたっては背後に景気の良さがないといけない。これはどちらもむずかしい。WFH 文化は、よほどうまくやらない限り現行の強いオフィス文化と競合する。そして、ただでさえ成長が鈍化しているところに疫病の不景気。気前の良さも期待できない。

従って WFH が文化に根付く期待は薄く、そんな WFH にやってくるのはお仕着せのみみっちい厚生がせいぜいだろう。結局のところ自分の勤務先は pro-office, counter-wfh なのだよな。アメとムチでいうとアメ側がメインなので counter side が強調されることは少ないが。

そうなると勤務先にとっての望ましい展開はあくまでオフィスワークの復帰であって、WFH はそれまでの繋ぎにとどまるのだろう。一方で social distancing の必要性は、一部では一年以上の長期化が見込まれている。そうなったとき何が起こるのだろうか。借りぐらしの WFH が長期化するのか、それとも socially distanced office が定着するのか。後者が期待されている気がするが、先に書いたように自分はその妥当性を信じられていない。一方で借りぐらし WFH を続けるのもあまりうれしくない。

理想的にはリーダーシップが長期的な WFH first に舵を切り勤務先がリモート中心の会社になることだが、完全にファンタジー。

若くて身軽だったら勢いにまかせてリモート中心の会社に転職しそうなところだけれど、そういう元気もない。この悲観的な見通しが実現せず気がつくとなんとなくいい感じになっていることを祈りつつ耐え忍ばせていただきます。Sigh.

追記

勤務先も年末までは WFH ということになったらしい: When Will Companies Let Workers Back Into the Office - The New York Times その他のアナウンスメントを読んだ感じでは、安全性をうやむやにしつつ職場復帰というパターンはなさそうな雰囲気。

最近の平日の一日:

• 6 時ちょっと前くらいに起床、かるくニュースを冷やかした後ひっそり家を出てストレッチ、ジョギング。
• 7 時ちょっと前くらいに帰ってきて皿を拭いたりコーヒー淹れたりなんだり。このへんで妻子起床。スキを見てシャワー。並行して奥様が朝食準備。
• 7 時半 - 8 時ちょっと前くらいから朝食。そのあと子の歯を磨いたり着替えさせたり。
• 9 時から子の preschool video chat 付き添い。30 分ちょっと。その裏で奥様ジョギング。
• 帰宅身支度した奥様に子を引き渡し、10 時少し前くらいから労働開始。
  • ただし月曜と水曜の午前中は奥様オフロードのため仕事をせず子供の相手。
• 12 時前後から昼食。日によっては自分が準備するが、基本的にはあるものを出すだけ。週一回くらい出前。
• 13 時 - 13 時半くらいに労働復帰。このへんのタイムテーブルは妻子の行動次第で、たとえば公園にでかけていて帰りが遅れると遅くなる。
• 15 時。妻子とおやつ。30 分くらい。
• 16 時半、仕事を切り上げて子守。
• 17 時半、夕食。
• 18 時半、夕食片付け、猫の世話、子の遊び場片付けなどの家事。奥様は子のねかしつけ。
• 19 時半くらいから仕事の夜ラウンド。21 時過ぎまで。ほんとは二時間働きたいが、疲労のため大抵は 1 時間半くらいで脱落。このへんのどこかで奥様が寝かしつけを終えて登場（起きてこない日もある）。
• 奥様と会話したのち 22 時就寝。

• 労働時間の短さ: 昼間 5h, 夜 1.5h で 6.5h. 月曜と水曜は 4.5h. やはり夜はもうちょっと頑張る必要があるな。家事を手早くやって、7 時くらいから夜シフトをはじめればいいのだろうか。あるいはメールの消化を朝のどこかにねじ込むとか。
• しかし夜に働くのは肉体的にしんどい。デスマ気分。まあデスマなわけです実際。
• 朝のジョギングを復活できたのはよかった。ほんとは更に早起きして朝に仕事したいが、子を起こしてしまう懸念があり断念。
• 課外活動はおろか考え事をする時間もないのがジリジリと精神衛生を削っているが、色々な諦めの結果ストレスカーブはまあまあ flatten されている。

• でかいことはやらず、インクリメンタルに成果を出せることに絞って作業。でかい作業をやりきれる見込みがないため。これは今の所機能している。しかしそろそろ大物を狩るフェーズに入らないといけない気もしており悩ましい。
• 労働時間が短いと税金の支払いが厳しい。俺のじゃねーバグの分析、インフラ変更への追従。ミーティング。こういうのは気合や工夫で圧縮できず、やってるだけで一日終わり、本業が進まない。ミーティングは以前に増してスルーするようになった。あまりよくないが、やむを得ないトレードオフ。毎週 coffee chat だの happy hour だのチーム歓談系のイベントが色々設置されているが、全部無視している。子の有無による class divide の深まりは否定しがたい。
• CRD (Chrome Remote Desktop) でクラウドにある Linux の Android Studio を使っているのだが、レイテンシが厳しい。たぶん Comcast のネットワークが音を上げている。最初はターミナルや vscode も CRD 越しに使っていたが、ターミナルは Secure Shell extention, エディタは社内の簡易ウェブエディタに乗り換えた。IDE は仕方ないので耐え忍んでいる。
• そのクラウドでビルドした APK をダウンロードしてくるのに 10 分以上かかり、きびしい。こないだはダウンロード時間が 30 分を超え、思わず仕事を投げ出した。なるべく lab の自動化用を使えるといいのだが、いまは作業が割と探索的なのでそれも難しい。つらい。AT&T なら少しはマシなのだろうか・・・。ただ実際は収集したプロファイルデータを睨んでいる時間の方が長いので、致命的なダメージは受けていないのだった。これが UI 仕事だったら発狂してたね。
• 追記: これを書いたあと Wifi ルータの設置場所、Comcast のプラン、モデムなどを刷新した結果 10 分かかっていた APK のダウンロードが 10 秒くらいになり、帯域の問題は解決した。
• Laptop を Pixelbook から Linux なり Mac なりに乗り換えたいが、在庫不足のため勤務先のラップトップ乗り換えは凍結中。いっそ自腹を切って laptop を買っても割が合うレベルなのだが、セキュリティ上それもできない。おもわぬ大企業税。Macbook Pro 16, オンラインで買えば来週には届くのに・・・いいよ $3,000 くらい払うから買わせてくれよ・・・みたいな気分。書いてるうちになにか抜け道がないか調べていい気がしてきたな。
• 実作業時間を最大化しようとする結果、仕事の方向性とかを一歩さがって考える時間がとれておらず、そこには大きな不安がある。週末の夜にでもきちんと時間をとるべきなのだろうが、おうちの仕事もあるし、もう疲れてて無理・・・。
• 時間がないといいつつ向井さんなど三人くらいで週に数回終業前 20 分くらい雑談ビデオチャットをしている。しかしこれは子守負荷増大前に始めたものなので、今や週一回くらいが妥当かもしれない。

• ロードバランスのため最初は炊事を引き取っていたものの、それよりは子守を引き取って欲しいというので炊事はやめ、朝のビデオ授業、夕食準備中、週二回の午前いっぱい子供の相手をすることにした。仕事の捗らなさに輪がかかったが、奥様の精神衛生が回復したので甲斐はあった。Child care をアウトソースできるという子持ち会社員の大前提が崩壊しているのでやむなし。Child を care する機会が増え、子との関係は良くなった。
• 当初は不安などからストレス気味っぽかった我が子、奥様による様々な試行錯誤のおかげで今は見たことがないほどご機嫌に日々を過ごせており、よかった。家族の精神衛生と健康が一番重要というか、大前提なので。
  • プレスクールは午前中いっぱいぶんくらいのビデオクラスを提供しているが、最初の 30 分くらいしか参加していない。うちの三歳児にビデオクラスは無理だわ。ビデオクラスに集中できないこと自体は特に問題視していないというか、できるわけねー。画面にむかってちゃんとリアクションしている一部の他所の三歳児をみると感心する。
  • 朝 30 分のビデオクラスをしたあとは、おやつの買い物で釣って近所を散歩するなり（自分の場合）どこかの公園に車で行くなり（奥様の場合）して、子の運動量を確保している。午前中は人が少なくてよい。午後は適当に遊ばせている。
  • 苦もなく英語を吸収できる三歳児の魔法の時期が過ぎてしまうのが悲しいが、ビデオクラスを無理強いしたところで成果があるとも思えない。我が家における厄災として受け入れている。
  • 中長期的には日本語の活字コンテンツ（絵本）の仕入れに苦労しそう。iPad でも買えばいいのかもしれないが・・・・。配達遅れを承知で Amazon.co.jp から投機的に発送してしまえばいいのかもしれない。
• 週末は、午前中に公園なり山なりで軽くハイキングして、あとは家でゴロゴロしている。疫病以前はハイキング先で弁当を食べていたところが違うけれど、それ以外は大差ない。
• Grocery shopping は週一回程度。自分が炊事している間は自分が行っていたが、先週からは奥様が行っている。なるべくオンラインで買い物を済ませ、足りないぶんを補う方向。

• Grocery stores はだいたいどこも入場制限をしているが、早朝にいけば問題ない。例外は日本食材店で、早朝は営業しておらず週末は大行列。平日の昼は空いているらしいが、平日の昼に買い物をすると労働時間が一層削られてしまい厳しい。なるべく行かずに済ませて欲しいと思っているが、奥様次第。アジア食材の宅配を検討中。
• 隣の公園は人が多い。ジョギングや散歩は公道の方が良いし、公園に行きたいなら住宅地から離れた所が良い。
• 隣人数組が子供同士を遊ばせていたり、公園に行ってもどうみても家族でない人々が連れ立っていたり、social distancing の実施にはばらつきがある。公道や公園で気を使ってくれない人と近距離ですれ違うのがいちばんのストレス。
• 屋外でのマスク着用はまばら。自分はいちおう持ち歩いているが、マスクでジョギングするのは何度かやってくじけ、今は人の少ない早朝に走ることで落ち着いた。
• 地元ニュースをまとめたニュースレターを書いていたが、行動に影響あるレベルのニュースが減り、政治の話が増えて S/N が下がってくるのに合わせ頻度を下げている。これをはじめたもともとの動機は shelter-in-place のニュースを当日に受け取ったのが仕事のチャットルームだけだった事実に端を発する情報不足不安および奥様のコミュニティの危機意識の低さのなんとかしたさだったが、疫病が日常になった今や役割はほぼ終わった気がする。SF Chronicle の subscription は引き続き地元ニュースを読む役に立っている。

子および奥様の状態が安定し、ベイエリアに限れば疫病の加速も収まり、表面的には持続可能性を感じられるようになった。一方で勤務先を含む世の経済は不景気に突入し、自分の仕事の成果もゴミのようにだだ下がりで、暗黙の前提である雇用と金銭的安定は暗雲というか雷雲のまっただなか。世間や勤務先の景気は自分がどうにかできるものではないが、仕事の成果をなんとかするのが次のステップなのだろうとは思う。しかし振れる袖が無い。また時間パズルを解き直す必要があるし、他にもなんとか成果を squeeze out することに頭を使うべきなのだろう。しかし「頭を使う」に必要な時間や精神力がなく、つまりこれが厄災の重荷。

テック業界、疫病の影響で中長期的にはどうなんのかね。主に自分の雇用が関心。

前提として、世の中全体の景気は悪くなる。回復するにしても、数年以上はかかるとする。サービス業は、長期的にはわからないが数年はどうにもならない被害を被る。ここまでは概ね合意があるように見える。

ここからは個人の見通し: テック産業も不景気の影響を受ける。そして基本的に新しい巨大な価値を生むようなイノベーションはしばらく生まれない（インターネットの祭りが終わってしまったから）。疫病による世間の変化で生まれる/盛り上がるニッチなテクノロジーはあるだろうが (ex: Zoom)、あとは従来の既定路線どおり。ただしタイムラインは変わる。

テック業界最大の疫病受益者は Amazon である。別に彼らが悪巧みをしたとかいう話ではなく、構造として。これまでも買い物は店舗からオンラインへのシフトを勧めていたわけだが、疫病によっての移行が桁違いに加速した。別の見方をすると、Amazon がリテールのシェアを一気に奪った。このマーケットシェアの移行は不景気をふっとばすインパクトがある。

Digital Transformation とかいわれているビジネスシステムのクラウド移行も加速するだろう。その受益者も一番手はやはり Amazon/AWS である。Microsoft/Azure も潤うだろう。Google/GCloud も少しは潤ってくれるといいのだが。WFH が生んだラップトップの特需は特に長期的なインパクトはない気がする。会社で使っていた PC が家に来るだけだから。

電話機業者、すなわち Apple とかがどうなるのか。不景気の影響で高い電話機はしばらく売れないだろう。そういう意味で iPhone SE2 は神がかったタイミングで発売されたといえる。景気がよくなるとも思えないがスマホが生活必需品なのは事実なので、脇を締めて乗り切る感じだろうか。このところ iPhone にひきづられて高価格化していた Android 電話機勢はどうするのだろうね、というかやすいの頑張るしかないと思うのが、頑張ってどうにかなるのかはよくわからない。

検索やソーシャルなのど広告業者。きびしい。別に悪いことはなにもしていないが、広告というのは景気の関数なので不景気になると辛い。Amazon が小売からシェアをとるように、疫病が非オンライン広告からオンライン広告への乗り換えを後押しすることはあるのだろうか。わからん。あまり想像できない・・・。広告業者、Google はきびしいなか少しは収益を diversify できている（クラウドがある）のが救い。Facebook のように広告に絞っていると厳しい気がする一方、会社の勢いでいうと Facebook はいまだ圧倒的なので勢いにまかせて乗り切れるのかもしれない。2009 年の Google がそうであったように。

実世界 disrupt 勢すなわち Uber, Airbnb やその仲間たち。ただでさえ上場後ぱっとしていなかったのが、いよいよ厳しい。数年前は実世界への進出がインターネット業界の未来だと思われていただけに複雑な気分。しかし Amazon だって実世界を相手にしたインターネット企業なのだから、別に実世界進出がだめなわけではない。Uber みたいのがダメだったという話だろう。

最近元気だったインターネット企業というと Slack とかのモダンエンタープライズ。このひとたちはどうなのだろうね。DX の加速に便乗できるのか、保守化した顧客は MS とかの手堅い方に流れるのか。

勤務先はどうなるのかね。不景気による広告の目減りをどこまでしのげるのだろう。一年くらいは現金があるので大丈夫だろうが、そのあとの冬の時代をどう生き延びるかをかんがえないといけない。会社がどう生き延びるかではなく、冬の社内をどう生き延びるかという話。

クラウドは相対的に存在感を増すだろう。しかし underdog である事実が変わるとも思えず、ついでにあまり興味がわかない。クラウドを使うのはいいが、中の人には特になりたくない。

電話機は・・・心配。ハードウェア業みたいに金のかかる博打、金がなくなったらだめそうじゃん。もっと OS とかのプラットホームに近づいておく方が安全なのだろうが、あいつらとはほんとに音楽性が合わないのだよな・・・。

検索と広告。なくなることはないが、脇は固くなるのではないのかね。どのみちそんなに興味ないけれど。動画。ユーザは増えているのだろうが、UGC をとりまくきな臭さが消えることもない。

タイミングを見計らってクビにならない場所に軸足を移したほうがよい気がする一方、別に今の仕事は嫌いではないしやることもあるので、雇用のためだけに逃げを打つのは気が乗らない。しばらくは現状維持、クビになったら撤収、くらいのつもりでいる方が地に足ついてる感じがする。

というか、アクションをともなうなにかについて考える心の余裕がない。現状維持で大丈夫と思い込みたい引力が強すぎる。

せっかく 100 年に一度的な大きな出来事の中を生きているのだから何かしら記録を残したほうがいいなと思うも、どうにも気力がわかない。

時間がないというのもあるし、生活があまりに家族との関係に満たされており個人的な要素がかき消えているので、表立ってなにか書く気になれないというのもある。

何か立ち入ったことを考えるのも、目の前にある uncertainty が大きすぎてなにか計画なり分析なりをする意欲がわかない。うつ病というほどではないが、もう日々をやりすごしてい行くしか無いという諦めのような達観のような、そんなかんじ。先の心配をするといっても、まずは家族として病気にならず、心の健康も損ねず、というベースラインの達成が目下の課題で、仕事とかマジどうでもいい・・・というと語弊があるけれども、人としてのベースラインを満たそうとした果てに仕事にあぶれたりしたのなら、それは仕方ないという諦めがある。

目に見えない色々なものが壊れて、失われて、でもそれが厄災というものなわけじゃん。別に自分は頑張っていないわけではなく、優先度をつけて頑張ったら仕事やキャリアにまわす予算が残らないだけ。悲しいことだが、世界を覆う圧倒的な難しさと比べたらほんとにささいに思える。今のところ給料の払われる職があって、住む場所があって、食うものがあって、みな健康で。でもそれを支えるのに手一杯で、他のことに気を取られる余裕がない。

自分は今まで相対的に余裕があったから色々と余計なことを考えることができたが、厄災が起こる前から世の中にはベースラインを支えるので精一杯の人生を送っている人が沢山いて、きっとこういう気分だったのだろうな、と思う。ベースラインを支えることのできない人も沢山いるわけだが、そんな他人に思いを馳せる心の余裕はないのだった。

奥様子守で疲弊のため炊事担当を引き取ることに。二年ぶり。一週間やってみたが真面目に頭をつかってやらないと破綻確実のためしばらく think aloud に記録をつけてみる。

水曜日

奥様に協力を仰ぎ、冷蔵庫および冷凍庫の不用品、賞味切れ品などを処分する。だいぶ余裕ができた。

木曜日

一週間の献立を決める。昼と夜、主菜のみ。必要な食材をリストに入れて翌日の買い物に備える。調理の連続性（材料の使いまわしなど）を考えることができなくなっている。要練習。

献立を毎週スクラッチで考えるのは厳しいので、昔やっていたように週単位のテンプレをつくる。すなわちこの曜日の昼はこれ、みたいな。おにぎりの日、チャーハンの日、粉ものの日、麺の日、冷凍プロテインの日、漬けおきの日、など。

さすがに毎日作るのは厳しいので出前もスケジュールに織り込むことにする。まずは週二回、ランチから。一回あたり $30-$40, 週二回だと月に 10 回で $400/m, $4,800/y.  週 3 回にすると $600/m, $7,200/y. 典型的な金で時間を買うカード。一年間ならアリかな。子の nutrition 等を考えると出前だけでは足らず野菜などを足すわけだが、それができるのが外食に対する出前の良さといえる。まあ外食できないんだけど。

昼飯は冷凍してあったボロネーゼソースでスパゲティ。

晩飯は・・・わすれた。

金曜日

朝から買い物。大きめの店舗にいくはずが、惰性で近所の小さな店舗に行ってしまう。結果としていくつか買えないものがある。しかし時間がなく帰宅。一週間ぶんの食材等を買うと量も多く時間もかかる。もっと速く済ませたいのだが・・・。そして時間の遅れに気を取られ会計時に会員カードを提示しわすれる。たぶん $20 くらい損した。

朝 7 時前に入店したため、入場制限の行列などはなかった。食材も、特別足りないという感じはなかった。欲しいものが売ってないことは、平時にもあったわけで。

二週間前くらいに申し込んだ Imperfect Foods のショッピングウィンドウがようやくやってきた。メンバーシップ型の食材配達サービス。週に一回の配達数日前にウィンドウがあり、その期間内に欲しい食材を注文する。品揃えは、いわゆるスーパーなどに比べると全然ないが、スタンダードな野菜はそれなりに揃っている。不揃い野菜を売るのがメインかと思っていたが、それ以上に生産過剰なものを売るのがメインに見える。アウトレット食材。特別不揃いの消費を助けたいというモラルはないので、むしろ好都合。

スーパーでの買い物をすべて補えるわけではない。たとえばプロテインは全然足りない。とはいえスーパーでの買い物量を減らせれば時短になるし、事前に手に入るものがわかるのは精神衛生によい。本当はなるべくこいつだけで食材を賄えるよう工夫すべきなのだろうけれど、そういうクリエイティビティを発揮する余裕なし。

ひるめしは奥様が冷凍していたチヂミと冷凍チキンナゲットなど。

晩飯は久しぶりにカレーを作る。子はなぜかカレーがあまり好きではないので、リスク回避のためカレーは鶏ももと玉ねぎだけでつくり、それとは別にじゃがいもと人参を蒸し、軽くバターであぶってトッピングにする。子がカレーを嫌がってもこれらは別に dip でもつけて食わせれば良い。煮崩れもないし、割とよい方法に思える。

土曜日

Imperfect Foods の配達は水曜夕方だが、それまで野菜の在庫が足りない気がする。昨日の買い物で買いそびれたものがあったのと、献立計画の時点で主菜だけを決めたためそもそも買い物リストに野菜が足りていなかった。困った・・・。

出前に Habit Burger. 子には適当にサンドイッチを作る。

晩飯は圧力鍋煮豚。セロリを買えなかったので仕方なく玉ねぎと煮る。このスープどうしたもの・・・出汁が出て旨いはずだが、具材が無い・・・。

時間パズル

スーパーへの買い物は週に一回に留めたいと思っている。これは人混みを避ける意図もあるが、そもそも時間がない。ただでさえ勤務時間のコミットメントを大きく割り込んでおり、これ以上時間を削りたくない。勤務にインパクトの少ない早朝に行くと、朝食準備等で奥様に負担が行くので本来の目的を損ねてしまう。週一回は不可避なので受け入れてもらうとして、足りないものがある買い物に行くと、そのたびに夫婦の関係がダメージを受ける。週一回でバシっと必要なものを揃える必要がある。しかも複数店舗を回る時間はない。

この制約がある以上、欲しいものを全部買おうとするのは現実的でない。買えなかったものを他のなにかで補うような柔軟性が必要。しかし何が買えないかは実際に買い物をするまでわからないため、買い物中に improvise しないといけない。しかも子の好き嫌いを想定する必要がる。難しい・・・。

どうすれば買い物失敗を補填できるか。仕事の時間に買い物に行くというのを試したが、昼間は入場制限とかで朝より時間がかかりがち。そこで 2 時間とか使ってしまうと勤務時間の短い現状では有給半日分くらいのインパクトがある。現実的でない。（これを試した日は有給を申請した。）

夜に買い物に行く、というのは試していいかもしれない。しかし閉店間際の混雑具合とか在庫とか期待薄。どうなのだろうな。しょうじきあまり行きたくないが、何も選択肢がないよりはマシ。月曜にでも試してみよう。自分のジョギングの時間が失われるが、それは自分自身の失敗の対価なので仕方ない。

週一回、一店舗の買い物（プラス配達注文）ですべてを揃える必要があり、かつ失敗した場合のペナルティが自分ではなく他人の負担（すなわち機嫌）。厳しいゲームすぎてストレスで死にそう。

この現状を打破するにあたって、ハイレベルには:

• まず野菜、プロテイン、乳製品といったカテゴリ単位で必要なボリュームを把握し、それより多めに買うようにする。余ったら多めに食べるなり捨てるなりする。
• 献立のフレキシビリティを高め、とりあえず何らかの形で nutritious requirements を満たすものを serve する。

具体的には:

• Staple は、野菜も含めて多めに買う。野菜の賞味期限が攻めがちになる（破棄の可能性が高まる）のは受け入れる。
• Staple 野菜と理想在庫量をリストし、買い物時にそれを埋めるようにする。(vs. 献立で必要なものを買う)

別の見方をすると、今の買い物は献立ドリブンすぎるので、もっと availability driven に近づけていく必要がある。といっても昼食は昼の 30 分、夕食は終業後 45 分で準備する必要があり、その前は仕事してて献立とか考える時間ないわけで、単純に献立ドリブンを捨てることはできないよなあ。調理の語彙を増やし、在庫から退屈でもいいから適当になんかつくれるようになる必要があるが、献立とか研究する時間ないわ。

仕事も進まずストレス、炊事もギリギリでストレス、文字通り頭痛気味。ここからどうやって sustain できる状態に持っていけるか考えないとうつ病になりそう。

忘備録

• 人参は 2lb では足らない。 日持ちするので 5lb 買う。
• ひき肉は足が早いので少なく買いがちだが、冷凍する前提で多めに買う。これも 5lb くらい買ってよい。ボロネーゼなどで割と使う。
• 鶏ももは漬けおき肉にする必要なし。ソテーでも旨いし、野菜と炒めても良い。最強。帰るときにでかいパックでドンと買えば良い。

追記

炊事は自分でやりたいという奥様からの要望により三週間くらいで終了。

このパンデミック、どう終わるのか。誰も知らないわけだけれど、それでも雑にウェブの記事を読んで分かる範囲のことを咀嚼したい。そのために think aloud writing してみる。

おおざっぱに３つのパターンがある。

• パターン 1: 感染者を隔離してウイルスが天寿を全うするのを待つ。ウイルスは世間から消える。
• パターン 2: ワクチンが開発されて人々がそれを接種して免疫を獲得し、社会活動ができるようになる。Coronavirus は今の flu みたいな存在になる。
• パターン 3: 人々がくまなく感染し、結果として抗体を獲得する。そして社会活動ができるようになる。

パターン 1 の隔離は、感染者の多すぎるアメリカではもう無理と言われている。

パターン 3 は herd immunity (集団免疫?) と呼ばれているもの。これは望ましくないとされている。なぜならパターン 2 より沢山人が死ぬから。数百万人の死者が予想されている。人口の数パーセント。自分も普通に死にかねない確率。医療機関がパンクして治療を受けられない人が増えるので、死亡率もあがる。

あとパターン 1,3 にしても最終的にワクチンは必要である。なぜならウイルスは他所からやってきたり mutate したりするから。

というわけでアメリカは長期的にはパターン 2 を目指している、はず。

ワクチンの開発には「最速で」12-18 ヶ月かかるとされている。つまりもっとかかる可能性もある。個人的には、世界の科学者が総出でがんばっているので割と楽観視している。一年半待てばなんとかる。なってほしい。治療薬の方はそんな期待してない。

パターン 2 を目指しても、政策の失敗などでウイルスの配布まで持ちこたえられず、望まざる形でパターン 3 に入り込んでしまう可能性も割とある。集団免疫って、聞こえはいいけど要するに全滅だからね。

つまり人類は集団免疫という名の全滅を免れるため医療機関が崩壊しない速度まで感染の広がりを抑えつつ、ワクチンの開発を急いでいる。全滅とワクチンの戦い。またの名を flatten the curve.

実際は医療機関はある程度は崩壊しそうに見える。つまり全滅とワクチンの戦いのうち、ワクチン圧勝の見通しは薄い。勝つにしても、大きなダメージは受ける。つまり数百万人は死ななくても十万人以上は死ぬという見通しが発表されている。もう一万人しんでるわけで、10x はそんな遠くない。あと地域により医療崩壊の程度にはばらつきがある。ベイエリアは NY ほどではないにせよ人口あたりの感染者が多く、崩壊しやすい側にいる。

そんじゃ 18 ヶ月 shelter-in-place で WFH しますかというと、それも現実的ではないと多くの人々は信じている。

自分とかはインターネット産業のホワイトカラーなのでやれと言われればやるが、アメリカ全体では既に一千万人くらい失業しており、この数はまだ増えると見られている。仮に数千万人（ざっと人口の一割以上）が失業した状態で国を維持するのは無理。就業可能人口の 10% じゃなくて全人口の 10% だからね。失業率 10% どころじゃない。

インターネット産業にしても、一番したのハードウェアやインフラが作れなくなってしまったら困るし、サービスを維持したところでユーザが失業して金がなかったら売上崩壊。広告産業とかガチで滅びかねない。Amazon だけは生き延びるかもしれないが・・・。

なので感染が「落ち着いたら」なんとなく「経済活動を再開」したい。政府含めた人々はそう考えている。しかしそれがどのように起こるのかはわかっていない。

最悪のシナリオ。再開以前に shelter-in-place が十分に機能しなくて全滅/集団免疫コースに突入すること。沢山の人が死に、集団が免疫を獲得し、ゲームオーバーののちに経済活動再開。

しかし人口の数パーセントが死んだ状態で再開する経済活動とか想像の範疇を超えている。最悪シナリオの終了までにどのくらい時間がかかるかは、死者数とのトレードオフ。数ヶ月から一年くらいだろうか。

ただ常識的に考えると行政は感染速度を見ながら lockdown の強度を強めていくはずなので、仮に現状の shelter-in-place が不十分だとしてもゲームーオーバー前のどこかで「落ち着く」ことは期待できる。なのでこの最悪シナリオは unlikely ・・・な気がする。

最悪シナリオのバリエーションとして、shelter-in-place が機能したのに油断して経済活動を再開したらまた感染が広がってあわてて lockdown ... みたいのを繰り返すうちに気がついたら全滅したりワクチンができたりするケースも考えられる。非現実的だと思っていた「18 ヶ月 shelter-in-place 」が望まぬ形で実現されてしまう。行政/国家の実力次第では、この展開はありうる。経済は崩壊。アメリカの財政赤字 $100 trillion, みたいな世界。 全滅よりはありうる展開。

したがってやるべきことは：「感染が落ち着いたら」再び流行らないよう「なにか手を打ち」、その準備ができたら「段階的に」すこしずつ「経済活動を再開」したい。ここまでは概ねコンセンサスがあるようにめる。ただしその「打ち手」がなんなのか、どんな「段階」を踏むのかは、よくわからない。

基本的な考え方としては、shelter-in-place 成功後の「落ち着いた」状態を冒頭のパターン 1, すなわり「隔離成功」の近似とみなす。つまり shelter-in-place によってウイルス保持者を「だいたい隔離できた」とみなす。

理想的な世界ではこれは正しいとされている。shelter-in-place の期間中に新しい感染が発生しなければウイルスは天寿を全うしていなくなるわけだから。ただ現実的にはそんわけなく、近似によるエラーがある。このエラーは何らかの方法でフォローしてやる必要がある。つまり、ウイルスはそんなに沢山はいないにせよある程度は残るから、それが再び感染爆発しないように手を打ちたい。その打ち手に人々は考えを巡らせている。

まず医療体制の強化。ventilator を増やすとか人増やすとか。医療体制が強化されるとそのぶん感染「爆発」の閾値があがる。これは再開とかいう以前にいますぐ必要なので、各自治体ががんばっている。でも、そんな増えなそうだよね。ぶっちゃけ。指数の力の前にこの小さな定数項がどれだけ助けになるのか、割と疑問。

あと言われているのがテストの徹底。テストを徹底することで、感染した人の隔離を確かなものにできる。テスト結果がネガティブだった人たちから「段階的に」経済活動に復活できる。とはいえ全人口をコンスタントにテストするのが現実的でない以上、どのように人々をテストすればいいのか自分にはよくわからない。この coronavirus は無症状の感染者が多いと言われている。なので熱などの症状がある人だけをテストしてもだめ。だとしたらテストの徹底なんで可能なのだろうか。

更に雑な（しかし頻繁に目にする）近似：テスト結果がマシだった地域（たとえば州）から「段階的」に再開する。でも人々が普通に移動できる以上、マシでない地域（たとえば NY) から人が来たりするよね？どうすんの？州境を封鎖すんの？できんの？

逆側の、より精緻な指標として、感染を生き延びてウイルスへの抗体が確認できた人を「部分的に」経済活動へ返していく方法も議論されているが・・・。まあその生存者が出歩くのは別にいいと思うけれども、それ経済活動を賄えんの？たとえば 1-2 割のランダムな住民が出歩けたところで、そのひとたちが行く職場や学校や遊び場は存在できるのだろうか。想像するのが難しい。ゲームーバーシナリオの中盤意向なら意味あるかもだが・・・。

個人や州単位の「部分的再開」とは別に、social distance を残したままでの再開に関する議論も見かける。たとえばレストランの席数を減らして social distance を保てるようにする、飛行機も有効席数を減らす、ビルの入り口で体温測る、公共ゾーンを除菌清掃する、みたいな。これが可能なビジネスもあると思うが、一方で線引きが曖昧で危うい橋にも見える。序盤での抑制に成功したアジア方面はこれをやっているように見える。

なお自分の個人的な関心としては学校/幼稚園どうするんかな、というのがある。小さい子供に social distance 守らせるとか不可能。中学、高校から上くらいならオープンできるのかもしれないが・・・。

そんな感じで、自分は経済の早期部分的再開というアイデアをあまり信じていない。「実施されない」とは思っていない。「実施されるが失敗する」と思っており、失敗の程度を心配している。

部分的再開のアプローチについては、アジア諸国やイタリアが先を行ってなんらかの結論を出してくれることを期待している。政府がそれらの学びをどの程度取り込むかには、若干悲観的。まあニュースは注視してます。

これを踏まえ、我が身について考える。

自分は（すぐには失業しなそうという意味で）WFH 可能な職についており、経済活動の早期再開にそれほど人生がかかっていない。幼稚園の長期閉鎖に伴う子の発達への影響は心配している一方、まあ一年くらい幼稚園にいかなくても人生踏み外したりはしないでしょう。就学後の学業が一年遅れるよりインパクトは低い。子が家にいると大変で仕事の生産性は激減だが、一年くらい仕事のはかどらない時期があっても、クビになるリスクはそれほどでもない。（長期化すると厳しいが。）

一方で、自分は若くない。そして喘息持ちである。喘息は covid-19 とセットで complication を起こすリスクがあり、要するに病気になって死ぬリスクがちょい高め。子も似た傾向を持っているように見える。なので危うい橋を渡ってまで経済活動再開に付き合いたくない。

といったことを踏まえると、世間の経済活動がどうであれ個人的にはワクチンを打つまで WFH したいなーという気持ちがある。しかし世の中の経済活動再開への eagerness を見るに、勤務先を含めた世間の人々は早期再開に乗り込んでいくだろうと想像しており、気が重い。世間一般はともかく勤務先は長期 WFH 側に倒してくれるといいんだけれど・・・。最悪一旦パートタイム労働に切り替える必要があるかもしれない。

ただこれは現状の不透明さに対して具体的すぎる心配なので今はほっとく。

むしろまず心配すべきはパンデミックの悪化。場合によってはガチで疎開が必要になるのではないか。日本も心配だが、相対的な期待値はマシっぽいから。ただそれそれでロジスティクスがだいぶ厳しい。妻子だけ返すのは悪手で家族揃って避難する方が妥当に思えるが、実現のためにクリアすべきハードルが多すぎて思考停止・・・。

書き出してみて、自分は経済の部分的再開というアイデアを信じておらず、それは世間のメディアの主流の態度とは違うことがわかった。あまりうかつなことを口走らないようにしたい。

自分の見通しが外れて部分的再開が成功してくれればそれは全然ハッピーなので、誰かにがんばってほしいもんですわ。

参考リンク

• Opinion | How America Can ‘Reopen’ After the Coronavirus - The New York Times
• Opinion | The Road to Semi-Normal - The New York Times
• In Italy, Going Back to Work May Depend on Having the Right Antibodies - The New York Times
• National-Coronavirus-Response-a-Road-Map-to-Recovering
• Americans are underestimating duration of coronavirus crisis, experts say
• The Crisis Could Last 18 Months. Be Prepared. - The Atlantic
• How Will the Coronavirus End? - The Atlantic
• This is how life under coronavirus will play out over the next year | WIRED UK
• What our leaders can do now | Bill Gates

• 子の休校がはじまると WFH が生産的なわけがなく、もう普通に働くのは諦めている。ランチも兼ね昼に二時間ブロックをとって、子の相手をすることにした。夕方も 30 分早く仕事を終えて家事育児。でないと奥様が燃え尽きてしまう。他にも細々と割り込みがあるため、実行的な労働時間は 5 時間くらい？それに加えてリモートデスクトップのオーバーヘッドもある。早朝か深夜に埋め合わせた方がいい気もしているが、そんな体力もなし。朝にメールくらいは見るかなあ。
• 自分のような電話機部門は「突然トラフィックが増える」みたいなことはない（むしろ電話機売れなそうで不安）なので仕事そのものに大きな変化はないが、クラウド部門などは大変そうな様子。自分は仕事と家の板挟みではなく、一方的に仕事にシワ寄せられるだけマシ。もう評定下がってもクビにならなければいいです。嵐が去ったら頑張ります。
• 子は不安定で、若干退行気味。仕方ない。そのうち適応してくれるといいのだけれど。ようやくちょっとずつ英語を pick up しはじめたタイミングでの休校、ほんとに厳しい。
• プリスクールは、ビデオチャット経由で色々やってくれている。ありがたいことではある。しかし子の言語の発達は teacher ではなく peer からの刺激が主だったように見えるので、それがほぼゼロなビデオチャットは厳しい。そして母親が一緒なので自立心も育ちにくい。この世代の子は、社会的な発達が一年遅れになってしまうのかもしれない。
• ずっと家にいるので子との bond は深まっており、これだけは朗報な気がする。
• 買い物事情。食料品の買いだめはおちついたらしく、細かいことを言わなければだいたい必要なものは買えている。ただスーパーに行く頻度を下げたいので Imperfect Foods という配達サービスに入る。これは奥様の友達の推薦。他も 2 つくらい見たけれど、枠が埋まっていた。トイレットペーパーなどの衛生用品は完全に欠品。ウォッシュレットも売れていることでしょう。
• ニュース記事をまとめる活動をはじめた。一日 30 分以上かかるので時間の使いみちとして正しいのか微妙だが、一方でニュースをきちんと追えている事実は精神衛生を助けている気もする。寝る前に書いている。SF Chronicle は購読した。メディアとしての好感度は NY Times >越えられない壁> SF Chronicle > SF Gate > San Jose Mercury だが、ローカルな実用性は逆という皮肉。NY Times は、なんだかんだで東海岸の会社だよなあ。その点西海岸な WP でも読むべきなのかもしれないが、どのみち地元ではない。
• ニュースまとめメールには書いてないが、大統領の無能さがほんとうにやばくてびっくりする。有事においては権力者がちゃんと権力使ってくれないと困るのだが・・・。100 年に一度の厄災に 100 年に一度の無能大統領が重なってしまったアメリカ、かなり壊滅しそう。生き延びたあとの不況でレイオフになる可能性を無視できなくなってきたが、とくに備えられることもない。
• 株価はすごい下がっているらしいが、あまりちゃんと見てない。証券会社から「loss harvesting が発動したよ」というメールがぼちぼちくるくらい。自分はもともと超保守的な portfolio でここ数年の好景気でもそんなに増えていなかったのだが、そのぶん減り方も世間の人よりは控えめだと思われる。とはいえリタイア可能年が 5 年くらいは遠のいた感じはする。むしろ給与における株の割合が問題で、今年の所得はすごい下がるだろうね。まあどのみちほっとくしかないし、生き延びるのが優先。
• 生き延びるという点で、喘息の prescription をゲットしておいたほんとによかった。

これは二週間くらい前に書こうと思っていたが、だいぶ情況がかわってしまった。

知り合いのいわゆる駐在、留学な人々の中に、帰国を早める人や勤務先から帰国を進められるケースが出てきた。自分も妻子を日本に逃がすことを考えているが、日本がどのくらい安全なのか判断が悩ましい。

子をどこかに逃したいのは健康が心配だからではなく、lockdown/shelter-in-place の影響が厳しすぎるから。三歳児、他の子供と遊べないのは過酷すぎる。２週間前、アメリカ/ベイエリアの shelter-in-place 長期化は明らかで、一方の日本はなんともいえなかった。もし日本が収束に成功するなら日本に返すのもアリかと思っていた。せめて近所の子と遊ばせてあげたい。

しかし今は日本というか東京も lockdown が予想されている（んだよね？）。子を逃がす先候補である奥様の実家は埼玉だけれど、まあ同じだよね。日本の lockdown がどのくらい厳しくなるのかわからないが、近所の子供と遊ばせるくらいはできたらなと思う。でもまあ、普通に考えたらやめたほうがいいよなあ。もっともこれは国の違いというよりは個人の性格の問題で、たとえば自分の隣人の家には他所の子が遊びに来ているのが見える。厳密には違法。

東京近郊も lockdown となると、相対的には spacious で遊具も揃っているこの家にいた方がよい気がする。親も二人いた方がずっといいし。もし日本の情況が、たとえば夏くらいに収束したなら、その頃に疎開させてもいい気はするが、lockdown するフェーズにはいったのならもう長期化するってことだよねえ。

それとは別に、疎開させたいと思ったタイミングで入国できるかも若干怪しい。すでに入管を厳しくしてるっぽいがだいぶ色々混乱しているらしく、その混乱に巻き込まれると辛い。たとえば二週間の self quarantine をする際に親元でそれをやるとなんというか、台無しになってしまう。一方で宿の確保は困難を極めている様相。

疎開は無理な気がしてきた。家にいたほうがよいな。

(金曜日に一週間を振り返りながら書いてます)

月曜日

週末に注文しておいた USB のハブや HDMI ケーブルが届いたので繋いで見る・・・が画面の解像度が上がらない・・・Sigh. 仕方なく USB-DisplayPort のケーブルを注文。しかし低解像度でもラップトップの 12 インチよりは 30 インチの方が目がラク。

SSH tunnel 越しの adb だと systrace はほぼ不可能という結論。やむなくオンデバイスで perfetto trace をとって Linux の VM から pull し、それを Chromebook で表示。そのデータをどっかにアップロードして URL 返すくらいやってくれやとおもっていが、そもそも API もないし機密データをアップロードすることもできない Perfetto UI. Sucks.

洗濯機や皿洗い機がめちゃうるさい。ノイズキャンセルヘッドホンが活躍。

モバイル OS がタッチレイテンシの削減に血道を挙げている一方でデスクトップはリモートでさわってもなんとかなってしまう現実。デスクトップはそのへんラクだよなあ。まあ、あるけどね。遅延。

火曜日

明日から公式に WFH 推奨というメール。予想通り。

画面解像度が低く入力のレイテインシもあるが、仕事は捗る。家には気が散るものがないという圧倒的な現実。WFH の方が働きすぎるという記事を過去に何度かみかけたが、わかるわ。

というか、家で仕事をしないと本当に言い訳の余地なく仕事をしていない。要するに会社にいて働いているフリをするという概念がないので、逆に仕事をしなければというプレッシャーがある。成果主義に体を慣らしてきたつもりだったけど、まだまだ職場という舞台装置への甘えがあったと思い知る。

寝室を片付けデスクを共用できるようになったのでようやく台所から脱出。

水曜日

前日、寝る前にちょっと仕事をしてしまった。寝る前に仕事ができる現実がやばい。睡眠に悪影響が出そうなのであまりやるべきではないが、割と捗るのも事実。

朝から喘息治療のため医者へ。いちおう「朝は不在です」というメールを出す。意味あるのだろうか・・・とおもったが実は上司との 1:1 があったことが判明。しかし医者なのでやむなし。帰りのタクシーでチャットで簡単に報告（「特に問題ないです」）をしたら「あのバグみといてね」と返される。はい。

USB-DisplaPort のケーブルが届いたのでつなぐ。ようやく会社員に望まれる解像度を手に入れた。4k にしたい気もするが, Remote Desktop の圧縮ノイズを目にすると解像度あげても無駄では・・・と思ってしまう。なおリモートでは IDE (Android Studio) とエディタ (VSCode) とちょっとしたターミナルを使い、あとは Chromebook 側で済ませている。つまり全部ブラウザ。

気分転換の散歩、腰が重い理由の一つがわかった。戸締まりが必要だからだな。その点会社の散歩はぶらぶら歩くだけなので friction free である。

話し相手が欲しくなる。チャットだと満たされない何かはある。なんとなくソーシャルメディアをしたい気分にすらなるが、たぶん同じく満たされないだろうからやめておく。奥様に「話し相手欲しくなるね」といったら「なるわよ」とのこと。ごめんね仕事中話しかけられるの嫌がってて・・・。

強い眠気のため夜の仕事はせずさっさと就寝。

木曜日

ワークステーションを再起動してね、というメッセージが出たので再起動したところ動かなくなってしまった。おいおい。仕方なく出社してトラブルシュート。ついでに億劫でやらずにいたクラウドのデスクトップ VM をセットアップ。クラウド VM, 会社の物理マシンより若干レイテインシはあるがそれ以外は大差なさそうな雰囲気。再起動のたびに会社いくのもやだしこれでいいかな・・・。

オフィスに来てみると、フロアの見渡せる範囲で数人。午後になると更に数人増えた。休憩コーナーが従来どおり整備されていて驚く。むしろ人がいないので普段よりおやつの在庫が潤沢。食堂は縮小＋衛生管理厳重モードで営業されていた。ま、もうしばらく来ません。

夕方、初のリモートミーティング。これはいつにも増して発言しにくいなー。滑舌やアクセントの悪さからただでさえ発言したくないのに、マイクの動作にも不安があってまた敷居が上がる。なお寝室の mess を映したくないのでビデオは切っている。

ミーティングといえば、チームの誰かが「雑談部屋」みたいなビデオチャット (Meet) のチャンネルを作っているが、帯域も集中力も無駄にする気がして参加する気まったく起こらず。

とはいえこう、疎外感とは違うけれど loop から unhook された感じは否めないねえ。自分は仕事は九時五時という人間なのでそんなに寂しさないけど、仕事の重要度が高い生き方だと寂しい、虚しい気持ちになりそう。

TGIF 動画を見ていたら娘が入ってきて「あのおじさん誰」とか「字だけなの？」とか言ってる。機密情報ですよあなた英語わかんないからいいけど・・・。なお先のミーティングでは  TL の画面にちょっとだけ息子が登場していた。TGIF 登壇の幹部たちは会社っぽい場所だったり自宅っぽい場所だったり、まちまち。

金曜日

夜ふかししてニュースを読んでいたため朝起きて走るのに失敗。しかしあからさまに精神衛生が損なわれているので妻子おでかけ後に走る。この柔軟性はいいな・・・と思ったが、走った直後はさすがに疲れていて仕事が捗らない。やはり朝走るのが一番。

Santa Clara School District が closure を発表。大統領も National Emergency を宣言。それにあわせてついに子のプレスクールも閉鎖。はー。予想どおりだけどいざくると厳しい。奥様と相談が必要だが、そんな時間もない。会社は緊急事態だから勤務は「柔軟」でいいとかいうけど結局人事考課では成果をみられるわけで、板挟み。まあ national emergency なので仕方なし。一年くらいは覚悟しているが・・・。それにしてもものを考える時間も場所もない厳しさよ。

それはさておき仕事。ベンチマークのスクリプト、普段は手元で動かしているがリモートでは動かせないので、自動化につかっている Lab で動かすスクリプトを介して動かす・・・が動かない・・・。手元で動かすには色々小細工が必要なのだが、自分の使っていたワークアラウンドはいつの間にか使えなくなっていた。インフラ担当のひとに泣きついて助けてもらう。しかしこの自動化スクリプトを挟むとターンアラウンドが 10 分以上かかるので、まったく仕事が進まない。きびしい。

自分の仮想終業時刻である17時前に妻子は返ってくるのだが、そうすると17時に切り上げるプレッシャーがより一層高まる。その割の朝は 9 時から働けない。もうね。ちゃんと働くの無理。 まあせいせい寝る前にちょっと埋め合わせますわ・・・。

来週からは大変だが、気が重いなーとか逃避してても仕方ないのでプロアクティブになんとかしていきたい。

人事考課の季節。チームでの tenure が伸びてきたのと隣接チームと仕事をすることが増えた結果、今回は割と多めにピアレビューを書いた（といっても社内的には普通の量）。久しぶりだったので感想。なお社内のピアレビューには大きく「出世用レビュー」と「普段着レビュー」の二種類があり、出世用レビューは一段真面目に書かないといけない。あとは更に気楽な「一言レビュー」みたいのもある。今回は普段着レビューと一言レビューのみ。

まず、できる同僚に「おまえは良い仕事してるぜ！」みたいなレビューを書くのは普段の気持ちを伝える意味でも書いてて気分が良い。ただ「階級の期待値の記述を満たしていることがわかるように書け」と指示されており、そこは難しい。とりあえず自分の気分をバーっと書いた後、肩書期待値表を見ながら事後的に調整している。たぶん良い書き方ではない。

「もうちょっとこうしたら良い」的フィードバック。良い仕事している同僚には「せっかくだからもうちょっと野心的でバーンとした仕事もやろうぜ、こういうのどう？」みたいな謎の励ましフィードバックをしがち。そういう内容は期待されていない気がするが、勢いと野心があってよく働く人々相手にボンクラから言いいたいこととか別にないよね。しいていえば「もうちょっと人の話を聞け」みたいのを言いたい相手はゼロではないが、まあ別に聞かないなりに付き合い方があるので困るというほどではないし。

むずかしいパターン 1. すげーいい仕事をしているが、すげーいい仕事をすることが期待されている階級であるケース。この「ちょういい仕事してるけどそれも給料のうちですよね」みたいな温度感を伝えるテキストはどうかけば良いのかわからん。仕方ないので「すげー良い仕事してるよね！すごいね！」と書きつつ定量的な採点はふつう、みたいになった。もどかしい。

むずかしいパターン 2. 上の逆で、なんかいまいちぱっとしないコード書くなあ・・・と思っていた相手が、大したことを期待されていない階級だった場合。むしろその階級にしは割といいコードだった気もする。この「ぱっとしない」というイメージを払拭するのが難しい。思っていることをバーっとかいても感じわるいだけなので、期待値表の文言を照らしながらなんとなく「この期待値よりはだいぶ良いよ」みたいなドライな記述をした。そして制度が期待しているのはどのみちそういうドライな評価な気もする。しかし書いていて特に盛り上がらない。

むずかしいパターン 3. たいして重要でもない機能のためコードベースを複雑にしている、と自分（森田）が思っている同僚。しかし「たいして重要でもない」は自分の完全に主観的な評価なので、その複雑さは実は割にあっているかもしれない。しかしその複雑さが生み出したバグが自分のところにやってきてその原因究明に追われ本業が進まない、という腹立たしい体験を何度もしているため、自分はその相手を「余計なコードばっかり書きやがって・・・」と恨めしく思っている。ので「もうちょっとコードの品質とかアプリ全体のアーキテクチャとか考慮しませんかね」みたいな苦情をいいそうになるが、一方で難しい技術的な問題を解いているのはそれなりに事実で、あとアーキテクチャ考えるとかは責任範囲外（畑違い）の相手にも思える。うっかりネガティブなレビューを書きかけたが締め切り前に考え直し、期待表と照らしてドライなバージョンに修正。評点も見直した。

たぶんいい仕事をしている相手には（出世用レビューでない限り）心をこめた賛辞を送ればよいのだろう。逆に自分が個人的な主観では好きでない、評価してない相手に対しては階級別期待値表をツールとして使い、個人のバイアスを排して組織の価値観を代弁する。無駄な軋轢を産まないレールとしての階級別期待値表。

いい仕事をしていると自分が評価している、有り体に言うと仕事ぶりを気に入っている相手のレビューに階級別期待値表を使わなくてよいのか。たぶん、ほんとはもうちょっと期待値の記述をベースに書いた方がよいのだろうねえ。自分は期待値表の記述を内心それほど信じていないのでそれよりは心からの賛辞を送った方がよいと思っている。一方で相手にとっては標準化された基準にもとづいて働きの良さを説明してもらえた方が嬉しいかもしれない。つまり、「森田からの評価が高い」よりは「組織にとっての働きの良さを森田が証言している」ほうが良い。どうせなら相手のためになるレビューを書いてあげたい。

しかしそのためには自分が普段から組織の価値観にあわせて価値判断をする必要があるように思える。階級別期待値表の記述を内面化する必要があるというか・・・。

そんなものを内面化してしまっていいのかという倫理的な不安がある一方で、会社員としてはよく理解しておくほうが都合がよいようにも思える。うーむ。良いピアレビュアであるのを諦める、というのも一つの選択だが、はて・・・。

特に結論はない。しいていえば管理職は普段からこういうことを考えてて大変だなと思いました。

CA が State Emergency を宣言し Santa Clara County も警戒を高めてきたのを受け、勤務先も遅まきながら自主 WFH を求めてきた・・・とまではいかないが、したければどうぞというフェーズになった。そんじゃやってみっかということでラップトップと開発用電話機を持ち帰り、家からコードを書いてみる。

Chrome Remote Desktop で会社の Linux ワークステーションにつなぐ。手元のラップトップは Chromebook.  こいつに電話機をつなぎ、公式 Linux VM 通称 Crostini で ADB を動かす。同時に Secure Shell 拡張で会社のワークステーションに SSH しつつ ADB のポートを tunnel する。と、あら不思議。Chrome Remote Desktop の中で動く Android Studio でアプリをビルドすると手元の Pixelbook に繋がった電話機に APK がインストールされる。ちょっと感動。さいわい Linux/GNOME の virtual desktop と Chromebook の Virtual Desks はキーバインドが重ならなかったので、ネストした仮想デスクトップで仕事。

なお Macbook だと普通に手元の Android Studio でビルドできるらしく、チームでは Macbook が推奨されている。そんなこといわれてもなーとおもいつつ、ちょうどラップトップの更新をしていい時期にさしかかっていたので注文。Mac OS とかもう使い方忘れちゃったよ・・・。また別の路線として、会社のワークステーションではなくクラウドの VM にデスクトップを置くのもアリらしい。これはまだ試してない。

疫病疎開の WFH なので仕方はないが、仕事は会社でやるのがよいなと思った。これは意外といえば意外だが「仕事をしたくない」と「会社に行きたくない」を混同しなければ自然な結論に思える。つまり「仕事をする」という現実を受け入れたなら、家で仕事するより会社でする方が良い。自分の場合はね。

一般論はさておき自分の身の上について考える。自分はもともと家で仕事をする気はなかった。書斎もないし、今や自分のデスクもない。たまに趣味でコードを書く時は台所のダイニングテーブルにラップトップを置いて書いている。これはエルゴノミクス的にはイマイチだが、腰痛とか肩こりが辛くなるまえに持ち時間が終わるので現実的にはそれほど困らない。

会社はとうぜんデスクもあるし、でかいモニタもあるし、でかいワークステーションもあるし（そもそもこれが必要なのはコードがでかいせいだが）、インターネットは速いし、そのへんに休憩用のソファも転がってるし、雑談したいならテラスもあるし、考え事をしながら歩き回れる空間もある程度はある。コーヒーもあるし、おやつも無限にあるし、食事もでる。空調もちゃんとしている。まあこれは自宅でも大して困らないけれど。

同僚も同じ空間にいるから、ちょっとした用事で捕まえるのに苦労しないし、コードレビューで押し問答になりかかったらデスクまで歩いていって相手の画面で IDE を開き、ほらここが・・・とかいうこともできる。

翻って自宅はというと、デスクはないし、でかい画面もないし（奥様のデスクにはモニタがあるものの、散らかっていてアクセスできない）、CPU はラップトップだし・・・まあこれは特に困っていないが・・・インターネットは遅くはないもの会社ほど速くないし、休憩で座れるソファは捨ててしまったし（無印の beanbag cusion があるが、ソファのほうが快適）、歩き回るには狭いし、コーヒーは自分でいれないといけないし、おやつは限られているし、食事は自分で作らないといけない。今日は面倒なので昼飯抜きにした。

困った時につかまえる同僚もいなければ、無駄にダベる相手もいない。猫はいるが、こいつらは仕事という観点では邪魔である。そして夕方になると妻子が帰ってきて仕事を続けることができない。8時間働けないだよ。

上司や同僚の目がないならサボってインターネットやり放題じゃん、みたいな仮想問答もありうるが、仕事をしなくても給料をもらえる身分ではないので別にサボりたくはないのだよ。むしろ同僚の目のおかげで背筋が伸びるくらいがちょうどよい。息抜き程度にさぼりネットをするのは、同僚がいようが別に構いはしないし。今日はむしろ選択掃除片付け炊事など家事への圧力というか引力を散らかった部屋や溜まった洗濯物から読み取ってしまい、気疲れした。というか部屋を片付けて洗濯して晩飯の準備までしてしまった・・・。

会社にいきたくない理由としてよく通勤を上げるのを目にする。でも自分は片道キックスクーターで 30min 未満なのでそれほどイヤではない、というか、むしろ軽く運動しつつ音楽なり Audiobook なりの音声メディアも消化でき、仕事のはじまりと終わりを仕切るいい節目になっている。仕事に区切りをつける良いで、歩いて五分で会社より、このくらい距離がある方がいいとすら言える。端的にいうと自分は通勤は割と好きである。

というわけで仕事するなら会社いいとこじゃんと再確認した。仕事のためにデザインされた場所なので当たり前なんだけど。

自分の生活は会社で仕事をするという前提にあわせ最適化されているのだから、これはもちろんまったくフェアな比較ではない。仮に生活を WFH にあわせて最適化するとどうなるだろうと想像してみる。

デスク、モニター、部屋。これは金で解決できる。部屋はすごく高くつくが、一方で今の家賃がすごく高いのは会社のそばに住んでいるからなので、田舎にひっこせば家賃の問題は解決する。ただし田舎に引っ越したいかどうかはライフスタイルの選択だからあまり自明でない。あと各人がそれぞれ空間や計算資源を持つのって、規模の経済にあづかりにくから効率は悪いよね。同じ金を払うなら会社に使った方が良いものが手に入る気がする。コーヒー、おやつ、食事・・・もやはりかねで解決できるし、相対的には安いものな気がする。食事はそうでもないかな・・・。

あるきまわるスペースがない。たとえば自分のアパートは隣に公園がある。気分転換に散歩をするのはどうかと試してみた所、そんなに悪くはない。ただ家を出て公園一周、みたいのはやや大袈裟すぎる嫌いはある。休憩コーナーでコーヒー淹れて返ってくるくらいの粒度で一息つきたいことは多い。書斎から出て台所でコーヒーをいれればいいのだろうか。今日は台所のテーブルで仕事をしていたので想像するのが難しいが・・・。

同僚がいない。これは難しい問題で、人々は ZOOM とかを使って乗り切ろうとしているわけだが、どうかね。隣にいる方がずいぶんラクだよね。とはいえテキストでコミュニケートするのも、皆が慣れているならそれはそれでアリとは思う。東京でブラウザやってたときとか、割とそういうかんじだったし。効率が良いとはいえないが、みな等しく効率が悪いなら自分だけ割を食うことはない。

通勤しなくてよい。これは裏を返すと仕事と家庭の区切り目が薄いということで、自分はあまり嬉しくない。WFH するには仕事場の部屋を隔離しろと各種リモートワークガイドは説いているし、じっさいフリーランスのプログラマもしばしば WeWork 的なのを借りている。やはり仕事と家庭で場所をわけるのは大事なのではないか。個人の性格もあろうのだろうけれど。

たとえば自分がワーカホリック独身者だった頃のことを考えると、仕事と家庭（存在しない）を分離するのはどれくらい嬉しかったろうか・・・。それなりに嬉しかった気がするなあ。会社は家事をせず仕事をできるから良いのと同じくらいに、家では仕事のことを考えなくていい、というと大袈裟だけど、目先の仕事に追われなくて良い。そういう安全な空間として、独身者だろうがなんだろうが職場ではない家は大切な気がする。

家で働く良さについても考えてみる。

まず（妻子がでかけているなら）まったく邪魔が入らない。その静寂の良さはある。これは寂しさの裏返しでもあるが、目の前の問題に集中しやすい面はある。ただし、飽きてくるたときに周辺の雑談に耳を貸してたまに割り込んだりする気分転換ができない対価はある。チャットは、その代替にはなり切れていない。これはチームのリモート成熟度の反映かもしれないが、オンラインであまり盛り上がられてもアンチソーシャルメディア勢としては嬉しくない。

静けさの仲間として、思考の自由度は増す。職場のプレッシャーってあるよね。これは気が散るの双対だけれど、一歩下がって考え事をする上で会社ではない場所にいるのは良い。ただし WFH が常態になったとき、この detachment の魔法が持続するのかはよくわからない。たまにだからよいのかもしれない。

通勤がないのは、自分個人にとっては軽運動兼メディア消費の時間が減るだけなので別にたいして嬉しくないが、家族にしてみればそのぶん家事とかに時間を割ける。効率は良い。

同様に、休憩がてら皿を洗ったり洗濯したり、同僚ではなく奥さんとちょっと話したりというのは、家族持ちとしては悪いことではないかもしれない。仕事の隙間にインターネットするよりは健全に思える。

自分はあまりに通勤会社員に最適化されているのでうまく想像できないが、自宅で働くのに最適化した人生にはそれなりの良さがあるのだろうね。ただ大前提として勤務室・書斎はどう考えても必要そうだなあ。

台所のテーブルで働くアパート暮らし妻子持ちの自分は WFH とどう付き合っていくべきか。

とりあえず目先の疫病疎開中は、ムリなくできる範囲で WFH への最適化をすすめるべきだろうね。それは奥様にデスクを間借りさせてもらうことかもしれないし、おやつを拡充することかもしれない。

疫病が一段落したあとはどうか。ここまでの議論を踏まえるなら会社で働く方が良いというのが正しい結論なわけだが、なんとなく、たまに WFH するのは良いことに思える。妻子がいないタイミングで、仕事で込み入った考え事をする時間に充てる、とかはどうか。

なぜたまの WFH をしたいのか。うまく説明するのはむずかしいが、伝統的会社員のライフスタイルに最適化されすぎている自分になんとなく不安を感じる。無理のない範囲で別の側を test the water しておくと、その伝統的雇用が揺らいだ時にすこしはマシに振る舞えるのではないか。あとは単純に、気分転換かな。会社、たまに息苦しいよね。たまにね。

世間が covid-19 の感染に震えるなか子が frozen-13 すなわち Frozen に七年遅れで罹患してなにかと Let It Go を聴きたがる。親として一緒に歌えないと色々と都合が悪い（というか歌えると色々都合が良い）ので覚えようと繰り返し聴いてみたけどまったく覚えられる気配なし。

歌ってどうやっておぼえるんだっけ？というか自分は歌を覚えたことがあるのか？すくなくとも 10 年以内、下手すると 20 年以内にはないような気がする。カラオケとか嫌いだし・・・。繰り返し聴いてる歌のサビくらいはちょこっと歌えるかもしれないが、そういう水準ではないのだよ。親の威厳をかけて Let It Go 全部歌う必要があるのだよ。

"let it go lyrics" などと検索すると歌詞のテキストが見つかるので、こいつを紙に印刷して壁に貼ろうかと一旦 Docs にコピーする。この感覚なんとなく覚えがあるな・・・とおもったアレだな。英語の shadowing. 印刷するのはやめて画面に Docs を表示し、ちょっとずつ再生しては一緒に歌ってみたり、再生しないで歌ってみたり。昔々にピアノの練習をしてた感覚にも似ている気がする。ほとんど覚えてないけど。とはいえ概ね shadowing である。

そしてあたりまえだが昔より英語力だけは高まっているので若干トリッキーに単語を繋いだり音が消えたりする部分があっても歌の音声と歌詞の相関を理解できる。英語やっててよかった気分をすごい久しぶりに味わえた。

たまに英語の勉強に洋楽を勧めてるのをみるけど、気持ちはわかるような、割と難しい気もするような。まあ今は歌詞の入手も音楽探すのもすごくラクだし、どんな歌もそのへんの音声教材よりは短いし上達した時の嬉しさは歌の方が上だし、いいのかもしれない。Let It Go を洋楽に数えていいのかはさておき。

それにしてもこの「覚える」訓練は子が生まれてからすっかり遠ざかっていた。久しぶり。ボソボソなりに声を出すせいもあり、普段使っていない脳の部位が活性化する（ポップカルチャー的な用法です）かんじがちょっと気持ち良い。15 分とかのそれなりに短い時間でも練習できるし、親としての歌の練習が英語の shadowing (の簡単なやつ) になっているお買い得感もある。これはしばらくやって良い気がしてきた。覚えないといけない歌も色々あるし。For the First Time in Forever とか Let It Go の倍くらい長いんだけど子が飽きる前に覚えられるのかこれ・・・。

Frozen 以前に英語圏の伝統的なこどものうた、たとえば itch bitch spider とか twinkle twinkle little star みたいな短いやつらもなかなか覚えられなくて長いこと居心地の悪い思いをしていたが、単に時間をとって shadowing 的に練習すればよかったのだな。こいつらは Let It Go と比べるとまったく盛り上がらないが一方ですごく短いのでそのうち練習して良い気がする。Frozen が片付いたらどこかで音源を探してきたい、かもしれない。あとは楽譜も欲しいなあ。

I found myself not to afford to write more, which was the original goal. This time I'm too busy, my mental traffic is so congested that I cannot have another task without harming things I'm responsible for.

Still, there are still some findings:

• I enjoyed writing these. It was fun to write some silly stuff. I love to waste time by these writing attempts. These aren't just affordable now.
• My writing tends to go too sentimental, and it degrades the clarity. I have to find a way to be more dry, concise and critical. Being emotional is easy, but not helping your thinking.
• I still have a lot of errors around articles and tenses. It's a shame. I think a continuous practice like this will help improving. It's disappointing that I cannot do it.

Again, it was fun. And I'm pleased that I can still enjoy writing these random stuff. I'll be back some other day.

These days I feel like that my procrastination is killing me. My chores are stacking up, my work is disorganized, but I cannot take any action and just keep wandering the internet news sites. My instinct is pushing back against the home obligation. At the same time, it feels guilty to spend time to thinking about work without fulfilling the home responsibility. I'm almost paralyzed by this conflict, and it's called procrastination.

Is it a matter of productivity and I should revisit things like GTD? Maybe. Maybe not. I'm depressed? Slightly, if any. Is this a midlife crisis? I don't know. I think I need some soul searching to convince myself.

I just finished the audio version of Susan Fowler's Whistleblower. There are a lot of stunning facts covered. One of such saddening points is that the harassing managers came from Google. So in theory, in a parallel universe, it might be Google. Instead of Uber.

Susan Fowler had the dawning thought that she was prepared to fight against Uber. Although it is true that she is prepared, there is no reason that it has to be Uber. I take it more as a probabilistic outcome. Uber is probably the most likely one, as its bad reputation suggests. However, I cannot think other companies, including my employer are perfectly innocent. There is so much evidences being publicly reported. Here is the latest one. The story has so many parallels to the ones from Uber's,  albeit it's a bit more nuanced.

To be clear, I haven't seen such a misconduct around me. All I have is a vaguely memory of a few rumors in this realms from years ago. I'm not sure whether I in the past years took it seriously. I just don't remember how I reacted. If I hear such kind of things today, however, I'll probably believe it. That's the effect of the movement Susan Fowler catalyzed: I no longer hold the level of the belief to my employer. While I still think it's a good place to work overall, I now consider it as a matter of some probability. The odds are on my side, but it can fail.

And the story tells me that it fails miserably if it does. I don't think I'm able to fight against it. The best I can do is probably just running away. To be honest, I'm not that confident that I even have that ability, to run fast enough.

Even before reading this book, I know I can never be like Susan Fowler and that's totally OK to me. After finishing the book, however, I now don't want to be one of the researchers in Physics department in UPenn, who stayed away from Susan once she became "the "problem". Still, I know I'm probably one of them if it happens. I don't know what I should do, how I can prepare. One thing clear is that it's not about running fast enough.

Whistleblower: My Journey to Silicon Valley and Fight for Justice at Uber: Susan Fowler

むかし Susan Fowler すげえなという話を書いたが、自分の認識は全然甘かったと深く反省した。件のブログはすごいクールにズバッと相手を切ったように見えたがそれは体裁であって、人生を賭けた一撃だったのだね。そりゃそうだよね。自分は「Stripe で楽しくやってる」とか書いたけど、件のブログを書いたせいで PR からめちゃ煙たがられたりして気の毒・・・だがその気の毒さは Uber が反撃のために送り込んできた私立探偵やおそらくインターネットトロルたちからの攻撃の酷さとくらべると些細な問題に見えてしまうという辛さのスケール。なお今は NYTimes の editor になり、思わぬ形で物書きになるという年来の夢を果たしたそうである。

Susan Fowler は home school だったため小中高と学校にいかず、いきなり大学から社会生活（というと語弊があるが）をスタートしている。それは前にインタビューを読んで知っていたが、その背景になる家庭の貧困についてはこの本で初めて知った。自分を white trash の trailer park コミュニティにいたと書いている。序盤の自伝パートはすごくアメリカ的。

その後アイビーリーグであるところの UPenn に編入し物理学の博士号を目指すが、メンヘル同級生の男に絡まれた上に大学に助けを求めたらトラブルをもみ消したい組織の意向によって逆に学校を追い出されドクターを取れない、のみならず、取得したはずのマスターの学位までなぜか抹消されてしまう。Upenn ひどすぎてびっくり。

この体験を通じて組織でのセクハラの扱いに絶望したことが、Uber での戦いへの備えになっている。UPenn での体験に限らずとにかく人生が壮絶すぎ、しかしその厳しさが Uber と戦う強さを育てたのも事実で、戦う定めの星の下に生まれた人なのだなという感想を持たざるをえない。本人の望みとは無関係に。

そんな Susan Fowler も告発ブログを書いて人生を ruin するのには恐れがあり Uber 脱出成功後しばらくは見ないふりをしていたが、ある日夜と霧を読んで覚悟を決めたという下りがあった。ナチの収容所からの生還譚が超絶ブラック企業の告発を促した。なんとも象徴的。自分もデスマのときに読んでいくらかの勇気を得た遠い記憶があるよ。

ところで Susan Fowler を abuse しつづけていた SRE 部門のクソ管理職チェーンはみな Google 出身者とされており、なんというか、がっかり。この会社のどこかにはきっと今でもこういうクソ管理職がいて、自分はたまたまそういうのを引き当てていないだけなのだろうと思うと薄ら寒い。自分はそうしたクソ管理職と戦う準備ができているか。できてないね。ハズレ上司を引いたら感傷とか責任感とかぜんぶ投げ捨てて逃げ出そうという思いを新たにした。

人々を勇気づけようと書かれた本を読んだ感想が「時が来たら逃げ出そう」なのは我ながら救いがたいが、自分にそうした勇敢さはないとこれ以上ないほどはっきり思い知ることができる本でありました。

本人による audiobook の narration は正直あまりうまくないが、時々感極まっている部分などが生々しかった。まあ、自分で読むべき類の本だとは思う。

"I found a secret." She said, after perfecting the taste of her potato salad / mashed potatoes. "To make the taste perfect, you can keep adding salt to the salad while tasting it and stop right before it gets too salty."

"It's like the Microsoft strategy for winning." I responded. "In their days they were said that their strategy was to keep running the business until they won, pouring money into it until competitors gave up." Twenty years ago, it sounded like a perfect strategy. Looking back, however, I cannot help but wondering - How many businesses had they won through this? Maybe their game console deserves the exemplar position. On the other hand, there are numerous counter examples. Think about their server market, which has lost to Linux, or mobile. A lesson from this quick lookback is probably something like this: The words from the winner sounds like the truth but you cannot tell.

That being said, I still have some respect for their commitment to the business continuity. My employer is famous for the business discontinuity. I used to think that it is reasonable, or at least make some sense. I'm not sure anymore. Instead I now believe Microsoft indeed won some ground with the strategy, and it must have paid off overall. It is just not a perfect strategy. There is no such thing.

Of course I didn't keep talking like this. That is not how couples talk. Here is what actually followed: "I think I read the same idea in Salt, Fat, Acid, Heat. I followed that advice for a while, but then noticed that it doesn't work on some occasions: Think about marinated chicken for example. You cannot taste the marinade, especially when you use some alcohol. You have to commit to some recipe, and all you can do is adjust it for each iteration."

In a sense the continuous-tasting secret resembles Agile Software Development, or Lean Methodology. You experiment, measure and adjust. In some cases, this works perfectly. For some others though, this doesn't make a lot of sense. There are software counterparts of the marinade - You have to commit. You can iterate only slowly. The perfection takes time and the early in-market does create the moat. Should you avoid software projects that's hard to experiment with? Now you know this a silly question - It's like asking you should avoid marinade. Fine. You can. But are you happy with it?

Of course I didn't keep talking like this. That's not how couples talk. Here was what actually followed: "But it works perfectly when it does. Give me a scoop. Wow this does taste perfect!"

The mobile app I'm helping to build at work has stunning number of threads and it's been complained by the system health related teams, who are monitoring the apps built in the organization and alert their developers as needed.

One day, an engineer from a neighboring team filed a bug that said "the app has too many threads". I was furious - Their teams is responsible for large part of it, and you just throw the shit to us and ridicule us? What a rude guy. I was furious also because their team has been contributing to the app unstability for a long time and debugging it has wasted a lot of my time. But this kind of them-vs-us mindset never solves any issue, so I just left the bug open and moved on (which doesn't solve any issues either, literary, but at least I don't make it worse.)

People casually create thread pools. In many cases that's not a problem. Each thread isn't that expensive after all. However, if a lot of teams who are developing compute-intensive features come together and put their efforts into a single app, each increment is gradually harming the performance.

How expensive are threads? Talking about thread overhead, the first thing people care about is the memory. Thread does allocate some memory, but the actual number is not clear. In addition to the linux thread, an ART thread is attached to each thread on Android.

In practice though, the thread creation latency becomes more like a problem than the thread heap consumption. The thread creation is serialized, blocking other threads. Even without that, it does a lot at the beginning of the thread lifetime, and its CPU consumption is visible in a startup trace data.

In short: Threads can be heavy in memory, but thread creation latency is more evident harm.

Why do teams create itstheir own thread pool instead of sharing it? Because it's easier. Creating a new one is one liner but passing around thread (or Java Executor) needs some plumbing, especially it crosses the team boundary. Also, it is often safe to have a new one if you need specific semantics, like serialized execution on a single thread. Java doesn't have a way to express these characteristics of an Executor.

If you think a bit more, you would realize that you can implement the serialized semantics over an existing thread pool. Guava's SequentialExecutor implements it for example. People just don't care. Another evidence that people don't care is that everyone creates the thread pool with number of thread as the device's CPU count. What a f*** - Multiply it with the number of thread pools. How does it possibly make sense. (I know it does in a few occasions, but it doesn't help me from the complaints from the other side.)

Java or Android could have had some API that returns an Executor with desired property but is backed by a system-(or process-)wide thread pool. That didn't happen. Whom to curse?

Using native (C++) code in the app makes the situation way worse: There is no obvious way to share threads (or thread pools) between C++ and Java. As a result, same people create separate thread pools in C++ in addition to ones in Java.

The number of thread is now the number of CPU cores multiplied by the number of participating teams plus the number of async-but-serialized executions multiple by the number of programming languages. This is crazy. And that's why the number of threads in our app is crazy large.

Solving this problem is technically trivial: You can build a cross language thread pool library that has thread sharing in mind. But it's more about organizational problems: You have to convince other teams to use that library. You have to demand other teams extra work and complexity. You have to convince that your design is right, eschewing the endless bikeshedding, while you have deadlines, as well as do others.

I don't have energy to go through all of these, but probably I should start building something small and start using it in our own codebase, then go to the rude neighbor, and then pitch it to the research org, etc, etc... Oh god it's depressing. Stop thinking too much and just start small. Later.

Another side of me appreciates where I am - It's much better to have at-least-partially-technical problems stacking up in front of myself, instead of having the need to looking around to find even niche problems to solve, or having a not-at-all-technical problems in front of, but not reachable from, me. For me a hired professional, problems I have are bread and bacon.

As instructed by my primary care doctor, I visited a specialist. I was supposed to have a pulmonary (lung) function test, but the doc said his office doesn't have the facility and I have to make another appointment to the hospital nearby. What a waste of time; What's the point of the specialist?

Without waiting for the test result, he prescribed a long-term control medicine for asthma. Why don't we wait? I was nervous, but kind of expected it. After all, asthma is very a vague categorization and the perception of the patient (me) matters a lot. And I went to the doctor, suggesting I consider myself an asthma sufferer.

Reading through the instruction of the medicine, the long list of the side effects scares me a lot. I hope I don't have to use this, but "long-term" means this is likely to become my lifelong medication. Sigh.

I was fed up with the series of my doctor visits. It's not close (20 min drive) and their office work is far from efficient. My primary care doctor/provider (PCP) hasn't shown up after my very first visit but only her subordinate NPs do. The specialist today was as blunt as I almost took it as an arrogance. I hate all of these.

My spouse has her PCP in a big hospital. It has its own strengths and weaknesses. One strength over my current mediocre small medical center is the streamlined services and the doctor's average quality of the service. The drawback is the long queue of appointments. Last week I asked her how long she had to wait for the possible next appointment. The closest date, it turned out, was about a month away. I'm not sure that is a good option. Even though my current situation is messy and has tedious arrangement, I can at least make an appointment in a few days.

Yet another option for me is the employer-provided medical center. I didn't like the idea of letting my life depending on the employer beyond the paycheck and I didn't have high expectations regardless. However, a friend of mine tried it and told me that he was very much satisfied. According to him, it has a couple of advantages over my current situation: First, the appointment latency is very short, which is a big plus. Also they are located on-site, meaning very close to my office. I would no longer have to pay about an hour plus $20 Uber fee for each visit. It'd be another big win. And so far I don't see any real shortcomings. Probably I should, and will, take a look - Once this asthma round is over.

I didn't like the employee-based services because I feel spoiled and I miss the opportunity to see "Real America." I don't have such an aspiration anymore though. Life is too hard to chase the reality behind the curtain. Now I'm happy to be illusioned.

A teammate came back from his business trip to a remote office in Asia. I found that I've missed him.

Let's call him T.  T is the one I talk the most at work, and he's the one who has interesting topics. My work days were quiet while he was traveling. And that's over.

T traveled to talk to the people below the tech stack. I and T have been talking about adding some corner-cutting private API across the stack for performance optimizations, but we knew too little about the lower layer to make it happen. So the goal of his trip was to figure the plan out with the team who know the needed details.

T went there because this is his project. At the same time, he went there on my behalf because it's also my project. Precisely speaking, it is still not a proper project with substantial commitment, but we want to make it real. T took action for that while I didn't.

T figured it out, but he probably wouldn't make it, that is, he probably wouldn't write any code for that. That's likely to be my part.

That's because ... T is a manager, specifically a TL-M. A tricky part is that he's not my manager. He did the legwork not because his reportees needed it but because he thought it was important for hitting bigger goals, for which I'm also responsible.

I feel bad for him - Probably I should've traveled instead of him, or at least we should've gone together. Or he should be able to work on the whole project by himself. The talk-code separation invites bureaucracy. I hate it, but I realized I just did call it.

I've been frustrated by my lack of the action, but I'm almost giving it up. Why do I have to depend on him? Why does he have to depend on me? Why cannot we pursue these technical challenges from the beginning to the end by each of ourselves?

This question can be easily answered in a way that critics do. But I would reject that. It's just a noise unless being actionable. I'll figure it out. Meanwhile, T has a bumper-sticker message in the intranet profile page. It says: Figure Things Out.

My English ability is declining - This is the feeling I have often these days. Although I've been accepting the fact that my English fluency is not getting better, having decline is different. I have struggled to articulate my engineering points to my teammates, which feels like a real threat.

More practice is needed, probably speaking, but writing is easier. So I decided to start some writing practice: I'll write some random trivial stuff once a day for ten days. I expect it to be plain diary and do not expect it to be worth a read. That aims to be pure practice.

What should I write about today, then? Here you go...

Why is my English fluency declining? There are several contributing factors.

First of all, I have spent no time on explicit English practice. I simply cannot afford it. This isn't great, but it's just a plain fact.

Secondly, I've largely withdrawn from podcast listening for a month. I still listen time to time, but my phone no longer has any podcast app installed. The intention was to spend more time on long-form audio books and my own thinking, and it paid off. However, thinking more to me means thinking in Japanese, and also listening to written English like Audiobooks isn't like listening to people speaking and somehow doesn't have the language gravity podcasts had. It might be matter of taking back podcasts again to my life, but somehow doesn't feel like that today.

Relatedly, I feel myself in a kind of introspective mode these days. I like to be introspective, but it's not a great way to be aware of languages. What's worse, my introspection is solely done in Japanese.

Probably I should spend more time on consuming spoken media, talking to people and thinking in English. I don't feel like that, but there needs to be some balance to hit. This writing project is a not-so-promising attempt to hit the balance.

By the way, have you tried Google Docs' spell checker recently? It's amazing. I wrote the text above in a single path, and pasted it to a gdoc, and edited based on the suggestion. I underscored such edits. I guess I could've spotted some of them if I re-read, but all of t hem. It's worth highlighting - It tells me my misspelling patterns.

Anyway, spell checker. It's worth a shot. (I guess GMail is now using the same checker, but I'm not sure.)

Edit: I've made several edits after the spell checker applied. There are endless mistakes and rough edges.

インドに住むフェミニストのアメリカ人が書いた子育ての本（ひどい要約）"Women's Work" の後半、著者は取材旅行のためはじめて家を空けてたびに出る。夫のために子育てカンペなどを整理しながら「なぜこんなことを」と理不尽に感じ、しかし旅先では「自分はもっと早くからこうすればよかった」とある種の達成感と開放感に浸る。そんな下りがある。

これを読み、自分の奥様にも家を空けて外出してほしいなと思う。何度か水を向けているだが、まったく進展しない。自分にとっても目先ではやや面倒が増えることなので頑張って urge しつづける意欲もなく立ち消えになるのを繰り返している。でも、たぶんそこは頑張って繰り返し背中を押すべきなのだろう。

自分が出張に感じる強い抵抗は、結局そこで生まれる借りを返せる見込みのなさに根がある、気がする。自分はただでさえ、たとえば podcast の録音や出張者とダベる外食などで帰宅を遅らせ、奥様に負担をかけている。つまり細々とした貸しが積もっている。しかしそれを返すことができない。返せない借金がある身で更にでかい借金（出張）をするのは気が重いので出張から逃げてしまうが、これは明らかにキャリアを損ねている。友達と遊びに行くとかも同じ理由で難しい。つまり自分が必要に応じて出張とかをするためには、奥様に旅行とかに行ってもらう必要があるのである。別にいいよとかいうけど、借金踏み倒すしか選択肢がない倫理的イヤさが伝わってない。

なんとなく mortgage の利息を決めるクレジットスコアを稼ぐために車のローンを組む、みたいな理不尽さを感じないではないが、そういう金融的メタファはさておきちょっと遊んで息抜きしたり人間関係を回復したり自分のことを考えるまとまった時間をとったりしてくれた方が関係性として sustainable に思える。現状には deadlock 的息苦しさがある。信頼を勝ち得てないのではという指摘も有りうるが、別に一通り子の世話をできることはわかっているのだからその点で自分にできることはあまりない。子と自分を信用して出かけてもらうよう強く促す必要があるのだろう。

ロジスティクスの問題として、家に車が一台しかないというのがある。自分は緊急時のため、あるいは平日だったら drop-off/pick-up のために車がいる。奥様が外出に車を使いたいとなると、どちらかが借りるなりタクシーなりで妥協しないといけない。借りた車で長距離でかけなくないという旅行者の思惑と、慣れない車に子供を乗せるところで苦労したくないという留守番者の思惑が食い違う。車くらい借りてくれよ・・・といいたいが、もしそれが本当に blocker なのだとしたら・・・自分が借りた車で送迎なりするのかねえ。まあいいけどロジスティクス的な不自由さはずいぶん増してしまう。が、そういう細部でフリーズしてないでガっと話を進める太っ腹さが求められているのだろう。 車をもう一台買う…のはあまり考えたくない。

もっと無責任に子供おいて遊び行くねじゃーねーとかいって出かけちゃってくれるとある意味ラクなのだが・・・というなんとも歪んだ悩み。

喘息関係で医者に行く手前、軽く予習。CDC のサイトをチラ見したあと、リンクされていた NIH のガイドにも軽く目を通す。

基本的には 1. 診断を受けて薬をちゃんと飲みなさいね 2. 環境要因を排除しましょうね。という話だった。そして NIH 的には 1 がメイン。そして投薬などのガイドラインを読む限り、いまのところ医者は間違ったことは言っていない様子で安心。自分はいまのところ short-term relief の薬しか使っていないが、long term control の薬も受け入れた方がいいのかもしれない。Inhaled corticosteroid の副作用は、割と控えめっぽいし。Oral はやばそうだが。まあしかし、あまり嬉しくはないなあ。環境要因の理解は、なんとなく自分が子供の頃から大きな進歩はないように見える。

そして自分はそれら環境要因の回避をかなり内面化しているのを思い出す。ある時期までは気にしていなかったが、奥さんと暮らしはじめてからというもの自分の神経質さを痛感している。最初のころ奥さんの家に遊びに行ったとき、あまりに possible asthma triggers に溢れていて発作が起こるのではないかと恐怖で気が気でなかった。埃をキャッチする布製品や毛糸製品ばっかりじゃん！やめてくれよ！みたいな。発作がおこることはなかったし、もうだいたい慣れたけど。

布にせよ毛糸にせよ、肌触りがいいから人々は好きなのだよね。一方でこれらは house dust の巣窟になりがちなので、自分は無意識に避けている。カーテンはツルっとした化繊のものを買っていたし、ソファもラグも持たなかった。自分の親が同じ方針だったので特に気にしなかったが、結果として家は殺風景になる。屋内に温かい景観を与えたい人とは意見が衝突しがち。

部屋に置くものに限らず、この喘息トリガーの回避を内面化した態度とそうでない人の衝突は時折おこって困惑する。最近のハイライトは去年のフランス旅行。喫煙者満載のカフェで「ゆっくり過ごす」みたいのは完全な恐怖体験なのだが、そういう感覚は理解されない。

ただ、そりゃ理解できないよなとも思う。他人の恐怖を理解するのは難しい。たとえば被痴漢行為経験者が公共交通機関に感じる恐怖とか、自分はきっと理解できないよね。これは辛抱強くコミュニケーションしていくしかないのだろう。

自分の子は喘息持ちっぽい兆候を見せており、自分は家の現状がもつ悪影響を心配している。しかしこれはまだ顕著化していない問題なので、フェアな形で懸念を伝えるのが難しい。あまり悪化しないといいなと思いつつ暮らしている。

Wunderlist がもうすぐなくなるので行き先を探さないといけない。

主要な使いみちは夫婦共有買い物リスト。条件としては iOS と Android 両対応で、できれば Web もあるとよい。結論としては Todoist でも使うか思っている。しょうじきそんなに好きではないが、ひげぽんも使っているので。（困った時はひげぽんの真似をしろ。これ人生の tips.)

眺めてはがっかりしたアプリたちを記録しておく。

• Microsoft To Do: Wunderlist の公式後釜。出来は良い。しかし自分は Microsoft ID を mess up しがちでトラブルが怖いのと、あとは背後に巨大な Office の影がみえるのに抵抗がある。Microsoft にも Office にも他意はないが、そういう巨大なものに sign up したいわけではないのだよ・・・。じっさい Microsoft To Do のウェブアプリをみると Office への導線はあるが Office から To Do への導線はない。かわりに Outlook Tasks Powered by To Do とかいうのがあって、そうかお前が黒幕か、みたいな気分になる。Outlook にも他意はないが、そういうのはいらないの。自分が大企業の犬なせいで org chart の臭いに敏感すぎるかのもしれない。
• Remember The Milk: まだあったのか！そして 2016 年に大型アップデートをし、ついにアイテムの順序を DnD で並べ替えられるようになったという。これだよこれ！・・・とおもったが、アプリがあまりにもゼロ年代というか肝心の並び替えができない。アホなの。ついでにウェブでは Google Sign-in できるがアプリではできないとか、そういえばゼロ年代世代ってこういう感じだったねーそんで mobile first みたいな標語が持て囃されたんだよねー・・・と懐古してしまった。ログインすると過去に productivity obsessしていた頃の黒歴史 TODO が発掘されたため、そっと削除。さようなら Web 2.0.
• Any.do: 割とよくできていて個人的には好きなのだが、VC money を燃やしつつブレイクできてない感にあふれており、有り体にいうと数年で潰れそうな気配。 奥様にも使ってもらうため、あまり冒険したくない。
• TickTick: アプリの起動が妙に遅いのと、なんとなく没個性なのでパス。いちおう GTask という Android アプリが元らしいので Android が主戦場のはずだが、それにしちゃシャキっとしなくね？

なお Wunderlist とは別に長期的なタスクのトラッキングには Basecamp を使っている。こいつを Todoist に統合できるとよいんだけど、複数のプロジェクトにある TODO を串刺しで一覧できる dashboard みたいのがないと Basecamp は置き換えられないな。

ツール探しは本来楽しいものであるはずだが、めんどくささしか感じない。老化か。

これとは別に自分の TODO を管理するアプリがほしいとぼんやり思っているが、今のところ何も使っていない。なぜかはうまく説明できないけど。これを機に Todoist 使うとするか・・・。

• Vega-Lite: A Grammar of Interactive Graphics

Altair は vega-lite というのをつかっているらしいが、これと Vega の違いがよくわかっていなかったので元ネタの paper を読む。

Vega-lite も Vega もフォーマットが JSON である点は一緒。Vega が低レベルの表現なのに対し、Vega-lite はもうちょっと高位の表現を持ち、その高位の表現から Vega のデータを生成する。Vega-lite をみると、Altair は要するに Vega-lite の Python 表現なのだとわかる。

Vega にしろ Vega-lite にしろ、データを JSON につっこんで JS のライブラリに描画をさせるアプローチ。これによってホスト言語 (ex. Python) 非依存にできる。そして対話性を与えられる。

理論的には良さそうだが、実際には弱点もある。まずでかいデータに弱い。せっかく Pandas がでかいデータを持てるのに、それを JSON に変換すると効率性が失われる。実際データポイントの上限が 5000 個に制限されており、適当に 1000 ずつサンプリングしたヒストグラム用のデータを 6 個つなげるとエラーになったりする。というか昨日その問題にぶつかった。サンプル数を減らせばいいんだけど、そういう制限気にするのかったるいのだよ・・・。データポイントの上限にヒットしていないのに描画中に死ぬこともある。ipynb も無駄にでかくなる。PNG を保存したい場合は Selenium 使ってねとかアホなの？（実際は右クリックで "save image" することもできるが。)更にこの裏返しとして、遅い。

対価として得られるはずの対話性: コードを書いてる身からすると図の上での対話性とか別にいらないのだよね。コードをいじって再描画すればいいので。図の上での対話性は、たとえば The Upshot や Distill などの data journalism みたいな文脈で意味があるのは理解している。D3 とかをやってた研究室発なのでそういう対話的可視化に注力しているのもわかる。でも自分には必要ないし、そのためのコストが生産性に跳ね返ってくるのが厳しい。

一方でブレイクダウンをいい感じにやってくれる高位表現というアイデアの力は、Altair をさわっているとたしかに伝わってくる。こういう気の利いた API を Python ネイティブでバリっと実装したライブラリがほしいなあ。

Python native の気の利いた API というと Seaborn があるわけだが、一旦 Altair をみたあと Seaborn をみるとしょぼい。Altair/Vega-Lite の uniformity は、冗長性はいまいちだけど納得感がある。Seaborn はそれと比べるとだいぶ ad-hoc である。というわけで自分が Seaborn を使うことはなさそう。

まあしばらくは DataFrame/Matplotlib と Altair の間を行ったり来たりします、というかまた SQL 仕事の機会がきたら考えます。

なお paper は Grammar-Based Visual Encoding の歴史を軽くおさらいしており、そこは勉強になった。The Grammar of Graphics はそのうち読みたいと思いつつ何年もたっているけれど、これが Tableau の言及になっていたとは知らなかった。

はー可視化とか一度くらい真面目に勉強してみたいもんだわ・・・。

• Friendfluence: The Surprising Ways Friends Make Us Who We Are: Carlin Flora

友達って大事だよね、変な友達もつと大変だったりするけど、でも大切だよね、という本。ベタな自分語りではなくよく取材されて書けれており、そうですねと思いながら読んだ。

自分の人間関係の雑さを反省し考え直すきっかけになればと思って読んだが、友達大事だよね、そうだよね・・・みたいな気分以上のものは特になかった。別に social skill みたいなものを学びたいわけではないが、その手の自己啓発色が強いのを読む方が何かしら provoke されるかもしれない・・・が、またこんど。

ふと思い立って ftrace 周辺のドキュメントを軽く冷やかしてみる。数年前から Sphinx ベースになったらしい・・・。

• Linux Tracing Technologies — The Linux Kernel documentation
• コードは、ちらばってるけどこのへんとか。

自分の五年前の理解は、間違ってはいないがだいぶ雑だった。

FTrace はもともとはカーネルのコードで GCC のプロファイラオプションというか gprof を使えるようにするというもので、ただカーネル空間にはプロファイラのランタイムがないのでカーネルが自前のランタイムを提供していた、らしい。そのランタイムのインフラに他のトレース機構、たとえば tracepoint が乗っかってきた。ここでいうランタイムは、具体的には CPU スレッド単位のリングバッファ。Android の ATrace もこのバッファに便乗している。

コンパイラが関数単位で instrument するタイプのプロファイラは全然スケールしないので、ある規模以上のコードベースではふつう sampling-based profiler を使う。Linux も perf とかはサンプリングベースだったはず。

ただしそれとは別に、FTrace は "dynamic ftrace" という仕組みを追加した。カーネルのコードをプロファイラ有りでビルドしつつ、ランタイム関数の呼び出しは起動時に全部 nop で塗りつぶす。この塗りつぶしができるよう、呼び出し箇所の一覧を事前に作っておく。そして API で関数を指示すると nop の所にランタイムへの呼び出しを書き戻す。デバッガがやるようなことをカーネルの機能として提供している。たぶん今はこっちの方が主流っぽい。手元の Ubuntu ではふつうに有効になっている。Android はセキュリティのためカーネルを read only にしている都合で無効らしい。でも性能改善のドキュメントで紹介するくらいなら userdebug では有効にしておいてくれや・・・カーネルのリビルドとかやりかたわかんないよ・・・。

そんなかんじで Android からはカーネルの中に明示的にうめこまれた tracepoint たちとユーザ空間から書き込まれたデータしかトレースできない。まあいいんだけど。

Tracepoint のようにプログラマが手で足すにしろ Ftrace のようにコンパイラの助けを借りるにしろ、トレースの記録通知と通知を受けて何をするかは分離されており、イベントハンドラみたいのを（カーネル空間で）登録できる。リングバッファに書き込む、という部分はそのイベントハンドラの責務となっている様子。なかなか正しいデザインと言える。Brendan Greg の BPF 本では BPF をカーネルのイベントハンドラと表現していた。実際トレーシングのインフラがイベントハンドラを提供しているんだね。

Perfetto も自分でトレースフックのカーネルモジュールを書けば効率的にデータを読み出せそうなものだが、そんなカーネル依存のことはしてないだろうなあ。

リングバッファに話をもどすと、バッファには trace_pipe を読むとでてくるテキストが直接書き込まれているわけではなく、何らかのバイナリ列を書き込む。そして trace_pipe を解釈するタイミングでそのバイナリをテキストに整形する。なお ATrace はユーザ空間から任意のテキストを書き込める trace_marker という API を使っているので、じっさいバッファにテキストを書き込む。整形の仕組みをユーザ空間からもアクセスされてくれればよかったのに・・・。なお trace_marker_raw というバイナリ列を直に書き込む API もあることはある。

トレーシングというものの実装としてはだいぶがんばっている例の一つだと思うので、参考のためにもうちょっとコードを読んでみたいもんです。そのうち。

久しぶりにログを SQL で調べものをする仕事。二日くらいで終了。

昔にくらべ SQL は相変わらず下手くそだが Pandas/Matplotlib スキルが上がっており、それなりのチャートを Pandas だけで出せるようになってきた。結果として、二年前の "SQL 書くなら Altair 必須" という気分は消え去り、気がつくとぜんぶ Pandas で済ませている。たぶん当時は Pandas と Matplotlib を混ぜて使えなかった。今は Pandas の plot() が matplotlib の薄いラッパであるという事実を活用し、subplot したり axes 重ね書きしたりできるようになった。

とはいえもうちょっとモダンでシュッとしたライブラリを使えた方がいいんじゃね・・・という反省もあり、今回描いたチャートを一通り Altair に移植してみた。が ...mixed feeling. コードはすごいコンパクトかつ宣言的になるし、描かれるチャートもいいかんじ。でも自分の生産性がどれだけあがるかは微妙。

生産性を妨げる要素は、大きく分けて二つある。

ひとつ目は、自分のデータ力の低さ。Altair は入力の DataFrame が tidy data 的に正規化されていることを期待している。Altair が ggplot の追っかけである事実を考えると当たり前の帰結なんだけど、自分の手元のデータは必ずしも tidy でないので reshape しないといけない。でもデータの reshape とか素人には認知的負荷が高いのだよね。Pandas の API もわかんないし。今回のデータでいうと、ひとつ目のチャートは pandas.concat で複数の DataFrame を連結する必要があり、ふたつ目のチャートでは DataFrame.melt というので unpivot した。データの最終型がわかっていればこうした API を探す心の余裕もあるけど、実際の問題の中でごちゃごちゃやってる時には新しい API をみつける気力が無い気がする。同様に SQL も一段階がんばって書かないといけない。最終的に tidy な DataFrame をつくるための小細工とかを SQL に入れる必要があるので。でも SQL とかわかんないのだよ・・・。

一方で Pandas を生で使っていると適当に for 文を回しながらゴミのようなデータから手続き的に欲しい絵が出せるので、問題を考える mental bandwidth を浪費しない。たとえば一つの tidy DataFrame を使うかわりに、二つの単純な SQL のクエリから持ってきた二つの DataFrame を順番に使う、みたいなことができる。ただしコードはゴミ。

Hadley Wickham の Tidyverse がスパルタなデータサイエンティスト養成ギプスとして機能しているように Altair を tidy data 養成ギプスとして受け入れるのがあるべき姿なんだろうけど、自分なんて通りすがりで四半期に一回くらい SQL 書くだけなので、正直そこまでがんばりたくない。弱音吐いちゃう。

ふたつ目は Altair の API ergonomics。

Matlab あたりから延々と鍛え抜かれ磨かれた Pandas/Matplotlib の API は色々ダサいが、一方で使用頻度の高い機能がトップレベルの雑なキーワード引数でズバっと実現できるハフマン符号化的強さがある。しかももれなく SO の回答がある。たとえば outlier を適当に無視しつつレイテンシのグラフを書きたい時、Pandas なら df.plot(...., y='latency', ylim=(0, 10000)...) とかやればいいところで Altair は ....encode(..., y=alt.Y('latency', scale=alt.Scale(domain=(0, 10000), clamp=True)), ...) とか書かないといけない。気持ちはわかるがもうちょっとなんとかなんないんですかね・・・。Altair も所々にショートカットを揃えようという意思は感じるが、ベースの API がやや大げさな上にプロジェクトの若さゆえユーザビリティの苦情による API の圧縮が進んでおらず、上のようなかったるさにしばしば遭遇する。SO も頼りにならない。

Ergonomics 上の問題その二は、ベースにある Vega というオブジェクトモデルが言語非依存なせいで発生する冗長さ。Altair は自分自身がデータを dice and slice する仕組みを色々もっている。まあデータのブレイクダウンが必要なのである程度は仕方ないと思うんだけど、Pandas でやらせてくんないかなあ。一連の Data Transformation の仕組みなんて vega expression というナゾのミニ言語を使わされて、しらねーよという気分。ただし、いまドキュメントをみたら「できるなら Pandas 側でやりましょう。そのほうが便利です」と書いてあるのにきづいた。なんなの・・・。

Altair にせよ Vega にせよ ggplot と戦う気なだけあって色々よく考えられ、その結果としてよく練られた抽象がある。ドキュメントも割とよく書けてる。ただ裏を返すと大袈裟で、学習勾配がきつい。通りすがりのモバイルプログラマにはやや荷が重い。

がしかし！データワナビーとして我々は！背伸びをしてでもモダンなフリをキメるべきではないか！問題解決原理主義者に負けるな！

コードは短くなるしチャートはシュっとしているし DataFrame は Tidy になるし、良いことは良いんだよねー。まあ締め切りの厳しさと相談しつつぼちぼち使っていきたい所存。SQL 仕事だけじゃなく普段のベンチマークの結果整形とかにも使って体を慣らしていくのが良いかもしれない。

追記

Colab の local runtime ではちゃんと動かないことが判明しがっかり・・・。

前回かいた Systrace (というか Ftrace) データのパース、やろうとおもいつつ procrastinate していた理由の一つは、それより Perfetto の trace processor を使う方が良いのではと思っていたからだった。が、まあ気のせいだったね。

Trace processor は Perfetto のダンプに sqlite でアクセスできる機能があり、これは魅力的である。ただ現実には自分は特別 SQL が流暢ではないので Python で regexp して Pandas で加工した方が速いし、できることも多い。例えばこのあいだアロケーションのレイテンシとサイズの相関を求めたが、その解釈にはネストした trace section を紐付ける必要がある。これは for 文で書けば自明だが SQL だとどうしていいかわからん。しかもその trace processor には Pandas インテグレーションとかがないので可視化もできない。使えねー。

より深刻な問題は Perfetto が lossy である点。Perfetto はオンデバイスのコマンドで、自分でバッファを持っている。ということは ATrace の API も Perfetto に直接フィードするのかな・・・と思いきやそんなことはなく、引き続きカーネルの trace_marker に書き込んでいる。言われてみれば atrace/systrace の動作を壊すわけにはいかないので当たり前だが、つまり Perfetto は ftrace のバッファをパースして Perfetto の protobuf に詰め替えているということである。しかもオンデバイスで！まじか。そんなことで余計な CPU サイクル使わないでくれよ・・・しかもオンデバイスなんてロジックにバグあったら直せないじゃん・・・デバイスの外でやれよ・・・。

オンデバイスでやりたいのはオンメモリのバッファでけでなくファイルに書き出す長時間トレースをサポートしないなどの事情と関係あるのは理解している。しかしトレードオフには納得できない。実際、Q のオンデバイストレース (perfetto フォーマット) を Systrace のデータに変換しようとすると失敗したり、エラーにはならないが表示が壊れることがしょっちゅうある。一方で Perfetto ネイティブなビューアは機能がたらない。だめじゃん。Perfetto Native UI は wasm とかをつかっているあたり、いかにも実用的なものをつくる気のなさを感じる。というとディスりすぎかもしれないが。

自分が Perfetto への乗り換えを考えていたのは Q から on-device tracing のフォーマットが Perfetto に変更されたからだが、こうした不利益をわざわざ受け入れる必要はないと考えを改めた。特に ATrace が引き続き ftrace に依存している事実を考えると ftrace のバッファが the source of the truth なわけで、間に lossy な Perfetto を挟むのはリスク。やめやめ。引き続き Systrace で生きていきますわ。

Perfetto は Chrome と Android 共通のインフラにすると主張している。そんなら Chrome で枯らした後で Android に持ってきてほしかった。勤務先には "a shiny but work in progress way と a functional but deprecated way がある" という格言がある。Perfetto はその一例になっている感。そういう場合は常に the deprecated way を進めというのが先人の知恵で、自分はそれを体現してしまったのだった。Sigh.

追記

Perfetto の UI がバージョンアップし、以前は表示されなかったメトリクスが見えるようになった。そして後ろの席の同僚は文句をいいつつがんばって perfetto コマンドを使っていた。そうですね我々会社員には使ってバグを踏んで報告して直させる、という暗黙の責務もあるんですよね・・・。職業倫理の差を感じる。はーつかうか・・・しかし Colab から読めねーんだよなー・・・ヒマなら業務外で Perfetto に首を突っ込みたい所だがちょっとなー・・・。

前回のつづき。

機能 F が招くコマ落ちの原因探求、最初の被疑者たる CPU 負荷は無罪の見通しとなったため、他の指標をさがす。

コマ落ちの直接の原因である HAL API A のレイテンシは機能 F の有無でどのくらい違うんだろうか。Systrace の HTML を肉眼で眺めていてもいまいち決定的な違いが見えない。重い腰を挙げて Colab を開き、適当に正規表現を書いて Systrace 内のデータに含まれる該当 API のトレースを読んでレイテンシを抜き出す。そして時系列にプロットしてみる。

と、やはり F 有効時はちょっと悪い気がする。しかしなぜかがわからない・・・。

さて、件の API は何かと言うと、共有メモリ (gralloc) のアロケーションである。そして件の API 内部のトレースには要求されたメモリのサイズが書いてある。このサイズを見ると、誰が要求したメモリなのかがひと目でわかる。そしてサイズがでかいほどレイテンシは大きくなりがち。

ふと思い立ってパーサのロジックを書き足し、プロット (scatterplot) にサイズを反映してみる。X 軸を時系列、Y をレイテンシ。サイズを色に割り振ると・・・やはりサイズがでかいアロケーションは遅い。そして F 有効時はそもそも「サイズのでかいアロケーション」の数が多い！沢山の細かいアロケーションに隠れていて気づかなかったが、こりゃ遅くなるわ！アプリのログや同僚へのインタビューでこの事実を確認する。振り返るとアルゴリズムの性質から自然な帰結である。OMG.

この初歩的な問題に何週間も気づいてなかったのは shame. 肉眼さん・・・。

API リクエストの頻度自体は他の機能によるリクエストが支配的で、総数は機能 F の有無で大きな差はない。しかし他の機能がリクエストするアロケーションはぜんぶサイズが小さい。F によるアロケーションはでかい。しかも F のスレッドが直接リクエストを発行するのではなく、F がメモリを長時間保有するせいで普段はプロセス内で資源が再利用され省略されるアロケーションが発生してしまうという間接的な症状なのでグチャっとしたトレースを睨むだけでは気付けなかった。

というわけで可視化重要。あとゴチャっとしたデータをパースして構造化するのも重要。トレースをパースするコード片を書き溜めないとな。

可視化素人としては subplot の利用と scatterplot の color axis を使えるようになったのが最近のブレークスルーであった。

とある機能 F を有効にするととある操作 T のあとでコマ落ちするという、ユーザ（上司）の手元では再現するが手元での再現率がいまいちなバグを直そうと苦戦しつつはや数週間。

ハイレベルには、F を有効にした状態で操作 T をトリガーすると瞬間的に CPU の負荷が跳ね上がり、画像パイプラインのクリティカルパスにある HAL API である A のレイテンシがフレームレートを超えてしまい、コマ落ちに至る。

A のレイテンシは普段は余裕で予算に収まるのだが、他のタスクが増えると CPU のサイクルを奪われて遅くなる。症状から A の重要性は明らかなので A が動くスレッドを SCHED_FIFO にしましょうと主張してパッチを書いたが、OS のひとにインパクトでかすぎるのでダメと押し返されうーむとなる。

なお HAL の一部では SCHED_FIFO はぼちぼち使われている...まあ「ぼちぼち」は overstatement かもしれないですね。はい。従ってこの問題は priority inheritance で解決されるのが筋だが、俺のせいじゃねー的 API のせいでその仕組みは使えないのだった。

それはさておき操作 T 発動時の CPU 負荷は機能 F の有無に関わらずどのみち高く、全てのコアが振り切る。機能 F のアルゴリズムが高価なのは事実だろうが、ほんとにコマ落ちの有無を決めるような規模のインパクトがあるのだろうか。こういう雑な仮説を盲目的に信じては痛い目に逢い続けて数年、いちおう検証しておこうと思い立つ。

タスクが多すぎてタイムスライスがもらえないとか、ロードアベレージみたいなのをみればいいんだっけ？と検索すると Brendan Gregg のブログがヒット。要約すると Linux の load average の数字は微妙なので他の指標を使っときなよとのこと。他の指標としては BPF が使えるよ、とかいうが Android でそれは大変。別の候補として紹介されている  /proc/schedstat ファイルを polling してみることにする。

ドキュメントおよびインターネットによると同ファイル内で "sum of all time spent waiting to run by tasks on this processor (in jiffies)" という数字を監視すればよいようだが、Jiffies ってなんやねん。その manpage およびインターネットによるとスケジューラのクロック、たとえば 100Hz だったら 10ms とからしい。なるほど・・・と値を眺めるが、全然合ってない。桁がいくつもちがう。最初は自分の雑なコードが計算ミスをしてるのかと思ったがそんなこともなさそうな雰囲気。はーなんだこりゃ・・・と落胆して帰宅。

翌日気を取り直してカーネルのコードを睨むと、数字の出どころは sched_clock() という関数らしい。実装が複数あるのでよくわからないが、ドキュメントは単位をナノ秒と主張している。 10ms と 1ns じゃだいぶ違うわけだわ・・・。ナノ秒として計算してみるとそれっぽい数字になる。やれやれ。カーネルのドキュメントも案外信用できない。

さてこうして計算したオレオレロードアベレージを定期的に ATrace_setCounter() しつつアプリをつついてトレースを眺めたところ・・・機能 F が有効だろうが無効だろうがロードに全然違いがない。

冷静になってトレースを見直すと機能 F はスレッドが一つ増えはするものの大した並列度はなく、そのスレッドも GPU に計算を投げたり他のスレッドの計算結果を待ったりで必ずしも全力では回っていない。仮説敗れる。はー・・・。

ではなぜ機能 F はコマ落ちを招くのだろうか。ユーザ（上司）の思い込み？でも自分の手元で問題がおきるときも機能 F の有無は影響ある気がするのだよなあ。

そして書いていて気づいたがトレースには sched の tracepoint が含まれているのだからカーネルが集めた stats を使うより自分で事後的に計算した方が色々わかることが多いきがする。たとえばカーネルの stats ではレイテンシの分布はわからない。ただその計算をするにはもうちょっとカーネル詳しくならんとムリだな。はー・・・。

年末にハカソンがあったので、自分は機能を削るとどれだけ起動が速くなるか実際にコードを消して調べることにした。一つ一つモードを消し、UI を外し・・・と一週間コードを消し続けた。しかし一ミリも速くならなかった。がっかり。

理由を考える。

まず前向きな理由がありうる: 余計なコードはクリティカルパスから取り除かれている。自分は余計なものをクリティカルパスからどかす作業を延々とやってきたわけだから、これはまあまあ的をいている。一方で、どうにも信じがたい。

最初の論点と少し関係がある仮説：起動などを遅くしているのは、モードや UI といった user facing feature のコードではなくフラグの定義やモニタリングのようなインフラっぽいコードである。そういうコードはどのみち消せないことがわかっているのでがんばって消すことをしなかったが、実際はまあまあクリティカルパスにあるのでほんとは消してみるべきだったのかもしれない。ただあちこちに断片的に埋め込まれてるので消すのが難しいのだよね。

このハカソンの少し前にフラグ取得の IPC がフラグの数だけ呼ばれまくっていたのを助っ人高速化隊のエースが発見し、それをバッチ化したら起動がぐっと速くなる出来事があった。これはインフラ税の存在を裏付けている。

自分が消していない部分に遅さがあるという意味だと、画像処理や C++ の中にある余計なコードがクリティカルパスにある可能性もある。画像処理パイプラインの「機能」は、わかる人には消せるのかもしれないが自分にはむずかしい。そしてこれらの「機能」は年々複雑化が進み、遅くなっている。

もうちょっと red herring な説: 一旦コードに持ち込まれた複雑さは、単純にコードを消すだけではキャンセルすることができない。たとえば新しい機能のためにリファクタリングして間接化や抽象化を足したとする。コードを消すと抽象化の裏にある実装は消えるが、抽象や間接化そのものが消えるわけではない。コードを消したら、そのあとよくコードを読み直して余計な抽象化を見つけ出し、それをベタなコードになおしてはじめてオーバーヘッドを取り除くことができる。かもしれない。自分は心の奥底でこの説を信じている一方、検証するのは難しいいイチャモンという面もあるのであまり強く主張する気にもなれない。

いずれにせよ「コードがでかくなると遅くなる」というのは必ずしも絶対的な真実ではないし、逆が真とも限らない。たとえばデスクトップ環境に巨大なアプリをインストールしたところで（そのアプリを起動しなければ）対して遅くはならない。一方でサーバに daemon の類をインストールすれば少しは遅くなるだろう。Android のアプリはその間くらい。単一プログラム内の余計なコードがデスクトップアプリのインストールとサーバの daemon のどちらに近いかは、ケースバイケース。というわけで「コードがでかい = 遅い」は経験則のひとつに留め、鵜呑みするのはやめましょう、という話。

そしてコードを消す話をするといつもこれを思い出してしまう人生の呪い。

Women's Work: A Reckoning with Work and Home

The Decade of the Parenting Manual - NYT Parenting で紹介されていたので読んでみた。ここにある本は半分くらい読んでおり我ながらサヨリべすぎて苦笑。そしてマニュアルではなく読み物ばかりだな、このリスト。

この "Women's Work" も例にもれず子育てガイドではなく読み物だった。著者自身の Memoir. もともと新聞記者の海外特派員だった著者が中国(北京)で妊娠し（配偶者もジャーナリストとして一緒に中国にいた）、新聞社の仕事をやめて子育てしながら本を書いてライターとしてのキャリアを続けようとする。しかし非協力的な夫を通じてジェンダー格差の現実に面し仕事が進まず、仕方なく nanny を雇ってみたら今度は中国の貧困やジェンダー格差に加担している自分に気づき思い悩む、という話。途中で第二子が生まれ、そのタイミングで夫の仕事の都合にあわせインド(New Delhi)に引っ越す。そこでまた nanny を雇い、同じ悩みを繰り返す。

ここで終わると傲慢なアメリカ人のうざい独り言なのだが、後半ではジャーナリストとして過去に自分が雇った（そのうち一人はクビにした）nanny に会いに行ってインタビューをする。そこは面白い。自分が employee として見ていた nanny たちのおかれた現実をジャーナリストとして revisit する著者の倫理的葛藤みたいのがよく書けている。

あと「うざい独り言」はやや言い過ぎで、自分も外国で子を育てている手前、そこにはある種の共感があった（インドに住むアメリカ人と比べるとカネの力で殴る経済力はないが）。そして自分はジェンダー格差の受益者なので、著者が夫にブチ切れるところでは胃が痛んだ。この手の本にでてくる夫は割とみんなひどい気がするのだが、自分がそうでないとなぜ言えよう・・・。

Amazon のレビューを見ると "White Privilege Horror Show" という批判がある。でも著者はそれに自覚的で、けれどその傲慢さを隠さない正直さみたいなのが面白いと思う。自分も読んでいる途中で著者のアメリカ人っぷりに笑ってしまう箇所がいくつもあった。書き手としての「声」がある点で「正しさ」に塗り固められた Lean In より個人的には好ましい。声といえば audiobook の narration はその鼻持ちなら無さを完璧にとらえており、最近きいた audiobook の中では最高峰の出来。

子供ができたら親である自分のキャリアは終わる。それは仕方ない。理由はどうであれ、多くの母親が仕事を辞め専業母親化する事実がそれを伝えている。そうしたコストの fair share を引き取ろうとしたら、定時強制の化石技能な万年末端になるくらいは妥当。理屈ではそうわかっていても、日々の impluse がしらずしらずのうちに privilege を claim してしまう。たまにこういう本を読み calibrate していきたい。

• Zero to One: Notes on Startups, or How to Build the Future

割と良かった。スタートアップは陰謀論でカルトなんだよ！と衒いもなく言い切る政治的正しく無さといい、なにかと引用される文献が渋いところといい、ファンもアンチも多いのがよくわかる。過剰なかっこよさ。あと薄いのも良いね。個人的には、世界の秘密を暴けるような仕事がよいという下りがよかった。

• The Startup Way: How Modern Companies Use Entrepreneurial Management to Transform Culture and Drive Long-Term Growth

リーンスタートアップどういう話か忘れてたのでいい復習になった。ちゃんと innovation accounting してる企業がどれだけあるのか見当もつかないし大企業にそれを売り込める気もまったくしないが、シリコンバレーの会社というのはこういうのを読んだり本物のスタートアップで体感したりした下々が草の根的に存在するので、上の方が雑でも少しはスタートアップ・ウェイがまじりこむのだろうなと思った。

Amazon のレビューを読むと「風呂敷広げすぎ」「よくある企業改革論」みたいな批判が目につく。まあそうなのだろうね。アイデアは Lean Startup から変わってない気がするので。

こういうビジネス書を読んではなくそほじりながらフンフンとかいってるあたり我ながらおっさんだなー。ちなみに actionable な要素は特になし。

via Graphics and Gaming Development | The Bifrost Shader Core – Arm Developer

ARM の割と新しめな GPU (Bifrost) の資料を眺める。

ARM の GPU には複数の "Shader Core" がある。最大で 32 個くらい。NVIDIA の GPU でいう SM に相当する、とおもわれる。

個々の Shader Core には複数の "Execution Engine" が入っている。上の資料で参照されている G71 というやつ（最新ではない）だと 3 つの EE が入っているらしい。EE  は NVIDIA の GPU でいうところの "CUDA Core" みたいなものだと思われる。

適当な NVIDIA の GPU (ここでは Turing) の資料とくらべてみる。

Turing の SM の数は、構成によって 28-72 個である。一方で SM あたりの CUDA Core の数は 64-128 である。この比率は ARM GPU とだいぶ違う。SM/Share Core の数はせいぜい数倍程度しか違わない一方、それらあたりの EE / CUDA Core の数は 10-20 倍違う。ARM も EE の SIMD 並列化を "Warp" と呼んでいるが、NVIDIA の Warp と比べると断然狭い、グラフィクスの頂点一個を並列処理するくらいがせいぜいに見える。

これは自分の直感の逆だった。ARM の GPU は、SIMD つきのシンプルなマルチコア CPU といった風情。しかもコア数が CPU より多い。GPU はおもったよりたくさんの異種タスクを詰め込めるように見える（他にボトルネックがなければ）。一方で NVIDIA の GPU が想定されているようなでかいベクトルをバンと並列に計算する能力を個々の Shader Core は持っていない。

これは・・・どうなの？少なくとも OpenGL を使っている限り単一プロセスがこのマルチコアの性能を完全に引き出すことはできないよね。なぜなら OpenGL はマルチスレッドのタスクを投げられない・・・というと語弊があるが投げにくいから。もちろんでかい頂点列をマルチコア向けに分割して処理するくらいは GPU なりドライバなりがやってると思うけれども, NVIDIA が暗に築いてきたメンタルモデルを逆手に取る利点はなんかあるのだろうか・・・。不思議。まあ色々なプロセスやスレッドから同時に叩かれるのを助ける面はあるかもしれない。

ARM GPU の理解を深めても自分の役には立たない。Qualcomm の GPU はどうなってんだろう・・・と調べるが、さっぱりわからん。相変わらずだなこいつらは・・・。

Picture Taking Practice をはじめて現在 36 日分経過。

• 完全に毎日はできないが、まあいいです。人間風邪引いたり調子わるかったりするので。精神衛生を損なうと写真を撮らなくなりがちで、ある意味バロメータになっている。
• 一日に一回 curate する頻度は割とちょうどいい感じがする。寝る前に 10 分くらいなので負担がない。
• 家族日記として機能している。自分の個人的な記録はないが、どこいったみたいな家族としての記録が残るのはよい。
• どうせとるならフルフレームが欲しいなーと思う一方、でかいのはムリだなという気分も深まる。でかいカメラを抱えて隣の公園で散歩するのもやはり silly に感じてしまうので。APS-C くらいでいいのかもなあ・・・というか 4/3 でいいのか・・・など無駄な物欲的悩み。
• アプリ的な話
  • 奥様にも写真を追加してもらうようにした。Photos はこれができるのが便利。
  • Timelapse がすばらしい。日常の banality も圧縮によって消える。
  • Portrait も、被写体を強調する目的でだいぶよい。ボケはひきつづきだいぶ雑だが、Pixel 4 は激しい壊れ方をすることは減った(人間相手なら）。スマホで眺める分には許容範囲かなと思う。
  • Night mode は子供を録るには不向き。水族館でも普通の Photo mode の方が良い。
  • 週末、プレイデート友達家族と外出した先で子らが遊ぶ様子を両親 x2 の四名がスマホで写真をとる瞬間にはその sillyness に躊躇がある。
  • カメラアプリのバグに遭遇しがち。ぐぐぐ・・・。

休暇中に精神衛生の劣化が限度を超えてしまい、ふと思い出して朝にジムで走ってみると・・・世界が！明るくなったぞ！（比喩的に！）そういえば走った日ってこういうかんじだったわ。すっかり忘れていた。トラブル気味だった大腸も元気になった。

スクーター通勤に切り替えて以来運動ができていなかったが、それでも通勤という軽運動はしていた。しかし休暇に入りそれすら途絶えていた。もっというと、通勤ランは色々気が散りがちでジムで走るほどの効能はない。ジムで走るみたいな純粋な心拍数向上活動は子が生まれて以来三年ぶりくらいな気がする。

睡眠に続き、目をそらしていた健康上の懸念を突きつけられた気分。じっさい休暇中は色々とストレスがたまりがちで、夫婦間の空気を険悪にしないようかなりの努力を要した（つまり、たぶんちょっと険悪になってたね。）色々理由を考えていたが、単に運動不足だったとは。脳内麻薬欠乏やばい。

やはり運動は必要に思える。薬物の質という点でジムなり公園で走るのが望ましい。そして薬効を最大限活かすには朝がよい。休暇前は朝おきて会社のメールを読んでいたが、これは諦めてジムに行くべし。

とはいえジムでの運動は着替えやシャワーを含む E2E で一時間。きびしい。5:00 に起きて、5:30-6:30 運動、そのあと家事。朝のメールが消える結果、8 時間労働を達成できない問題は振り出しに戻ってしまう。このトレードオフは字面からはあまり自明でないが、脳内麻薬の欠乏（に無自覚であること）は無視しがたい恐怖を感じるのではやり運動は取り戻したい。

一方、これを時間割とすると家でラップトップを触る時間はほぼ消えてなくなる。いまは就寝前にちょこっとさわったりしているが、大して生産的でない割に睡眠を削ってしまい望ましくない。

年末からは fast を兼ねて会社では昼飯を食べず、かつちょっと時間をちょろまかして昼食前後一時間半くらいを課外活動に当てている。これが自分の課外活動の全てとなる。八時間労働できないのに時間ちょろまかすのどうなの、という話はあるけれど、ただ子の着替えやトイレを待つのに使う時間と課外活動に使う時間ではトレードオフの妥当性が違うのだよ。

家でパソコンとかさわらないプログラマってこういうかんじか・・・ほんとに・・・？しかしここで躊躇して運動しないと鬱病になってしまうのでとりあえず運動はします。はい。今日もスタバまで走ってきたよ。

今年の振り返り。

仕事:

• 自分のなかではがんばって働いたつもりだけれど人事考課に変化はなかったので、成果はそこそこということでしょう。チームがだいぶ強化された結果、あれもこれもやらなくてよくなったのはよかった。
• 課外活動の時間はどんどんなくなって、クビになるまで今の仕事にしがみつくしかないという現実の壁は高くなる一方。これを打破するには健康か今の仕事か家庭のいずれかを損ねるしかないとはっきりしているが、そうはしていない。

生活:

• Podcast をやめた結果、個人的な時間/心的予算をとりすぎている後ろめたさはなくなった。一方で子供や家のために十分に考えたり行動したりできているかというとそうでもない。自分は selfish な成分が強すぎ、子のことをいつも気にかけている「良き親」でない。なんというか intrinsic な drive がない。結果として後手に回っては後悔してばかり。システムで後押ししないとだめそう。
• 運動する時間すらなくなって、精神衛生に不安がある。

自分の行き場のなさに向き合うと暗い気持ちになってしまう。とはいえ今のところ子は健やかに育っており、自分も奥様も概ね健康で、まともな職もあり、そういうベースラインが維持できている事実は appreciate したい。ベースラインの維持は割と高く付くこともわかったけれど。

• Why We Sleep: Unlocking the Power of Sleep and Dreams 感想
• Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently by Jonathan Rasmusson 感想
• Antisocial: Online Extremists, Techno-Utopians, and the Hijacking of the American Conversation 感想
• How to Raise an Adult: Break Free of the Overparenting Trap and Prepare Your Kid for Success 感想
• How Children Succeed: Grit, Curiosity, and the Hidden Power of Character 感想
• The Writer's Process: Getting Your Brain in Gear 感想
• Oh Crap! Potty Training: Everything Modern Parents Need to Know to Do It Once and Do It Right 感想
• The Case Against Sugar: Gary Taubes 感想
• The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery by David Thomas, Andrew Hunt 感想
• The Obesity Code: Dr. Jason Fung, Brian Nishii 感想
• Digital Minimalism: Choosing a Focused Life in a Noisy World 感想
• The Curse of Bigness: Antitrust in the New Gilded Age: Tim Wu 感想

12冊。うち子供関係 3 冊。健康関係 3 冊, self-help 2 冊。アメリカ関係 2 冊。軽い技術書 2 冊。がっかりなスループットとラインナップだが、たまにはがっかりさを直視しないといけない。いつもしている気もするが。つんどく、つまみぐい、中断したやつらは書いてない。

ぜんぶ雑に感想をつけられたのはよかった。

どうでもいいウェブをみるノリでどうでもいい技術書を読むのは悪くないかもしれないと、どうでもいい技術書二冊を epub で読んで思う。ブラウザのタブに pin しておくのがいいのかもしれない。いっぽうどうでもいいもの読むならウェブの記事でよくね、とも思う。

来年は・・・と意識高い目標を口にしかかったが、嘘になる確率がたかいのでやめておく。

• Why We Sleep: Unlocking the Power of Sleep and Dreams: Matthew Walker PhD

睡眠学者が睡眠の重要性を説く本。睡眠をおろそかにしてた自分を反省した。

個人的な発見は、まず睡眠は睡眠不足してる間だけでなく永続的なダメージがあるということ。なので「一時的にがんばる」みたいのは一見するほどアイデアではない。どのみち生産性がおちるので良いアイデアではないのだけれど。

もうひとつは寝不足時の自動車運転のヤバさ。わかってはいたけど具体的な数字を挙げあれるとウっとなる。寝不足とアル中は事故率に大差ないのに寝不足が放置されているのは社会としてよくないと著者は説く。

睡眠のリズム。体のリズムは固定されていて急にはかわらないので、日によって就寝にばらつきがあると睡眠の質がさがる。つまり遅くまで起きていたぶん朝寝するとか、前の日が寝不足だったぶん早く寝るとか、意味はあるが規則正しく寝起きするより効率が悪い。

自分の朝の活動は睡眠不足だったと反省し、目覚ましを使うのをやめた。八時間睡眠 (sleep opportunity - 布団に入ってから起きるまで) を推奨されているので 21 時に寝て 5 時に起きることにして一週間くらい経過。わかったこととしては、なにもしなくても普通に 5 時くらいには目が覚める。自分は 2-3 時すぎたあたりからずっと眠りが浅く、どうしたものかと思う。ただ眠りが浅いからといって 3 時とかに起きると昼間眠いので、浅いとはいえいちおう睡眠の効果は得られているっぽい。

カフェインも昼に一杯飲むだけに変更など、ほかにも細々と生活を見直した。なお睡眠 good practice などは特別新しい話はなく、それよりは睡眠不足のヤバさを突きつけるのが主な論点。ただ論点を示された上でこうしろといわれるとだいぶ説得力がある。

朝の活動の時間が減り、かつ夜もダラダラせず寝るようにしてるので、一日が 1-2 時間短くなった。ただでさえ時間がないというのにどうしたものかと考える。が、それは別エントリで書きます。昼間の眠気は今のところ完全になくなった。

しかし朝の活動の寝不足なんてかわいいもので、自分は結婚するまでずっと寝不足だった気がするな。インターネット依存にありがちなこととして。寝不足がはじまったのをふりかえると・・・たぶん学生時代の夜間インターネット定額制度（テレホーダイだっけ？）あたりな気がする。あれはマジで壊滅的な制度だったと今にして思うのだった。テレホーダイ世代は集団訴訟すべき。まあ人のせいにしても仕方ない・・・。

最初の会社の頃なんてたまに徹夜したりとか夜中まで酒飲んだりとか、そんで昼間は会社で居眠り。狂ってたとしかいいようがない。まあ若い頃は色々おかしかった。そういう愚かな若者にならずちゃんと暮らしてた人がエリートなのです。

via Learning at work is work, and we must make space for it | Hacker News

HN のコメ欄は本文を読まずヘッドラインだけみて言いたいことだけいっているクソコメで盛り上がっているが、自分も興味のあるテーマだったので PDF を買って読んだ。

内容としては: "Boot Camp" みたいのでなにかを勉強したり教わったりしてスキルや知識を身につけるのは "Incremental Learning" であって、大きな飛躍はない。一方 "Playground" で実際になにかをやって、その体験を内省的に振り返り、新しい自分を発見する "Transformative Learning" には飛躍がある、そういうのをやろうな・・・みたいな話だった。Kate Matsudaira 的 BS 感・・・というと語弊があるが他人事感・・・を拭いきれないが、著者は HR 方面の人なのでそれも仕方なし。

たとえば delegate できないリーダーが例として登場する。そのひとたちは失敗できないがゆえに delegate できない、だから色々なことを試してちょっと失敗してもいい learning のための space をつくってやるのが組織に必要なことである。みたいな話をする。そして企業が transform するには、そういう space をシステマティックにつくる playground をトレーニングに組み込もうな、と結論づける。後半にいくほどどうでもいい。しかしこの記事は企業の digital transformation (ってなに?) を応援する issue の一部なので、書き手に文句をいう筋合いはない。釣られた HN が悪い。

自分はというと、出世パスに乗っていないおかげでまあまあ transformative learning  をする機会を持てているなとは思う。一方、下っ端プログラマが生存するために必要なのは仕事を通じてものの見方を transform することではなく、機械学習とかクラウドとかがわかるようになることではないか、というと極端だけれども、知識やスキルというのは下っ端には必要なのだよ。リーダーシップの皆さんはそういうの足りてる前提で話してますけどね・・・。

というわけで「俺は仕事中もコソコソ勉強してるぜ」みたいな HN のコメが本文を読んでないゴミであるといいつつも、その sentiment には共感があるのだった。

ところでなにかと脊髄反射で悪口をいいがちな Kate Matsudaira, いま何してるのかなこのひと、と見てみたら・・・あまり人の悪口とかをいうのはよくないですね、という良い例でありました。はい。ごめんなさいね。

見直したら毎年書いていたのでいちおう記録をしておく。

お手紙活動の影響もあり、今年はついにアップロードを誰にも気づかれないという偉業 (?) を達成した。寂しいが、意図通り。ちょっと速くなり HTTPS にもなり、いちおう進歩はしている。

来年もたぶん似た感じでやっていく予定。ほんとの newsletter platform を使ってみたいという見栄の欲望は引き続きがあるが、書くことないのが現実。衝動的に色々試すかもしれないのでそういうときお手紙仲間の皆様は温かい目で見守ってください。

• 先送り - steps to phantasien
• Publishing 2017 - steps to phantasien
• Publishing 2016 - steps to phantasien

（もくじ。）

普段から断片的に書いていることの繰り返しも含め、だいたい書きたいことは全部書いた気がする。こうした反省を踏まえてどうするかというと・・・特になにもない。「あのときこうすべきだった」という反省は「あのとき」という条件付きの宣言だから。できないことも、今となっては意味のないこともたくさんある。そして「あのとき」の前提がないものは、できる範囲で実行にうつしている（と思っている）。だからこの文章を踏まえてなにかを変えたいとは思わない。

こうした反省とは別にぼんやり考えていることは色々あるけれど、それらはまた別の機会にぼんやり書いていきたい。

（もくじ。）

ウェブ標準の仕事について。

あのプロジェクトは失敗したと言って良いと思う。出荷はしたし使われている部分もあるので全体として完全な失敗ではないにせよ、長い時間がかかったし評判も期待したほどではなかった。自分が担当した部分については完全な失敗で、誰も使ってない。仕様は deprecate され実装も消されることが決まっている。

なんで失敗したのか、どうすればうまくできたかと繰り返し考えた。自分にとっての結論はあるようなないような状態。もう情報が増えることもないし、いい機会だから書き出しておきたい。

端的には：野心的な目標に対してチームが実力不足だった。いうまでもなく自分もだいぶ実力が足りてなかった。

なんでそんな野心的な目標を持ってしまったのかというと、時代の空気かなと思う。勤務先、および該当製品は、世の中からも割と愛され当事者は調子に乗っていた、と書くとかんじわるいけど、勢いがあって強気だった。

一方、ウェブテクノロジは行き詰まっているように感じられた。Node.js を中心とした JS のエコシステムは盛り上がりはじめていたが、まだ中心が定まっていなかった。たとえば ES6 Modules はまだなくて、複数のモジュール化標準が入り乱れていた。ウェブフロントエンドのフレームワークについてもかなり混沌としており、ぜんぶぱっとしなかった。（まだ React はなかった。）ので調子に乗っていた我々は、ウェブ標準の力でこれを解決したいと考えた。

どのへんが実力不足だったか。DOM のようなコアのウェブ標準をいじる経験は誰にもなかった。それまで同ブラウザが足した API はデスクトップ OS の機能を expose するようなものばかりだったから（データベースとか。）実装の側もようやくフォーク差分を upstream しおえたくらいの時期で、まんなかの方をがちがち触れる人間は限られていた。

野心的なプロジェクトに挑戦して失敗した。それは仕方ない。挑戦しない方がよかったとも思わない。こうすればうまくいったかもという反省は、色々考えたけれどもう一回やる機会もないし、だんだんと忘れてしまった。

勤務先はさておき、自分がやるべき仕事だったのかについてもよく考える。

自分は標準化というアイデアがそんなに好きでない。必要性は理解しているが、あまりお近づきになりたいとは思っていなかった。この感覚がプロジェクトを通じて強まったのは事実だが、標準化というのは根本的に design by committee. 自分が好きでないのは当たり前。

ついでに自分はプラットホームとかフレームワークとかがあまり好きでない。「ウェブプラットフォーム」に「フレームワークとしての API」を足すプロジェクトを仕事でやる。きびしい。特に自分はウェブ開発者としての専門性がまるでない。そんな人間がフレームワーク API とか設計してもいいものができるわけない。設計は他の人がやってくれるという期待があったけれど、やはり自分の肌感覚がないものを作るのは落ち着かないものだった。設計も、細かいところは結局自分で決めないといけないし、大きな変更をする必要だってあるかもしれない。けれど直感が働かないからそれができなかった。

標準化にブロックされ、オープンソースにブロックされ、チーム内の終わり無い議論にブロックされ、コードを書けない時間がとても長かった。この非生産的で無力な自分にはもっと自覚的になり、なんらかのアクションをとって解決すべきだった。プロジェクトを変えるべきかもしれなかった。

でも総体として同じプロジェクトに stick した自分の判断が間違っていたとは思っていない。自分はそれまで job hopper だったし仕事はしょぼいものばかりだった。このときは難しい、価値のある問題を放り出さず向き合いたいと思っていた。だから自分にとっても難しいことに挑戦して失敗したプロジェクトだった。難しさの種類がチームにとってと自分とでは少し違ったというだけで。そこに学びはあった。だいぶ高くついたが仕方ない。

自分にとっての学びはなんだったか。

まず、価値判断が自分でできる仕事をするのが重要ということ。ウェブの API の良し悪しは自分にはまったくわからない。そういうのを仕事にするのはよくなかった。標準化みたいのも好きでも得意でもないから、やはりいまいちだった。価値判断の重要性は、受託開発で働いてきた自分が自社製品開発をする身として学ぶ必要のあることだった。受託開発だと、価値判断はしばしば麻痺された方がよいからね。いつもそうだとはいわないけれど。

もうひとつ、他人にブロックされることが多い仕事はよくないということ。ボトルネックは自分の側にあった方がよい。それはストレスでもあるが、自分ががんばっただけ進む仕事の方がよい。一見ブロックされているが努力によって unblock できる問題もあるから、この判断はそれほど自明でない。とはいえある程度の期間仕事をすれば gut feeling を通じて傾向は判断できると思う。

あとは、製品やプロジェクトの良さと自分との相性は必ずしも足並みを揃えないということ。仕事のウェブブラウザは製品としても良かったし、組織もよく回っていた。会社の調子もよかった。自分もブラウザというテクノロジは関心をもてた。ただ開発者体験を良くするための新しいウェブAPI の標準化という仕事は自分と合っていなかった。

トレードオフもある。オープンソースの仕事をするとかアメリカの会社で働いてみるというのは自分にとっては意味のあることだった。うまくいっている製品チームの一員として学ぶこともたくさんあった。だから負の要素に目をつぶるのは、ある程度は理にかなっている。程度の問題。

たとえば自分の今のアプリの仕事だと、本当にコアの部分・・・たとえば画質・・・みたいのは自分では価値判断できない。そこに後ろめたさはある。ただ画質以外の要素・・・たとえば速度・・・の良し悪しはわかるので、画質のような本道ではなく速度のような補助的な役割を担うことで妥協している。製品のコアな価値を担えたらかっこいいとおもうけど、そういう仕事はなかなかみつからないね。それは勤務先のせいではなく自分のしょぼさだと思っている。

他人によるブロックについても、大企業だったりチームがある程度でかかったりすると細々とブロックされるのは日常。そういうのは複数の作業を持つことで乗り切っている。今は以前とくらべだいぶブロックされることが減り、ボトルネックを自分の側に近付けられていると思う。これはチームやプロジェクト自体の性質もあるし、立ち位置選びがうまくなった面もあるし、チーム内での自分の tenure も関係ある。時間をかけて信頼を高めればそれだけ自律性が増すし、ブロックされにくい道もよく見えてくる。これだけだと 10 年前に戻っただけだけど、リーダーシップ的なのをほぼ完全に捨てることで組織オーバーヘッドを最小化できているのが進歩といえば進歩かもしれない。

話を少し戻して、件のウェブ標準プロジェクトはどうすればうまくいったのだろうか。

越権を承知で無責任かつ雑に書くと、たぶんレンダリングエンジンじゃなくて JS という言語の側に注力すべきだったんじゃないかな。JS は愛されているし人々は気にかけている。レンダリングエンジンは、そんなでもない。たいした根拠はないし、言語をいじったところでいいものができた保証もないけれど。あとは abstraction ではなく真の capability に的を絞ったほうが良かったとも思う。ユーザとプラットフォームの役割分担として。

プロジェクトの最初期は JS の拡張も含めた様々なアイデアが模索されていたけれど、結局レンダリングエンジンの側をなんかするところに収束した。なぜかはわからないけど、たぶん当事者の多数がレンダリングエンジン側の開発者だったから。手にある武器で殴りたくなるポップカルチャー的 conway's law の帰結、に思える。Abstraction に手を出したのは・・・立案者の趣味かな。たぶんね。

同じ人々はその後 service workers という capability focused でずっと広く使われる標準をずっと短い時間で出荷した。同世代の野心的失敗プロジェクトである Native Client も競合たる ASM.JS と手を組んで Web Assembly という広く使われそうな標準に至った。組織もまた学びを糧に前に進んでいる。もっと fail early しろと Eric Ries に怒られそうだけど、それは仕方なし。

自分は今の会社に入る前から何年も仕事をしていて失敗プロジェクトもいっぱいあったのに、あまりそれらに関する反省が思い出せない。あまり反省しなかったのだろうか・・・。とおもったが、昔のブログを見ると少しは反省しているね。メランコリックすぎてわかりにくいけど。

あと、プロジェクト自体がしょぼすぎて色々責任転嫁の余地があったのを言い訳に、自分の不足に目を向ける誠実さを欠いていたとも思う。自分のだめさに自覚的であるべきだったが、中二病ってのはそういうことしないんだよ。

（もくじ。）

業務ではない課外活動。趣味プロジェクトとか勉強とか。

趣味プロジェクトは、実用性を重視しすぎて小物ばっかりつくったのがよくなかった。役に立とうが立つまいが挑戦として OS なり言語処理系なりを作ればよかった。そういうのをやらなかったのは根性がなかったせいでもある。そして実用といいつつ使えたものは殆どない。なさけなし。

座学/読書は、もうちょっとノートをとるだとか環境に気を使うとか、ムダに挫折したり放置したりしないよう勉強の仕方というものを気にすべきだった。ここ 4-5 年で多少改善したけれど、時すでに遅し。挫折や放置はそれ自体も問題だけれども、そのあとしばらく勉強する気を削いでしまうのもよくない。

コード読み。少しはやったが、日常にするところまでたどり着けなかったのは残念。コードを読む日常に憧れがあったが、どうすればよかったのかはよくわからない。雑誌連載は動機づけにはなったが、ややきつかった。

競技プログラミング。全然やらなかった。まあいいです。何らかのコードを書いていればそれでよいと思っている。個人的に趣味プロジェクトをがんばりたかった。

英語。まあ、こんなもんですわ。入社直後、あるいは引っ越し直後にもっとがんばればよかったとは思う。やる気と時間のバランスがよいはずの時期。あと、やはり勉強法みたいのにもっと気を使うべきだったね。特にキャリア序盤。

総体として、もうちょっと高い目標をもって根性だしてメタスキルも高めて継続的に色々挑戦できればよかった。昼まで寝てマンガ読んで酒を飲みに行くのが青春だった身には、まったく高望みだとも思うけれど。

他人となにかやること。

小さい活動をもっとたくさんやればよかった。たとえば自分はむかし小さな読書会をはじめた。実際の運用は別のちゃんとした参加者の人が引き取ってくれたから続いたのだけれど、これはよかった。たまに友達と小さなプロジェクトをやってみたり、「もくもく会」みたいのに顔をだしたりして、それもよかった。こういう小さな集まりをもっとカジュアルかつ継続的にやればよかったと思う。場所を探すのが億劫だった記憶があるけれど、別に自宅で 2-3 人の集まりを持てばそれでよかったね。最後の数年住んでいた広尾のボロアパートはさすがに厳しいかもだが、日頃そういう集まりをしていたら引っ越しに際しマシな部屋を選んだかもしれない。

よその勉強会みたいのは、まあ、たまに出るくらいでよかったかな。自分が話さない勉強会はきほん意味なかったなと思う。自分が話すのはオフラインで個体を認知される意味で良い。飲み会を尊ぶ声をオンラインでたまに見かけるけど、自分にとっては二日酔いになるし喉をやられ風邪をひくしで、あまりいい思い出はない。その割に頻繁に顔を出していたが・・・。

オープンソース。自分の勤務先だと「仕事で使うから」みたいな理由をサードパーティのプロジェクトに見出しにくく、結果としてコントリビュートする気があまり起きなかった。残念だけど、本業として数年やったからいいかなとも思う。残ったものはないけれど、やっている間は楽しかった。会社のカネで meetup にも参加できたし。趣味と仕事が一致していた瞬間。

これらを書き出してみて思うこと。

趣味や勉強の支えとして、友達と一緒に勉強したりコードを書いたりをもっとしてよかった。特に若い頃はまわりのひともみなヒマなわけだし。なぜそれをしなかったのか今になって思うと不思議だけれど、内向的すぎとか臆病とか腰が重すぎとか色々理由はあげられる。あまり考えもしなかった気がする。友達とやることなんて、酒のむか飯くうくらいだったような。結局、そんなに意識高い身分ではなかったのだよ。

友達となんかやる方がいいという感覚は snippet train なり podcast なり、比較的最近の経験に裏付けられた気分にも思える。結婚して引っ越してヒマも相手もいなくなった後に気づいたのは残念。

ライフハックやメタスキルみたいのを重視するようになったのも最近の傾向で、むかしはもうちょっとバンカラ志向だった気がする。年を取って自己啓発にかぶれたと見ることもできるが、パッショネイトバンカラ野郎を気取るには期待値に対し素の実力が足りない。

（もくじ。）

少し脇道に逸れ、インターネット芸人活動について。これについては過去に何度か書いている(1, 2, 3, 4)。自分はある時期までは無自覚な attention addict であり、それが自分のキャリアを損ねたと思っていた。その反動で、一旦は原理主義的な意見に至った。すなわち、関心/承認欲求のためにオンライン活動をするとプログラマとしてのキャリアを損ねる。それよりは実力の足しになるようなこと・・・たとえばコードを書くとか・・・をするとよい。その結果引き起こされる関心だけが本物の通貨で、あとは贋金である。

これはあまりに draconian で、関心/露出/知名度にはキャリア上の利点もある。自分はそれを享受している。だからその「偽物らしさ」に自覚的であれば、必要悪のツールとして芸人になるのもよい。原理主義化したあとは、そう考え直しもした。

「自覚的である」ことはそれなりに難しい。とはいえ関心への飢餓感が孕む危険は主に聴衆側の成熟によってある程度は理解が進んだ。たとえば「炎上芸」みたいな語彙は昔はなかった。今は、プログラマはともかくウェブで悪目立ちする一部の「ブロガー」を人々は失笑しているし、YouTube personalities の burnouts などもしばしば報道されている。

そうした芸人としての罠がオンラインで活動するプログラマにもあてはまることを理解した上で、趣味としての芸を楽しむのは別にいいんじゃないか。最近はそう思っている。プロ芸人でない自分たちのようなプログラマにとって関心の病を自覚するのは案外むずかしいこともあるが・・・。

依存症の比喩からこう考えることもある：自分は依存症を通じて脳が変質したからアル中やヤク中がそうであるように依存対象すなわち関心からは自由になれない。だから諦めと受容を通じ距離をおいて付き合っていくしかない。

外国ぐらしをするようになり、自分にとって日本語圏でのアテンションの直接的な価値は下がった。結果として見栄に引きずられず芸人活動の趣味性を楽しめるようになったのはよかった。これは Podcast で特に顕著だったとおもう。いまでもアテンションは気になるが、前よりはうまく距離を置けている気がする。出羽の守化がさほど進行せずにすんでいる（と信じている）のは、解毒の成果とみることもできるし単に加齢のせいかもしれない。

自分の社会的アイデンティティを考えると、また違った見方もある。自分はインターネット「芸人」である以前にインターネットの「住人」で、自分の人間関係にはウェブを通じて作られたものが沢山ある。オフラインが起点の知り合いでも、互いがオンラインに書いたものを通じ理解しあった関係もある。発言の場としてのインターネットはそうした人間関係を育む土壌であり自己表現の舞台なのだから、芸人だの関心だのと腐してばかりはフェアでない。相応の重要度と敬意を持って接するべきではないか。有り体に言えば、自分はインターネットと一緒に人間関係を放棄していないか。

これらの矛盾する見解は、それぞれ正しいと自分は思っている。ただ互いに矛盾しているので歯切れの良さはない。まあ、仕方ない。 これからも試行錯誤が続くだろう。

（もくじ。）

大企業について書こうと思ったが、自分にとっては外資系というか非母語で働くという変化と受託開発から自社製品開発への変化も同時にやってきたのでれらは切り離しにくい部分がある。まずは別々に議論してみる。

まず大企業と大規模プロジェクトについて。自分は今の会社に入るまでは中小企業で働いていた。気づいていなかったが、働き方も中小企業に傾いていた。それを補正するのに苦労した。

規模と細分化

中小企業の働き方は役割が未分化である。製品のコードベースも大きくないからフロントエンドからバックエンドまでふつうに全部さわるし、人手がないからマネージメントはしないまでも TL っぽい立場にはなりやすい。色々やる。

その色々の品質は高くない。多くの場合、とりあえず動けばよい。ひどいところは直そうかな、くらい。要素技術を売るスタートアップのコア技術とかだとまた違うのかもだが、中小企業というのは基本的にしょぼいものをしょぼしょぼ作って売っているのである（殺されそうな発言）。しょぼいは酷い言い分で、ニッチというほうが良いな。

大企業は人がいっぱいいる。仕事も規模がでかいので、役割が細分化されている。マネージメントも管理職以外はそんなやらなくてよい。偉くなりたいなら TL くらいはやった方がいいだろうが、別にやりたい人（偉くなりたい人）はいっぱいいるので自分がやらなくても他に人はいる。ビジネスは成功している（からでかくなった）ので、その先に積み上げるものへの期待値は高い。

細分化の結果、個々人は専門家として仕事をしないといけない。その専門はわかりやすい（市場価値のある）切り口の場合もあるし、製品固有なニッチの場合もある。マネージメントも専門である。TL はある意味ではジェネラリストだが、それでも守備範囲のスコープは狭い。なぜなら個々のチーム自体の守備範囲が（相対的には）小さいから。"Uber TL" という TL の TL みたいなポジションもあるにはある。割とすごいプログラマがすごい視力をもってやる仕事とされている。なおスコープが小さいといってもコード量が少ないとは限らない。コードの総量が多いので。

自分はというと、チームのつくっている特定のアプリの性能の専門家となっている。でも性能の指標をすべて見ているわけではなく、起動レイテンシや Jank のような限られたメトリクスしか扱っていない。たとえば画像処理のスループットとかメモリ消費とかは他の人が見ている。前のチームは今より小規模だったので、もうちょっと色々見ていた。一方その前のチームは今よりずっと巨大で、自分が性能の専門家になる余地はなかった。

大企業というか大きなプロジェクトは仕事が進まない。具体的にいうとコード産出のスループットが低い。なぜなら満たさなければいけない期待値、品質のバーが高いからである。性能改善とかはその傾向が顕著かもしれない。コードを書くよりプロファイルやトレースを睨んでいる時間の方がずっと長い。

現実の問題に裏付けられた専門のニッチにどこまでも踏み込んでいく知的刺激は得難い。一方で、どうってことないコードをフルスタックで雑にいっぱい書く方がコード書きの筋肉はつくし潰しは効くだろうなと思う。

Small autonomous team で Microservices みたいのは大企業が中小企業の身軽さを取り戻す術とされている。Microservices でなくても、新規製品の立ち上げみたいなプロジェクトにはこれらプロジェクト規模の問題がなく比較的ザクザクとコードがかけるため、勢いのある人たちに人気。ただ自分はそういう仕事はしていない。今のチームも新機能やっている勢はそこそこコードのスループットがある気はする。コードを書くという視点だと、性能仕事は微妙。

まとめると、大企業はプロジェクトの規模が大きくなりがちで、結果として仕事は細分化、専門化しがちで、期待値の高さから品質のバーはあがりがち。ただし弱小製品や新規プロジェクトなど例外も多い。コードを書く量は総体としては少なくなりがちだが、程度にはばらつきがある。うまく仕事を選ぶと雑用がすくないぶんコード書きに集中できる面はある。

自分は専門家になるより E2E でコードを書きたいと思っていたし、TL/TPM 的にプロセスなどをコントロールできないことに強いフラストレーションを感じていた。性能の仕事はコードを横断することができるので良い。ただし新機能実装みたいな機会はない。プロセスについては超非生産的な年月を経て慣れた。どちらも適応には時間がかかった。

社内固有の事情

大企業はでかいので、社内固有の事情が色々ある。そうした社内固有の事情に関する知識は、転職を見据えると基本的には無駄。ただ日々の仕事には欠かせない。

社内知識にはスタックのように技術なものと書類や人間関係のように技術的でないものがある。運用のプロセスみたいのはその中間くらい。

まず技術的な知識について。自分の勤務先はオープンソースにあるような分野のものも色々内製している。そういう内製スタックに詳しくなるのは無駄だからと、なるべく近づかないようにしていた。

ただ後から気づいたこととして、その内製スタックの上に作られた製品固有のテクノロジ（画像処理、検索などなど・・・）はオープンソースに代替品が存在せず、ものによっては業界最先端だったりする。そうした製品固有のテクノロジを学ぶ税金として内製スタックは勉強しても良かった。反省。とはいえ規模の問題もあるので、製品固有テクノロジを学びたいならそのテクノロジの上で仕事をしないといけない。片手間で理解できるような代物ではない。検索について知りたいなら検索を仕事にしないとだめ。たぶん。

もうちょっと汎用的な内製技術スタックが「時代の先を行っている」とされている場合、未来を見るメガネとしてそれを学ぶのには意味があるのか？個人的にはあまり無いと思う。「時代の先を行っている」はだいたい当事者の思い込みで、実際はニッチな袋小路に過ぎないことが多い。その未来は来ない。上に書いたような理由からそれを理解するのは悪いことではないけれど別に未来じゃなくね？やはり論文なりオープンソースなり世間で評価にさらされないと勝敗はわかない。

しかし学ぶ意欲を得るにあたりファンタジーが助けになるのも事実。自分も、自分を騙せる勢いが残っているうちに内製テクノロジにどっぷりすればよかったなと思う。まあブラウザとかもオープンソースなだけでニッチ性は内製テクノロジみたいなもんだから、それを学んだのでよかったのかもしれない。未だに心のどこかでサーバサイドには「秘伝のタレ」があるというファンタジーを捨てきれてない。

技術的でない社内知識。たとえば人脈とか部門間の関係とか他部門の動向とか。ほんとに社内でしか価値がない情報だけれど、ゴシップ的な面白さはあるのでひやかし程度に詳しい人の話を聞くくらいでいいんじゃないかな。チームメイトなど、直接接点がある人たちとの関係を良好にするのは大事だと思う。自分がこれらをちゃんとできているとは思わないが。

半分くらい技術的な知識。たとえばプロセスや、それをとりまくツールと人間。自分が agile とかが好きなせいかもしれないけれど、これが一番学ぶに値するものだと思う。プロセスというのは細部は組織固有だけれど big picture は存在し、それはソースコードほどオープンでないし知識として明文化するのも難しい。そこそこ機能している "The Way"には学ぶ価値がある。そして座学で学ぶより実際に動いているものを目にするほうがずっと身につく。それらのプロセスが最適であるとは限らない。でも何も知らずに完全にランダムな解空間を探索するよりは良い。

企業 blog やオープンソースにはじまり Devops movement やその周辺 SaaS へと続く情報開示によって、様々な大企業 ways も段々と標準化、商業化されているような気はする。そうやって小奇麗になったバージョンを学ぶほうが効率的に思える一方、土着のプロセスが動く生々しさに触れる良さもある。自分は一時期こういうのに興味があったけれど、モバイル部門は音楽性が合わなすぎて興味を失ってしまった。ただ各種の社内ドキュメントはもうちょっと熱心に読んだほうが良いのだろうなあ。

官僚的なものごと

大企業が官僚的であるというのはたぶん事実だが、体感するフラストレーションはばらつきがあった。

ミーティング。自分はいま週に 1.5 時間くらいかな。チームの定例が一個と、1:1 が隔週から月一回くらい。隔週の demo day は時期によって開催頻度はまちまち。自分がヒラ社員すぎるせいとはいえ、これは会社の規模によらず割と少ない方ではないか。（しかもたびたびすっぽかしている。よくない。)

出張とか経費精算とかのペーパーワークはずいぶんラク。人事考課は、ちょっとめんどい。ただフェアさを考えると妥当かなと思う。制度に改定があるたび、下々の手間は少し減り、同時に透明度も少し失われている。

非同期でやるミーティング相当の行為。コードレビューとか、ドキュメントのレビューとか。まあそこそこ。やはりヒラなのでそんなに多くない。バグのトリアージは今の仕事はすごい多くて苦痛。ただ割と例外的な気がする。メールはそんなに書いてない。読むのは適当にやってる。

リリース。相当めんどくさいはずだが TPM がぜんぶやってくれる。専業の人間がいる時点で官僚的なのは事実。TPM ではなくエンジニアがやってるチームもある。自動化はされているが、自分たちのチームは割と激しく cherrypick するとか QA チームによる手動のテストが挟まってるとかのせいでめんどくささが増していると思う。官僚的だからというよりは、チームの練度不足に思える。

なんか新しいことをはじめる。自分の裁量でできる範囲なら特に面倒はない。人が欲しいとかエンドユーザから見える違いがあるとかだと大変。製品の表面積が小さいほどエンドユーザ向けの機能を足すのは大変だと思う。カメラアプリとかだいぶ大変。電子書籍はもうちょっとラクそうだった。どちらでもプログラマがやりたいと言い出した機能が入り込んでいくのを見たので、機能の筋の良さと本人のパッションに依存している。たとえばカメラの RAW 保存とかはプログラマ発だった気がする。

機能ではなく、新しい製品を始めるのは、きっとすごい大変。自分には無理だし、エラ目の PM とかでないと正しい攻略パスを進めないんじゃないかな。PM と仲良くなれば良いという話かもしれないが。

新機能にしろ新製品にしろ始めるのは大変だけど世に出すのはもっと大変で、リリース前のプロジェクトはしょっちゅうキャンセルされている。世に出たものもよくディスコンして世間の顰蹙を買っているけれど、あんな生易しいもんじゃないんだぜ。今のところキャンセルでもクビにはならないのはめでたい。

日々の仕事の官僚性。ビルドが遅いとかテストが遅いとかは技術的な官僚的オーバーヘッドと言えよう。コードレビュアがみつかんないみたいのは、昔でかいチームだった頃はよくあった。今はあまりない。忙しくて全然レビューしてくれない時はたまにある。分散バージョン管理のおかげで、仕事の並列化はやりやすくなった。多少ブロックされても遅延を隠せる。

コードにおける官僚性。なんかのインテグレーションをするとか、コードの静的チェックとか。UI の見た目の足並みを他アプリと揃えるとか。まあまあある。そして、これは大きいチームにいるより小さいチームにいる方が負担を感じる。なぜならシステムが巨大なチームのために作られているから。大きなチームだと、面倒なことは割と誰かがやってくれる。（自分がその面倒な担当にならなければ。）

総体として、自分の役割を果たしている分にはたいしたオーバーヘッドを感じないが、役割を超えてなにかしようとすると非現実的に大変な印象。自分は最初のころ役割をよくわかってなかった。そのせいで無駄に苦労をした気がする。

英語と外国

英語と外国の影響は理論的には大企業である事実とは直行しているはずだが、自分の場合は大企業による影響を reinforce している。すなわち、フルスタック雑用リーダシップではなく末端専門家プログラマとしての振る舞いを後押しされている。

英語の影響、すなわち言語バリアは、プレゼンやメールや立ち話といった自然言語による説得を難しく、かつ高価にする。その結果、1. 事前に説得するより実際にコードを書いて結果をだしてからもっていくようになる 2. 主観的な性格が強いもの(例: コード品質)より成果を客観的に見せやすいもの(例: 性能)を目指して仕事をするようになる。3. 人に頼むのではなく自分でやるようになる。4. 他人の仕事に口を挟まなくなる。全体として、リーダーシップ/マネジメントではなく末端/ICであることを志向するようになる。

外国であることの影響、すなわち人的ネットワークの喪失の影響。これは日本で育んだネットワークが役に立たないからでもあるし、言語バリアのせいで新しいネットワークを育てられないせいでもある。家族がいると社外のイベントの類も全然顔をだせないし、社内の業務外グループみたいのに参加する余力もない。結果として、仕事では人づてに裏で口を利いてもらうとかはできないし（これは日本にいたときもしたことない気がするが）、同じく人づてに面白い仕事を探すこともできない。社外でも社内でも。結果として 1. 転職とかをする気がおきない(人づてに行き先がみつからないから) 2. 自分のプレゼンスを高めるためにがんばる、みたいなことをしない。（プレゼントする先がないから。）といったことがおきた。最初のチームにいたときは社内ソーシャルメディアで管をまくチームメイトもいたので自分も割とやっていたが、今はもう社内ソーシャルメディアもしなくなった。

まあ社外とか社内の遠い何処かとかはさておき、チームの隣人に対してはもうちょっとつきあいよくしてもいいかもしれないと最近は思っている。人として。人間的な接点がないと仕事場に「所属してる感」がなくてやや寂しい。ただ同僚とランチとか時間の使い方として贅沢すぎてちょっときびしい感があるし、週末に遊びに行くとかありえないかんじ。子供ができる前にもうちょっと社交しておくべきだったと思う一方、既婚者にはそれもバー高めなのだった。

全体として、大企業/外国ぐらしは自分を専門的なテクノロジを末端で行使する人にしている気がする。専門性がニッチに先鋭化していくのは望ましくないが、技術以外の側面を捨てるよう後押しされるのはプログラマとして生きていく上でいい圧力ではなかろうか。職業人生の前半と互換性がなさすぎて苦労はした。最初から大企業にいる人々はエリートネイティブという感じでうらやましいが、彼らは大企業にいるからエリートなのではなくエリートだから大企業にいるのだった。

もうひとつ、こうした圧に任せているとまったくエラくはなれないね。外国人でも圧と戦いながら大企業の中で偉くなっていく人々には尊敬がある。でも自分は舵を切りたくなったらそれを後押しする圧のある環境に移る方がいいな。そういう日が来るのか、そういう日が来たとして異なる環境が自分を受け入れてくれるのか、不安はあるけれども。

（もくじ。）

事実関係の振り返りを横断的に眺めると、繰り返しあらわれる話題がある。自分の気分の底を流れるテーマも頭をよぎり始める。

まずひとつめは、このひと根性ないね・・・ということ。これはモダン根性論に感化されて以来より一層思う。特に大学時代の自分のやるきの無さときたらやばい。学費の！もとを！とるきあんのか！

つぎ。これは根性のなさに少し関係があるけれど、仕事の決め方が雑。不確実性を扱うのが苦手で、探索が苦手。仕事を選ぶタイミングというのはすごい自由度があり、それゆえ不確実なことも多い。だから色々な手を考え、それだけでなく実際に話をきいて、いくつものオプションの中から選ぶ方が良い。自分は考えることは一定程度しているが、おおむね思い込みでバンと決めている。話を聴くのをさぼっているし、不安定な状態を嫌っている。これは自分のコミュ障や臆病の帰結ではあるけれど、もうちょっとがんばっていいのではないか。とおもって前回はちょっと頑張ろうとしたが、そもそもレジュメでお断りされてしまったのだった。なおバンと決めてる割に現状さほどひどいことになってない点は自分の運を讃えたい。

仕事選び雑さという点だと、割といつも仕事が辛くなって雇用主やチームを変えており、それが雑さにつながっている面もある気がする。ほんとはもっと心に余裕のあるとき仕事を変えると良いのだろうね。その反省から前回は三年たったらチームを変えようと思っていたが、三年待たずにトラブルに巻き込まれてしまったのだった。

つぎ。大企業と中小企業の違い。中小企業時代の反省というのはあるわけだけれど、それらは今の大企業の文脈にまったくあてはまらない。例えばチームやプロジェクトのリードの仕方、みたいのは考えても無駄。リードしないし、チームの構成人員もリソースも全然違う。まあ10年近く前のことを反省しても仕方ないんだけど、このギャップは未だに埋め切れていない感がある。同じような大きな飛躍として受託開発と自社開発の違いもある。国の違いもある。ただ自分の中でこれらは大企業と零細の違いとうまく区分できていない。こうしたギャップを埋めるのに自分はだいぶ苦労したなと思う。これはきっと稿を分けるのが良いでしょう。

大企業に関するメタな感想として、自分の期待値はきっと釣り上がっているのだろうとも思う。感じの悪さを恐れず書くと、大企業の中やその周辺の人々はわりかしエリートである。そういう人々の振る舞いを baseline にすると自然と期待値があがる。しかし現実の自分の baseline はどちらかというと中二病気味なボンクラである。中二ボンクラな自分の期待値と大企業エリートの期待値には重なる部分もある（「すごいプログラマになりたい」とか）が、大きな違いとしてボンクラにはロードマップがない。エリートにはある。別の言い方をすればボンクラの期待値はファンタジーだがエリートにとっては現実だ。ファンタジーを現実として突きつけられると、あ、ごめんなさい・・・みたいになる。とはいえいまさらファンタジーに戻すこともできないので、無理な期待値にちょっとでも近づけたらとできる範囲でしたばたしてる。（前にも似たようなこと書いたな。）

ボンクラ・・・というかノン・エリートによるロードマップレスの「がむしゃらな頑張り」がファンタジーを現実にすることもたまにはあるらしく、そういうストーリーはそれはそれでかっこいい。ただ自分は該当していない。あとここでいうエリートは長期間着実に努力と成果を積み重ねられる強い自制心の持ち主という意味で使っている。これは現実のいわゆるエリートとだいたい重なっているが、もっと地味なエリートもいる。とはいえ自分くらいの年齢になるとまあまあ結果がでてる気がする。

（もくじ。）

まず・・・どこまでもどればいいんだろうか。大学？自分は私立大学の推薦入学というやつをして、それはよくなかったと思っている。ちゃんと受験勉強を戦う根性を出すべきだった。ただ当時の自分がそこで迷った記憶もないので、自分の根性の無さの帰結とみなす方が自然に思える。いくつか候補がある中で情報系を選んだのは、なかなか先見の名があったと思う。市場動向とかを調査した記憶もないので、まあまあマグレではある。プログラマなんてゲームプログラマしか知らなかったし、プログラミングもしたことがなかった。なお「手に職」と親に強く念を押されていたため、文系は考えていなかった記憶。これは親がえらかったともいえるが、別に文系にだって職はあった気もする。我ながら雑である。評価としては、大学受験をしなかったのはダメな判断だが情報系という選択は、運の要素もあるが良かった。

そのまま同じ大学の大学院に進んだ。大学院大学みたいのも教員に勧められたが、田舎の山奥で寮暮らしをして正気が保てるとは思えなかった。（インターネットには大学院大学在住の変人がいっぱいいた）。まあこれらは言い訳で、根性がなかったね、やはり。評価：根性なくてだめだが、無難ではあった。

学生時代は最初は本屋でバイトをしていたが、プログラマのバイトをしたいんですよねと教員に話したところ授業の TA を紹介してもらい、その TA の仲介でいわゆるエンタープライズ孫請けみたいな会社で Java を書くバイトをした。それとは別に、これはきっかけは忘れたがウェブで組込系の会社のバイトをみつけ、そっちでも Java を書いた。組み込み系の方は家から遠かった上に時給も安かったので一年ぐらいでやめた。もう一個のエンプラ孫請けは 2-3 年くらいやってた気がする。

プログラマのバイトは、まあ、よかったね。本屋よりお金をいっぱいもらえたし、仕事でコードを書く様子を覗き見られた。特に当時の一大産業である「エンタープライズの Java 開発」というやつがどんなものか体感できたのがよかった。それらのバイト先が特段優良企業だったとは思わないが、自分も別にコードをかけたわけではないから、実力を考えると良い仕事だったと思う。評価：運がよかったというよりは時代が良かった。時代の波にのる良い判断ではあった。

大学院生には「学校推薦」という優遇雇用枠で就職できる利点があり、自分も大学院に進む時は視野にいれていたと思う。ただ実際目の前に来てみると、企業からの様々なしがらみに関する噂や雇用枠を巡って学生の間に漂う微妙な空気など、めんどくささの総量が自分の許容範囲を超えていた。なのでふつうに就職することにした。そこで説明会とかに行くことにした。

最初に行ったのはマイクロソフトだったと思う。ただ説明によるとトップ大学卒でないと話にならなそうな雰囲気だった。会場で「質問」みたいのを繰り出す学生の意識高い感じも厳しく、ああ二流私大のおたくはお呼びじゃないのねと退散した。安い革靴で痛んだ足の記憶ばかりがはっきりのこっている。もう説明会に足を運ぶのも面倒になり、先に一年だけバイトをした組み込みの会社に求職し、説明会とかも一通り行って、採用された。エンタープライズ系のバイト先は仕事の印象が(本業の候補としては)よくなかったのでパスした。エンタープライズ受託は親も子も孫もイヤだと思っていた記憶。

つまり自分は説明会には二つしかいかず、求職したのは一社だけだった。やるきねえなーーー。本当に根性がなかったとわかる。今振り返ると数年後にやってくる就職氷河期に巻き込まれたら就職できなかった可能性あるね。あぶなかった・・・。

評価：一社にしか求職しない根性のなさはダメだが、その後の学校推薦をとってるメーカー系大企業のぱっとしなさをみると、それらを退けた判断自体はよかった。エンタープライズ IT を避けたのが良かったのかどうかはわからないが、それが自分のバイト体験に基づいた判断である点は地に足がついていたよかった。

最初の組込系ブラウザの会社。かなりハードワークしたが三年弱で辞めた。

ベンチャーという触れ込みだったが今振り返るとストックも自社株もないし、顧客が大企業だったせいか仕事の仕方もぜんぜんベンチャーぽくなかったし、社員も年寄りが幅を利かせていたし、やたら会議が多かったし、なにより労働時間の長さは異常だし、いまいちだった気がする。

一方で、作っているものがウェブブラウザなのはよかった。後に今の会社に入る役にたったのはさておくとしても、来るウェブ時代の基盤技術に仕事を通じて詳しくなれた。自分は別にウェブブラウザがやりたくて入社したわけではない（特にやりたことはなかった）ので、これは運がよかった。

会社の偉い人たちは、本人らが主張するほどテクノロジの重要性をわかっていなかった気がする。おかげでコードを書くのは新卒入社数年目みたいな若者が中心だった。これは会社の競争力という点ではよくなかったが、新卒入社の身分である自分にとってはよかった。自分は入社早々組み込み SVG レンダラを開発したけれど、初期バージョンを書いていたのはグラフィクスを何もしならない一年上の新卒社員だった。しかしこの SVG は Macromedia (当時) Flash と戦う必要があったのである。新卒入社一年二年、しかも専門性のない素人を西海岸と戦わせるとかアホなの？ふつうに考えたら社内の使える TL を軸にゲーム業界とかのグラフィクスわかる人員を雇って脇を固め、新卒はせいぜい補助的に手を動かす仕事に回すとこじゃね？ところがそういうことは微塵もおこらず、自分がビットシフトとかしながら Bitmap にピクセルを置くコードを書いていたのだった。やばい。勝てるわけない。しかしそのあり得ない期待値のおかげで上から下まで自分でぜんぶデザインして書く、という得難い体験ができた。

会社の中に人はいっぱいいたので、これはスタートアップの人手不足ストーリーとは少し違う。組織の価値観の歪みによって生まれた機会という方が近い。社内の同世代も、似たような事情で沢山コードを書く人が多かったと思う。もっと気の毒な感じの仕事に回されてしまった人もいたが・・・。

評価: 選択の根拠やプロセス自体はそんなによくなかった。運良く沢山コードがかけたのはよかった。ウェブブラウザだったのも運がよかったが、それなりに勢いのある会社を選べばどこでもそれなりに時代に合ったテクノロジには触れられたんじゃないかな。労働時間が長すぎるのはよくなかった。これは運の問題に思える。

つぎは外資系の名を冠した SI の会社に転職した。二年くらいいた。特によいことはなかった。グラフィクスの仕事をできるという触れ込みだったが、入って最初にやったのは Java で Web をつくる仕事だった（なんで？）。最終的にグラフィクスの仕事も少しはできたけれど、半分以下だったと思う。一つ前の組み込みの会社も今おもうとプログラマの扱いはひどいものだったけれど、この SI の会社はほんとにプログラマ・エンジニアをリソースとして見ており、エクセルとにらめっこする上司を横目に、ああ人月ってこういうことなのねなるほど・・・とある種の感慨があった。

後から振り返るとこの転職のきっかけは過労すぎなどで損ねていた前職時代の精神衛生だったので、精神衛生や健康は仕事より大切にしなさいね、というのが教訓。

なおこのとき仕事への思い入れみたいのが完全に失われた結果、仕事のクソさにもかかわらず精神衛生は回復した。あと仕事のやる気のなさの反動でインターネット執筆活動がはかどり、ブログの時代の追い風もあってそこそこオンラインの知名度が高まったのは良くも悪くも後の身の振り方に影響している。趣味プロジェクトも捗った。

評価: 判断も結果もよくなかったが、前の段階でよくない判断をしてしまう状態に身を置いたのがよくなかった。一方で、それも若さ/時代かなとも思う。メランコリックな若者だったし、IT といえば過労で鬱という時代だった。インターネット活動は、自然言語よりコードを書いた方が良かったとは思うけれど、文章も書いたなりに影響力を持てる時代だったので悪くはなかった。

次は零細ゲームミドルウェア会社。大手ゲーム会社の子会社だった。小さい会社がいいなというのと、速いコードを必要としているところがいい、という判断だったと記憶。三年弱。

社長はスタートアップぽい野望を色々もっていたものの、別に金もないし子会社で株もないしで、別にスタートアップではなかった。ただ前の二者と違い社員 20 人とかの小さい会社で、小ささ自体は悪くなかった。エラそうなことをいいつつ沢山コードをかけたのは良かった。エラそうにする必要はなかったけれど、たとえばアジャイルごっことをしたりとかは小ささの利点だった。同僚も気のいい人々で、おおむね楽しく働けた。(なんとなく擁護しておくと、一つ前の会社も同僚は概ね良い人たちだった。)

ただ本当にまったく儲かっておらず、儲かるあてもなく、経営や採用も雑で、企業としての先行きは暗かった。実際じぶんがやめた一年後くらいに店じまいしてしまった。

この頃からインターネット活動でも身元を明かすようになった。小さい企業なのでそのへんは気楽でよかった。インターネット芸人成分が増したとも言える。

評価: 小さい会社にいく判断自体は, job hopper になってしまった身からすると悪くなかった。大きい会社は雇ってくれなそうだったから。小ささの恩恵は堪能した。どうせならもうちょっと儲かりそうなところに行けば良かった気もする。一方で自分の中の天邪鬼は儲かってて軽薄そうな空気を嫌がっていたので、そんな判断を出来た気もあまりしない。

つぎ、外資系大企業でオープンソース。

入社じたいは、まあめぐり合わせと運みたいなもんです。ブラウザつながりだけど、東京にウェブブラウザやる仕事がある理由からして未だに謎というか特になかったと想像する。雑だから、くらい。

最初の 4 年くらいは新しいウェブ標準の提案実装をやった。これについては前に何度か書いた。なにかもう少し書くことはある気がするけれど、稿はわけておきたい。このプロジェクトの最後の方で転勤した。

そのあと一年くらいは割と実験的なプロジェクトを手伝っていたが、気がつくと新しい OS やらマイナー自社言語の UI フレームワークを作るプロジェクトに姿を変えており、どちらも自分の価値観とあわなかったので一年くらいで退散した。プロジェクトを選んだ時は想像していなかった展開なだけに運が悪かったとも言えるが、大企業の野心的なプロジェクトは自分の価値観とはズレがちという事実は知りつつ踏み込んだわけで、自業自得。仕事の作業自体も色々な事情で全然はかどらず、たぶんこの一年は職業人生の中で二番目くらいに非生産的だった気がする。（一番非生産的だったのは SI 勤務時の数カ月だが、それは自分の意思でさぼってただけ。）

評価: 運の要素もゼロではないとおもうけれど、それよりは野心的プロジェクトを通じた出世の欲をかいて価値観や原則にあわないことをしたり、前のプロジェクトで染み付いた非生産性を払拭できなかったりと、入社以来降り積もった自分のダメさが結実したような一年だった。ただ転勤を助けてもらった義理を果たす面もあったので、一年やったこと自体は妥当と思う。

そのあと二年くらい電子書籍アプリ。ウェブがモバイルに負けると言うならモバイルというものを見てやろうとモバイルアプリを選び、Web の知識が役に立ちそうなので電子書籍。結局半分くらいの時間は WebView の中でうごく JS を書いていた気がする。ウェブの知識で成果を出しつつモバイルに入門するという狙いどおりにいったのはよかった。チームはそんなに大きくも強くもなく、それは良いところも悪いところもあった。大企業モバイルのベストプラクティスみたいのはまったく触れる機会がなかった一方、割と雑にいじっても見逃してもらえたので裁量はあったと言える。サーバ側もちょっとだけさわれたし。コードは割とレガシーで厳しかったが、チームを説得してそれをガっと書き換えるのが自分の職位に期待されていることのはずで、それができたかったのは実力不足。文句をいう筋合いはない気がする。じっさい自分がやめたあとにけっこう人がいれかわり、今はだいぶ近代化されたと伝え聞く。育児休暇のあと復帰した際に巻き込まれた Git to Monorepo の移行プロジェクトに伴いチームの空気が悪くなり、いたたまれなさが限度を超え逃げ出した。

評価: 欲をいえばウェブからモバイルに寝返る勢いでもっとでかくて勢いのあるチームでバリバリ働く道を選べばよかった気もするが、現実的にはこういうプロプリエタリなコードを書く小さなチームでオープンソースや超大規模開発からの禊をするのはリハビリとしてよかったと思う。新しいチームを決める前ににいくつかのチームの話を聞けばよかったかもしれないが、そんなに候補もなかった記憶。チームの空気が悪くなったのは残念だったけれど、結果的にみるとリハビリを切り上げるにはいいタイミングだった。

そのつぎが今いるカメラアプリ。もう二年くらいやってる。これについては繰り返し書いているので割愛。総合的には割といい判断だったとおもっている。

一年を振り返る季節だが、とくにかわりばえのしない一年だったというと言い過ぎだけれども仕事的には去年と似たようなもんだし来年も似たようもんであることが予想されるので、今年は趣向を変えて自分の職業生活をはじめの方からふりかえって評価してみる。特に転職等の大きな判断の良し悪しを遠くから見直したい。何年かに一回書いている内容。

ダラダラ書いていたらだいぶ長くなったので分割した。目次:

• A Long Reflection 2019 (1) – Timeline
• A Long Reflection 2019 (2) – Grit and Expectation
• A Long Reflection 2019 (3) – Bigness
• A Long Reflection 2019 (4) – Attention and Citizenship
• A Long Reflection 2019 (5) – Extracurriculars
• A Long Reflection 2019 (6) – The Failure
• A Long Reflection 2019 (7) – Not Looking Forward

Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently by Jonathan Rasmusson | The Pragmatic Bookshelf

人気の Agile 入門書 The Agile Samurai の著者が自分の Spotify での体験をもとに "Unicorn" ... いわゆるテック企業、インターネット企業を指す用語として使っている ... の働き方をエンタープライズな読者に説く、という内容。なのだが、だいぶどうでもよかった。

目次を見るとわかるとおり、割と総花的である。薄い本 (150p. 薄いのは良い)なので個々の踏み込みが甘いというか、全然踏み込まない。そして切り口に方法論として軸がない。テック企業の働き方というのは資産（出資金にせよ利益にせよ）があるからできる博打の一部という面もあるわけで、方法論というよりは俺たちがカネののちからでやってることをおまいらもやるといいよ、みたいな話がぼちぼち入り込んでいる。そうでない話題もあるが、そういう話題と混ざってるせいで台無し。

Unicorn (インターネット企業) というくくりも雑すぎる。大企業とスタートアップじゃずいぶん違うでしょうに。そしてスタートアップの方法論というのはここ 5-10 年くらいでだいぶ文書化されたから、この本に新しいところはないように思える。一方の大企業ウェイというのは規模の制約を規模の力でねじ伏せる別のゲームをやっているわけで、スタートアップとは同列に議論できないし真似しないほうがよいものも多い。

偏見だけど, Agile 信者がテック企業に入ったら Kool-Aid でやられてしまったのだな・・・という印象。自分も似たような部分があるのである種の共感がなくはないが、Agile Samurai はもうちょっとマシな内容だった記憶があるだけにがっかり。自分が悲しく汚れちまっただけななのだろうか。

Spotify 固有の部分は半分ゴシップ、半分ケーススタディとして興味深く読んだ。無理に一般化しようとせず What I Learned At Spotify みたいな本にすればよかったのにね。

がっかりの反動で唐突に Eric Ries の The Startup Way を聞き始める。同じくエンタープライズにスタートアップ方法論を売り込む話なのだが・・・この本はいいね。

The Lean Startup は Pivot だの MVP だのを流行らせ growth hack や startup methodology の先駆けになった。そういう movement を生み出しただけあって、Eric Ries の話は説得力があるし、理論もよく整理されている。語り口も良い。この本自体はさすがに三番煎じくらいで新しい話が少ないのかあまり売れなかったようだが、個人的に Eric Ries は割と影響を受けているのもあり、久しぶりに話を聞くと気分が盛り上がる。宗教家としての格の違いを感じる。なお Audio book は Eric Ries 自ら narrate している。さすが教祖。

スタートアップ論には方法論も精神論もあるわけだけれど、unicorns の皆さんと compete しようと思うなら 150 ページの薄い本を読むよりはこの Amazon で The Startup Way の関連書籍に並んでいるような奴らを順番に読んでいく方がいいのではないかなあ。

自分はその手の本には若干食傷気味かつ他人事なので足が遠のいていたが、来年は教養/気分転換/ドヤ顔素材としてもうちょっと聴いてもいいかもしれない。

旅先の宿で夜中に目が覚めた。頭をよぎったことを書く。

しばらく前から自分のキャリアが下り坂に入った手応えがある。職業的なピークは過ぎて、あとは何かが下がっていくだけなのだというぼんやりとした重量加速度。

学生時代に人生のピークがあった人物が、哀れさのステレオタイプとして世の中の物語に時々登場する。自分がそんな風でなくて良かったとたまに思う。人生の楽しい瞬間は会社員になってからの方が多かった。退屈な学生時代だっただけかもしれないが。

もしピークが過ぎたのだとしたら、いよいよ自分は楽しかった過去を惜しむばかりの哀れなステレオタイプに成り下がったのだろうか。だとしたらピークはどこかと振り返る。しかしこれといった山場は見当たらない。一方で道が平坦だったというのにも違和感がある。

気分だけでいうと、確かにピークはあった。一つは外資系の会社に雇われてオープンソースの仕事をはじめた瞬間。もう一つは外国に引っ越した瞬間。でもこれを人生の、あるいはキャリアのピークと呼ぶには抵抗がある。どちらの瞬間でも何かを成し遂げてはいないから。

何かを成し遂げた瞬間、たとえばあるソフトウェアの大きな機能を世に送り出した実績はあるか。おそらく HTML Imports はそれに当たるだろうが、これはかけた時間と労が大きいだけでとても成功と呼べない。Bittersweet な思い出くらいがせいぜい。学生時代のステレオタイプに比喩を求めるなら、なんだろう、学年一の美女とデートした(が何も起きなかった)みたいな感じだろうか。したことないからわからないけど。

つまり、自分の人生…というと大げさすぎる…職業人生に、特にピークはなかった。いくつか小さな谷があったから平坦ではない。でも山はなかった。残念だけれど、谷で足を踏み外し崖から落ちてないことを感謝するのがフェアな態度にも思える。感謝祭だし。今夜は。目の前の下り坂もあまり急じゃないことを望む。

気分的なピークを振り返る。求職相手から the offer letter を受け取った日、あるいはプロジェクトから the open source reviewer の権利を受け取った日。転勤願や永住権の認可が降りた日。何も成し遂げていないそれらの夜に頂点を迎えたものは何か。

可能性。あるいは期待。この先の人生で何かすごいことが起こるかもしれないという感覚を強く感じたのがたぶんこうした瞬間だった。けれどその期待を実現することはできなかった、というとあまりに悲観的なので、未だできていないと書いておこう。

けれど「何かすごいこと」なんておこるのだろうか。そんな形のない質量だけの願望を、人は叶えることができるのか。学年一の美女とデートしたい十代ですらもっとマシな見通しを持っている気がする。自分は可能性や期待ばかり追いかけて、その先に何があるかをよく考えなかった。「何かすごいこと」をしようと思っていたのかすら疑わしい。キラキラしたものを追いかけていただけじゃないか。だから大きな可能性を掴んだとき、その奥にあるものを引き寄せることができなかった。きっとそうだよな。

可能性の向こうのことなんて未だにわからないから羨望こそあれ後悔はしようがない。大きな成果を上げている同世代と手のひらにある自分の可能性の燃えかすを見比べると不甲斐なさから多少の失望はあるが、今はまずその可能性たちをささやかに弔うのが筋にも思える。会えて良かったよ、ありがとう、形にできなくてごめんなと。異国の盆は遠にすぎ、感謝祭だけど。今夜は。

[1506.02025] Spatial Transformer Networks

チュートリアルに出てきたので読む。2015 年, 2100 citation くらい。画像の affine transformation のパラメタを learn できるという話。Differentiable Image Sampling というのがなんとも不思議。

grid sampler みたいのはどうやって PyTorch で実装するのだろうとおもったら、めちゃ C++ だった。しかも CPU と CUDA と CUDNN の実装がある。まあ grid generation 自体は事実上 range の生成で、sampler は texture の sampling みたいなものなので GPU で頑張る余地があるのはわかる（論文にもそう書いてある）が、こんな頑張るほどよく使うものなのか。

[1905.03813] When Deep Learning Met Code Search / Neural Code Search: ML-based code search using natural language queries

コードの構造をどう活かすのか気になって読んだが、基本的には雑に tokenize したのち NLP 的に扱うらしい。「メソッド」くらいの粒度は利用する模様。まあそうしないと特定の関数をみつけだす、といった検索ができないからあたりまえか。1 ソースファイル = 1 ドキュメントではないという意味でコードの構造は活かしていると言えるのかもしれない。なんとなくもうちょとミクロな構造を想像していたけれど。

なぜ Facebook がそんなにコードサーチをがんばっているのか謎。PL の研究者がいっぱいいるのでそういう demography の余波なのかもしれない。

またチュートリアル一個進めただけ。朝起きられない。

チュートリアルの写経がまったく捗らない。面白くない、とい面もあるけれど、前に進む感じがないのもやる気を起こさない原因に思える。チュートリアル、ランダムな話題のあつまりにしか見えない。書いてるのもそれぞれ別の人でスタイルに一貫性がないし、品質や重要性も疑わしい。もうちょっと前に進む手応えを感じられる話題が欲しい。なんで毎回この training loop を書き直さなければいけないんだアホくさい・・・。が、そういうことをいってないで黙々と手を動かせという気もする。

代替案として PyTorch の本をやるのはどうか・・・・と目次を眺めるが、チュートリアルの colab やるのと大差なさそう。結局じぶんは読んで得られる知識は足りていて、手を動かす motor skill が圧倒的に不足している。苦手だから読む方向に逃避したくなるけれど、ここは踏みとどまるフェーズなのでしょう。

したがって朝おきられなさは対症療法で凌ぐ必要性を感じる。例えば、寝る前にちょこっと notebook をさわって記憶を蘇らせるというのはどうか。あんまし就寝前に laptop したくないけど、なにごとも試してみるのが大事ということで。だめなら他の方法を考えましょう。

あと Tensor と Module をちゃんと理解してないせいで足元がおぼついていない気もするので、ドキュメント読むなりコード読むなりして理解を深める必要もあるかもしれない。ただ寄り道してると進まないので、これ朝以外の時間に best effort でやる。コードもリンクしとこう。

• pytorch/tensor.py at master · pytorch/pytorch
• pytorch/module.py at master · pytorch/pytorch

コード読みたいけど、読む活動に傾いてしまうと的をきっと外してしまうのだよなあ・・・。

前回。

朝おきるようになってからだいたい一年くらい経ったらしい。

ここ一ヶ月くらいまた起きられなくなっていて困ったものである。基本的に朝の時間は論文を読むことか、Podcast のオフシーズン中は小さな余暇プログラミングプロジェクトに費やされていた。今は PyTorch の写経をしているが、こいつがまったく捗らない。

捗らなさについては別に書くとして、朝おきるのは機能していたなと思う。朝と週末のスタバ逃避は自分にとっては dignity を保つのに必要。なので朝に時間がとれないと精神が削られていくのがわかる。

なぜ夜ではなく朝なのか。世の中の子持ちの大人はよく子を寝かしつけた後に「自分の時間」活動をしている。自分の場合、夜は起きていてもぼんやりインターネットで時間を溶かしがち。あまり意味のある活動ができない。なぜなら夜は疲れているからである。世間の大人たちはなぜ夜でも大丈夫なのかというと、あいつらは若くて体力あるんだよ！若さを口にするのが age discriminative なのだとしたら単に体力の差だということでもいいが、人間の個体差というのは存在するのでみな自分にあった方法を探していきましょう。

夜に活動する別の問題は over budgeting すなわち夜ふかししすぎて翌日に差し支えがち。昼の仕事が世を忍ぶ仮の姿で夜の活動がメインの aspiring people はそれでいいけれど自分は昼の仕事の成果は重要なうえに雇用リスクはリアルなので、あまりそっちを危険にさらしたくない。夜ふかししすぎることはあっても朝早く起きすぎることはあまりないので、そのへんは安心。

実は目覚ましを使うと朝早くおきすぎることはあり、一時期それで寝不足だった。それ以降、就寝が遅れた時は目覚ましの設定時間も遅らせるようになった。

朝起きるための工夫。

Philips の明るくなる目覚まし。これなしにおきるのはほぼ不可能といってよい。最近は子の寝室でも使っている。就寝の際に段々と暗くなる機能があるのも（子の就寝の）役に立っている。まあ大人はスパッと消せば良い。もうちょっと明るいといいんだけれど。光量を補いたいと青い光のバージョンを併用したこともあるが、目覚ましと連動しないのでいまいち。

部屋のデフォルト照明を明るくする、のは夜に眩しいなど様々な都合でやっていない。しかし検討すべきかもしれない。

Fitbit 腕時計の目覚まし機能。腕でブルブルされると、それなりに目が覚める。Philips のお供に。眠い時は無視してしまうが、そんなに眠い時はどのみち寝たほうが良いから問題なし。目覚まし専用機とちがって一日中つけておけるため、つけ忘れがよい。Android や Apple の時計はバッテリーが持たないのでダメ。

すかさず Podcast を聴く。音があると目が覚めやすい。内容はどうでもよいものほど望ましい。立ち入った話は眠くなるので。そういう意味で Audiobooks は不向き。朝のニュースみたいのがよい。つまりラジオだな。音をならしつつトイレに行って用を足し、顔を洗って髭を剃る。ダメな人っぽいがそういうもんです。

すかさずラップトップの光を浴びる。人の睡眠を妨げると評判のブルーライト、それを逆手に取ろうではないか。しかしダラダラと時間を溶かしがちな諸刃の剣。スマホは完全に時間を溶かすだけなのでおすすめしない。

早く寝る。だらだらとインターネットして夜ふかしすると試合終了してしまうが、やりがち。ありがちな問題として、夜のうちに片付けなければいけない諸用があるのに procrastinate して就寝がおくれるパターン。これはきっと翌朝に繰り越すのがただしい。ただしシャワーとかはさすがに寝る前に浴びたほうが良い（が、ダラダラおくれがち。）

早寝の助けとしてメラニンを服用する。イライラしているなどで寝付きが悪い時に有効。定常的には使ってない。

朝にやるプロジェクトを exciting なものにする。あるいは締め切りのあるものにする。やることがはっきりきまっていないと起きられない。最後にかいたけど、これが一番重要かもしれない。しかしそんな exiciting なプロジェクトがあれば苦労しないのだよ。

金曜、土曜と続けて筋トレできず。

子供の就寝に向けて家中を暗くして、ベッドの上で絵本を読んだりしていると自分まで眠くなってしまう。奥様に付き添いをタッチして抜け出した後に体をおこし直すのがしんどい（眠い）。しかも自分はそのあと早々に寝るわけで、あまりおこしてしまうのも良くないし。就寝直前に筋トレというアイデアが良くない、のはわかっているけど、どうしたもんかね。

自分の筋トレは腕立て腹筋スクワットと自重だけでやる極めてカジュアルなもの。15 分もあればおわるのだから、仕事中にやってしまう手はあるかもしれない。たとえば昼食前とか？場所はどうするか。適当に開いている会議室をハイジャックするとかだろうか。幸いあたらしいビルはいまのところ会議室は潤沢。

しかし毎日会社で筋トレするのは気が乗らない。前日の夜に筋トレをしそびれたら翌日会社でやる、くらいはどうか。こうすれば二日つづけて筋トレそびれることは減るであろう。

メタな話として、ここしばらく自分のスケジュール調整をこの日記シリーズとして意識的に記録している。書き出してみると毎週のようにこの話題に頭を悩ませているのが露呈してばかっぽいというか、自分のことしか考えてないっぷりに若干 embarasssing.

もうちょっと頻繁に写真をとるようになりたいなと思っている。このことは定期的に考えるが、あまりに身になる結果につながらない。

写真をとりたい理由そのいちは仕事関係。いちおう毎日手元でビルドしてカメラの APK をインストールするよう自分に課しているのだが、さぼりがち。毎日録る動機がほしい。とくに最近微妙に性能上のバグがある気がするので毎日様子を見たい。（原因はわかっているが他人にたらいまわしたため。どのみち出荷までには直します。）ようするに真面目に dogfood したい。

理由そのには家族関係。子の写真はゆこっぷ（奥様）が割ととっているからいいとして、奥様の写真が少なくて申し訳ないとおもっているため。

理由そのさんは物欲関係。フルサイズフレームのミラーレスが欲しいとずっとおもっているが、買っても撮らなそうという不安がある。写真をとる行為をもうちょっと空気を吸う感じでできるようにしておき、準備ができたら物欲を行使したい。

自分がいまいち写真をとらない理由はいろいろ列挙できるだが、そういう分析よりは意識的に習慣化する訓練が望まれている気がする。

というわけでまず目標設定をしようではないか: 写真を一日三枚以上とる。しょぼい。そのうちバーをあげたいけれどまずはこのくらいで。これを 365 日やったらフルフレームを買って良いとする。

撮るのはいいとして共有するあてがないとむなしすぎて続かない。自分は Instagram には近づきたくない。As well as FB. Blog みたいのがあるといいんだけれど、写真は割とかさみがち。Google Photos でも使うかな。

というわけで一個アルバムをつくってみる。まあこんなもんでいいのではなかろうか。アルバムのタイトルは連番 + 一日のサマリにして、コメントに付加情報をつける。そしてこれを奥様および母上にシェアするものなり。まあ、しばらくやってみます。

ゆこっぷ（奥様）はスマホおよびカメラで写真をとる習慣が完全に板についており、感心する。日常の進行を遮って写真をとることもあり、それは slightly annoying だけれども、自分もおなじことをするのが平和な解決に思える。

とった写真は別にソーシャルメディアに行くとは限らず、どうしているのが不思議。ただ FB などの public social media の他に友達とだけやってるやつだとかメッセージングだとか色々と connected なのでそういうところで share している部分もあるらしい。あと日記 (Day One) とか。使う先が色々あると写真もとる気になるのでしょう。自分はいろいろこじらせていてよくないが、ソーシャルとかメッセージングとかやりたくないしなあ。

日記に写真をつけるのは良いアイデアかもしれない。このブログももうちょっと写真をいれるべきなのだろうか。WP には Google Photos インテグレーションもあることだし、それはそれでやっていいかもしんないね。ただこのドラフト公開スクリプトが写真対応してないからだめかな。

ほとんど進展なし。チュートリアルを一つ進めたくらい。

進展がない一番の理由は時間を割いていないからで、ふたつ目の理由は写経でタイポして原因究明に時間を使っていたから。タイポというか、自分の好みのスタイルに書き直した時に壊れてしまった。まあ一字一句おなじにタイプして壊れなくても特に体験としては意味ないので、書き直して壊すのも写経のうちかなと思う。PyTorch のデバッグのしやすさというのを体験できたのはよかった、かもしれない。

ところで nn.Module には training というフラグがあるのだが、このフラグによって評価時の戻り値の型が変わる (training 時には loss が、それ以外では inference 結果が返ってくる)という実装が普通に行われており、これが Python first の reality か・・・となった。

PyTorch DevCon 2019 のビデオをちらちら眺める。代表的なモデルはオフィシャルに色々実装されていることを知る。チュートリアルでも torchvision の pretrained MaskRCNN を使う例があってなるほどとおもったけれど、それだけではないらしい。CV の detectron2,  BERT とか NLP の新しいやつらの fairseq など。モデルじゃないけど torchtext もあるし。アルゴリズムの実装を眺めたい時に品質のわからない野良コードを探して読む必要は必ずしもないことがわかってよかった。

そのほかおもしろかったビデオ:

• PyTorch on Google Cloud TPUs - Google, Salesforce, Facebook - YouTube PyTorch TPU 対応の話。Glow とか TorchScript とかではなく LazyTensor という独自の仕組みを使っているという。もうちょっとコミュニティの norm に載ったほうが将来トラブルすくなくてよいのでは・・・。
• PyTorch at Tesla - Andrej Karpathy, Tesla - YouTube Tesla の PyTorch 事例。FSD というチップを作って使ってるよ、とかいっててびびる。そんなスタック自分でもつ体力あるのかきみたち・・・。チップ部門のトップは Intel に行ってしまったと言うのに・・・。
• Privacy Preserving AI - Andrew Trask, OpenMined - YouTube PySyft という differencial privacy とかの実装をしている人たちのはなし。そういうのってライブラリにできるもんなのだな。

前回。

雑な "リファクタリング" (クオートつきな理由は察せられたし) をして帰宅したはいいが割と基本的な挙動を壊していたらしく、時差のある世界で仕事をしている人々が右往左往している様子が翌朝にチャットのログから伺えた。ごめんね・・・しかし困ってないでさっさと revert してくれよ・・・。

いい機会なのでチームあてに "壊れてたら遠慮なく revert するのがみんなのためだからそうしとこうね" というメールを書く。これは社内では "rollback first" あるいは "revert first" と呼ばれ、民度の低いモバイル部門以外では常識になっている。その常識を説明したドキュメントをリンクして「ほらみんなやってるでしょ」と伝える。いくつか賛同の声がスレに連なる。

この「壊したらまずは revert」の常識、なんか名前があったはずなんだけどどうも "revert first" ではないっぽい。検索してもでてこない。社内ジャーゴンをあたりまえのように口にする人間にはなりたくないのだが。

ふと考えたが monorepo は rollback first 強制力が高い。なぜなら何かが壊れたときの影響範囲が広いから。TensorFlow が壊れては困り、Protobuf が壊れては困り、まあこのへんは稀なのでいいとして, CV 部門のライブラリが壊れては困り, Research の奥の方の何かが壊れては困り、なんかよくわかんないサードパーティのライブラリがアップデートされ壊れては困り・・・。アプリ側も割とストレスだが、ストレスのたまったアプリ勢からチクチクされる monorepo ライブラリ勢にはなりたくないもんですな。

このところ妻子の就寝後の夜中に grocery shopping と cooking する機会が増えており、結果として就寝が遅れ、翌朝起きられず課外活動が削られている。

食料(材料、作り置き)の在庫を管理、補充するのは大仕事なのでときどきこうした遅れが生まれるのは仕方ないのだが、自分が買い物や調理をしてしまうとこのリズムがいっそう乱れがちな vicious cycle になり、それは困ったものだ。

なぜリズムが乱れるかというと、自分が買い物なり調理なりに介入することで奥様が在庫を把握できなくなるから。まあ冷蔵庫を見れば理論的にはわかるんだけれど、自分で作るものを決めて買い物をして調理してと End-to-End で担当した場合にくらべメンタルモデルを作りにくく、記憶が薄れがちになる・・・と個人的な体験にもとづき理解している。

これは仕事とかで下手にヘルプをつけられると協調コストでスループットが下がるのに似ている。ヘルプ人員（ここでは自分）がフルタイムなら協調コストも割に合うかもしれないが、片手間ヘルプなのでマネージメントに手間をかけてしまうと本末転倒である。具体的にいうと、食料在庫や調理計画の共同管理をがんばるのは大変すぎる。

こういうときのヘルプの定石は「手離れの良い仕事を引き取る」だと思う。そう思っていままでは朝食の調理を引き取って来たのだけれども、今起きているのは朝食材料の不足や子の弁当の材料および作り置きの不足である。つまり朝飯の調理だけを引き取るのだと不十分なことがある。まあ朝食の調理なんて卵を焼くくらいでほとんどやることないから、他の仕事を引き取るのはやぶさかではない。しかし管理コストを増やさない「手離れの良い仕事」を探さないといけない。どういうオプションがあるのか。

ひとつは朝飯の grocery shopping もやり、朝飯を E2E で引き取ること。これは理論的にはいいのだが、重複する材料（例: 卵) の扱いをどうするかが悩ましい。まあ卵は日持ちするので朝飯とそれ以外で共有しないのは一つのオプションかもしれない。あとは奥様が（好みなどの都合により）介入したいケースもある気がする。(たとえば自分はいつも whole wheat で multi-grain のパンを買うが白いパンも食べたいなど。) まあそのくらいの介入はどうぞ、ということにすればよいかもいれない。材料が余ったら冷凍するなり捨てる（ひどい）なりする。

ただ不足で困るのは朝食よりは子の弁当なので、朝飯を takeover してもいまいち問題が解決しない。では子の弁当も takeover すればいいかというと・・・。ちょっと荷が重いなあ。そしてこれは「たまに朝食と弁当の準備が発生する」現状より自分の仕事が多い。しかしまあ、それが正しいようにも思える。

が・・・ちょっとそこまでのコミットメントをする覚悟がないなあ。食事の不足や手抜きを受け入れるのもアリではあるが、食事が貧相だと場が険悪な空気になりがちなのでそれはそれで厳しい。のでしばらくは現状の不定期夜間買い物および調理を受け入れようとおもいます。はい。PyTorch は早起きできたときだけさわるということで。精神衛生マージンに若干不安があるが、まあ永遠に続くことでもないからだいじょうぶでしょう・・・。

もっと具体的で小さな問題な気がしてきた。朝食用食材の在庫補充を責任をもってみている人がいないせいではないか。夫婦で互いになんとなく足りないものを買ったり買い物リストに入れたりしており、そのせいでしばしばタイミングが遅れたり品揃えに漏れが出る。典型的な responsibility gap.したがって自分がすべきことは在庫補充担当の takeover ではないか。

ということでストックしておきたい朝食用食材を書き出してみるとオプショナルなものを含め 20 個くらいある。そりゃ買い忘れるわ。

紙にリストを書き出し、うち必須常備品に下線をひき、台所に貼っておく。これを寝る前や朝食調理時に walk through して足りないものを買い物リストに入れればよいでしょう。この手の作業の mental overload の出処は 1. 必要なものを思い出すこと 2. 必要性の有無を判断すること なので、リストを貼っておけばだいたい解決のはず。

いまなぜこの問題が顕著化したかというと、奥様の忙しさが高い時期だからでしょう。材料ではなく常備菜の枯渇については別途検討すべし。

ひまつぶしにぱらぱら論文を読む活動は続けたいと思い、昼休みとかにちょこちょこ読んでる。論文単位で記事にすると細かすぎるが、日記にまぜると見失いがちなので、何本かまとめて書き出してみる。

[1910.02190] Kornia: an Open Source Differentiable Computer Vision Library for PyTorch

PyTorch を使って OpenCV みたいな伝統的 CV を実装してみたよという話。GPU が使えて割と速いし、NN のアルゴリズムでも前処理に OpenCV つかったりするからぜんぶ PyTorch になってると便利だよと主張する。OpenCV の contributor の一人が書いている事実は面白い。

有り難みに実感はないが、NumPy の上に作られたライブラリたちを PyTorch 用に再実装すると嬉しいケースはぼちぼちあるのかもしれない。

• kornia/kornia: Open Source Differentiable Computer Vision Library for PyTorch

A Landscape of the New Dark Silicon Design Regime

しったかぶりをしてしまった反省を踏まえ、関連論文を読む。これは Dark Silicon をテーマにやっていた UCSD のプロジェクトの終盤にかかれたまとめ論文みたいな内容。Dark Silicon の有効活用として色々な方針があるという話をしている。一つは Near Threshold Voltage Design という、要するにクロックを下げまくるという話。あまりピンとこない。あとはキャッシュに使うのも良いと行っており、最近のサーバサイドの CPU のキャッシュがやたらでかいのは余り面積を活用するためだったのか・・・と腑に落ちた。

特殊用途の回路を作る話としては Android platform の一部を C からコンパイルするハードウェアで置き換えた GreenDroid という研究が紹介されていた。おなじ UCSD のグループが 2011 年にやったもの。Domain Specific Architecture の前進みたいな Conservation Cores というアイデアに基づいているらしい。

[1909.09436] CodeSearchNet Challenge: Evaluating the State of Semantic Code Search

GitHub が MSR と共同ではじめたコードサーチランキングの competition を紹介する論文。自然言語でコードを検索したいんだけどどうしようという問題。

サーチとかランキング以外の部分を作るだけでも大変じゃん・・・と思っていたが、ランキング以外の部分はぜんぶ前処理して JSON を用意してくれており、それをランキングするという趣旨だった。あと LTR みたいなログ頼りではなく伝統的 (?) な IR に近い。

具体的にはコードのコメントをクエリーにしてメソッドを特定するような構成。メソッドは本文も適当に tokenize した文書になっている。最終的なテストは Stakcoverflow のデータを使っている。コメントをクエリーに見立てるのはどうなの、というと、若干いまいちだけど他に良い教師データがないから仕方ないと主張している。

PyTorch 入門日記。

ぐだぐだしてても始まらないので何も考えず入門チュートリアルをこなすものなり。とりあえず最初のやつだけやった。一週間で進捗がこれだけとは捗らなすぎ。来週からはもうちょっと時間を割けるといいのだが。

手元に環境を作ろうかと思ったものの、環境セットアップで時間を溶かしがちな過去を踏まえまずは Colab で。というか実は Conda を入れて Jupyter を起動したのだけれどキーバインドが思い出せず Colab に撤退した。そのうち Conda に戻るかもしれないが、とにかく「正しい環境」を作るのは意識的にさぼり、行けるところまでは素人ぽく進めるのが今回の目標。すなわちなるべく pyenv とかそっち方面は避けたい所存。Colab, リリースされたばかりの PyTorch 1.3 がさっそくインストールされており感心。

さわった感想:

• ほんとに numpy ぽくつかえるのに感心。
• backward() したあと buffer が開放されるタイミングがよくわからない。が、保留。
• nn.Module と nn.functional の住み分けがいまいちわからない. Trainable parameters がある場合は nn.Module にするかんじなのだろうか。まあ実用上はふんいきで使えば良さそう。そして nn.Module の定義をみていると Python にも pipeline operator あればよかったのになと思う。
• DataSet や DataLoader はしょぼいが、こんなもんでいいのかもしれない。
• データの中身を覗くところに強い苦手意識を感じる。いわゆる EDA というやつ。ML 以前に data exploration の練習が必要（だが今はその事実を無視してチュートリアルを進めてまいります。）これとかこれみたいな本があるあたりに R の歴史的強さを感じる。そのうち The Pandas Book (2ed) でも読むことにしましょう。
• TorchScript がモデルフォーマットの標準になると思い込んでいたがまったく間違いで、実際は Python code + weight の dump を使うものらしい。たしかにその方が pretrained モデルが Python オブジェクトとしてさわれるから再利用は圧倒的にやりやすい。TorchScript はあくまでコンパイルされた実行環境向け表現なのだね。

本当はなんらかの ML プロジェクトをやるなり Kaggle に参加するなりオープンソースに PR するなりデータ職を得るなりのゴールをもって進めた方がいいのだろうけれど、決めることができなかった。興味のもてる ML プロジェクトはないし、競技にもやる気を起こせないし、オープンソースをするならコードなりバグなりを読んだほうが早いけど自分がやりたいのは ML だし、職の点では TF をやった方が良いし。

意味のある目標を持つ意義は理解しているが、自分は目標について考えるほど自分と ML の間にある距離の現実を突きつけられ憂鬱になるばかりだった。何か意味のある（キャリアに影響のある）形で ML に関わることが自分にできるとは思えない。

ただその現実に discourage されて何もできずにいるのは癪なので、深いことは何も考えずチュートリアルで手を動かすことにした。これは Hello Work と同じ精神。多くを期待せずただなんとなくさわってみる。なにかおもしろいことがみつからないかなと淡い期待を抱きながら。

やってみてわかった（というか、思い出した）のは自分はとにかくデータを触るのが苦手で、こんな簡単なチュートリアルですら結構 uncomfortable だいうこと。そしてこの uncomfortable な感じは仕事だとなかなか得られない。

実害の無い形で苦手なものを触り「苦手さ」を和らげていく体験として PyTorch をやるのはアリだと思うに至った。目標がなくても手を動かすのは、何もしないよりはマシ。手を動かさずにいると忘れがち。

朝のスケジューリングを工夫した結果 、妻子のドロップオフ最遅時点まで家族として 30 分近くの空白をつくることに成功する。が、その 30 分は「ゆっくり過ごす」という形で消化され、自分は出勤を早めることができない。所定労働時間を満たせない日々が続く。どれだけ時間を shave out しても無駄なのではという絶望が頭をよぎる。フラストレーションで頭が痛い。

冷静に考えるとこれは「時間がない」ストレスではなく「時間をコントロールできない」ストレスなのだろう。20-30 分くらいの時間は勤務時間内ではしばしば浪費されるが、これほどのストレスは感じないわけだから。

朝キチキチと物事を進めて時間を前倒すのには、それはそれで子を急かすなどのストレスがある。それが「所要労働時間を満たす」の対価に見合わないと暗に捉えられているのだろう。結局のところ働くというのは個人的な所作で、仕事への態度には深いレベルで理解しあうことのできない部分がある。仕方ない。これを説得することに関係性のバランスを費すのは割に合わない。

かわりに退社を 30 分おくらせることにする。退社時間は自分がコントロールできる変数。「時間をコントロールできない」不満を、時間に対する自分のコントロールを行使することで解消する。まあ、妥当。

対価はある。帰宅後の進行が遅れ、子の就寝が遅くなる。30 分ぴったり遅くなることはないにせよ。多少ね。これは望ましいことではないが、自分の精神衛生にもあまりマージンがない。すべてが思い通りにならないのは仕方ない。

子の起床を遅らせることで、朝の bin packing によって生まれた時間を「朝食後にゆっくり過ごす」ではなく睡眠に割り振ることはできる、かもしれない。子は 30 分遅く起きて、家族は従来通り学校の時間にあわせ家を出て、自分は 30 分退社を遅らせる。結果として子の就寝は 30 分遅くなる、というイメージ。子の睡眠は失われず、自分は失われた労働時間を取り戻す。

これでよさそうだな。まあ自分の帰宅通勤は kick scooter によって 15-20 分短縮されているので、実際は上に書いたよりマシになっているはず。

Kick scooter 通勤初日。

徒歩 45 分、ランで 20-25 分のところを 25-30 分くらい。つまり今のところ走るよりちょっと遅い。割と疲れる。心拍の負担はそんなでもないのでランのように汗だくにはならないが、バランスをとったり地面を蹴ったりするので別の筋肉が必要。

道の bike lane を走るのかと思っていたが、ランより遅いので歩道がメインだった。一方、自分の通勤路の歩道は舗装がしょぼいのでガタガタ。交通量をみつつ、安全な範囲で bike lane を使いたい。舗装の良し悪しがそのまま走りやすさと速度に直結している。

いちおう前日にちょっと練習したけど、なんだかんだで新しい乗り物なのでそれなりに不慣れで、あぶなっかしさはある。まだまだ練習というか慣れが必要。しばらくは通勤のオーディオコンテンツ消化はおやすみだな。

総体としては「歩きより速く走りのように汗を書かない」という最低限のゴールは達成されたが、ぼんやりと期待していたそれ以上の素晴らしさは特になかった。それは通勤路の舗装がへぼいせいでもあるし、自分が既に自転車やランなど「歩きより速い人力通勤」の経験者だからでもあろう。

そんなかんじで若干がっかりだったが、たいして練習もせずヘタクソな身分で期待と違ったと投げ捨てるのもかっこ悪い気がするためもうしばらく練習したい所存。久しぶりに普段使わない筋肉を使っている感じがあって、それは良い。スポーツだと思って取り組むべし。返品のウィンドウは一ヶ月だけど、どうかな。せめてもうちょっと上手になって、危なっかしさが下がるといいんだけれど。

Kick scoot したあと他のオプションについて考えたこと。

自転車はよくできている。すごい速いしラク。家に置き場所があるあら自転車に乗りたいもんです。「自転車」という形態が究極的な良さを持っているというより、十分に需要があるおかげで人類ががんばって改善を重ねてきた結果な気がする。Scooter、もうちょっと伸びしろあるんじゃないの? 自分がもっているやつより車輪の直径がおおきく、かつサスのあるモデルもあるらしい。ただのりやすさが増すほど嵩も増すのが悩ましい。まあ、しばらくは今のやつに乗ります。奮発したし。

ここ一週間くらい通勤中にあらためて周りを見ていると E-scooter は結構みかけるが、あれはないなという結論。あまりに運動しなさすぎ。

製品開発においていちばん影響力をもっているのは誰か。もちろん組織構造で上の方にいる人が偉いわけだが、それはさておき様々な SWE, SWET, PM や UX など色々ある職能のうち誰が強いのか。

ブラウザをやっていたころは、プログラマが強い印象だった。自分が  Web の API を増やす部門だったせいもあるとはおもう。プログラマ（のうち意見のあるアジテーターみたいな人）が色々とやりたいことを決める。PM は主にロジスティクスとか辻褄あわせとかをやる。仕事の性質上 UX はいない。Web API に限らず、ブラウザという製品の舵取りをするのは founding member のエースプログラマだった。今はどうだか知らないが・・・。

UI にしても、デスクトップだとメニューに要素を一個足すくらいなら UX に相談とかは一切なく新入りプログラマが思いつきで足すようなことを平気でやっていた。というか自分は  パッチ修行として Mac Chrome に「辞書を引く」というコンテクストメニューの項目を足した。十年前は牧歌的な時代だったという話でもあるが、それだけでもあるまい。

UX

スマホアプリのチームに異動してびっくりしたのは UX の力の強さだった。プログラマが雑に UI を決めたりはせず、基本的には UX (デザイナ) のつくったモックを実装する。プッシュバックしたりはあるが、ほとんどのプログラマは自分でモックを起こすことがない。新入りが勝手にメニューを足していたデスクトップとはだいぶ違う。画面が狭いので雑さが許されない。

UI をデザインするというのは、結局機能をデザインするのと同じ。なので UX が製品の舵をとっている・・・というのは大げさすぎるが、プログラマには「降ってきた仕様」を実装する下っ端ぽさがあった。（自分が性能改善ばかりやっていたのは、それがなんとなく面白くなかったせいもある。）面白いのは UX の人々が自分の権力を自覚していないように見えたこと。そして UX とプログラマの関係が妙にウォーターフォールぽかったこと。プログラマ主導、実験指向で漸近的な開発を誇っていた企業のはずなのに、モバイルになった途端こんな前時代的になってしまうとはとショックを受けた。

まあプログラマは別に地位が低いわけではないし意見もある人々だったのでただおとなしく仕様を実装したりはせず色々ネゴしたり自分のやりたい機能をゴリっと入れたりもしていたがそれは個人の努力であって、プロセスはそうしたプログラマの自律性を後押しはしていなかった。

ただしばらくモバイルの仕事をして振り返るに、これはやや極端な例だった。つまり、必ずしも UX パーソンが仕様を主導するわけではなく、それができるのは優秀かつ意見のある人だということ。たとえばチームの新機能ブレストみたいのをリードするのは誰か。UX の人が主導するチームもあるし、プログラマが主導するチームもあるし、PM がやるときもある。

自分が体験した UX 主導プロジェクトは、プログラマが相対的にボンクラだったのに対し UX のひとはすごい優秀だった。実際そのひとはトントンと出世し、どこかに行ってしまった。その人の下で働いていた UX の人がいまの自分のチームにいて、やはりというか割と優秀である。

PM

Mini CEO などともてはやされがちな PM. 存在感はまちまち。ブラウザ時代いっしょに仕事をした PM は雑用っぽいかんじだった。無能というわけではなく、ただ方向性とかは主張しない人々だった。当時はまわりに TPM も PGM もいなかったけれど、事実上そうした仕事をしていた気がする。おかげで人々から感謝はされていた。

電子書籍時代の PM は、下っ端の若者はさておきシニアな人は大きな方向性やビジョンみたいのは決めていた気がする。たとえば「Audiobook やるぞ」みたいな。そういう人がミーティングでバーンとプレゼンし、具体的な機能は、その方針をうけてプログラマなり UX なりが考える。PM がエラそうにしてる！と最初はちょっとびっくりした。

電子書籍ではコンテンツホルダ（出版社）との窓口をするパートナーシップの人も存在感を持っていた。契約上の色々なめんどくさいことはこうした人たちが PM と組んで deal してくる。プログラマは出る幕なしで、決まったことを実装しないといけない。これはパートナーシップ部門の人が偉いというよりはコンテンツホルダが偉い、すなわち Content is king という話な気もする。むかし Ben Evans が Content isn't king と書いていたが、これは市場を独占した人たちに限った話。

PM は色々なことをトップダウンに決めているように見えたが、実際は関連部門の意向をとりまとめていた面もあったのだろうと思う。今やっているカメラの PM は比較的仕事ぶりの transparency が高くどうやって物事を決めているか開示している。それによれば、リサーチ部門からハードウェア部門から OS 部門まで各方面に話を聞いた上で判断を下している、ように見える。バーンとトップダウンにプレゼンしているように見えた電子書籍時代の PM も、たぶん事前に各職能の leads と相談し、おおよその合意を形成していたのだろう。自分が気にしてなかっただけで。

トップダウンより合意形成を重視するのは、一つには PM は別に関連部門の上にいるわけではないからだろうね。それでも自分がいまいるチームの PM はそれなりに筋の通った価値基準を持ち必要に応じて外からの提案を押し返したりもしているので、個人的には評価している。エラくなりそう。

SWE

プログラマはソースコードという最終成果物に直接アクセスできる強みがあるので実質的には一番権力がある・・・と思っていた時期もあったが、実際にはケースバイケース。

たとえば勤務先のモバイルだと勝手に UI をいじれない。レビューが必要。これは大企業だから官僚的という面はあるし、モバイルだから画面予算の管理が厳しいという面もある。

電子書籍だと、コンテンツホルダとの契約があるのでデータのいじれる範囲に限度がある。社内で実験的になんかいじるのはいいのかもだが、その結果の扱いには制限が多い。新機能のために契約の制限を克服するにはパートナー担当や PM の協力が必須。そしてふだんからパートナーシップに接している PM は契約をどこまで交渉できるかの肌感覚を持っているので、標準的なプログラマとくらべ機能デザインにもカンを働かせやすい。

Web API にしても標準化されてるのでコードがいじれるからといって勝手に増やしていいわけではない。標準化団体で人々を説得するなどが必要。とはいえモバイルプラットフォームとかの方がプログラマが自分で API を決めて実装している色が強い。何らの官僚的なプロセスはあるにせよだいたい会社の中に閉じており、競合他社を説得するとかは必要ない。コミュニティを説得しないと新しい API を使ってはもらえないが。API を決める仕事とっても色々あるね。

様々な場面でプログラマが主導権を発揮できないのは、該当者がボンクラだからという面はゼロではない。UI プログラマならモックくらいいじれるべきだし、電子コンテンツプログラマなら権利関係を理解しているべきだし、Web API プログラマは弁が立って然るべき。といえなくもない。

たとえばカメラの高画質を支えるアルゴリズムを開発したリサーチ部門のトップは製品開発の組織系統に直接は所属していないにもかかわらずめちゃめちゃな影響力をもっており、他のチームが一年かけて作ってきた機能を一声でボツにしたりする。これは実力の帰結と言えよう。

これは極端な例かもしれない。とはいえプログラマなら勝手に書いたコードはそのまま出荷はできないにせよデモくらいはできる。雑な世界にあった自由と力はないにせよ、なんらかの優位はある。ただデモとかハックをするにはある程度ヒマが必要なので、締め切りに追われてるとダメだね。

組織で働く会社員プログラマの仕事場として望ましいのは誰が力を持つチームか。

プログラマが力を持つ環境で一度くらい働いておかないと、それがどういう状態なのか理解するのは難しいかもしれない。今の会社に入る前の自分は、たぶんわかってなかった。一方で他の職能のひとが活躍している様子を見るのは、それはそれで学びがあり、人を humble にする。

あと一つの職能の人だけが活躍しているより、それぞれが主張をしつつ交渉や議論のダイナミクスの中から製品が立ち上がってくるほうがわくわくする面はある。プログラマが主役になってばかりの環境にはない面白さがある。

たとえば UX のひとがもってきた新しいデザインに、ちょっと気の利いたツイストを加えた POC でプログラマが応じる・・・みたいなのは見ていて楽しい。あるいは自分がやっている性能仕事のドキュメントをもとに PM が気の利いたピッチをスライドにするのを見るのも・・・まあ、なるほど、とは思う。自分がもうちょっと野心のある身だったら盛り上がるのではなかろうか。今は若干こっちくんなとか思ってしまうがそれは PM のせいじゃないからね・・・。

ただプログラマが仕切っている環境の方が、その仕切っている人の価値観とズレがないならストレスは少ないね。ストレスが低いのは、それはそれで大切。

Draft の底に沈んでいたやつを Rebuild で話す準備として掘り起こしてみたが、話す時間なさそう。

• Indistractable: How to Control Your Attention and Choose Your Life: Nir Eyal

Growth 指向の product design 本 Hooked の著者が書いた、気を散らせずにやることやるための自己啓発本。

断線リテラシーを高めるために読んだ。基本的にはライフハック集。だいたい聞いたことがあるような話。著者は Cal Newport のような反テクノロジー業界原理主義者でないせいか、テクノロジーからの割り込みと戦う話だけでなくそのそのほか様々な割り込みや誘惑との戦いにもページを割いている。要するに The Willpower Instinct みたいな方向性も織り込まれている。

ライフハック集としては悪くないが、態度の煮えきらなさはある。全体としてテクノロジーは悪くないといいつつ、ゲームやアプリといったコンテンツは注意力を奪う専門家が作っているから気をつけろと言ってテクノロジーブロッキングのためのライフハックを紹介したり、子供がゲームやインターネットにハマるのはテクノロジのせいではなく親の問題といいつつ最終的には "feature phone からはじめるといいよ" といってみたり、ライフハック以外の文脈では TED 的 inspirational-but-not-actionable な「自分を信じろ」的議論をしてみたり、盛り上がらない。自分はなんだかんだで Cal Newport ファンだと思い知らされた。

一方でもともとテックで一山あてた人間が反テクノロジーの流行りに乗っていく軽薄さに鼻白む思いをしていた自分としては、2019 年の今日「いやテクノロジは悪くないですから。付き合い方の問題ですから」と言い張る著者にある種の誠実さを感じないでもない。

Self-Determination Theory という学派（本もある）の主張を引き、子供がスクリーンに引き寄せられてしまうのは basic psychological needs が満たされていないからと主張しているのは面白かった。この本は冷やかしてみたい気もする。

去年は色々なものを並列化して速くしようとしたわけだが、実環境での trace をみるとしばしば CPU のロードが満杯になっている。つまり並列化しても速くならない。手元で実験しているときはデバイスの状態が clean なので、この実環境の現実は忘れがちである。

CPU のロードは自分たちのアプリや関連サブシステムだけでなく、あんまし関係ないアプリおよび OS のロードに使われている。下の方のレイヤだとたとえば LMK や OS の paging, SystemServer がなんかしてるなど。もうちょっと上だと Play Services がランダムになんかしていたり、システムからの broadcast に応じて寝ていたアプリが起きたり、色々ある。

OS 性能班の人がでてくるとこういうのを直してくれたりしなかったりするが、自分にシステムの大局的な挙動はいじれないのでアプリでできることを探す。

CPU がオーバーロードすると何が問題なのか。たとえば、並列化して追い出したつもりのタスクがサイクルを使いクリティカルパスを遅くする。同じことが投機的実行についても起こる。いわゆる prefetch みたいなコードがサイクルをうばう。そうした non-critical path コードが CPU だけでなく何らかの専有的資源 (I/O とか) をブロックするとさらに遅くなる。

クリティカルパスのコードはそれなりに高い thread priority を持っているが、Linux の scheduler というのは realtime ではないので優先度の低い thread もそれなりにターンが回ってくる。そして low priority threads がいっぱいあると集団として high priority threads を overwhelm してしまう。

一部の HAL は realtime thread を使っているのでこういう問題が起きにくいが, HAL の中に限ってもクリティカルパス全てが realtime に保護されているわけではない。たとえば最近みたやつだと realtime なスレッドから間接的にリクエストを受け取った gralloc HAL での共有メモリ (ION) のアロケータが realtime でないせいで滞り、結果として realtime HAL も詰まらせていた。知らんがな・・・（buffer を preallocate すれば問題を回避できることは確認したが、対価となるメモリ消費量がそれなりなので判断は保留して詳しい人に引き渡した。)

そうした事情から、今年はアプリ起動時の高速化方針を変えた。つまり、色々なものを並列化して eager に初期化するのではなく様々な初期化をなるべく lazy に直して最低限の機能が動くまで先送りし、ベースラインの準備ができたあとで投機的な初期化のタスクを動かすことにした。まあまあの成果。

高負荷状態を手元で再現するのは難しく、まだできてない。単純に CPU やメモリのロードを増やすのは簡単なのだが、それだと SystemServer のようにクリティカルパスをブロックしがちな platform のコンポーネントを stress することができない。もうちょっと platform を exercise するような load generator が必要。OS の中の人はそういうテストをしてるらしいけど、関心は systems としての throughput や stability なので、アプリ単位での latency みたいのは当事者（自分）がなんとかしないといけない。

いまのところ、たまにヒープを baloon するプロセスを動かしつつ CPU コアを半分くらいとめて trace を眺めるといったローテクかつアドホックでいまいちな方法を使い、ふーん・・・とかいってる。それでも先の gralloc のレイテンシは再現できた。しかしもうちょっとなんとかしたい、しかし自動化やってるとあっという間に月日が流れてしまいがちなので誰かにやってほしい、というかやってくれることになっているので気長に待ってる。

カメラは画像処理とかの性質上 C++ のコードを使いがちなのだが、各チームどころか各個人がアドホックに使うものだから .so ファイルの数が大変なことになっていた。社内のグループで "そうはいってもネイティブライブラリ減らすのって大変ですよね。我々も N 個から N-1 になかなかできずに苦労してます" というコメントがあったが「いや我々 M (>>>超えられない壁>>> N ) 個くらいあるのでとりあえず low hunging fruits からやっつけますわ」などと会話をしたら、M の大きさに相手は戦慄していた。

そんなん Blaze (Bazel) のせいで俺のせいじゃねーーー。とおもって放置していたのだが、全社的に性能問題への締め付けが厳しくなった結果 OS の中の人からチクチク言われることが増え、仕方ない尻拭いするか・・・と直したら色々速くなった。あ、ごめん・・・。みたいな気分。

以下ではロードする .so の数が多いと何が問題なのかという世の中の大半の人にとっては極めてどうでもいい話をします。

まず前提としてこれらの .so は必要な依存関係を全て含んだ自己完結 SO である。OS 付属のライブラリを除くとぜんぶ必要なコードが入っており、ある SO が他の SO のシンボルを参照したりはしない。（一つの理由としては、そういうのが苦手なビルドシステムを使っているため。) 結果としてけっこうコードが重複している。コードの重複はヒープを圧迫することはあれ必ずしも性能低下につながるとは限らないが、こいつらは傾向として雑に書かれた C++ のため、static initializer がけっこうある。ABSL みたいな共有コードの initializer は何度も走る。まあ、無駄。

また SO をロードする bionic のローダは global lock を持っている。symbol table を保護する必要があるので割と仕方がないとは思うが、たとえば Dagger の object graph provisioning が複数のスレッド上で並行しておこると lock contention になる。そして初期化のコードはがんばって CPU を使うべく並列化してあるので、実際ばんばん衝突する。しかもライブラリを読むとかいうのはしばしばファイルアクセスが伴うのですごい待たされる。厳しい。

JNI メソッドの symbol lookup は、それなりにコストがある。 ベストプラクティスは RegisterNatives という JNI の API を使った early binding だが、export するシンボル名を convention に揃えることで Java runtime に late binding させることもできる。その方がコードを書くのはラクなので、雑なコードはしばしば late binding になっている。

がしかし！その late binding は当然 symbol lookup が伴うので潜在的に lock contention の可能性がある。というか dogfooding 上司のよこした on device trace をみるとめっちゃ競合してる。厳しい。しかし知るかよーーさぼんじゃねーーー！

しかもしかも、JNI の symbol 名は SO 単位でテーブルが作られ、lookup はそのテーブルのリストを順にスキャンしていくのである！ (参考: FindNativeMethodInternal()) そうですよねー常識的に考えて O(M*log(S)) ですよねー・・・つらし・・・俺のせいじゃねー・・・。

手抜き C++ プログラマたちのせいで OS の人から突き上げられるのにいいかげんイライラが限度に達し, 半月かけてチーム内の SO をマージした。レビューをたとむと「え、それが遅いって証拠あるの？」とかいってくる子もいて心底うんざりしたが、「OS 方面からのお達しですので」と言い張り心を無にして完遂。組織の壁を超えた連結は諦めつつ、そっちはそっちでまとめてね、と協業チームに頼んでくっつけてもらうくらいはした。なお GCAM の皆さんとは仲良しかつ自分がファンなのでこっちでやってあげた。ははは。そういうもんです。

なお Chrome のようにスパルタネイティブ集団がつくるアプリにはこうした問題は一切ない。謎の tooling で自動的にこうした問題が解決されている。すばらしい。（と一瞬思ったが、あるときじっとコードを眺めていたら .java のコードを C preprocessor に通しているのを発見して目が覚めた。ガラケーアプリかいな。)

こうした問題がおこるのは、基本的には C++ を画像処理 DSL だとおもっている（間違ってないけど）困った人たちのせいなのだが、その雑さを許してしまう Blaze/Bazel というビルドシステムのせいでもある。

Gradle と違い、Bazel で JNI のコードを書くのはすごいラク。Bazel はクロス言語のビルドシステムという顔をしているが、現実的には C++ と Java のビルドシステムである。だからこの二つの言語を混ぜるのは超得意。ただ混ぜるのが簡単すぎるので、ピンポイントでちょこっと C++ で NDK の API を叩きたい誘惑に屈しがち。結果として細かい SO が大量にできることがある。

いや出来ないよね普通。おかしいよね。ほんとに。

なお最近の Bazel は cc_library を androd_binary の依存関係のどこかに入れておくとそれをかき集めていいかんじに単一の SO を作ってくれる。しかしこれは割と最近の機能なので、自分たちのように歴史あるコードベースは従来の suboptimal な方法に従っているのだった。まあ実際に遅延ロードしたいネイティブコードもあるので、問答無用で一つにまとめられるのはそれはそれで困る。

まあどうでもいいです。人々は油断するとすぐ新しい SO をつくってくるので本当に腹が立つ。たぶん linter なり presubmit check なりで取り締まる必要があるのだろうな。そんなタスクを登録したまま忘れてた。来週気が向いたらやろう。

高速化の達成度と自分の達成感が噛み合わない mixed feeling な仕事だった。

テクニカルな理解が低いと良い意思決定ができない。でもそういうのが必要な場面はしばしばあって辛い。という話。

去年の今頃、テストやベンチマークの自動化を強化するプロジェクトをはじめた。そのときは隣に QA チームがいたのでおすすめの自動化フレームワークを聞いたところ、彼らの作っているツールを勧められた。QA チームが保守しているベンチマークを自分たちの都合良いように書き直したい思惑もあったし、彼らはこのツールでテストを書き直すというし、他によい当てもなかったのでそのツールで自動化に着手した。

のだが・・・とにかく使いにくい。やばいレベルで使いにくい。ほんとにこれでテストとか書き直せるの？無理じゃね？どうしてこんなものが存在してるの？と思ったものの、専門家であるはずの人々がそれでいくというのでがんばって使い続けた。しかし全く捗らない。ツールを自分に勧めてきた A 氏は席を外していることが多かったので、その隣にいた同じ QA チームの B 氏に、ほんとにこれでいくの？どういう予定なの？などとたびたび質問した。しかし B 氏の反応もいまいち煮え切らない。

自動化にあわせてアプリ本体のコードに入っている計測のフレームワークも整理する必要があり、自動化作業自体はしばらく保留して製品側のコードをいじっていた。そのころチームに新しい TLM の X 氏が入ってきて、彼らの自動化業のためのスタックを評価しはじめた。件の QA 部門推薦フレームワークも評価し、これは全然ダメだからやめた方がよくね？というドキュメントを書いてチームに回覧した。あ、それ言っちゃうの？という外交的配慮と、まったくその通りだよ、という安堵が同時に頭をよぎる。なお自分も少し前に似たような評価のドキュメントを書いて「こいつは若干いまいちだが隣の QA の人たちからのサポートもありそうだし足並みそろえた方がいいのでこれにしましょう」という結論を書いていた。

一方、別のオフィスにいる比較的最近はいってきた別のプログラマ Y 氏が、また別の目的で自動化作業をはじめていた。 TLM の X が書いたドキュメントから実際の自動化コードがリンクされていたので見てみると・・・よさそうじゃん。（自分が作業をはじめた頃はまだ計画だけでコードは見当たらなかった。）

自分は隣接 QA 部門との間でスタックを断片化したくないのでいまいちなツールを使い続ける気だったが、同じチームの Y は既に別の（よさそうな）ツールを使い始めている。つまりどのみち断片化してる。そして自分が保守したくないとおもっていた自動化インフラの boilerplate なども Y がぜんぶ片付けてくれている。この船に乗るしか無いとそれまでに書いたいまいちバージョンのベンチマークを捨て Y の選んだフレームワークで書き直した。これまでの苦労はなんだったのかというくらい色々なものがあっさり解決し、そのいまいちツール対応のためにアプリ側に入れたワークアラウンドも削除することができた。その前の 1-2 ヶ月の苦労は何だったのか・・・。

ベンチマークは今でも動き続け、たまにリグレッションをみつけたりしている。

自分に自作ツールを勧めてきた QA チームの A は、気がつくといなくなっていた。他の部門に異動したらしい。隣でツールへの評価に口を濁していたテストエンジニア B も、しばらくするといなくなった。たぶん機能不全なチームだったのだろう。

この事件のあと、自分はなぜ正しい決断ができなかったのだろうと考えていた。ツール自体への評価（出来の悪さ）は明らかだった。新しくやってきた TPM の X は早々にダメだしをした。別のオフィスにいた SWE の Y はダメツールには（たぶん）一瞥もせずマシなフレームワークで作業をはじめた。なぜじぶんは嫌な予感を押し切ってダメツールを選んだのか。

最初に考えたのは「政治的意向で技術的判断をするのがよくなかった」という反省。つまり QA チームと足並みを揃えたいという気遣いが判断を曇らせたというもの。これは一理あるが、一方で純粋に政治的判断というわけでもない。同じツールを使えばインフラの保守を相手に任せられるという潜在的な利点がある。

じっさい出来のよい自動化フレームワークを使うためのインフラのセットアップはけっこう大変で、Y がやってくれたからよかったけれど自分でやりきれた自信はない。一方で保守をしてくれるはずだった A と B は QA チームからいなくなってしまったので、彼らのインフラに載ったとしても人の入れ替わりに際して自分が尻拭いをする必要にせまられた可能性もある。

次に考えたのは「人を見る目がなかった」というもの。出来の悪い自作ツールをピッチしてきた QA エンジニアの A は信じるに足る相手だったのか？謎のオレオレ再発明が跋扈する厳しい社会を生きるには信頼できる相手を見抜く目が必要なのでは？この論点にも理がないではないが、一方でテクノロジを評価するのに人を見る目を養うというアイデアは自分の価値観に合致しない。そういうのは VC のひととかががんばることだと思う。

最終的に自分の腑に落ちた結論は、自分の会社員モバイルエンジニアとしての実力不足とコミットメント不足だったというもの。

たとえばダメだし文書を書いた X はその前にまともなでかいチームで働いていて、なんらかのマシな自動化インフラがあることを（自ら作業した経験がないにせよ）なんとなく知っていた。

出来の良い自動化フレームワークを導入した Y は、その後チームの自動化担当としてほぼ専任でインフラの面倒をみている。そのインフラはよく壊れる（当人の問題ではなく組織の問題）ため、保守は大仕事。じっさい彼のいるオフィスはテストやベンチマークなどのインフラを一手に引き受けるサブチームへと発展していった。

判断を下した時点で、自分にはより良い答えがある確信も、インフラの保守ふくめ全部自分の正しいことをやり切って引き取る覚悟もなかった。（後者は今もない。）ただしい判断を下すには X のような「正しい環境で働いた経験」か、 Y のような「ぜんぶ自分でやる覚悟」のどちらかが必要だった。どちらも自分にはなかった。

今は覚悟を決めた Y およびその周辺の人々のおかげでインフラが整備され、自分は「正しい環境」を知ることができた。チームを異動して似た仕事をする機会があったら正しい判断を下せるだろう。つぎはもうモバイルやりたくないけど。

この会社員的な視点から一歩下がって考えると、一人前の Android プログラマとして知識が足りてなかったように思える。もうちょっと勉強しとけや、というのがより一般的な教訓かもしれない。

でも実機でベンチマークを自動化する環境づくりとか、仕事じゃないとやらない気がするね。趣味で mobly を使える気がしない。なんかもうちょっと普通に使える host driven な E2E のモバイル向けベンチマークツールないのだろうか・・・。

技術的負債ってときどき返さなくていいときあるよね、という話。

わかりやすい例: いわゆる MVP として雑になにかをつくり製品としての手応えを確かめた結果ダメそうという結論になったとき。その試作的コードは捨てられておしまいとなる。

OS バグなどのワークアラウンドをベタっと埋め込んだ時: OS のバージョンがあがってそのワーウアラウンドをまるごとばっさり消せる。同様に CPU の遅さを回避すべくグチャっと非同期なコードを書いた時: CPU がはやくなってそのワークアラウンドをまるごと消せる。PM が締め切り前に無茶な機能をつっこむよう求めていたのでやっつけ仕事をしたが、その思いつきは結果が出なかったので巻き戻すとき: これは冒頭の MVP の例と一緒か・・・。

無駄に一般化するなら: 目の前にある複雑な問題と戦う抽象を生み出すことができずベタっとゴミを投げつけ目をつぶっていたら、いつの間にか複雑な問題自体がなくなってしまうことがある。そういうときは技術的負債、借金を踏み倒せる。

これは単に「そういうこともたまにあるんだな」という発見を紹介しているだけであって、だから負債しても OK とかどういう負債は免責されやすいとか、役に立つ洞察は特に無い。しいていえば一種の YAGNI を示唆していると解釈できるかもしれない。つまり、過剰な一般化をしてしまうと問題が消えた時に巻き戻しにくいので、相手をしている複雑さが居座るとわかるまではベタって書いておいた方がよい、かもしれない。

なおゴミコードを書いたあと異動なり転職なりをするという踏み倒しもありうるが、人間関係の負債にすり替わりがちなので waiver できたとは言えない気がする。

つづき。

Redux の one-way data flow というアイデアは正しいので取り入れたいが、UI 全体を一つの状態で表現するのは自分の目的にはエクストリームすぎるし変更がでかすぎるので仕事で使うことはなかろう。Reducer 使おうとか人々を説得できないわ。

そして Redux にせよ MVx にせよ自分の面している主要な問題を解決してはくれないことに気がついた。それはおそらく、相手にしている問題が典型的な JSON からリストを表示するお仕事ではないせいに思える。

"App Architecture" の皆様が暗に共有している前提がある: 沢山の種類のデータがあって、それを表示するために沢山の画面を素早くつくらないといけない。そして画面の作り方はなるべく標準化されていてほしい。この Airbnb チームの記事は彼らのライブラリ MvRx で 100 screens 作ったよと誇っており、この要件を鮮やかに伝えている。

自分たちのアプリは大きな activity が二つしかなく、そのうち一つは設定 activity。自分の関心はもうひとつのメインの activity だけである。しかしこの画面が割と複雑でなんとかしたい。

カメラアプリには複数の「モード」がある（例: 写真、ビデオ)。しかしこれらのモードは同じ画面、同じ UI を共有している。この「モード」は言ってみれば reactive な data source / model. 常識的に考えると個々のモードごとに別の画面にするのがラクなわけだが、シームレスさなどの都合でそうはなっていない。

モード間で UI がまったく同じならまだ話は簡単なのだが、当然そうはいかない。shutter button の色がモードごとに変わったりする・・・のはまだいいとして、たとえばビデオだと録画時間を表示するだとか、長時間露光モードではプログレスを表示するだとか、そういうのがコード上には全部つっこまれている。

つまり一つの UI を複数種類の "model" が共有しており、そのときアクティブな mode / model が UI を専有する。当然ユーザとのインタラクションもモード次第。

そんなら各モードが勝手に UI を使えばいいじゃない、というとまあまあそうなのだけれど、現実には大量のコピペが発生する。なぜならモード間で共通の挙動も沢山あるから。そいつらをなんとか factor out してあげたい。しかし各モードは違う人々によって実装されているので、そういう cross-cutting concerns は見逃されがちである。

モード固有の UI にも問題が多い。あるモードが新しい UI を足すと、他のモード固有の UI に干渉したりする。なぜなら画面の real estate が限らているから。モードの切替時に飛ぶ鳥後を濁さないようにしてほしいのだが、モードの切り替えは mess になりがちである。

そしてモードの切り替え、およびアプリの起動はなるべく速くしたい。多くのアプリでは UI の初期化なんてネットワークリクエストの遅延でマスクできたりするのだけれど、カメラの HAL の初期化はそれなりに速い場合もあるのでデバイスの性能によっては UI の初期化がクリティカルパスになる。全てのモードの UI を非表示の状態で雑につっこんでおく、とかやられるとどんどん遅くなってしまう。Lazy に初期化しないといけない。しかしそうした laziness を後から足すのはわりかし骨が折れる作業である。その UI 部品が複数のモードから共有されていると特に。

そして様々なデータソースがガチで reactive というか realtime stream である (例: autofocusの位置.) UI も immersive なので drag みたいな操作が頻出する (例: ズーム). ViewPager にまかせとけばいい、というわけにはいかない。

そして画面の回転をシームレスにするためのロジックがこれら全てをじんわりと複雑にしている。

とか色々問題がある割に UI は割と頻繁にかわる。なぜならコンシューマ製品には見た目の新鮮さが欠かせず、しかし製品の性格上「画面の背景色」などがあまり存在しないので色とアイコンのような theme をいじってごまかす手が使えないからである。

めんどくせー。

大げさにいうと、カメラの UI は「モード」というプラグインを差し込むためのプラットフォームである。モードに必要な拡張性、カスタマイズ性を提供しつつ、挙動の一貫性やモード間の隔離や性能を保証することが期待されている。しかしそういう複雑さと戦う準備がまったくできておらず現状の mess に繋がっている。UI は detail とかいったひと、こっちきて clean architecture とやらで手伝ってくれや・・・。

この "UI は detail" の態度は自分たちのチームにも若干あり、それは比較的 junior なプログラマが UI 共通部を担当している事実から伺える。皮肉なことに、モードとかがそんなに沢山なかった製品開発の初期には割と実力のあるプログラマが色々作り込んでいた形跡がある。現状の UI の扱いにはそうした人々が move on した "保守フェーズ" という暗黙の想定を感じる。

でも QA cycle を消費しているのはそうした UI の mess に起因するしょぼいバグたちであり、UI のコード品質がチームの velocity 下げてますよね？ OS の HAL や画像処理アルゴリズムのネイティブコードのクラッシュや AI 的機能の concurrency にまつわる微妙な deadlock や性能のオーバーロードによる瞬間的なコマ落ちなどは「難しい問題」でシニアな人々が沢山でてきて頑張って相手をしている一方でしょうもない UI のバグを相対的にシニアでないプログラマが直したりしているけれども、消費されている関心ではなく単純に出荷 delay でのインパクトだけを見たら「しょうもない UI バグ」の影響はなかなかのものなんじゃない？

もっともこれを "UI は detail" という態度の帰結だというのはあまりフェアではないかもしれない。どちらかというと "UI は壊れやすいもの" という諦めの帰結という方が近い気がする。どちらにせよ個人的にこれは受け入れがたい結論である。我々の UI は (競争的優位ではないかもしれないけれど) チームの生産性にとって瑣末なものではないし、それは良いコードによって改善できる問題である、はず。

というわけで今年の残りと来年は UI なんとかするぞ！その「難しいバグ」はお願いだからこっちくんな！という心意気になった今日この頃。ただ上の方の人にそういう認識がないので、肩身が狭いのだよなあ。「難しい問題」の呪いを感じる。

仕事の UI コードをなんとかするアイデアを得るべく Android Weekly のアーカイブを眺ながら "Application Architecture" 的な話題を探す。

MVVM, MVP あたりまではフォローしていたが MVI (Model-View-Intent)というのが何なのか気になっていた。結論としては MVI = Redux/Flux だった。MVI をウェブで探しても canonical な資料が上の方にでてこないのは、そもそも MVI という用語自体が冗長だからだったのか。発明なしにラベルだけつけ直すとか、ほんとに Android プログラマコミュニティはしょぼいな・・・。

なんとなく Redux は React.js のような Virtual DOM を前提としている気がしたが、MVI の人々は気にしていない。MVVM の ViewModel を functional につくり、Presenter がその ViewModel を View に適用する。要するに ViewModel の POJO Data object なり ORM のオブジェクトなりが React の component の役割を果たす。たしかにそれで概ね問題ない気がする。

React が virtual DOM を必要としているのは,  ウェブフレームワークの伝統として結果を "render" する ... すなわち HTML を生成する... というメタファをそのまま持ち込みたかったからだ、と自分は解釈している。ウェブ以外の UI プログラマからすると "render" としてHTML を生成するのは完全に狂っておりわけがわからない。しかしその狂った伝統を貫き通すため React は virtual DOM (以下 VD) という mad science を必要とした。

一方で伝統的な UI ... というと広すぎるので Android に限った話 ... では、render のように HTML というか View の XML を動的に生成するみたいなナンセンスは存在しないし、そもそも API の ergonomics が頻繁な View 構造の作り直しを促さない。基本的には最初に一回つくっておしまい。状態の反映は既に作られた view hierarchy の property を更新して実現する。Android で Redux をベタにやると property update が雑になるなので副作用を最小化する工夫が必要といえば必要だが、特に難しくはない。というか View の実装は大半の property が既に副作用最小化のガードを実装している。雑な propety update の副作用で性能が落ちるのは、別に Redux に限った問題ではないからね。

VD で特別難しいのはたとえばリストのスクロールなどで View の構造が dynamic に変わりうる場面。だけれど Android だとそういう動的な View 構造の変更は RecyclerView なり ViewPager(2) なりが実装している。そしてこいつらがやっていることは大局的には VD の delta application  とおなじ。RecyclerView の adapter を Redux 的に実装するのは・・・やったことないけどそんな難しくはない、気がする。結局, RecyclerView というのはそれを使うプログラマと協力して View を recycle する・・・すなわち古い View に delta を apply して使いまわす・・・というものなわけだから。

大企業による Android Redux 的なものの紹介記事などをリンクしておく:

• Introducing MvRx: Android on Autopilot - Airbnb Engineering & Data Science - Medium
• Making our Android Studio Apps Reactive with UI Components & Redux
• spotify/mobius: A functional reactive framework for managing state evolution and side-effects.

なおこいつらは誰も MVI という単語をつかわない。やはり MVI はダメだな。スルーでよし。一体誰が言い出したんだろうね・・・・。軽く調べるとこのへんらしい:

• REACTIVE APPS WITH MODEL-VIEW-INTENT - PART1 - MODEL | HANNES DORFMANN
• Cycle.js

ケチつけてばかりいるのもどうかとおもうので、いちおうあとで読んでみよう・・・。

なお Android なら VD とか要らなくね、という自分の見立てとは裏腹に Android の中の人は Jetpack Compose という Kotlin React みたいのを実装しているらしい。Apple も SwiftUI とかいってるし、時代の流れなのだろね。

冷やかしでかるくコードを眺めると・・・これとか delta application ですかね。とりあえず引き続きスルーでよさそうなのが確認できてよかった。しょうじき使う日はこなそうだが、頭の体操にひやかすのは悪くないかもしれない。そのうち。

Eric Schmidt が最初に mobile first と言ったのは 2010 年らしい。興味深いことにリンク先のインタビューには Android が一言も出てこない。Sundar Pichai が AI first と言ったのは, 探した範囲だと 2016 年が最初。これらは自分の記憶ともだいたい一致している。

Mobile first がなんなのか、最初は誰もわかっていなかった。モバイルウェブをがんばれという話にも思えたし、アプリをつくれという解釈もあった。数年のちようやく「モバイルのアプリとしてサービスインする前提で製品をデザインする」のが mobile first だと人々は理解するに至ったが、新製品とかそんなにないので、まずは既存サービスのアプリをちゃんとするのが現実的な行動となった。アプリはみな最初はなんとなく Android 版をがんばっていたものの、世界の半分は iPhone であるという現実に目覚め iOS もがんばるようになった。新機能も、だんだんと（本来の意味で）mobile first なものが増えていった気がする。

自分はモバイルと一番縁遠いウェブブラウザの世界からモバイル OS 部門の周辺アプリというモバイルの内側に異動したせいで、いちばん興味深い「ウェブ出身だけどモバイル化していったサービス」を間近でみていない。だから上のような表面的な変化の裏で実際にどんな苦労があったのかは知る由もない。でも "mobile first" だなんて、大企業の戦略にしては随分と雑な代物だったとは思う。現場は混乱したことだろう。

Mobile first の成功は製品によってまちまちというのが自分の主観的評価。Mobile に倒すのが向いているサービスは mobile first によって飛躍したし、あまり mobile に向いてないサービスは苦労の割に価値を引き上げられていない気がする。

ただ、総体として mobile first はまあまあ成功した。まったく新しい大ヒット製品を生むことはなかったにせよ、デスクトップとウェブの時代の成果はまあまあモバイルに持ち越されたし、地図のようにモバイルでこそ本領を発揮したものもある。今日ではたくさんの人々がそれらウェブ出身サービスをスマホ経由で使っている。"Mobile first" という掛け声の雑さを考えると驚くべき成功だと個人的には思う。

AI first の成否は、自分にはまだ見えない。AI first が何を意味するのかも、しょうじきはっきりとはわからない。人々は大きく分けて三つの方向性を見出しているように見える。

一つ目は "ヒューリスティクスを捨てて learn しなさいね" という ML first とでもいうべき路線。適当に計算したスコアを足し合わせてなんらかの判断を下す労働集約的なアルゴリズムは data から learn する方法にとって変わられ、もともと ML だった人々も representation を learn する deep な方向を目指す。個人的にはこれがいちばんまともな AI first の解釈だと感じる。

二つ目は有り物の NN モデルをもってきてなんかする路線。NN first とでもいおうか。わかりやすい例だと segmentation を使った写真の疑似ボケだとかマンガの吹き出しアニメーションだとか。あるいは活字おこし対応音声レコーダとか。棘のある言い方をすると PM による AI first とでも言おうか。よりがんばる例としては画像検索があり、そこまでいくと段々と ML first に近づいていく。

三つ目は AI first を Assistant first と解釈し、Alexa Skills 的な音声コマンドに対応する路線。個人的にはこれを AI と呼ぶのに抵抗があるが、pop culture 的 AI の解釈に一番近いようにも思える。

どれも一理あるといえばある。しかし互いにだいぶ違うものである。解釈のブレ幅に AI first という掛け声の雑さを見ることができる。だいじょうぶなのか不安。

Mobile first はなぜそれなりにうまくいったのだろう。たぶん mobile first にはたまたま「ユーザのいるところに行け」という圧倒的正しさの含意があり、それがコンシューマ向け製品にとして良い結果につながったのではないか。

同じ含意を持つ AI first の解釈は assistant first. 自分の直感とは裏腹だけれど、voice devices には新しいユーザがいる、あるいは従来のユーザと新しい接点を持つことができるのは確か。

煮えきらなさを説明するのは mobile と voice devices の現状のマーケット規模の違いだろうか。Alexa built-in デバイスは 100M くらい出ているという。現状のスマホの MAU すなわち約 Android 2.5B + iOS 1.5B = 4B の 2-3% くらいの数しかない(しかも MAU と sales figure を比べるのは雑すぎ)。だいぶ投機的といえる。ついでにモバイルで iOS を真面目にやる程度に Alexa も真面目に相手した方がよいのでは・・・とも思う。余計なお世話ですが。

AI first の別解釈たる ML first は堅実に成果を出している気がする一方でプログラマからすると世の中 ML と縁遠い仕事も多く（たとえばウェブやアプリなどの frontend 開発)、若干ニッチに思える。そして ML first する要素を持たない人々が苦し紛れに AI first をすると NN first になってしまい、ちぐはぐさが生まれる。

そんなわけで自分は ML first 以外の AI first には懐疑的。ただ自分の予測がはずれ AI first で勤務先が潤ってくれればその方が嬉しい。悲観が外れ, 何らかの形で "AI first まあまあ正しかったね" と思える日を待っている。

まあそれはさておき企業の標語で XX First は雑すぎだよ。次はどうすんだ。Quantum First か。

Antisocial: Online Extremists, Techno-Utopians, and the Hijacking of the American Conversation

Alt-right や white supremacy と呼ばれる人種差別的インターネットトロルがソーシャルメディアなどを駆使しいかにオンラインの言論を制圧したかを書いた本。

よく取材しており、自分のように alt-right とかそういうめんどくさいものは目にもしたくないし目にする機会もない外国人にとっては現状を追体験できる優れた読み物だった。オンラインのメディアを熟読のうえ色々引用してくれるだけでも（話題の性質上）臨場感があるが、それだけでなく Alt-right 方面のブロガーに密着取材（本人の許可を得たうえであちこちに同行する。ホワイトハウスにまでいく。）してみたり、そのカルトを抜け出してきたインサイダーにインタビューをしたり、Reddit の CEO にも取材をし、同社が利用規約変更の日の社内 war room に入り込んでレポートをしたりで、始終読ませる。

著者は The New Yorker という伝統的左メディアの人間で、ソーシャルメディアみたいなテックの連中は disrupt とかいって従来の gatekeeper を駆逐したけど、それでいいんですかね？やっぱり何らかの gatekeeper 必要だったんじゃないんですかね？とたびたび問う。自分は著者の批判する techno-utopian の末席におり、この主張にはほぼ脊髄反射のレベルで鼻白んでしまう。ただ social media は逆戻りのできない社会実験の失敗だったいう確信は深まった。社会として有害なものが歴史の成り行きで消えない傷になる例は過去にも色々あるので（タバコとか）、それ自体は仕方ない。ただ社会としては失敗に合意のうえ move on してほしい。時間はかかるだろうけれど。

著者はトーマス・クーンを引きながら paradigm shift の話をする。そして alt-right のメディア戦略の根底にあるアイデアとして paradigm shift のインクリメンタル・バージョン Overton Window が繰り返し言及される。Alt-right による window-shifting に著者はしつこく警鐘をならす。

自分はアメリカの思想的シフトよりソーシャルメディアの先行きの方に気をとられている浅はかな techno-utopian なので、同じ文脈で social media という社会実験の精算について思いを馳せてしまう。つまり social media が有害であるというアイデアは新しい paradigm として世代が進むにつれ常識となり、まともな現代人の大半がタバコを吸わないようにまともな大人の大半がソーシャルメディアをやらない時代がくる、という形で実現される・・・と予言できる確信はまったくないけれども、実現されるべきだと思う。トーマス・クーンがパラダイムシフトのドライバを世代交代で説明したように。

なお自分はブログがソーシャルメディアと比べて本質的にマシだとは思っていない。ブログはインターネットにおけるブロードキャストのシステムがソーシャルメディアに向かう未完成な通過点で、その未完成さゆえに致命傷を逃れた・・・というかダメージがちょっとマシだった。（それでも致命傷には至っているかもしれない。）

インターネットをつかい friction free で voice を broadcast するというアイデアが根本的なヤバさを孕んでいる。人々が private messaging のような non-broadcasting media に流れているのはその煙からの避難なのだろう。逃げた先がマシかは誰にもわからないが、ここが燃えているのは誰の目にも明らかだから。

Zuckerberg とかは明らかにこうした時流を理解しており、だからこそ private messaging へのシフトを急いでいる。一方で Antisocial の著者が激しく批判する free speech の擁護を改めて打ち出してくる。Zuckerberg の中指的態度は Ukraine での密談を突き上げられ開き直った大統領の態度とどこか共時性がある。

NYTimes は 大統領を reckless, Zuckerberg を defiant と評しており、ほんとにそう思う。そして reckless なほうはともかく defiance にはちょっとだけときめいてしまう自分もいる。このときめきこそが alt-right のような social media mastery の狙う精神的脆弱性であり、日本語ではそれを中二病というのだった。

自分の中の techno-utopian で libertarian でしかし communist という矛盾は失敗した社会実験の一コマとして時代をうねる paradigm shift の波の狭間に消えてゆくのだろう。いいよ、消し去ってくれよ。

今日は The @Scale Conference 2019 なのだがまったく見に行く気が起きず、ふつうに仕事をすることにした。この「見に行く気が起きない」事実が悲しいので気分を書き出して気を済ませたい。

行く気の起きなさ、一つにはこのカンファレンス固有の事情。去年なんとなくさびしい気分になった記憶が億劫さを助長している。他人事感、自分のぼんくら具合をリマインドされる憂鬱さ。

もう一つはコンテンツの浅さ。浅いというと完全にアンフェアではあるものの、この 10 月の @Scale はテーマを絞らない総花的なイベントである。夏の Performance @Scale みたいにテーマが絞られていればいいんだけれど。

今年はトラックが AI, Data Infra, Privary, Security. 盛り上がらない。AI はテーマとしては興味あるけどこの手のカンファレンスは運用とかスタックの話が中心になりがちで、しかし自分はそれより理論やハンズオンを先に理解したいと思っているため噛み合わない。NN フレームワークを hello world したくらいの身の自分が MLOps とか言われてももねえ・・・という虚しさ。

あと @Scale はどうしても宣伝っぽさが強くなりがち。企業主催のテックカンファレンスは本質的に自慢大会なので仕方ないし文句を言う筋もない。Facebook の話とかまさに sponsor session なわけだが、Recruiting 目的ならともかく最近は PyTorch を売り込みたいみたいな下心が透けすぎていて辛かった。なお一昨年は TensorFlow を売り込みたい会社のセッション、去年は GPU を売りたい会社のセッションがだいたい似た雰囲気だったので Facebook を特別責める気はない。

そういえば東京にいたこともたとえば「デブサミ」みたいな総花的なイベントはあまり興味なかったな、と思い出す。東京なら知り合いに会える期待が背中を押してくれたが、ここではそれもないし。@Scale, 最初の頃は FBHQ 開催でもうすこし小規模だったのもあるし、自分もシリコンバレーヒャッホイ、みたいなテンションが多少はあったから盛り上がれたが、今はそういうのが全然ない。自分の中で旬が過ぎたのだろう。

申し込んだのに行かないのは悪いなとは思う。せっかくがんばって準備してくれてるのに、ごめんね。

テックカンファレンス全体への参加意欲も下がっている。貴重な有給をカンファレンスセンターで人の話聞いておわりにしちゃうの？みたいな。どうせ仕事休むならコーヒー屋で考え事しながらブログ書いたり本や論文よんだりした方がよくない？ビデオみるにしても積読テックトーク消化した方が割がよくない？みたいな気持ち。

テックカンファレンスは、そういうケチくささを押しのけ時間の無駄を承知で参加し、ある種の selendipity や inspiration を期待する性質のものだとはわかっている。でも今の自分はそういう無駄を afford できないね。別の言い方をすると、テックカンファレンスは時間を持てるものがその暇資産を投機的に使うための機会だとも言える。羨ましいことですが真似する気にはなれない。

一方でビデオでしかアクセスできないコンテンツというのはある。イベントに足を運ばないにせよビデオを見る行為はもうちょっと日常に織り込んでいかないとなあ。さいきん全然見てない。

去年。

寝ている妻子を背に家を出る。東海岸の 10 時は西海岸の 7 時。まだ暗い。ライブストリーム鑑賞会の会議室にいくと PM がドーナッツの箱を持ってきた。有難くいただく。アプリのチームからは自分しか来ていない。HAL の人が一人か二人、そして今日は Marc Levoy が出てきて喋ると聞きつけたリサーチ部門の人々が数名。

歴史上最も発売前にリークした電話機の座を獲得してしまっただけあり、発表会はバーンとした雰囲気が微塵もない地味なものだった。意図せぬ形で退屈な電話機の方向に向かっている、のだろうか。地味で売れるのかは謎だが。高いし。

今年は二年目だけあって、活躍とは言えないまでもいちおう何らかの仕事はした気がする。ハードウェアのメモリも増えることだし去年ほど大変ではないかと思っていたが、よく考えるとアプリは引き続き古いハードウェアで動かす必要があるし、アルゴリズム部門のやつらをはじめ人々はガンガン機能をつっこんでくるのでそれなりに仕事はあった。

もともとクライアントサイド AI/ML の舞台という淡い期待をもって異動してきたチームだけれど、アプリというのはそういうファンシーな話以前に「いつもちゃんと動く」という暗黙の期待を満たす必要があり、カメラは用途の都合から特に期待値が高い。さっと起動してぱっと写真をとれないと、たとえば子供がファニーな踊りを披露した瞬間を逃してしまう。「ちゃんと動く」という観点から見ると巨大で複雑で計算資源を hog し UI も増える AI 機能たちは邪魔にしかならない。

自分は「ちゃんと動く」を維持するのが主要な仕事なので、それを邪魔しがちな割に特別素晴らしい何かを実現してくれるわけでもない AI  というものへの評価は自分の中で下がり続けている。フェアな評価ではないかもしれないが、目の前でおきていることは認知への影響が大きいのだよ。たとえば今年のカメラアプリで自分が一番評価している新機能は「カメラモードでシャッターボタンを長押しするとビデオを撮れる」というものだが（たまたま iPhone 11 にも同じ機能が実装され、人々は先を越されて悔しがっていた。) ここには微塵も AI の姿はない。

まあ Live HDR+ は ML based な上に実際インパクトのある機能なので ML/AI がぜんぜん意味ないとはいわないけれど。AWB もついにぜんぶ learning based になったらしいし。なお Pixel Neural Core はすげえ使ってるよ。すくなくともカメラでは。Pixel Visual Core も無理やり NN のバックエンドになってたけど、専用の回路の方がきっといいのでしょう。

電話機の発表会に話を戻すと、今年はどういうわけか以前ほど強く "AI" を全面に押し出さなくなっていた気がして、そこは自分の価値観との align という点でよかった（これについては別に書きたい。）まあアシスタントとか文字起こしつきボイスレコーダーとか、いわゆる "AI 機能" なわけだけれど、その二文字のアルファベットを連呼しないだけでも前進といえる。我ながらなんてえらそうなコメントなんだ。

発表会がおわったあとは自席に戻り, 開発に使っていた Pixel 4 XL を dogfood 用にセットアップ。出荷は来週らしいけど、もう持ち歩いてもいいでしょう。（というか本当は発売前に使ってバグ報告などをしなければいけなかったんだけどね。）以下感想:

• CPU (Snapdragon 855) はいちおう速くなっている。ベンチマークだけでなく、さわってもわかる。
• Pixel 3 と比べるとやはりでかくて重い。カメラとして使うにしても小さい方がホールドしやすくて好き。なお Max な iPhone はもっと重いらしい。ハイエンド電話機の重量化。
• 顔認証、別に遅くはないが自分はデバイス背後での指認証が好きだったので落ち着かない。慣れるだろうか。この議論は iPhone および Galaxy ユーザが繰り返したものなので、ことさら追加で書くことはない。
• カメラ。光学ズームあるのはいいもんです。他社製品は二年くらい前からふつうにみんなレンズ２つなところにようやく追いついた・・・というと語弊があり、最近のハイエンドはレンズ３つが主流。一周遅れ。
• ケースは以前より布っぽさが薄れ、硬い手触りになった気がする。そのうち熟れるかしら。
• 手をひらひらする機能は使いみちがわからない。

今日から使って参ります。

PyTorch Mobile

PyTorch 1.3 の一部。Caffe2 の名前が変わったのかと思ったら、ほんとに PyTorch の一部らしい。ということで久しぶりにサイトなどを冷やかす。以下わかったこと:

PyTorch は 1.0 あたりで TorchScript なるものが追加された。TorchScript は Python のサブセットを C++ で実装したバイトコードインタプリタみたいなもの。コード表現 (IR) は直列化もできる。Python と違って GIL もないし機能も少ないので速いしスケーラブルだと主張している。

TorchScript のコードを作る方法は２つある。一つ目は "tracing". モデルの実行をフックすることで、どんな計算を実行するのかを記録する。Autograd 用に計算を追跡する仕組みはすでにあるので、その横でついでに tracing  すればよい（割とひどいコードになっている)。ここには関数呼び出しみたいな概念がない。計算はぜんぶ「インライン化」される、つまり分岐もなにもない計算だけの IR が生成される。

IR をつくる２つ目の方法は Python AST からの変換。Python の AST を TorchScript の AST に変換し、それを IR に落とす。Python AST から変換すると関数呼び出しやループや分岐といった情報の保存された IR ができる。

Tracing と AST の住み分けはよくわからないが、Python 上のモデルがサポートされている AST のサブセットに収まらない場合は tracing を使うのだろうか？そんなんでいいのかよくあわからないけど。

Python サブセットのテキストをパースして TorchScript の AST を作る仕組みもあるという。エンドユーザには関係ないが、内部的に python の build-in を実装するのに使っているらしい。これかな？この規模ならパーサ書かなくても C++ の DSL でやればいいのでは、・・・。

PyTorch Mobile の実体はこの TorchScript である。AI 人材が Tracing なり AST 変換なりで TorchScript の IR をつくり、直列化して保存する。アプリ開発者は PyTorch Mobile の API でその IR をロードし、外からデータを渡して実行する。TorchScript (IR の実行部分) は C++ なので Python が要らない。ちなみに直列化フォーマットは Python pickle (のサブセット) で直列化した IR が zip (のサブセット) でパッケージされている。ぜんぶ C++ で書いてあるのにこれとは、さすが Python first を名乗るだけあるな・・・（なお最初は JSON をつかっていたらしく "LEGACY" とマークされた JSON ロード用のコードが残っている。

TorchScript と並行して CuPy にあたるレイヤも書き直しているっぽい。まえは ATen とかいうやつを使っていたが c10 というプロジェクトに置き換えようとしている、らしい。

あと  TorchScript はいちおう different-i-able ではある模様。ただどのくらいちゃんと動くのかは不明。inference だけなら backward path はいらないし。

以下感想とか。

TF との比較でいうと、TorchScript は PyTorch として AST/Graph を一級市民にするという意味で TF 的といえなくもない。ただ SavedModel と比べてふつうの言語っぽい IR を全面に押し出しているところが違うといえば違う。TF だと XLA とか MLIR みたいな IR のレイヤは SavedModel の下にある。

PyTorch の一族には Glow という中間表現およびコンパイラがいた。こいつがどうなったのかと覗いてみると、特殊な ML ハードウェア向けコンパイラインフラという TorchScript より一段下の位置づけになった模様。じっさい Glow のツリーには TorchScript IR をロードするフロントエンドみたいなコードがある。TorchScript 自体はネイティブコードへのコンパイルとかできないインタプリタなので、CPU でも E2E のネイティブコード生成をしたいなら Glow がやるのかもしれない。

PyTorch Mobile が TorchScript ベースだとすると少なくともモバイルの Caffe2 はさよならなのかな。モバイルにかぎらずプロダクションは Caffe2 を捨て TorchScript に移行する見通しなのだろう。そして Caffe2 がいらないならモデルの可搬性が必要なくなるから ONNX もいらないね。Glow も TorchScript IR を直接ロードしているし。

リサーチ志向の PyTorch が苦手なプロダクションの穴を埋めようと ONNX 連合に参加した他の ML フレームワークにしてみたらひどい話だけれど、これが大企業同士の戦争というものなのでしょう。

ふたたび TF との比較に戻ると、PyTorch は一つの TorchScript 実装でプロダクションをサーバからモバイルまでカバーしようとしているように見える。一方 TF はモバイル用に TF Lite を作った。TF Lite は自己完結したシンプルなインタプリタで、カーネルとかもぜんぶ TF とは独立して再実装している。TF はもともと C++ 中心で TFX Serving とかも Python なしに動かせるんだから、モバイルもそれでよかったのではという気がしないでもない。少なくともある時期までは Non-Lite な TF をモバイルで使っていたはずだから不可能ではないはずだけれど、どうして再実装したんだろうね。でかすぎたのかな？

TF Lite はモデルのフォーマットも flatbuffer で TF 本体と互換性がなく、toco というツールで SavedModel を変換しないといけない。Python 上の PyTorch から .pt ファイルを保存してそれを直接モバイルにロードできる PyTorch スタックと比べ moving parts が多く cumbersome に見える.

TF は単一開発元で E2E で全部もってるのが売りだったけれど、フルスタックな割に中身がバラバラ（特にモバイル）。PyTorch は Caffe2 だの ONNX だの Glow だのとバラバラだったのが、1.0 過ぎたあたりから統合が進み部品も揃ってきた。

そして朝に 1-2 時間くらいパラパラとコードをドキュメントを眺めただけでここに書いたような理解ができるくらいドキュメントも揃ってるしコードもコンパクト。実際どうなのかはさわってみないとわからないけど、触ってみたくなる空気はある。

突然やりたくなって時間を無駄にするもの。部屋の掃除、ノートアプリの物色、カメラのウィンドウショッピング、ブラウザの設定。今日はブックマークを整理します。なぜ。

なおここでいうブックマークは「読んだ」と記録するソーシャルブックマーク的なものではなく、普段 navitational に使うもの。

仕事では Github Pages 的なやつにリンクを集約している。同じドキュメントには頻繁に使うが覚えられない CLI のスニペットなども書いてある。素晴らしいアプローチとは言えないが、いちおう機能しているし、保守もできている。その前は仕事ログの Google Docs 冒頭に同じ情報を書いていたが、仕事ログを書くとき目障りだったので Docs からは追い出した。Docs は開くのが遅いし二回クリックしないとリンクを辿れないし、どのみちブックマークには向いてない。

個人のブックマークもどこかのページに集約しようかと思ったが、ふと思い立ってブラウザのブックマークを使ってみることにした。ブラウザのブックマーク, Omnibox (アドレスバー) で履歴を検索するのが Chrome Way だと思っていたし sync で壊れがちな印象があったので使っていなかったが、サイトにブックマークをまとめようとしている時点で履歴検索は敗北してる。再評価しようではないか。ということで整理。工夫したこと:

• ブックマークは bookmarklet 含め常に Omnibar 経由で使うよう練習する。
• Omniにbar 検索で一意に絞りこめるようタイトルを必要に応じ編集する。
• ぜんぶブックマークバーに置く。Bookmark Manager は使わない。
• フォルダ名に絵文字を入れる。認知性があがるし、見た目もファンシー（重要）。
• Omnibar から使うので理論的にはどこに置こうがどうフォルダ分けしようが関係無いわけだが、片付けの成果が目につくところにあるとメンテを続けるする気になりやすい、気がする。
• Sync 壊れは気づいたら直す。（主に重複や索条項目の復活が観測されている。）

まあ、ふつうに便利。

今までブックマークをちゃんと整理していなかったのが不思議に思えてくるが、social bookmark を使ってあげたい青春があったり、履歴検索に正義を見出していた時期があったり、ゼロ年代世代にありがちなこじらせだったね・・・と時代のせいにしておく。

via Why Is the World So Loud? - The Atlantic

Arizona に住む男が近隣を覆いはじめた謎の騒音に苛立ち、正体を追いかけたらデータセンターだった、なんとかしたかったが行政とかは全然助けてくれなかった、という話。2つの点で興味深かった。

まずアメリカってなんだか妙に色々音がデカイなとは引っ越してきてからずっと思っており、その印象を裏付けてくれた面があること (aka. the confirmation bias.)

家の外は電車、車、芝刈り機に枯葉掃除機、謎の排熱施設など。屋内も掃除機、洗濯機、食洗機、冷蔵庫、空調までなにかと音がデカイ。まあアメリカは主語でかすぎで a suburban cheap  apartment dweller perspective である点は disclaimer すべきだけれども、音でかいよね。なにかと。日本は無駄な音楽やアナウンスを流すスピーカーからの音害がしばしば非難されるが、それ以外は割と全て静かじゃん。スイスとかフランスとかそれすらなく完全に静かで素晴らしかったなそういえば・・・。

二点目として、データセンターと石油の比喩的な近接。巨大資本の富の源泉である点には以前から親しさを感じていたが、赤くて貧しい州の規制の弱さにつけこんで環境を犠牲に資源を吸い出している点にも類似性がある。データセンターは建物がでかく排熱がある点である程度は環境負荷があると誰もが感じているだろうけれど、個体差はあるとはいえまさか騒音が届くような近所に人が住んでいるとは思わなかった。

データセンターの騒音は、他の環境問題にくらべると技術的にはまだいくらでも改善の余地があるように思える。防音の施策は色々ありうるし、立地だって妥協できる。一方、問題の相対的な subtle さと巨大資本のアグレッシブさを照らし合わせると対策がなされる期待も薄い。記事も漂う悲しさ、無力感を伝えようとしている。資本と地域コミュニティの一方的な戦い。

こうしてみるとデータセンターの騒音ってすごいアメリカ的な現象だね。そしてふと思い出すに、大手町のデータセンターはすごく日本的というか東京的な存在だった。金融オフィス街のビルの一つがさりげなくデータセンターであるカオス感というか詰め込み感というか。クラウド以前の牧歌的な存在だったとも言えるが。シンガポールのデータセンター群はどういう立地なのだろう。

なおリンク先の記事は無駄に長い上にデータセンターの騒音問題自体はあまりちゃんと取材していないので、がんばって読む価値は薄め。

The State of Machine Learning Frameworks in 2019

ML 再入門するにあたって TF2 やるか・・・しかしやりたくない・・・という気持ちを察したかのような記事で、やはり PyTorch の方が良さそうと背中を押された。

TF2 の PyTorch に対する敗北には色々感じ入るものがある。基本的には Facebook の中の人ががんばった、えらかった、でおしまいなのだけれども、負け方に既視感を感じる。

最初に思ったのは、これは MapReduce (Hadoop でもいいよ) の Spark に対する敗北に似ているな、ということ。MR は Mapper と Reducer (ついでに Partitioner と Combiner だっけ?) というわりかし剥き出しのプリミティブをプログラマに強いることで堅牢な並列計算を実現したが、より親しみ深い抽象と対話的実行を備えた Spark にやられた。その後 MapReduce には Flume (Beam)なり Hive なりといったマシな抽象が与えられはしたものの、安い計算資源をバッチで使う根本のところは変えられず対話性はないままだったし、どのみち遅きに失し今日に至っている。

TF1 はデータフローのグラフというわりかし剥き出しのプリミティブをプログラマに強いることで並列実行やら最適化やらのコンパイラテクノロジを ML フレームワークに持ち込むことができた。しかし Python の親しみ深さを活かしつつ tape-based すなわち operator overloading で計算トラックすればいいでしょと対話的実行を後押しする PyTorch にやられた。TF2 は対話的実行デフォルトに方針を切り替えたけれど、相変わらず複雑なデータフローのグラフすなわち SavedModel が canonical representation である重苦しさは拭えない。

難しい問題を解くため最低限の抽象を頼りに剥き出しの複雑さと向き合う Jeff Dean 的アプローチにはハイテク企業らしさがあって、自分はけっこう好きだ。けれどコミュニティとかエコシステムみたいなものを相手にする必要があると、そういう荒削りさが足を引っ張る。プログラマへの優しさが計算資源への優しさを打ち負かす。そして競争に勝ってマインドシェアを獲得すると、計算機への優しさは事後的に解決されたりする。

もうすこし自分に身近な例で考えると、これは Mozilla (Gecko) の WebKit に対する敗北とも似たところがある。Gecko は XPCOM や XUL などクロス環境かつクロス言語でアプリケーションを作れる仕組みを目指したが、MacOS べったりで C++/Objective-C から HTML をかけるだけの WebKit に敗北した。

これらを「古くて巨大で複雑なテクノロジが新しくて小さく気の利いたテクノロジに負けた」ストーリーとして解釈するのは近似としてはあっている。でもそういう雑でメタな話は Malcolm Gladwell と Clayton Christensen にまかせ、ソフトウェア開発の文脈で考えてみたい。

自分は MapReduce や TF の複雑さが不必要なものだったとは思わない。最終的にはいらないものになったかもしれないけれど、登場した時点で目の前の難しい問題と戦うためには必要だったと思うし、そこにある種のかっこよさがある。Gecko の複雑さが必要なものだった、という主張は生理的に受け入れがたいし実際ゴミも混じっていると思うが、とはいえ 「Windows をやっつけたい」という当時の時代背景を考えると同情はできる。実際、なんらかの価値があったからこそ一度は勝利を収めたわけじゃん。

自分は複雑なテクノロジでフロンティアを切り開く Jeff Dean 的世界観が好きだしすべてのソフトウェアはリファクタリング可能と信じたい宗派なのでどうすればこれらのレガシー巨人が小粋な後発と戦えただろうと考えがち。でもそれよりは、後発はどうすればレガシー巨人の弱みに付け込めるかを考える方が健全に思える。それは結局 Christensen なのではと言われるとそうなのだけれど。

・・・などと与太話を続けようかと思ったが、せめてもうちょっと TF2 なり PyTorch なりに詳しくなってから書くべき話に思えてきた。終了。

OCP のサイトをみていたらこんなアナウンスがあった:

• New Open Domain-Specific Architecture sub-project to launch within the OCP Server Project. » Open Compute Project

関連 PDF:

• Open Domain-Specific Accelerators: What They Are & Why They Should Matter to Cloud & Network Providers
• The Open Domain-Specific Architecture: A Chiplet-Based Open Architecture

OCP は言ってみればデータセンターで使うハードウェア CPU とかの「入れ物」を標準化、公開するプロジェクトだった。たとえばラックであったりシャーシであったり、あるいはもうちょっと踏み込んでネットワークスイッチであったり。加えて NIC のようなわりかしコモディティ化しがちなハードウェアの設計も提供している。こいつらは組み合わせて使えることが期待されている。(OCP ベースの製品一覧。)

ODSA はその SoC 版といえる。従来の OCP は、たとえば CPU や GPU のような知財は普通に Intel なり NVIDIA から買ってきていた。OSDA も SoC の個々のコンポーネントは世間で売られているものなり自社開発したものを使う。ただしそれをパッケージングするための標準を決めたい。

キーとなる意思決定が Chiplet の利用. Snapdragon のような SoC は複数のコンポーネントを一つの ASIC にギュっと詰め込んで、一つのプロセスで彫り出す。一方、OSDA では個々の機能単位を "Chiplet" として独立に製造し、それを multi-chip module としてインテグレートする。Monolithic Service に対する Microservices みたいなもん。なので先に SoC と書いたけど違う気がする。System-on-Chip じゃない。

Chiplet はコンポーネント毎に異なる製造プロセスを使えるしそもそも違うベンダーから買えるし、ダイを切り出す単位が小さくなるので歩留まりもよくなる。一方で Chiplet 間をつなぐのは大変だし電力も多くなりがち。なのでその欠点を小さくするようなデザインを標準化して、標準にのっかった Chiplet ならぱぱっと組み合わせられるようにしましょうね、そうすれば Domain Specific Architecture のチップを作って売り買いしやすくなるでしょと主張する。

言われてみると DSA のチップを作っても単品では使い物にならないので SoC を作ってる人々に売り込むなり自分でフル機能の SoC を作る必要があるわけで、なかなか大変。コアのビジネスに集中するために周辺は標準化のうえコモディティ化したい。

じっさい OSDA を提案しているのは Netronome という NIC を売っている会社のひと。eBPF を実行できる DSA をつくったりしているらしい。こういうのを NIC なりサーバの中なりに配備する際、OSDA のような標準があると嬉しいのだろう。そこに NN accelerator を OCP でつくりたい Facebook などが乗っかってきたという構図。

いまは掛け声ドキュメントしかないので、2-3 年たったころにまた冷やかしてみたい所存。

掛け声ドキュメント自体は DSA に限らず従来の accelerator の現状をざっくり説明していて面白かった。たとえば cyrptcurrency とか冗談ではなくほんとに ASIC でやってるのだなとか、アカデミアでは Near Memory Computing というのがはやってるらしいとか (1, 2). たまに普段と毛色の違うものを読むと発見が多くて良い。

2019/11 追記

Chiplet は 2018 年に AMD が採用したことで話題になっていた

• To Keep Pace With Moore's Law, Chipmakers Turn to 'Chiplets' | WIRED

クラウドに抱いていた素朴な疑問を素人的に読み解いていくシリーズ。

ぎもん: クラウドの GPU って自由に数を選べるけど、どうやってハードウェアをラックにぶらさげてるの？ロボットアームみたいのがガチャンと GPU を抜き差しするの？それはなさそうだが、実はロボットがやってますと言われても驚かない程度には無知。

秘密主義のクラウド業者に対する嫌がらせ勢である OCP が何かやってないかと探してみると、まず Facebook が Big Basin (および v2) という GPU ノードみたいのを発表していた。

• Introducing Big Basin: Our next-generation AI hardware - Facebook Engineering
• The next step in Facebook's AI hardware infrastructure - Facebook Engineering

同時期に Microsoft と NVIDIA が HGX-1 および HGX-2 という似たようなラック刺し GPU クラスタを発表している。

• Ecosystem momentum positions Microsoft’s Project Olympus as de facto open compute standard | Blog | Microsoft Azure
  • Project Olympus Hyperscale GPU Accelerator
  • Microsoft Project Olympus Hyperscale GPU Accelerator (HGX-1) | Microsoft Azure
• HGX-2 Fuses HPC and AI Computing Architectures | NVIDIA Developer Blog

どちらも GPU 同士は "NVLink" というオンボードのバスで繋がっている。CPU はない。CPU を持つ "head node" すなわちふつうのサーバーノードに PCIe のケーブルでつなぐらしい。PCIe, ケーブルとかあるのか。

つまり、少なくともラックの中で GPU はサーバと別のシャーシには入っている。ではこいつを複数の "head node" から共有できるのか？ HGX-1 はできると書いてある。PCIe のポートが外側に 4 つあって、それぞれ別の箱をつなぐことができる。CPU のある head node と繋いでもいいし、もう一つ HGX-1 とつないで倍の GPU を一つの head node に見せてもいい。柔軟。(文中にはでてこないけれど、世間では Multi-Root IO Virtualization というらしい。)

なお HGX-2 は Open Compute ではないらしく NVIDIA のハッタリドキュメントしか見当たらない。こいつらは一個の head node にどれだけ大量の GPU をぶら下げるかにしか興味がなさそうで自分の疑問には答えてくれない。

当初の疑問にもどり、GPU はどうやってラックや他のサーバにぶらさがっているのか:

• GPU だけを 8 個なり 16 個なり詰めこんだシャーシを作り、ラックに刺す。
• そのシャーシからは 1-4 個の PCIe ポート(!)が出ている。このポートを介して CPU のはいったふつうのサーバ "head node" にぶら下げる。
• 複数のサーバにぶらさげるケースは強調されていないので、現実には需要ないのかもしれない。それよりはいかに大量の GPU を詰め込めるかを各社とも強調している。

彼らは CPU と GPU を disaggregate できたぞというけれど、仮想化して切り売りする段階ではすくなくとも head node の CPU とは抱き合わせて売る必要があるため bin-packing の制限はあるはず。そこは allocation algorithm のがんばりで足りるのだろうか。

Resource allocation どうすんのかなと K8N を覗いてみると... limits というセクションに GPU の数を指定するらしい。Limits というセクションはたとえば CPU の速度やネットワークカードの帯域などを細かく指定するのに使う。それとおなじように GPU の種別などを指定し、クラスタマネージャはそれに従ってハードウェアを切り売れば良い。

なんとなく CPU を売り切ってしまい GPU が余って困ったりしないのか疑問だったけれど、それは GPU に限らずリソース全般に入れることなので GPU 固有の難しさというのは (自分が理解できるような範囲では) ないのかもしれない。

といったところでだいたい謎はとけたので満足した。ウンチクとして以外に一ミリも価値のない知識だけれど、雑学というのはそういうもんです。

業界どうなんのかな、という雑な印象論。

モバイルだと、垂直統合の Apple はいい位置にいるなと思う。チップセットから OS, アプリまで全部持っているので、dark silicon の使い方を自社内に閉じたまま探求できる。自分の勤務先を含む水平統合の競合陣営は会社を跨いて協業するオーバーヘッドが大きい気がする。たとえば Snapdragon 855 の DSP セクションを見ると 845 とくらべ色々記述が増えているけれど、どれがリアルで、世間のデバイスはそのうちどれだけを使っているのだろうか。

クラウドはよくわからない。GPU はすっかり普及したけれど、FPGA クラドみたいのは一般的になるのだろうか。クラウド業者の中は色々なものが commoditized され software defined になるというのが 10 年前くらいの見立てだったけれど、また段々と専用のチップに戻っていくのだろうとは思う。まあクラウド業者の中身は自分にはあまり関係ないなので、がんばってくださいというかんじ。なお詳しい人に AWS はじっさいアクセラレータを頑張っていると教わった。

FPGA はともかく GPU はどのくらい存在感が増すのだろね。NN/ML で必須になったのはさておき、その必須化に伴いクラウドで GPU が使いやすくなった結果他の用途でも利用が広まることはあるのだろうか。Facebook とか近傍検索に GPU を使ってるらしいけれどこの手の話題は増えるのかな。自分で CUDA を書くことはないにせよ、デプロイの制約とかは変わってくるよね。

モバイルに話を戻して、アプリ。アプリは現状 CPU 以外だと GPU くらいしか使えない。NNAPI などを介すると TPU 的なものは使えるようになるんだろうけれど、GPGPU の自由度に比べだいぶ制限されている気がする。まあ GP-GPU ももともとは general purpose じゃないものを無理やりハックするところからはじまったので GP-TPU みたいのも出てくるのかもしれない。サーバサイドだと MLIR がそれなのかもしれない。こういうのがモバイルに降りてくる日は来るのかねえ・・・。

あるいは、モバイルは CPU の停滞とともに沈み、Alexa つきデバイス みたいにチップと一緒にソフトウェアを開発するビジネスが流行るのかもしれない。あまり信じられないけれど、モバイルに強くバイアスされている自分の判断はあてにならない。

そういえば Nest Mini は Edge TPU 的な何かが載っていると宣伝していた。こういうデバイスでプログラミングしたいならモバイル以外の仕事した方がよいのかもしんない。しかし結局 TF Lite つかっておしまいとかいうオチか・・・。

モバイルもクラウドもボイスデバイスも、今はでかい会社が覇権と領土を巡って小競り合いをしている時代という印象。でも Innovation Happens Elesewhere を信じて育った世代としては垂直統合のフェーズはさっさとおわらせてまたモジュラーな世界に帰ってきてほしいもんです。シリコンの上の計算資源、大企業だけで囲い込まず市井の開発者にも還元してくれ。

10 年くらい待ったらそうなってるのかね。その頃には引退したい気もする・・・。

といったところでこのシリーズはおしまい。

身近な性能問題もだんだんと CPU と OS だけ詳しくてもダメな場面が増えており、不安。

たとえば GPU. かつては GPU を同時に使うタスクは一つか二つ（すなわちアプリ画面の描画と、場合によってはスクリーンの合成）くらいだったのでその描画のコードを書いている人ががんばって速くすればよかった。しかし NN なり画像処理なりで GPU を使う人が増えてくると、複数の GPU タスクを同時実行したくなる。結果として GPU の overload がおこる。

複数タスクによる overload を解決するには個々のタスクを実装した人ではなく複数タスクのタイミングとかを仲裁するひと、たとえば自分とか OS の人、とかが問題を分析してタイミングを小細工したり (自分) スケジューラをいじったり (OS の人) する。

しかし Systrace にしろ vmstat にしろ top にしろ GPU のロードはまったく見えない。GPU のタスクを post したり同期を待ったりする CPU 側のカーネルスレッドのアノテーションは見えるから、それで間接的に GPU がなにかしていると理解するしかない。しかしこうした GPU 情報の粒度や正確さはカーネルの提供する CPU の observability とくらべカスみたいなものであまり役に立たない。

世の中には Snapdragon Profiler というのがあり、これが最後の希望。しかしめちゃめちゃ使いにくい。昔使おうとして挫折した。しかもオープンソース側のツールにまったくインテグレートされていない。不便すぎる。その使いにくい GUI に割く開発資源があったら performance counter なりカーネルドライバの API なりを文書化して upstream のツールから見えるようにしてくれ！カーネルはオープンソースにしなくていいから！ARM はしてるけど！(野良だった。) なお ARM は ARM で Mobile Studio という似たような GUI ツールを作っているらしい。はー・・・。

GPU はまだツールがあるだけマシで、これが ISP とかになると完全にお手上げ。ましてヘンな DSP たちときたら。

あるとき仕事のアプリで誰かが何らかの新機能を flag flip したところ、どうも ISP を酷使しすぎで熱の問題があるらしいとバグの報告がありフラグは再びオフに、という出来事があった。しかし Systrace をみても全然違いがわからない。

熱の問題は電力消費が原因なので Monsoon で電力をモニタリングすればデバッグできることはできる。そうした電力 sensitive な機能を開発する人や一部の CI インフラはこれをつかってるのだけれど・・・リアルな電力を測るしか性能問題のデバッグをする方法がないとか荒々しすぎませんかね・・・電力読める sysfs の endpoint なんでないの・・・。(2017 年の LWN の記事から同じ不満を訴えるスライドがリンクされいた。)

一方で OS の中の人からやってくる advisory は相変わらず Systrace と、あとはせいぜい I/O を睨んだ理解にもとづくコメントばかり。アプリの起動みたいに CPU と I/O だけで説明できる問題を追いかけているうちはそれでいいけど、起動したあとはもうだいぶブラックボックスだよ？アプリの中の人がヘマして電話熱くなってもお手上げじゃない？だいじょうぶなの？

自分は Linux カーネルに詳しくないので、OS の中の人とまともに話ができるくらいは詳しくなりたいという希望がある。一方で、カーネルや CPU の外に熱や性能のボトルネックが生まれつつある。一方で GPU にしても ISP にしても結局アプリとの間にはカーネルが挟まっているので、その理解をさぼると E2E で問題を理解できない。きびしい。

といった動向から身の振り方を考えるに・・・

短期的には、Snapdragon Profiler はどれだけ出来が悪くてウンザリでも触れたほうが良さそう。こういう残念なツールへの習熟は仕事のための税金として受け入れよう。

長期的には、それでもいちおう Linux にはもうちょっと詳しくならないとダメだなと思う。古典として。サーバ側でも意味のある知識だし、潰しは効くでしょう。

長期的な課題そのにとして、Out-of-CPU への理解を深める上で今更ながら CUDA を実際に触って見る必要もあるかもしれない。これももはや古典。ほんとはモバイルの GPGPU をさわるほうが身近なんだけど Android の GPGPU は mess すぎ。OpenCL を SDK に入れなかった罪を反省してほしい。TF Lite も Caffe も OpenGL ES とかマジかいなと思う。Vulkan Compute とか冷やかしてみたほうがいいのかなあ・・・。

より投機的には Cloud の FPGA みたいな方向性もあるけど、自分はそんな最先端じゃなくていいです。

こどもちゃれんじに対する自分の抵抗をもうすこし長々と言語化してみる。気を済ますためであって、世間の親たちにケチをつけたいわけではない。

じぶんのこどもちゃれんじへの懸念は、Attention Resistance 勢すなわち Digital Minimalism, The Attention Merchants, Irresistible などを真に受けている人々の延長にある: この手のエンゲージメント強化型幼児教材は当初の目的(学力などの獲得)のためにユーザ(子供)の attention/engagement を exploit しすぎている。

一部の attention resistance はここに企業の悪意を見出しているが、個人的にはインセンティブのフレームワークみたいなものすなわち The System の帰結だと考えている。

ユーザーの Engagement すなわち DAU や MAU や似たような指標というのは、長いこと純粋な善だと考えられてきた。結果としてこれを the north star とする製品開発チームは多かった。たとえば例の OKR の本では YouTube がユーザの総視聴時間を the north star とした事例を OKR のケーススタディーとして紹介している。エンゲージメント駆動のわかりやすさはスケーラブルな問題として多くのインターネット企業の推進力となった。

が、今は Tristan Harris あたりからはじまった批判が高まって Screen Time(iOS) や Digital Wellbeing (Android) といったスマホ機能ができたり、ソーシャルメディアについてもしばらっくれきることはできず、最近は Like を隠すかもとまで言い出した。

そういうインターネットの動向を踏まえ子供向け教材コンテンツを見直すと、こいつらも似たようなものなのではないかという疑問が頭をよぎるのは自然でしょ。

類似性について考えるため、インセンティブの構造に目を向ける。

教材コンテンツを評価するのは子供（ユーザ）である。一方、金を払うクライアントは親である。親は基本的に子供の学力（思考力でもいいよ）を高めたいとコンテンツに金を払っている。しかしそれだけではない。まず、子供がコンテンツを好きになったなら、よほどのことがない限り取り上げたくはない。子の喜ぶことをしてあげたい親心がある。そして、子供が「一人で遊ぶ」コンテンツを重宝する親もいる。なぜなら子が一人でコンテンツを消化している時間は親が自由に使えるから。子供の相手で疲弊している専業主婦にとって、これが特に重視されがちであることはオンラインのレビューなどからもうかがえる。（こどもちゃんれじのサイトでもその効能を示唆している。）

このユーザ-クライアントの不一致にはインターネット企業との相似を見ることができなくもない。親と子の関係は、広告主とユーザの関係とはだいぶ違うけれど。

教材であるという建前を無視すると、教材コンテンツは「アンパンマン」のビデオを見せるのと大差ない。タッチペンは対話性があるぶんより没入度が高い可能性すらある。アンパンマンは没入度、中毒性の高さが広く知られており、子供を一時的にほっておきたい親たちに広く支持されている。同時にアンチスクリーン派には警戒されている（とおもう。）別の言い方をすれば、アンパンマンは「厳しい親」が伝統的に警戒しているアニメというメディアの枠にいることで、よくも悪くもゾーニングされている。

エンゲージ系教材は「学力」を隠れ蓑にしてエンゲージメント、没入を売っている面がある。この二重性に自分は強い反感を感じる。「健康」のラベルで砂糖の塊を売るシリアルとも通じているし、「メリット」を盾にその「コスト」を押し付けているという digital minimalism のソーシャルメディア批判と同じ構造でもある。

というわけでやめとくかという判断に至った。

この議論が孕むいくつかの居心地悪さについても記録しておく。

まず、そうはいっても世の中のメディアは教材に限らずエンゲージメントとアテンションで回っているんだからいつまでも逃げられはしないんじゃないの？解禁したときの反動とか心配ないの？という懸念。これはもっともではあるが、基本的に年齢が低いほど心身が無防備で没入系コンテンツの副作用が大きいというのが（副作用を信じる人たちの間での）共通見解なので、先送りは総合的にはマシな判断だと思うことにしている。待ってる間に時代の風向きが変わるかもしれないし。

つぎ、個人的といっても他の親のやってることの批判になってますよね、でもほんとに時間がない親だっているんですよ仕方ないでしょ！みたいな意見。親の時間のために子供をほっとく場面が必要なのはよくわかる。世の中にはベストではないが妥協として受け入れていることは色々ある。自分だって特別 pround でない選択は人に言わないだけで色々している。人によって priority は色々なので、他人の意見にいちいち腹をたてずお互い自分の価値観を信じてやってまいりましょう。

そのさん、おまえは attention にやられてるんじゃないの？それで子供に教育とかできんの？みたいな心の声。自分たちの親の世代が子供にピアノをやらせたかったように、自分たちの親の親の世代が子供を大学にやりたかったように、自分は子供に集中力をあげたいのだよ。なぜなら、それが今の時代には大切だと思うし、自分にはそれがなくて苦労しているから。こうした親の「希望を背負わせる」滑稽さは自覚しているけれど、笑ってもらっていいです。そういうもんです。

さいご、そんな神経質になんなくても大丈夫じゃないの？という話。まあそうかもしんない。ただ attention との付き合い方は自分の人生にとって重要な課題となっているので、無視はできない。他の人にとってどうでもいい話題なのはわかってるのでそっとしといてください。

世の中には「終わってしまった技術」というのがあって、そういう技術相手にはなるべく時間を使いたくない。ただ「終わってしまった」にもバリエーションがあり、完全には無視できないこともあるなと思う。

無視してよいものについて先に考えると「死んでしまった技術」はもう放っておいて良い。わかりやすいところだと WebOS とか、要素技術でいうと prototype.js とか。厳密には死んでしまったわけではないが行き止まりになった技術もある。仕事はどこかにはあるだろうし何かしら変化はしているだろうが、いま縁がないならこの先も無視してよいようなもの。たとえば COBOL のようなメインフレーム技術や、多くの人にとっては Windows アプリ開発も「行き止まり技術」だろう。

一方で、終わってしまったが死んでもいなければ行き止まりになってもいない技術もある。

筆頭は UNIX.  終わったとか言うと怒られそうだけど、ユーザとして最新動向を気にする必要性は感じない。一方でコマンドラインでなんかするとかファイルシステムの構造とかルート権限がどうとかの典型的な使い方と基本的な概念は知っていないと不自由する。

Web も似たところがある。アプリケーションプラットフォームの Web というアイデアの落とし所はだいたい見えて、今や Web 標準の動向を真面目に追いかける必要は感じない。フレームワークの流行り廃りも、Web 開発者でない限りは無視して良い気がする。一方で、たとえばデータサイエンティストが Web を scrape するにしろ無名の若者が売名ブログを書くにしろ HTTP(S) と HTML と CSS くらいは軽く理解していた方がよいし、簡単なウェブアプリも作れる方がプログラマとして小回りがきく。

UNIX や Web は古典、あるいは教養になったと言ってもいい。

従来、情報産業の古典や教養はいわゆる CS の教科書みたいなもので賄われていた。UNIX や Web はあまり computer "science" というかんじじゃない。でも実務者にとっては同じくらい重要だし、割と長い歴史を持ってもいる。自分が学生だった 20 年前は Windows が花盛りだったせいもあって UNIX はそれほど foundamental という印象はなかったし、Web は目新しいものだった。

Unix や Web が真の古典としての普遍性を持っている気は(まだ)しないけれども、他の技術にくらべ長生きだし安定しているし他のものの基盤になっている点は評価されてよい。特に新しい技術がその上に積み重ねられている点は、他の「終わってしまった技術」にはない強さに思える。いまこれらを「教養」と感じるのは産業の成熟なのか、自分の老化なのか、どっちだろうね。

自分が学ぶべき「終わってしまった技術」あるいは「古典」はなんだろうと考える。

ぱっと頭にうかぶのは信号処理と確率。これは従来の意味での「古典」だけれども、たとえば Matlab ... はともかく NumPy や SciPy でさっと画像処理とかできたら守備範囲も広がるのにと思うことはある。同じく確率を真面目にやれば NN も Bayasien も今より恐怖を感じずにすむかもしれないという淡い期待がある。

あとは RDB と SQL ... を終わってしまった技術よわばりするのは若干抵抗があるけど、クールファクターがないという意味で終わってはいる。しかしもうちょっと触れたらいい気はしている。

自分がこうした古典を勉強して穴埋めする日は永遠に来ないかもしれない。残念なことだが、致命傷とも思わない。これは「古典」についてあまり語られない事実を物語ってもいる。つまり、古典は知っているに越したことはないが、すごく重要とは限らない。古典を学ぶ豊かさは尊いけれど、知らないなら知らないなりの人生がある。

音の鳴るおもちゃが苦手で、子にはあまり買い与えていない。

楽器ではなく、 ボタンなどのスイッチを押すと録音されて効果音が再生されるようなやつ。同時にランプが点滅したりもする。楽器ではないと書いたけれど、楽器やオーディオ装置を模した形をしていることも多い。

ランダムに音が鳴るのも苦手だし、プラスチッキーな外観も好きに慣れない。例外としてボタンを押すと短い歌が流れる "sound book" を 2-3 冊持っている。別に何らかの criteria を満たしからではなく、これらをいくつか買ったあとでもうたくさんという気持ちになった。強いていえば sound book は嵩張らないところがマシ。

自分たちはよくあるテックな親としてスクリーンも控えめにしか見せていないので、子は音に耐性がない。音の鳴るおもちゃ、にかぎらず音というものにはだいぶ sensitiveで、mall とかにいくと全方向から鳴る音にキョロキョロしている。過敏すぎが少し心配ではある。

そんなかんじで音の鳴るおもちゃのない家に「こどもちゃれんじ」の教材デバイス「はてなくん」がやってきた。別名タッチペン。ステルスインクを読み取るスキャナで、教材の冊子のページ内に埋め込まれたマーカー ID を読み取ってなんらかの録音を再生する。たとえば動物の絵をスキャンするとその動物の鳴き声が再生される。

さらにデバイス内に簡単な state を持てるらしく、クイズの設問マーカーをスキャンしクイズを再生したあとそのクイズの正解をスキャンし設問に答えることができる。たとえばページ左上のしまじろうアイコンをスキャンしたあとページ全体に描かれたモブから彼をさがしてスキャンすると該当キャラのよろこびの声が再生される、といったことできる。

タッチペンの「はてなくん」は音の鳴るおもちゃである。しかもかなり出来が良い、つまり子供を引きつける力の強いやつ。まず再生される声のデータが多い。見開き 5 ページくらいの冊子の各ページに 10 パターン以上の音声が再生される。先に書いた state を駆使してかなりインタラクティブだし 、たまにランダムで自分のテーマ曲を歌う easter egg まである。

コンテンツにはもちろんベネッセの稼ぎ頭「しまじろう」が登場する。しかもそのコンテンツが毎月更新される、というか毎月新しい冊子が届く。サイトによると 10 ヶ月分で合計 4700 音声らしい。そこらへんで売ってる嵩張るばかりの音の鳴るオモチャとは格が違う「面白さ」、刺激の強さがある。

開封した翌日、普段は寝起きの悪いその子は朝起きると「はてなくんで遊びたい」といった。昼寝から置きた時も、ふだんなら「ぶどうたべる？」とかいっておやつの力で意識を呼び戻すところ「起きてなにしたい？」ときいたら「はてなくん」と答えた。じゃあ遊ぶかと一緒にあそんでいたら・・・

おしっこをもらした。ここのところトイレトレーニングは順調で半月以上もらすことがなかったのに、タッチペンに夢中すぎて尿意を無視してしまったらしい。だいぶショック。文章にするとファニーだけど当事者にはおおごとなのだよ。

タッチペンの楽しさ、刺激の強さ、あるいは「エンゲージメントの高さ」は親である自分を不安にさせる。同類の刺激の強いおもちゃはずっと避けてきたのに、教材の顔をしたこの刺激テクノロジが突然乱入してきて焦る。

自分の中にある「音の鳴るおもちゃ」への抵抗は主に aesthetic なものだとなんとなく思っていたが、それだけでないことに気づいた。この抵抗は「スクリーン」への忌避に通じている: 当事者(子)の effort に対する reward としての刺激が強すぎる。簡単にヒマが潰せすぎる。

「音の鳴るおもちゃ」を選ぶ世の中の親を非難したいと自分は思っていない。スクリーンをはじめとする刺激物の影響に確固たる結論は出ていないはずだし、どのみち子育ては各人の判断でやるものだから。ただ、自分たちの中の standards や boundaries はなるべく一貫させたい。タッチペンはその壁を激しくぶちぬいてきたので動揺している。タッチペンにはスクリーンと同じような扱いが必要なんじゃないか。

というか、そもそも与える必要はあるのか?

教材である以上なんらかの学習効果を期待しているわけだが、その効果はこの刺激のコストに見合っているのか。今回のコンテンツを見る限りその見返りは感じない。他の本やトイで足りてんじゃね?

ウェブで世の親の声を眺めてみると、言語の獲得を助けるのが主要な効能として評価されているようす。つまりタッチペンで遊んでいたらしゃべるようになった、字が読めるようになった、というようなもの。幸い子はすでにだいぶしゃべるしひらがなも読めるようになってきたので、その点でタッチペンの助けは要らない気がする。

公式サイトはそのほかの効能ジャンルとして「数」「図形」「論理」「好奇心」を挙げている。そんなに高い効果あんの？コンテンツからそういう作為・・・・という書き方は悪意がありすぎるけれども、意図は感じる。しかしそんな思い通りにいくの？

他の教材なのかおまけなのかよくわからないコンテンツたちも、やはりテイストが親たる我々の趣味とあまりにも違い、その割に子供は夢中で、しかし教材としてのユニークな価値というものは感じられない。（世の中ユニークな教材なんてものはほとんどないだろうから、この批判がフェアでないのはわかっている。気分を書き下してるだけです。)

この受け入れられなさが刺激が強すぎるという「子のため」の判断から来ているのか、テイストの不一致という「自分のせい」なのか、冷静には見極められない。ただ親としての居心地の悪さがどうにも辛いので、夫婦協議の末に解約した。

ウェブを眺めてもタッチペンに対して自分と同じような不満は見つからない。しかし音の鳴るおもちゃへの批判はあるはずなので、やや不思議。きっと自分と同じような指向性の人はそもそもこの教材を購読しないのだろうね。不用意だった。ただ「こどもチャレンジ」がどういうものかわかったのはよかった。高い勉強代、あるいはうかつ税となった。

ソーシャルな場面、特に家庭で、ラップトップなりスマホなりの画面を眺めているのは感じが悪い。自分も食事中にスマホをされるのは不愉快なので家では夫婦とも食卓でのスマホはナシとしている。

一方、たとえば食後にソファなりベッドなりで画面を眺めているのはどうだろう。人にもよるだろうけれど、自分の感覚だとこれは食事中ほど感じはわるくない。一方で、子供がいるとやりにくいし、実際自分たちはあまりやっていない。しかし、結果として子供の目を盗んで画面を見るという本末転倒なことがしばしば起こる。なんか不毛。

いま子に画面を見せたくないのは、それが過剰に引力を持っているから。一旦画面に気を取られると、たとえば何らかの動画を見せろと tantrum が起こる。一旦見せても次々に見たがりきびしい。この問題は、ある程度は時間が解決すると思っている。

もう一つの問題は子に限ったことではなく、画面というものが持つ awkwardness に由来している。つまり、画面の向こうで何が起きているのかが外からわからない。

食卓の例にもどると、たとえば食事中でもちょっと調べものをしたいことはある。一方で、調べもののついでにソーシャルメディアなどをひやかすことも可能だし、実際に寄り道はおこる。画面が見えない事実も寄り道を招きがち。その寄り道はしないでほしいし、自分でもしたくない。画面が外から見えないとその不信感は払拭できない。

食卓に限ると、調べものとかはテーブルに電話を置いて作業しようと決めている。画面を隠さない。こうすると、少なくとも夫婦間での問題は解決する。地図を見るとか買い物アイテムを足すとか、別に他人に見られてもいいし。

ソファやベッドは同じ方法が使えない。こうした時間にソーシャルメディアなり何なりを眺めるのは何も悪いことではない。ただ問題が無いわけでもない。相手に話しかけたい時、あるいは話しかけられても構わないときに、良いシグナルがない。つまり画面を見ている誰かはいま「忙しい」のだろうか。それともどちらかというと「ヒマをつぶしている」のだろうか？ラップトップや電話の背中はこうした問いに答えてくれない。

ラップトップや電話のない世界では同じ場面で何が起こるか？テレビやテレビゲームは、そこで何が起きているのか筒抜け。ポータブルゲーム機は、すくなくともゲームをしていることはわかる。紙の本や雑誌を読んでいるなら、本や雑誌のタイトルはわかる。雑誌は、どの記事をよんでいるかまではわからない。ノートに日記を書く。日記を書いていることはわかる。何を書いているかは見えない。ノートと教科書をだして勉強をしている。科目くらいはわかる。電話で誰かと話す。筒抜け。

ここには何らかのシグナルがある。ゲームをしているなら、その場で話しかけてもムダだろうが（ゲームに集中しているから）、一方でそのラウンドがおわったら用事があると伝えることはできる。電話もおなじ。本や雑誌を読んでいるならたぶん話しかけて問題ない。日記も、たぶんだいじょうぶ。勉強は、そっとしておいてあげたい気もする。

プライバシーも、一定程度はある。つまり（少なくとも家族なら）日記を覗き込むんだりはしない。読んでいる雑誌を覗き込むのは、たぶん構わない。他人に知られてくない読みものは、そういう場面に持ち込まない。仕事の電話も席をはずす。

スクリーンにはこうした nuanced  なプライバシーやシグナルがない。それが awkwardness につながっている。

不透明でない画面の可能性

少し意外な発見として、デスクトップの画面は場合によってはシグナルがある。具体的には living rooms にデスクトップを設置すると画面はまわりに筒抜け。職場での画面も同じ性質を持っている。デスクトップを使っていたり、ラップトップを大きなモニタにつないでいると、作業はまわりに筒抜け。これはある種の制約としてもよく機能する: 仕事中あんましソーシャルメディアとかみてんなよ。まったく気にしない強い人もいるが、すくなくとも Facebook やってる同僚に仕事の話で割り込むのに気後れはない。

Kindle のデバイスも少し似たようなところがある、つまりすくなくとも本を読んでいるであろうことはわかる。カバーつきの本くらいの可視性。

スクリーンを使いつつ、適切な可視性で家族にシグナルを伝えることはできないものか。つまり、つかっているアプリなりみているウェブサイトくらいは外から見えてほしいんだけど、見せられないんですかね？

富豪的な解決は用途別にデバイスをわけること。これはインターネットにつながるデバイスとそうでないデバイスをわける、みたいな断線の仲間だけど目的は違う。機能するかもしれないが、そのためにはメインのデバイスでソーシャルをしない決断が必要で、それは自分はともかく他人（奥様）に強いるのは難しそう。

Surveillance dashboard をつくる。ブラウザ拡張や強い権限のあるアプリで、いまつかっているアプリやみているサイトを検出のうえなんらかの見える場所に表示する。おおがかり。あと iPhone 相手だと使えない。 ついでに寝室には surveillance dashboard 置きたくない。十分に非侵入的かつコンパクトで持ち歩けるデザインなら話は別だが・・・。

理想的には PC なり電話なりの背面に小さい画面があって、そこにアプリのアイコンなりサイトの favicon を出せるといいんだけど。そういう時代は来ないだろうなあ。

紙を選ぶ

より現実的に、画面でなくていいものを画面から追い出し、シグナルのあるメディアを受け入れることもできる。要するに紙の雑誌を買う。紙の本を買う。紙のノートで日記をつけるなど。

紙のメディアは「かさばる」という大きな欠点があるわけだが、その「かさ」がまさにシグナルとして機能する事実は無視できない。いわゆる affordance というやつ。本の affordance がどれだけ重要かは場合によるが、それが本当に priority なら紙の本を買うのはアリだと思う。ただ失うものも多いので悩ましい。

そんな理由で最近はためしに紙の本を買ってみている。でも技術書は厳しいね。でかすぎ。一方、たとえば Modern Operating Systems は表紙が賑やかで楽しいらしく子が興味を示す（まさかこのダサい表紙にそんな魅力があるとは）し、ヘネパタを読んでいる時に子が寄ってきたら裏表紙をみせて「これがヘネさん、これがパタさんだよー」とかいう話ができる。などなど affordance の力は感じている。

ただ長期的には family-aware で less awkward な media consumption device に出てきてほしいなあ。Apple と Amazon に期待。ていうか Kindle DX 帰ってきて！愛してた！

追記

その後も実現方法をぼんやり考えていたが、子供を画面に近づけたくないうちは無意味なアイデアに思えてきた。そのフェーズが終わり子供に画面、というか画面つきデバイスを渡すようになったら surveillance dashboard を作っていいかもしれない。

ハードウェアがあまり速くならない世界で、ソフトウェア開発はどうあるべきか。

マルチコア化や GPU 対応みたいのは、ある程度は進んでいるが「Many core が来るぞー」といっていた時に想像していた、全てのループとデータ構造が並列化される、みたいな勢いには至っていない。(知り合いもそんなことを言っていた。)

これは、端的にいうとクライアントサイドだとコア数がそんなに増えなかったからで、サーバサイドだと serving の inherent な concurrent nature を exploit すれば足りたから。Big data 方面の data parallelism は進展があったけれど, functional にしましょうね (Spark),  Stream も相性いいよ (Kafka), でもできれば declarative にしましょうね (SQL) というあたりでアプリケーションプログラマの用は足りた。こうした data processing や cloud のインフラを開発している人は色々難しい問題と戦っているだろうけれど、そういう人たちは別に many core とかいう前から大変だったはずなので、がんばってくださいね。

GPGPU についてはほんとに "general purpose" なコードを書く必要に迫られる人は少なく、何らかの(グラフィクスでない) specific purpose ごとに定型的なやりかたが生まれ、人々は分野ごとにそのパターンを使いまわしている印象。具体的には何らかのデータフローのフレームワークがあり、プログラマはそのノードを埋める CUDA のコードを書く。ML はそうだし、画像処理も似た感じ。他の分野はどうなのだろう。ゲームとかは general purpose してる人がけっこういるのかもしれない。物理エンジンとか、どうなのかな？

ある分野の専門家として上を目指すならそのドメインの定形フレームワークを自分で実装できた方がよいだろうけれど、それはなんでもかんでも GPU に追い出すぞ！みたいな勢いとは違う感じがする。一方でそんなフレームワークををかけるくらい CUDA に精通すればなんでも GPU に追い出せる能力を持っている気もする。

要素技術の話はさておき、プログラミングやソフトウェア開発の慣習は Moore's Law 時代の暗黙の前提がまあまあ残っていると思う。

たとえば「まずは正しく動くものを綺麗に書いて遅かったら高速化する」("premature optimization is the root of all evil.") というアイデア。Knuth のもともとの premise は正しいといえば正しいが、その「正しさ」はどんどん速くなるハードウェアによって割増されていたと思う。つまり書いたものがちょっと遅いことはよくあったが、ほっておくとハードウェアの高速化によって解決してしまった。

「綺麗に書いたらあとはハードウェアの進歩がなんとかしてくれる」というこの期待は、昨今はよく裏切られる。けれど、どうしたら code hygine と性能のバランスをとれるのかの答えは出ていない。Go, Rust, Swift のようなモダンで速い言語は答えの一部なのだろうけれど。特に Rust は zero overhead abstraction とかいってるし。

こうしたプログラミングの所作だけではなく、ソフトウェアの製品デザインにも暗にハードウェアの進歩を期待している。具体的には、人々は既存のソフトウェアにどんどん新しい機能を詰め込んでいく。ソフトウェアはじりじり遅くなる。

モニタリングやベンチマークといった fitness function enforcement によって性能低下を防ごうとするのがモダンソフトウェア開発ではあるけれど、新機能の追加によるちょっとした遅さを deliberate choice として受け入れる場面はしばしば目にする。つまり「この機能は重要だから」とトップダウンな判断でちょっと遅くなる。また完全な fitness function は存在しないので、気づかないところで色々おそくなったりしがち。たとえばウェブブラウザでいうとページの中で使うプリミティブはよくベンチマークされているがページの外側の UI は相対的にザル。

ハードウェアは今でもいちおう速くなり続けているので、こうした小さい性能低下は今のところあからさまでない。ただし「速くなった」と主張する新しいハードウェアの性能をエンドユーザが体感できる機会は減った。伸びしろをソフトウェアが食いつぶしてしまうから。

クライアントサイドはモバイル、サーバサイドはクラウド。ここ 5-10 年でユーザの性能に対する期待値は一旦リセットされた。だから「コンピュータは速くならない、遅い」という時代の空気はまだそれほど高まっていない。でも PC をとりまく倦怠感に似た空気は、そろそろ現世代のコンピューティングにもやってくるんじゃないの？

というかモバイルには「退屈なハイエンド新製品」という形で倦怠期が来ている。毎年 CPU が（ベンダー公称でなく実際に) 1.5 倍はやくなってたら別にカメラとか AI とかがんばらなくてもみんなスマホ買い替えてくれるよたぶん。クラウドも「自分でサーバを持たなければ自動的にハードウェアの進歩がやってくる」みたいな初期の約束はうやむやにされてるじゃん。それは別に AWS 鞘抜きでぼったくってるからではなく、ハードウェアが言うほど速くなってないからだよね。

話が逸れた。

プログラミングにしろソフトウェア製品のデザインにしろ、CPU 性能バブル期になんとなく染み込んだハードウェアの進歩に対する暗黙の期待が今でもあちこちに残っていると思う。Many core parallelism や GPGPU みたいなわかりやすくてかっこいい取り組みは気にされているけれど、日々の細々とした営みの中にも unlearn した方がよいものが色々あるんじゃないかな。

意図せず環境の sustainability を巡る議論とよく似た論調になった。子どもたちの未来のために限りある資源としての性能を大切にしていきましょう・・・というのは半ば冗談として、限られた機能の速いソフトウェアは、今も色々あるけど今後いっそう存在感がましてくる、かもね。Environmentally responsible products ならぬ responsibly performant software.

via What is Developmentally Appropriate Practice (DAP)? | NAEYC

NAEYC というのは幼稚園の業界団体みたいなもので、自分の子がいく preshchool も入っている。幼児教育本を探すにあたりこの団体の出している Developmentally Appropriate Practice in Early Childhood Programs という本の評判がよかったので、Developmentally Appropriate Practice というのが何なのか下調べしていたらこの資料をみつけた。（リンクされているドラフトの PDF.)

名前からして年齢相応のアクティビティのリストみたいなものかと思っていたら全然違った。幼稚園教育のスタンダードを定義するメタフレームワークみたいな話。しかもリンクされている PDF はその実現方法については議論しておらず「我々のスタンダードはこうです」という話だけをする。position paper を名乗っているのはそういうわけだったか。

書籍も中を覗いてみたいけれど、目次すらオンラインには見当たらない。ただ先の文書を読んで家での教育と preschool 運営はやはりだいぶ違うという認識に至ったので、あんまし参考にはならないかもな。自分は幼稚園の先生になりたいわけではないからね。

読書記録:

• How to Raise an Adult: Break Free of the Overparenting Trap and Prepare Your Kid for Success

おまえらは学歴にこだわりすぎだし過保護すぎる、厳しく、しかし愛のある親になろうな・・・という話。こう書くと退屈な本みたいだが、なかなか面白かった。

まず書いているのが Stanford の元 freshman dean (新入生担当課長みたいなかんじかな) である。そして著者自身 Palo Alto に住む二児の母でもある。超高級住宅街で子育てする学歴社会頂点勤務のひとが「学歴にこだわりすぎる」というこの圧倒的居心地の悪さが面白い。

本書の前半 1/3 は過保護な親の現状に関するレポート。なのだが、書かれている過保護っぷりがやばい。アメリカ社会共通のダメさ (helicopter parenting - 子がどこにいくにも車で連れてく)はそれなりに共感があるし、公園のような公共空間の過剰な安全指向についても身に覚えがある。しかしそこから先はアホかと呆れる話が続く: 子供の宿題をやる親、大学にだす出願エッセイを書く親（および代行業者）、修学旅行についてくる親、一日連絡がとれないと大学に連絡をよこす親、子の職探しをする親、職場の上司に人事考課の苦情を言ってくる親など、エクストリームな逸話が多すぎて他人事ながら面白い。アメリカの金持ちはアホだな・・・という気持ちになる。結果、そうした過保護が生み出す問題（子のうつ病、親の育児鬱、study drug 中毒など）について議論する中盤 1/3 も半分以上他人事に感じられ、がんばってくれやと冷やかしながら読んだ。ただ anecdotes としては面白かった。

後半 1/3 は、そうした現状を脱するための指針を議論する。ここは狂っていない upper middle 家庭向け parenting book guide といった体裁で参考になった。書き手はさすがによく取材というか調査しており、参考文献がとても充実していて良い。紹介されている本を何冊かは読むことになろう。議論されている指針自体も前半を踏まえると割とまとも（平凡ともいう）で、我々夫婦の感覚とまあまあ近い気がする。プロキシ言語化として役に立ちそう。

ただ最後が「Stanford と Harvard と Yale 以外にもいい大学は色々あるからこのへんのウェブサイトを参考にして探してくれよな」みたいな話でおわっており、アメリカの大学進学率何パーセントだよ主語でかいな、という白けはあった。高学歴の呪いの根深さを感じてしまう。いや Stanford も Harvard もすごいと思いますけどね・・・・。Amazon のコメント欄も絶賛と白けに分断されている。こんなところにも class divide.

しかし我が子の避けがたい helicopter parenting という現実をみると、アメリカの学校教育システムや社会そのものの変化もまた異常な過保護を生み出す何らかの避けがたい構造的な圧力を持っているのではないかと不安になる。10年後アメリカにいたとして、自分も気がついたら子の所在を GPS でトラックしつつ宿題をやっちゃったりするのではないか、巻き込まれるのではという恐怖。

自分にはアメリカ学校生活への無知から来る不安があるので、それを払拭するためにもそのうち何らかの調査をしなければと思った。

夕方、晩飯を食べて風呂に入れると子はもう寝る時間。まったく戯れる時間がない。週末ためしに晩飯前に風呂に入ってもらうと食後に余裕が生まれた。

夕食前に子を風呂に入れたい。しかし奥様は炊事をしている。自分が帰ってきて風呂を担当する必要がある。17:45 くらいに帰ってくれば 30 分で風呂に入れて出して 18:30 前に夕食できる。しかしそのためには 17:00 ぴったりに退社しないといけない。

一方、朝は子の歯磨き補助やプレスクールの送り出し補助などで出社が遅れがち。9:00 仕事開始を miss することが増えており、8 時間労働のコミットメントが危ぶまれている。この slippery scope を下りたくない。遅れた日は帰りを少し遅らせて補っているが、子の風呂を担当するなら帰宅時間もハードデッドラインになる。それは無理なのでは・・・。

色々と愚痴の萌芽が脳内を渦巻くがそれはスルーし、できることを考える。そろそろ手を付けたくなかったものに踏み込んでいく必要がある。

候補 1: 通勤時間の短縮。自転車を買い直して自転車通勤する。三年前に盗まれて以来徒歩だった。これで 30-40 分増える。しかし自転車を使うと通勤を兼ねたジョギングが自分の生活から失われ、運動不足および脳内麻薬切れの恐れがある。また帰路のオーディオメディア消化もだいぶ減る。

候補 2: Mail WFH. 家でメールを読んでおく。朝か夜か。まあ朝だろう。いま課外活動に使っている朝の時間の一部を仕事メールの消化にあてる。家で仕事をやるのも課外活動を削るのもイヤだが、可能ではある。朝はどのみちインターネットでダラダラしがちなので、かわりにだらだらメールを読んでも大差ないかもしれない。あと会社で朝からメールを読んで勢いを損ねる残念さを克服できるかもしれない。

候補 3: 候補 1 のバリエーションとして、徒歩通勤で歩くのをやめ帰りも走って帰ってくる。そして自分の風呂ついでに子も風呂に入れる。一瞬名案かと思ったけど、現実的には自分は風呂に入れない可能性が高い。そして風邪をひく。危険。

候補 4: 候補 1 に加え、夜中にジムなり公園なりで走り脳内麻薬を補う。就寝が遅れるので朝の課外活動が削られるが、メールに削られるよりはマシかもしれない。朝走るよりは夜走るほうが、シャワーを夜の一回で済ませられて良い。あとジムで走れば本が読める・・・かもしれない。しかし夜はもうだいぶ疲れててきびしい気もする。本をよむ気力はなさそう。

候補 5: 仕事中いまよりカリカリ働く。できりゃ苦労しねえっつうの。言ってみただけ。

候補 6: 候補 2 (Mail from Home) と 候補 4 (自転車 + 夜のジム) を同時にやるとどうなるか？朝の課外活動の時間が睡眠とメールで完全になくなる。しかし会社でメールを読む時間を減らせ、かつフル 8 時間いられるので・・・仕事がはかどる。いや仕事はそこまで捗らなくていいな。アメリカのワーカホリックというかんじの時間割。

候補 7: 夜の睡眠を削り、昼休みに昼寝する。ハードワーク父母のあいだでは割とポピュラーなオプションである現実を目撃しているが、精神衛生および健康を損ねがちなのでパス。

自転車、あったらあったで通勤以外も便利だとは思うけれど、家の中には置く場所がなく外におくとまた盗まれそうにも思え、うーむ・・・。

課外活動か精神衛生と家族の時間のトレードオフ。むー・・・。まずはためしに朝メールを読んでみるかなあ。いちばん開始の敷居が低いので。

とかおもっていたら今日は奥様が夕食前に風呂をやっていてくれた。ありがたし。

なお以前書いた寝る前の家事は、できたりできなかったり。気力がない時もあるし、dish washer が done でない日もあるし、こうしてなにか書くのを優先する日もある。さぼった翌日はだいたい朝が遅れ、出社が遅れ、イライラしがち。自業自得だけど、そんないろいろちゃんとやるには意志力が足りてない。

最近たまたまハードウェアに詳しい人と話す機会があったので「なんかムーアの法則ってけっこう前におわっちゃってたんですね？」と水を向けたところ、「いやムーアの法則は今でもまあまあがんばっていて、おわってしまったのは Dennard scaling だと思うんだよね」と言う。

Moore's Law は半導体の集積度がどんどんあがっていくという話だった。プレイヤの数はどんどん減って TSMC とか数社になっちゃったしペースも少し落ちたけれども、プロセスはひきつづき細かくなっている。ただし集積度が上がることで消費電力がさがる、という現象はなくなった、

この「集積度があがると消費電力がさがる（そのぶんクロックを上げたりコアを増やしたりできる）」という現象が Dennand Scaling であり、それが 2006 くらいでおわったらしい。2006 年からしばらくはまだ電力バジェットに余裕があったからコアを増やせたし Big.Little みたいな発明も助けになったけど、以前のような勢いはもうない。

最近のスマホの SoC で CPU の占める面積がどんどん小さくなっているのもこの帰結らしい。Moore's Law によってチップの集積度は上がっている。しかしチップ上の回路をぜんぶ同時に使うと消費電力が多すぎる。しかし CPU はその汎用性から基本的にぜんコア同時に使いたいハードウェアである。だからダイの予算を活かそうとコア数を増やすと電力消費も増やさざるを得ない。つまり SoC 内の CPU の大きさはダイの面積ではなく電力によって制限されている。

なので CPU の性能向上でみると Denning だろうが Moore だろうが結論は変わらない。つまり、もう大して速くならない。

一方で CPU 以外は事情が違う。同時には使わない用途限定のハードウェア同士なら同じ SoC に詰め込んでいくことができる。そこで将来 CPU のかわりに色々な特殊用途の DSP なり DSA なりが色々 SoC につっこまれるようになった。たとえばカメラの ISP (image signal processor) とかすごいでかい。A13 では CPU よりでかい。これはカメラを使ってるときしか使わないハードウェアだからなのだね。

別の見方をすれば、CPU は SoC 上の面積では存在感が下がっているが、消費電力では引き続き目立っているのだろう。CPU にしても、たまにしかつかわない命令のための回路 (Dark Silicon) は増やせる。AVX とかはそういう枠、という認識。どのくらいの空間的・時間的粒度で回路をオンオフできるのかは自分にはよくわからない。CPU 業者の腕の見せ所でもある。

たまにしかつかわない DSP/DSA が増えているのはムダだとおもっていたけれど、電力や熱がボトルネックで SoC の面積は相対的に余裕があるのなら、ピンポイントで CPU をオフロードできるハードウェアでその余剰面積を埋めていくのは理にかなっている。Domain Specific Architecture, おもったより時代の要請だった。

そう考えると TLS ... はもうハードウェア支援ありそうだけど、あとは JSON のパースとかも ハードウェアにされちゃいそうだな。あとは GC とか色々研究あるけどそろそろ実践投入してもよくね? 個人的には View のレイアウトとかもなんとかしてほしいなー。などなど、あまった回路で DSA する将来には色々夢があってよい。

ふと手元にあったヘネパタをぱらぱら眺めたら 5 章にだいたいこのようなことが買いてあった。左様でありましたか・・・。

アカデミア的には 2011-2013 あたりに盛り上がっていた話らしい。

• Esmaeilzadeh: Dark silicon and the end of multicore scaling - Google Scholar 1700 citations
• Taylor: A landscape of the new dark silicon design regime - Google Scholar 160 citations

前に書いたことの続き。

以下では「人に教える」という行為のネガティブな話を色々書くわけだけれど、だから教えるのが良くない、という話ではない点に留意されたし。物事には多かれ少なかれ対価があり、この文章はその対価に話題を絞っているだけ。総体として教えるのがよくないとは特に思わない。自分は機会がないからやってないけれどね。

前の文章では教えないことの対価が言語化の不足だと書いたが、教えることの対価があるとすればそれはまず言語化の過剰、あるいは望ましくない言語化である。

人に何かをおしえるとき、特に企業のトレーニングのような実務的な文脈ではおおきく二種類のバイアスが入り込みがちだと思う。

ひとつめは単純化。人に何かを教える時は、わかりやすさのために物事のニュアンスを落として説明することが多い。アイデアの限界や例外は、しばしば省かれる。教わる側はなにもしらない状態から単純化して理解した状態になるからプラスだけれど、教える側はどうだろう。本来もっていたニュアンスを落とした言語化をすることで、当人のメンタルモデルからもそうしたニュアンスが失われることはないだろうか。ニュアンスは言語化されず単純な部分だけが言語化されたら、その単純さは reinforce されないか。

ふたつめのバイアスは overrating. 説明されるアイデアが過剰な「正しさ」を与えられてしまいがち。これはひとつ目の単純化の特殊ケースとも言える。どんなアイデアやプラクティスも、多かれ少なかれ「仮止め」としての性質を持つ moving target である。別の言い方をすると「いちおう動いてるっぽい、たぶんこういう理由でうまくいってる」くらいのアイデアは多い。しかし単純化によって「こういう理由でこのやりかたは<正しい>」という単純化がおこりがちである。ここでも教わる側はゼロよりはマシになるのでいいとして、教える当人は本来あるべき以上にアイデアを信じてしまうのではないか。棘のある言い方をすれば教えているアイデアを信仰化してしまう恐れはないか。

この overrating の延長として、教える側にいると自分の能力を過信しがちではないか。何かを教えると「生徒」からは「尊敬」されがちである。企業などだと公教育の現場みたいなピュア教育環境ほど極端な非対称性は生まれないけれど、それでも教えることで権威は生まれる。教える側が報酬としてこのブースト現象を「利用」するのは構わないと自分は思っている。ただその立場がエゴにつながる心配はしたほうが良い。教える立場からうまれた権威の影響半径は、体感よりも小さいから。

思い入れや権威があると、アイデアを捨てるのが難しくなる。Unlearning というのはただでさえ難しいのに、それに輪をかけると色々こじらせがち。自分が大切、重要、本質的などと公に訴えてきたものを、時代がかわったからといって「ごめんもうそれどうでもいいわ」とはなかなか言えない。一言多いのを承知でいうと Uncle Bob を見よ。

最後の対価は、これは対価なのか報酬なのかはっきりしないけれど、人に教えていると教えることの専門家になってしまうことがある。人に教えること、教えることについて考える時間が増え、結果として他のことに使う時間が減る。そういうキャリアは別に悪いものではないと思うけれど、本人の望みなのかは・・・どうなの？教えるキャリアに入りつつある同世代に聞いてみたいね。

上に書いた話の半分くらいは人になにかを教えていた時期の自分の経験に基づいている。また教える立場にいる人を横から眺めておもったことも混じっている。

世の中のキャリアに関するアドバイスでは、しばしば人に教えることの価値を強調する。それを否定する気はない。けれど対価が議論されない片手落ち感は長いこと気になっていた。どんな行為にも対価はあるでしょう。

そうやって対価を議論すれば、対価を割り引いて落とし穴を避けるための議論を積み上げることができる。実際、教えるキャリアの長いひとは何らかの手を打っているにちがいない。そうした議論は、教える行為の価値とセットで語られていいのではないか。ただ価値だけを語るのは、先に書いた overrating そのものだ。

A caveat: 自分は教育リテラシーに特別詳しいわけではない。教える身分の人の間ではこうした議論は既に行われていて、自分が知らないだけかもしれない。そういう文献などをご存知の方は興味あるのでお知らせください。

読書記録バックログ

• How Children Succeed: Grit, Curiosity, and the Hidden Power of Character

聞き始めた途中で、むかし日本語版を読んでいたことに気づいた。

• 成功する子 失敗する子――何が「その後の人生」を決めるのか

Amazon の履歴によると 2016 年に買っている。子供が生まれる心の準備としてよんだっぽい。このときには気づいていなかったが、実はモダン根性論の本だった。モダン根性論の集大成たる Grit の出版が同年なので、まあ気づいてなくても仕方ない。ちなみに本書には Grit の作者が根性理論(?)の研究者として登場する。2012 年出版の本に登場するくらいには昔から活躍していたんだなあ。

この本は育児のガイドブックというよりは育児や教育をとりまく状況のジャーナリズムなので、いまいち actionable な要素は少ない。ただ読み物としてはまあまあ面白い。なお本書のいう character というのは要するに根性 (self control や self-awareness などの meta cognitive skill) を指している、性格というとなんとなく先天的なものに思えるが、ここでは non-academic な skill を意味するのに使っているのだね。

話は貧困が子供の教育というか発達に与える影響の話から始まる。貧困家庭、治安の悪い家庭にいると、そのストレスだけで知性が阻害される。だから貧困家庭に必要なのはいわゆるアカデミックな教育ではなく、それ以前に（今でいうところの）physiological safety なのだ、それを行政はわかってない、というような話。幸い我々はいまのところ貧困家庭ではないので、金銭以外のリスクファクターである夫婦仲はがんばって良い状態にしておかねばな・・・と身を引き締めた（いつも気にしてますが）。

そこから話は段々とモダン根性論的になっていく。早期教育の段階から meta-cognitive skill を扱うプリスクールがあるという話や、アカデミックにフォーカスした charter school KIPP の失敗と立て直し、などに触れる。また貧困地域の学校のチェスクラブを全国大会に導いた教師の話などにも多くページを割いている。また根性/characterを定量的に評価、フィードバックする学校なども紹介されている。

本書の本題とは少し外れたところで考える事の多い本だった。

むかし自分は、才能という先天的なものはアンフェアな存在で、根性（モダンでも伝統的でも）によるスキルアップは後天的に努力でなんとかなるフェアなものだとぼんやり考えていた。だから talent を強調するアメリカの（日本もかもしれないが）育児や教育には違和感があった。

しかし根性あるいは character, meta-cognitive-skill の重要性が裕福で教育熱心な人々のあいだで認識され、根性をつけるモダンな教育というものが（本書で説明されているように）研究開発されると、金を払ってそういう先進的な根性教育 (!) を受けられる学校に進学させたり、親としての資源を子の根性教育に傾けるといったことが起こる気がする、というかたぶん一部では既にやられている。

これはつまり、「本人の」意思でなんとかなると信じていた努力というフェアネスの象徴が、親の金で買える資本主義的アイテムになるということである。自分は勤務先の関係で根性あるエリートを観測する機会にまあまあ恵まれているが、当人らの生い立ちおよびそうしたエリートの子息がうけている扱いは、資本としての根性というアイデアとまあまあ合致している。

逆にアンフェアだと思っていた「先天的な才能」のようなものには、ランダムな要素があるぶん少しはフェアネスが残っているように感じる。以前は 「poverty が prevailed な学校にいる brilliant で talented な child に機会を」というようなアメリカ教育論におけるフェアネスの主張を「才能だって不公平なパラメタじゃん」と斜めから見ていたが、すくなくとも class や capitalism の限界を乱数の力で超えていける可能性のぶん、何らかのフェアさはある気がしてきた。いわゆる gift という呼称が腑に落ちたとも言える。

自分の子には金の力でもなんでもいいから根性や生命力を身に着けてほしい。がそれはそれとして、子のなかにある才能というのを見出してやるのも大切だと思うようになった。何の才能があるかはよくわからないが・・・。

ところで本書ではぱっとしない学区から躍進するチェスのチーム I.S. 318 のストーリをつかい、アカデミックなスキル（ここでは暗に暗記みたいのを想定している）ではなくメタ認知的スキル（自己認識みたいなもの）こそが重要だという話をする。チェスチームのコーチが何を子供に教えるか、訓練するかの記述がストーリーのキーとなっている。のだが・・・

これ根本的にそのコーチがガチで強いチェスプレイヤーである事実が一番重要なんじゃないのかなあ。ガチチェスプレイヤーが様々な成り行きからその（本来ならぱっとしない）学校のチェスクラブのコーチになったある種の偶然こそが快進撃の理由であって、非認知スキルとかどうでもよくね？というといいすぎだけれども、他のぱっとしない学校やぱっとしない親からするとまったく再現性のない他人事ストーリーだよね。この事例をもとに教師が非認知的スキルを教えるようになればぱっとしない学校もかわる、という暗黙の主張を支えるのは無理がある気がする。そんなことしたってチェスつよくなんないでしょ、どう考えても。

一方でこれは根性について一抹の真実を伝えてもいる: メタな根性というものは存在しない。というか根性だけをピュアに身につけることはできない。何らかの具体的な mastery を通じて根性は獲得される。この本だとそれは Chess だったし、Grit では Ballet (Violin だっけ? わすれた)だった。

自分の子にただ「根性をつけてほしい」と願うのは不毛で、本人が好きになれるもの、才能のあるものを探すのを手伝ってあげたり、それを身につける過程で根性がつくよう後押ししてあげるというのが、望まれていることなのだろうね。こうかくと大変あたりまえの話に思えますね。そうですね。

根性と才能と訓練というのはかように噛み合っている。モダン根性論の理解が深まる一冊ではありました。

読書記録。

• The Writer's Process: Getting Your Brain in Gear: Anne Janzer

大きめの変更を始めるにあたり design doc 的なものを書きたいが時間がとれず、考えがまとまらず、もしかして design doc を書くのって文章を書く人々から学ぶことがあるのでは・・・みたいな謎の気の迷いから聴いた。それなりに興味深い本ではあった。プロセスの話で、どうやって時間をとるか、どういうフェーズがあるか、というようなトピックを議論していく。

時間がないのは、ソーシャルメディアとかしてるんじゃないよ、自分にあった時間帯を見つけて書くんだよ、みたいなことをいうんだけどいやそうじゃなくて他の仕事があるせいで時間がないのだよ・・・。しかし根本的に時間は必要なので確保するしかないという現実に目を向けることができたのはよかった。

その後仕事（バグ取りなど）の忙しさは一段落したので、時間をとって書くことができた。もともとそんなに長い文章ではなく、3-5 ページくらいの短いもの。こんなものすら書けないとは・・・。

フェーズは、Research, Incubate, Structure the idea, Writing the first draft, Let the draft reset, Revise... とつづく。

自分のように大きめのリファクタリングをするだけ、みたいなケースは「調査」が必要という事実を忘れがちだが、人を説得するのに design doc を書くんだからちゃんと調べて（この場合、既存のコードを丁寧に読んで）やることを正当化したり事前に整理した方がいいね、という当たり前のことを remind できた。

アイデアを整理するにあたり、freewriting すなわちなんでも頭にあることを書き出してみるアプローチを推していて、自分はこれを以前から braindump と読んでいるけれど、そういうのも自覚的にやってみたら割とよかった。 3 ページの mini doc なんてズバっとかけそうなものだけれど、それでも一段階 freewriting / brandump を挟むとだいぶ認知の負荷が下がって良い。それにしても blog 書くのにやってんだから design doc でもやれっつう話ではある。

The Writer's Process が想定しているのはたとえば「本を書く」ように文章そのものが最終成果物なプロジェクトである。一方で自分はソフトウェア開発すなわちコードを書くという具体的かつ専門的なゴールがあり design doc はその一部に過ぎない。なので良いドキュメントを書くことに重点を置きすぎるのは的外れだし、場合によっては BDUF につながる恐れもある。特に自分はコード中心探索的アプローチ原理主義者なので事前にドキュメントを書くことに強い reservation がある。

一方で design doc を書くと決めたならそれを機能させる必要があるが、内容に何を含めるかはともかく「作文のプロセス」にはあまり共通見解みたいのはない気がする。ちょっと探した感じではこれというのが見当たらなかった。まあソフトウェア開発にとって作文は本題でないから仕方ない気もするけれど、それにしても人々はどうやって書いてるんだろうね、ドキュメント。

自分は design doc をガっと書くような気合が失われているので、コードを読んで調査をまとめたり疑問やその答えを記録して、やりたいことを箇条書きして眺め、というのを二周くらいして、それからドラフトを書く、という簡易版 writer's process がよく機能した。

それにしても立ち入った考え事をする能力が弱っているなあ。こうやって crutch を探しながら進まざるをえない人生のきびしさ。

読書記録バックログ消化。

• Oh Crap! Potty Training: Everything Modern Parents Need to Know to Do It Once and Do It Right

トイレトレーニングのやりかたに関する本。知り合いの家で見かけたのを忘れないよう Amazon の wishlist にいれておいたらいつの間にかゆこっぷ（奥様）が買って聴き、自分も聴くよう促されたので聴いた。

この話題で 300 pages / 8 hours 書けるってすごいな・・・という感慨があるが、さすがに専門家として obsess してるだけあって網羅的だった。網羅的ってなんだよと思うかもしれないけれども、そういうことってあるのだよ。

内容をかいつまんで書いても仕方ないので書かないが、トイレトレーニングには親のコミットメントが必要だぞ、という前提からはじまる本だった。重要なコンセプト（というのがあるのだよ）を何度も繰り返すので、叩き込まれる感じがある。おかげで役にはたった。若干スパルタ過ぎるのため全てをフォローできているわけではない。まあ自分よりもゆこっぷのほうが頑張ってくれた。

この本を読むと、その前に買った何らかの日本語のランダムなトイレトレーニング本はまったく情報量のないゴミだったなあと思う。インターネットの anecdotes を集めたようなやつ。育児関係で素人のコメントをランダムに載せてどうするんだ・・・。

トイレトレーニング、他の育児マイルストーンと同じくどれくらい苦労するかは子次第、および保育園/託児所次第という面もあるらしい。まったく何の苦労もせずパンツに移行したという人も、何ヶ月もてこずっているという人もいた。

ここまで書き忘れてたけど気になっていたことを思い出した。

ハードウェア集積度アップの歴史はダウンサイジングの歴史でもある。ハードウェアは小さく安くなり、イノベーションのジレンマがおこる。2008 に iPhone が登場し、コンシューマ向け計算機のダウンサイジングがおきた。Moore's Law がおわるとこのサイクルもおわるのか？

PC はある時期まではガンガン値段が下がっていったが、下げ止まった。むしろハイエンドはちょっと値上がりしてる。モバイルもハイエンドは値上がりしている一方で、PC と比べると値段の下落は最近まで続いていた。OLPC が 2005 年に夢見た $100 laptop は $50 smartphone という形で商業的に実現している。 ただ、さすがにもう値下がりしなそう。

Moore’s Law による集積度向上が続いたのなら、このあと更に小さいコンピュータが登場するはずだった。しかし CPU はもう(指数的には)速くならない。既存のフォームファクターは色々な改善を寄せ集めてがんばればいいとして、桁違いの計算性能がもたらすはずだった新しいフォームファクターはどうなってしまうのか。

Apple Watch みたいな画面つき時計や各社の喋るスピーカーは新しいフォームファクターの例である。（IoT みたいなエンタープライズ方面はもっと色々あるのかもしれないけれど詳しくないので触れないでおく。）あいつらは半導体業界の進歩が生み出した時代の子なのか？それとも半導体業界の停滞を押し切って出てきた、ちょっと無理のある存在なのか？

時計とスピーカーは同列に議論できない気がするので別々に考えてみる。

Smartwatches

コンシューマ向け計算機のダウンサイジングという点で post mobile の筆頭にいたのが時計だった。スマート時計は Apple Watch が一強で、そのほか Fitbit などの雑魚っぽいのがいるという理解。自分は Fitbit を使っている。こいつに可能性を感じるのはわかるが、どうにも遅い。ゆこっぷ（奥様）がつかっている Apple Watch をみるとだいぶマシだが、やはり遅い。

iOS 開発者の話とかを読んでいても、時計アプリは速度とかメモリが可能性の上限を決めているように伺える。今後時計の CPU は速くなるのか。ある程度はなるだろうが、指数的には進歩しないだろう。バッテリーが大きくなる様子もないからモバイル初期のような勢いも期待できない

... といっても Apple Watch はすでに 64 bit dual core だし Snapdragon も 4 core らしいけど。Galaxy Nexus (2011) くらいのイメージ。思ったより速い・・・。ただバッテリーの小ささを踏まえるとスペック上の性能を発揮できる時間はスマホ以上に限られていて、プラットホームもなるべくアプリを寝かそう殺そうとしてくるであろう。

時計のバージョンアップにも省電力志向は反映されている: 汎用アプリプラットフォームとしてより Fitness への特化を進めている。用途限定の省電力チップを足しセンサ情報を処理したりする。こうした用途限定ハードウェアではサードパーティのアプリのかわりにプラットホームの中の人が書いたコードが重要な役割を果たす。アプリはなんらかの集約済みデータにアクセスできるだけ、みたいな世界。

Smart Speakers

スマートスピーカーは時計よりでかいし給電もされるから、理論上はスマホと同じかそれ以上にパワフルになりえる。しかし収益モデルの違いなどから価格が安く、結果として CPU もケチられている。この Wiki によれば Echo Dot とかは MediaTek の ARM 1.3GHz 4 core. 上の Snapdragon Wear と同じクラスっぽい。

そしてどのみちアプリ開発者にはアクセスできない... が Alexa Built-in のデバイスをつくるために Amazon と提携するという路線があり、そういう意味で open platform ではある。ただ Echo 以外で Alexa 入りのキラーデバイスみたいのは聞いたことが無いな。

時計と違ってセンサーもあまりないし、Alexa デバイスをつくりたいならプラットホームは least common denominator になりがちで、時計のように小さいなりにがんばった SoC がやってくる期待は今のところなさそう。

Observation

コンシューマ向け Post-Mobile のフォームファクターである時計とスピーカを眺めた。これらはまあまあ売れているが、次なるプラットホームの決定版という勢いはない。今のところニッチに留まっている。

では iPhone のようなまだ見ぬブレイクスルーによってこれらがニッチを抜け出す日は来るのか。わからないけれど、半導体の進歩はあまり助けてくれなそうではある。Edge TPU や NPU のような省電力 DSA が降りてくる展開を当事者は期待しているかもしれない。しかし時計やスピーカに乗った DSA が中の人以外からアクセスできるようにはならなそうなので、自分のような外野は遠くから健闘をお祈りしていればいいかな。

そういうハイテクとは関係なく、1.3GHz x4 core の CPU はスピーカや時計に使うくらいしょぼいものであるというのは個人的な学びだった。年寄りなせいで 1GHz とかいまだにすごい速く感じてしまう。ARM かつ省電力のプロファイルだからという面はあるにせよ、これらの「遅さ」を内面化できないと危うい。ラズパイとか触った方がいいかもなあ・・・。RP4: Cortex-A72 1.5GHz x4 core.

付随する問いとして、2011 年のスマホ相当の CPU を載せている 2019 の時計やスピーカ, 8 年後には 2019 年のスマホ相当の CPU を載せているのだろうか。Moore's Law の slowdown が事実ならこの期待は満たされないわけだけれど、なんとなくそのくらいは速くなりそうじゃね？2027 年だよ? すごい未来じゃん?

未来のことはわからないね。

このブログを Letters + Fragments 方式にして 5 ヶ月。まあまあ機能している気がするものの、欠点や不満もわかってきたので微調整したい。

欠点そのいち。Fragments が若干雑すぎる。自分が雑に書けるのはいいが、ゴミ度が高すぎてこれ publish してどうすんの感がある。一方で自分が雑に書くにあたり publish する精神的敷居が邪魔になるときもある。端的にいうと仕事の脊髄反射的愚痴を書きたいのに若干はばかられる。そういうのはその瞬間に溜飲をさげるべく書きたいだけであって別に公開したくはない。WordPress として別の post にすれば非公開にはできるけれど、そんな大げさなもんじゃないのだよ。脊髄反射なのだよ。

欠点というか不満そのに。Letter をかく前に下書きというか頭にあることの箇条書きをする場合があるが、その敷居が高い。今は独立した（非公開の）Post にしているが、自分が wordpress.com 上で眺める時のノイズになりがちである。あと独立した post をつくる、という行為が僅かにめんどい。とはいえ Fragments にダンプしてしまうと自分以外には本当に意味不明なため邪魔すぎる。

不満そのさん。日々の reflection が足りてない感じがする。一日の最後に日記を書く、みたいな行為はやはり必要なのではないか。仕事日記は週に一回くらい書いているけれども、独立した Post をつくる腰の重さが頻度を下げがち。Fragments くらい日常に解けこめるとよい。

といった点を踏まえ、Fragments は非公開にして自分用のゴミ溜めとして使い（欠点 1, 2 への対処)、それとは別に公開日記をつける(欠点 3 への対処)、という風にしてみたい。公開日記はなんとなく毎日つける気力はない気はする。あと公開する必要があるのかはわからない。

まあやってみます。来週より。

WP 上での運用としては、公開日記を従来の fragments category におき、自分のゴミ溜め用に別の category をつくることにする。ほんとはここまでの fragments も非公開にしたい気がするけれどめんどくさいので放置。クビになるほどまずいことは書いてないはずだからいいでしょう・・・。

2019-11-18 追記

二ヶ月くらいやってみたところ、この「公開日記」部分は表面的には従来と大差ないことがわかったのでタイトルなどを従来の Fragments に統一した（これまでは無駄に Reflections という名前にしていた)。それとは別に非公開の "timeline" というゴミ捨て場が運用されている。

つづきもの。まず CPU と仲間たちがどうやって Moore's Law を終えたのかを雑に考える。

PC

身近なところでまず PC クラスの CPU を考えてみる。あまり良い資料がないなとおもっていたら Apple が全製品のスペックをカタログ化しれていたので冷やかす。やはり印象としては同じで、2005 年くらいまではびゅーんと伸びていく。Apple は 2006 年あたりで Mac を Intel に移行して PowerPC に見切りをつけるが、皮肉なことにこのへんで Moore's Law がおわってしまい Intel CPU たいして速くならない。Intel Core とかいってた頃。

2006 年の初代 Intel Macbook Pro が 2GHz x2 core. 2019 年の最新機種が 2.4 GHz x8 core なのでクロック数は 13 年で 2 割しか増えてない... というのは若干フェアではなく、2019 年のCore i9 は TurboBoost で 5GHz までクロックを釣り上げられるので 2.5 倍増えたと言えないこともない。そしてコア数は 4 倍。（値段は二倍くらい？)

つまりクロック周波数という Moore's Law Pop Culture の基準では 2 割, TurboBoost とマルチコアを考慮すると 2.5x4  = 10 倍増えた。13 年、ゲーム機に世代分なので昔なら周波数だけで百倍速くなったところで定常周波数は二割、マルチコアと TB あわせても 10 倍。時代がおわった感がある。

コア数や TurboBoost など色々な条件付きで性能を議論しないといけなくなった事実も Post-Moore 時代の特徴と言える。CPU にしてもたとえば Core Duo は 2MB の L2 cache だったのに対し 2019 の Core i9 は 16MB の L3 cache がある。PC 全体の性能でみると、各種バスは速くなっているし SSD という大きな変化もあった。二割しか速くなってない、というのはまったくフェアでない。13 年のあいだに 100 倍はないけど 3-5 倍くらいは速くなってるような気がする。まったく何の根拠もない主観だけど。

そういえばここ 20 年くらいの PC における大前提の大きな変化として、主戦場がデスクトップからラップトップにうつった。結果として PC といえども消費電力の影響を受けるようになったし、排熱の要件もタイトになった。結果として単純にコアを増やし続ければ良いというわけにもいかなくなった。

ラップトップの主流化はいつ起きたのだろうね。個人的には Macbook Pro あたりからラップトップに完全移行した記憶がある。世の中的には Netbook のあとに Ultrabook とかいうのがでてきて、それが普及したようなイメージ。Intel が Ultrabook と言い出したのは 2011 年。Macbook Pro は初代が 2006. まあ 2011 以前にも速くて軽いラップトップは一定程度あって、自分は VAIO Z というのをつかっていた。これは 2004 年らしい。雑にいうと 2005-2010 年の間に段々とそうなった感じだろうか。

Servers

サーバサイドの CPU はもともと PC の CPU を定数ファクター速くしたものという印象だったけれども、PC がラップトップ主流化で電力キャップされるに従い給電や排熱に融通しやすいサーバーとの差は大きくなっていったと思う。

いま見てみたら最高級の Xeon は 2.6-3.8GHz x 56 cores らしい。値段はさっぱりわからないが Arstechnica の記事をみると 36 コアのバージョンですら $10000 かららしいので、$20k - $30k くらいだろうか。消費電力も 400W とかまったくわけがわからない。一つのサーバはこれを 4 つまで挿せるらしいので、そのサーバは 200 コアくらいあるのか。すごいね。

まあ今どきサーバを買う人なんてほとんどいないわけなので次は EC2 を見てみる。Compute Optimized な C5 instance は c5.metal というやつで 96 vCPU. TurboBoost で 3.5GHz. 上に書いた上限の半分のコア数のやつくらいまでは売ってることがわかる。(ついでに GCE をみると・・・よくわからないが 64 vCPU まで増やせるとある。)

PC の初代 Macbook Pro と比べるべく 2006 年の Xeon のうち一番値段が高いやつを Wikipedia のリストからさがしてみると 7140N が $2000. 3.3GHz x2. MBP の Core Duo とコア数は同じ、動作周波数が 8 割増くらい。サーバという単位でみると、たぶんこの Xeon を 4 つくらい挿せるサーバがあったことでしょう。しらんけど。

13 年の差分をみると、動作周波数は 3.3GHz -> 3.8GHz で 2 割増。コア数が 2 -> 50 で 25 倍。あわせて 30 倍くらい。ラップトップの 10 倍よりは伸びているけれど、値段も 10 倍くらいになってるので正しく比較できてる感じがしない。雑に 2019 年製から $2500 くらいの CPU をさがすと 6240 が 2.6-3.9GHz x 18 cores. これだとだいたい 10 倍くらいでラップトップと同じ水準の成長となった。

つまりサーバの CPU はだいたい PC と同じ経緯を辿っているだが、金とデータセンターの力よくわからん。よくわからん。ででかいコア数を積み増していた。

なお Intel のサイトにはプロセスの集積度も載っている。2006 年の 7140N が 65nm, 2019 年の 9282 が 14nm. 4 倍、というか面積でいうと 16 倍?  更に 10 年遡った 1995 年の Pentium Pro は Wikipedia によれば 500nm くらいっぽいので 1995 -> 2006 は 7.5 (or 60) 倍だった。

2006 年から 2019 年のあいだにおきたサーバサイドの大きな変化は言うまでもなくクラウド。でもそれが CPU の発展にどういう影響を与えたのか、自分にはよくわからない。$10000 を超える超高級巨大 CPU を作る気になったのは仮想化のおかげだろうから、そういう広い意味で「クラウド」の影響はあるかもしれない。

クラウド業者のデータセンターは小規模なサーバファームと比べ圧倒的に電力消費にうるさいので、以前と比べ野放図に電力を使えなくなった面はありそう。それがなるべくコア数を増やし集積度をあげるという方向に背中を推したのか、それともでかい CPU を避ける圧力となったのか。まあ結果をみるに前者なのだろうな。

Mobile

2006 年にはモバイルは・・・なかった (雑すぎる近似。)

iPhone よくわかんないので Android. 2008 に G1 がでた。CPU は Qcom の ARM11 で 528MHz x 1 core. ときは流れ 2019 年の Galaxy S10 は Snapdragon 855 で "1x2.84 GHz, 3x2.42 GHz and 4x1.8 GHz".

動作周波数が 5 倍, ぜんぶのコアをあわせると 30 倍。Moore's Law の期待値 100 倍には届かないにせよ 13 年で 10 倍の PC よりは健闘している。毎年でる電話機の新しいモデルは前の世代より体感できる程度には速くなっているから。その経験則とも一致している。

この健闘はどこから来るのか、雑に想像してみる。ひとつにはモバイルに流れ込んだ資本の勢いだろう。PC 全盛の時代の ARM ファミリーは Intel に比べたらたいした技術力はなかったろうが、モバイルの隆盛にともない金が流れ込んで相対的な技術的洗練が進み、Intel との距離を縮めた。別の言い方をすると、限界までアーキテクチャ的な無理をしてきた Intel に対し素朴さを保ってきた ARM 勢が、その素朴さ貯金を取り崩して性能を手に入れた。

もうひとつはバッテリーサイズの巨大化。ラップトップ PC が薄型化によってバッテリーサイズを削られたのに対し、モバイルは画面の巨大化に伴う筐体サイズの増大に助けられ、バッテリーサイズを増やせた。おかげでマルチコア化など性能を電力で買うアプローチを積極的に使えた。

結果として PC とモバイルの距離は縮まった。性能ポップカルチャーの北極星 Geekbench によれば Macbook Pro 2019 のスコアが 6900 で Galaxy S10+ が 2100.  3.3 倍くらい。価格差はもっとある・・・のはいいとして、たとえば G1 と初代 Macbook Pro なんてたぶん 10 倍以上差があったことでしょう。

GPU

進歩してるんだろうけれど、よくわからない。すごい雑な印象として、少なくともモバイル CPU くらいのペースでは速くなってるかんじ。Intel CPU ほど終わってしまった印象はない。

計算の性格上 CPU と違って容赦なく並列度を上げていけるので、並列化に重点を置いて増やしている印象がある。あと AI/Crypto で存在感を増し、かつ Cloud 到来にともないデータセンターの中でバスパワーとかの遠慮なく電力を使えるハイエンド機がでてきたのも高速化に寄与している気がする。

あと CPU と比低レベルの ISA とかを公開していないぶん互換性の制約がすくないので、回路の非効率は CPU よりすくなく、そのぶん性能の伸びがよい、という面はあるのかもしれない。

それ以外はターゲット領域の CPU に足並みを揃えて進歩してるのではなかろうか。つまり: よくわからん。

FPGA, ASIC and Domain Specific Architecture

サーバや PC の世界ではごく限られた用途のニッチという理解。一方モバイルの SoC は面積の半分以上が CPU および GPU 以外すなわち ISP などの ASIC なので、モバイルにおける Moore's Law の文脈でこいつらの存在感は無視すべきでない。

が、全然わからん。ビデオの codec などは PC でもモバイルでも CPU (のふつうの命令を処理するところ/AP)以外がやっているわけで、それなりに予算を使っているはずなんだけど。

TPU, NPU や PVC のような DSA は emerging technologies なんでとくに歴史として振り返るものはない気がする。

SIMD

CPU は引き続き AVX や Neon などのメディア処理専用命令を足し続けて動作周波数あたりのスループットの改善を試みた。AVX は最初のバージョンは 2011 年, AVX512 というのが 2016 から入り始めて、じりじり命令を増やしている。2011 以前にも MMX や SSE があった。ARM も昔から NEON があり、AVX512 に対応するものとして SVE というのがあるらしい。

System

システム全体でみると、歴史的にはそもそも CPU 以外、つまり IO とかが性能のボトルネックという場面が多かった。それを補填するために CPU はでかいキャッシュを積み続けバスも太くなり、その傾向はおおむね続いているという理解。バスについて考えると、モバイルは SoC なので標準規格に引きずられず自分の都合で色々できる利点がある。データセンター業者も非標準な I/O をつかいがち。

CPU がもたもたしている間に I/O は高速化をつづけ、ギャップは小さくなっている気がする。ストレージだと SSD や NVM. ネットワークも 1Gbps から 10Gbps, 100Gbps と規格が改善し、AWS もインスタンス間は 25Gbps とかいってる。データセンターについてはクラウドの台頭に伴うこうした著しいシステムレベルの改善が CPU の停滞感を隠してきた印象。

モバイルも、よくわかってないけど色々進歩してるんじゃないの？そういえば 3G から LTE になったのは大きかったね。これも 10 倍以上 100 倍未満の改善。モバイルじゃないけどいわゆる「ブロードバンド」な帯域は 15 年でどのくらい速くなったのだろう。いまいち調べる方法がわからない。

Observation

「なにがおきたのか」という当初の疑問に自答すると:

まず上に書いたスペックの二点比較だけからは自明ではないが当たり前の事実として、動作周波数上昇の slowdown はいきなり起きたわけではなく、徐々におきた。CPU 業者はあの手この手で slowdown の影響を補填しようとした。

わかりやすいのがマルチコア。動作周波数の停滞に伴いコア数が増えた。ただ PC やモバイルでは思ったほど増えず、せいぜい 8 コアくらいが現状。サーバ側は 100 コアみたいな勢いのでかい CPU もあるが、値段も消費電力もアホみたいに高いので CPU が期待通りの性能上昇を果たしたと解釈するのは無理がある。どちらかというと昔からある HPC/スパコンみたいなジャンルに Intel が踏み込んでいったと見る方が正しい。

消費電力の壁から、可変周波数が普及した。Intel は TurboBoost があるし、ARM の一族もふつうにクロック数が上下して最大周波数での可動時間はほんとに短い。動作周波数を下げるだけでなく一部のコアを止めることもできる。

ARM 家は可変長クロックにくわえ Big.Little のような非対称コアが現れた。Snapdragon 855 にいたっては Prime 1, Gold 3, Silver 4 みたいな三段階構成。

同一クロックでのスループットを稼ぐ SIMD は昔からあって特に Moore's Law 関係ないのかもしれないけれど、引き続き強化されつづけている。

システム全体でみると CPU の存在感は相対的に下がり、グラフィクス以外の用途、というか 主に ML のおかげで GPU がもてはやされるようになった。特にデータセンターでは PC 相手には役不足なかんじのでかい GPU も重宝されている。モバイルも同様に GPU の存在感は増しているし、GPU だけでなくメディア用途などの ASIC も SoC の面積予算を多く使っている。

単純なコンピュートだけでなくシステムレベルでの改善もデータセンターを中心に進んだ。ネットワークもストレージもだいぶ速くなった。15 年のスパンだと 100 倍まではいかないにせよ 10 倍よりは改善している。モバイルにしても LTE がやってきた、今年から来年にかけて 5G がくることになっている。家庭のブロードバンドはよくわからない。

というわけで...

CPU の動作周波数停滞は CPU 内外の数多の改善によって覆い隠され、計算機業界全体としてはこの 15 年もひきつづき進歩を実感できた。PC は動作周波数依存のパラダイムから脱しきれずに停滞感があったが、サーバサイドはデータセンターへの集約にともなうアーキテクチャの刷新がシステム全体の性能を高めたし、モバイルは雑魚っぽいところから本気度の高い SoC へと進歩し、デバイスの巨大化によるバッテリ容量の増加もそれを助けた。

ただし Moore's Law のようなわかりやすく乗っかりやすい単一の指標はもうない。レイヤのあちこちでおこるブレイクスルーをその周辺にいる人々が活用し、産業全体としてなんとなく前にすすんでいるのだろう。

こうした変化をプログラマやソフトウェア開発チームはどのように受け入れたのか、については別項で。

少し前に Podcast で Reality Engine の論文をよんだとき、この時代の CPU クロックのあがりっぷりにビビった。いわゆる Moore's Law というやつ。Mooore's Law は半導体の集積度について言及しているのでそれをクロック数として解釈するのはポップカルチャー的ではある。ただ近似としてはあってる。

Podcast では Reality Engine の比較としてなんとなく PS1, PS2 を引き合いに出した。その延長としてゲーム機を例に考えてみる。

ゲーム機、だいたい 6-8 年に一回くらい新しい機種が出る(1983 にファミコン, 1990 にスーファミ,  1994 に PS1,  2000 に PS2, 2006 に PS3, 2013 に PS4. 2 つの系列を混ぜてる雑さは見逃されたし。) このサイクルに Moore's Law を当てはめると、だいたい世代が一つ上がるとクロック数がひと桁増えるかんじになる。6 年 = 4 Moore Cycle = 16 倍、みたいな計算。スーファミの CPU が 2MHz, PS1 が 33MHz, PS2 が 300MHz, PS4 が 3200GHz なので、この間のクロック数はじっさいひと桁づつ増えている。

このあと PS4 の CPU は 1.6GHz x 8 core となり、クロック数が下がってコアが増えた。CPU アーキテクチャが PPC から x86-64 にかわったので厳密にクロック数で比較はできないが、ひと桁は増えてないという雑なレベルでは間違っていないとおもう。そしてコア数がひと桁近く (8 倍) 増えている。

この数字から判断するに, Moore's Law は 2006 から 2013 の間に終わったと言える。議論の雑さにも関わらず、これは自分の肌感覚とも合っている。

自分は Moore's Law が最後にフルスピードだった 2000 年代前半に大学を卒業した。だから自分の中の色々な常識や期待は Moore's Law を織り込んでいる... とおもっていた。でも Post Moore な 2019 年にこうしてぼんやりプログラマをやっていて、クロック数が倍々で増えていく当時の身体感覚はすっかり失われていている。そういえば学生の頃はクロック増えまくってたわ。最近のラップトップとか全然速くなんねーな、と思いつつ受け入れてたわ。

こんな大きな変化が起きたのに何事もなく生き延びている自分と業界にびっくりする。まあ何事もないわけでなく、大きな変化は起きたのだろうけれども。でもあんまりそういう体感ないじゃん？あたしの感性にぶすぎ？

いい機会なので、何が起きたのかを自分の中で整理してみたい。関心は大きく分けて２つある。ひとつ目はハードウェアの中の Moore's Law がどう終わったのか。ふたつ目は、プログラマというかソフトウェア開発はその事実をどう消化したのか、あるいは消化できていないのか。

この２つを言語化する気力があるかわからないので、とりあえずは「法則の時代がおわってたことにも法則が成り立っていたことにも同じくらいびっくりした」という事実だけを記録しておく。

追記

がんばってかいた:

• How It’s Been Ending (2) – CPU
• How It’s Been Ending (3) – Downsizing
• How It’s Been Ending (4) – Dennard Scaling
• How It’s Been Ending (5) – Software Development
• How It’s Been Ending (6) – Me
• How It’s Been Ending (7) – The Ecosystems

「週末一日働くかわりに平日一日休みたい」というようなことを言う人がいる。自分もたまにそう思うことがあった。今日、子を暑さから逃すため平日に仕事を休み涼しい Monterey の水族館にでかけたところ、いつも混んでいてうんざりしがちな水族館が人影まばらなすばらしい場所になっており感動。この「平日週末スワップ」という（実現することが稀な）願望のことを思い出した。

これは、昔は結局やることはあまりなかったし、今もできる気がしない。なぜか。

昔、というのは妻子を持つ前かつ東京で働いていた頃だけれども、スワップをしたい動機は主に仕事の生産性アップだった。人がいないところで集中して働きたいという。平日に休みがほしいとは特に思わなかった。無趣味ひきこもりだったので避けたい週末の人混みもさほどなかったし、有給もだぶついていたから平日たまにどこかいきたいならふつうに休みを取ればよかった。労働時間の柔軟性もあったから休む必要すらなく、午前中に用を足して午後から遅く働くオプションもあった。

有給が少なく労働の柔軟性のない仕事をしていた頃も同じようなことを考えたが、当時はそもそもスワップを実現できる人事的な柔軟性がなかった気がする。自由のきかない零細中小企業とはそういうもんである。

今はどうかというと・・・。理論上はそれなりに制度の柔軟性があり、かつ自分は平日の休みを欲しているが、いざやろうと考えてみると腰が重くなる。なぜか。

まず仕事はそれなりに調整しないといけない。チームに周知するくらいは必要。結果として若干のカルマを消費する。しかし自分はカルマに余裕がある気がしていないので、そうした調整活動に身の危険を感じてしまう。巨大な締め切りが過ぎ、緊張が低い時期ならまた違うかもしれないが。あと休日に仕事をする側で家族の logistics をなんとかするのも面倒。

全体的に、得られるものが norm から外れるコストを justify していないという gut feeling がある。なぜ得られるものが重要に思えないのかというと・・・有給とって休めばよくね？と思うからだろうなあ。そんなにバンバン使えるほど有給があるわけでもないので気のせいにも思えるが・・・。

あるいは具体的に行きたい場所がそれほどない曖昧な状態で休みの確保というめんどくさいことを考えているから気が乗らないのであって、もうちょっと平日に行きたい具体的な場所リストが育ってくるとがんばってやりくりする気も起こせるかもしれない。

製品寿命が伸びてくると登録されたバグの数がどんどん増え手に負えなくなる。

対策として、まずはバグの優先度の解釈が厳密化される。たとえば P3 は「いつかやるかもしれないバグ・新機能」みたいな扱いになる。バリエーションとして「いつかやるバグ」というマイルストーンをセットすることもある。GTD 信者には "someday maybe" といえば通じるだろうか。

症状が進行すると本当にいつかやりたいバグと単に放置されているものの区別がつかなくなる。この段階での対処は色々ある。

たとえば「いつかやるバグ」とは別に「冷凍保存したバグ」というマイルストーンが追加される。「もうやりません」という意思を明示するぶん、ある種のコミットがある。バグを登録した人や新機能を要求した人はその意思を受取り、文句をいったり諦めたりする。

より激しい対処として、一定期間なんのアクティティビティ（コメントなど）が観測されなかったバグを一律 "Obsolete" とマークして閉じる「バグ破産」というアプローチも見たことがある。これはほんとにひどい話だが、よく考えると「バグ破産」で閉じる行為自体がひどいというよりは、そこまで手に負えなくなってしまった事実が問題に思える。

ここまではチームや組織単位での対策。これらとは別に、自分は個人的にバグを弔うやりかたを一つもっている。それは「墓場バグ」をつくること。

どうにもならないが、度々報告される問題がある。自分の仕事だと「遅い」というやつ。わかってる。手も打ってる。良くする計画もある。でも完全には治らない。原因はまちまちだが、はっきりもしない。そういうバグのために自分は「遅いバグの墓場」というバグをつくっている。新しい遅さバグが報告されたら、ログを睨んで何らかの診断を下し、特に新しい情報がない場合（すなわち大半の場合）はその遅いバグを「墓場バグ」の重複報告としてマークする。「遅いバグの墓場」は、遅さの種類に応じて複数個用意してある。

診断をコメントし、ありがとう、がんばってるからよろね、と挨拶してバグを墓場バグに重複登録 (dedup, de-duplicate) する。バグを登録してくれた人も納得するし、バグも成仏するであろう。たぶんね。

「なんか画面の表示が乱れる（がちょっとつつくと直った）」というバグも度々うけとる。これも原因はよくわかっていない。アプリのレイヤではなく OS のバグであることはログから確かなのだが、では OS の何が壊れているのかはよくわからない。こうしたバグは、受け取られるたびに色々な人の間をたらいまわされ、各段階で各人が時間を無駄にする。不毛なので、自分のところに来たときに「いつものやつ」だとわかったら「描画乱れの墓場」に dedup する。

こうした墓場バグがあると、問題のカテゴリに名前がつくおかげですくなくとも「似たような問題前にも見たな・・・」みたいなことが減る。そして既存の類似バグに dedup するよりは後腐れなくていい。コメント欄も荒れにくいし。

これらの墓場バグ自体は、冷凍バグなりなんなりの「やるきはないが閉じないバグ」に所属している。明らかに suboptimal な所作だけれども、生きていくために目をそらしたい現実もある。あのバグたちにはせめて成仏してほしい。

なお遅さバグについては、直す気はあるという意気込みを込めて墓場ではなく動物園と名付けている。"Zoo of the slowness"  みたいな。Graveyard だとしょんぼりしちゃうけど、Zoo はなんとなく楽しげでよい。今日も速くしてくぞ！

• The Math behind Project Scheduling, Bug Tracking, and Triage | USENIX このトークみてみようかな・・・。

https://twitter.com/kazuho/status/1170911284713230336

そうっすね・・・という。自分も upstream するみたいな言い回しはそもそも WK なり Chrome なりで身につけたはずだが、もうマインドセットがオープンソースじゃなくなってるなー。

via Blow to 10,000-hour rule as study finds practice doesn't always make perfect | Science | The Guardian

モダ​ン根性論ポップカルチャーのはしりのひとつ Outliers (5000 Amazon reviews!) が論拠としている 1993 年の研究を replicate しようとしたけどだめでした、という研究の話。ふーんとリンク先の論文も眺める: The role of deliberate practice in expert performance: revisiting Ericsson, Krampe & Tesch-Römer (1993) | Royal Society Open Science. 割と面白い。

• 元研究、およびこの研究は great, good, less good の violinist をあつめて比較している。これどうやってあつめるかというと: Great と good は一つのエリート音楽学校からサンプルする。具体的には学校の教師にノミネートしてもらう。Less good はエリートではない音楽学校から適当にサンプルする。
• モダン根性論用語になった "deliberate practice", 具体的には "teacher-designed practice" だった。対にあるのは self-guided practice らしい。Deliberate practice ってなんとなく自分で工夫して負荷を高めるもののように考えていたけれど逆だった・・・というか、もともとは Delibrate practice の定義は存在しなかった、あるいは主張に応じてコロコロ変わった、らしい (4.1)。この論文は元論文著者 Ericsson の雑さを強く批判している。
• 練習以外の activities についても時間の情報を集めている (table 3). たとえば "意識の高い会話 (professional conversation)" みたいのもはいってる。

この論文のキーとなる発見は

• Good および Great 勢は Less Good 勢より圧倒的に練習している。
• Great​​ 勢と Good 勢は practice も teacher-designed practice も大差ない。（むしろ great 勢の方がちょっと少ない。)

この論文の趣旨はオリジナル論文の主張の replication なのでそのほかの点については細かく議論していないが、外野としてグラフを眺めるとなかなか趣深い。特に "3.5. Retrospective estimates of practice during development" のセクション、自己申告による練習時間の経年変化。

• Best 勢は人生序盤 (8 歳くらいまで) の teacher-designed practice の量が Good/Less Good よりだいぶ多い。しかし 12 歳あたりで Good が逆転する。つまり violin で Great になるには幼少期に教師に鍛えられるのが重要なのではないか。逆に一定程度年をとったあとにキャッチアップしようとしても難しいのかもね。この一定程度というのが 12 歳であるあたりに violin 業界の厳しさを感じるが。
• Good 勢の練習量は 15 歳あたりから Best よりもだいぶ多い。(二割くらい違う。) そして Good の練習量は 18 歳に向けてどんどん増えていくが、そこで頭打ちになり下がり始める。一方 Best 勢の練習量（Good 勢より少ない)は 18 歳を過ぎても下がらない。ボンクラ努力家が 18 で自分の限界に気付かされる様を見るようで気の毒。

音楽の世界は厳しいなあ・・・。

あと Best と Good が同じ学校の同級生で、Less Good は別の学校という事実にも趣があるね。Good/Great と Less Good の差はほとんど peer pressure で説明できそう。実力をつけたいなら厳しい環境に身を置くのが大事だね。

プログラマ、音楽家と比べるとほんとに平和なものでよかったな・・・と思う。

• Best でなくてもふつうに生活できる。
• 幼少期にプログラミングを教えてくれる teacher とかいない (少なくとも一般的でない). Teacher-designed practice もあんましない。

Best と Good を violinist を区別するものが (12 歳以降の) practice でないならなんなのか。幼少時の訓練なのか「才能」なのかそれとも他のなにかなのかはよくわからないが、音楽のように成熟した世界ですらこれなのだから、プログラマみたいに雑で新しい世界でそこそこの成果を出したいなら、いくらでもやりようはあるのだろうね。まあ AI 方面はアカデミアという超成熟した過当競争世界にも見えるけれど。

「後輩を指導する」みたいなことを基本的にあまりやらなくてよい立場にいる。誰かを指導する行為には副作用があり、それを被らずに済んでいる事実を appreciate している。

多くの人々が無意識に払っているであろう「教えることの対価」についてそのうち書こうと思っていたが、最近は逆側にある「教えないことの対価」に出くわしがちなので、まずそれについて書く。

隣の席の同僚の書く UI まわりのコードにやや不満がある。性能改善のために UI まわりもさわりたいのだが、変更に弱くバグりがちで困っている。これはもうちょっと MVC とか MVP とかなんか architectural pattern みたいのも考えてくれや Flux にしろとはいわねえからよ・・・という抽象度高めの不満と、それコピペしたり雑に分岐する前にもうちょっと考えて整理してくれや・・・という細部への不満がある。

抽象度高めの方は件の同僚以前に昔からそうなので、これは「なんとかしなかった」the lack of action に対する不満であり、期待値が高いだけと言える。細部のもうちょっとなんとかならんのか感はモバイル専業でやってきたおっさんとかにありがちな症状なのだが、その同僚は割と若い。年齢関係なかったねごめんね・・・。つまり勤務先でモバイルをやってるだけだとこういうコードになってしまう気の毒さ。

おっさんのコーディング傾向に口を挟むのは不可能だと前のチームで学んだ。しかし若者はまだ救えるかもしれない。フィードバックしてあげたい。しかしあまり良いフィードバックをできる気がしない。その同僚は、成果はだしている。本人はコード品質で struggle を感じている様子はない。だから下手に口を挟んでも余計なお世話。コードレビューとかで場当たり的になんか言うことはできるが、もうちょっとこう、あなたのコードはこういう傾向があるからこれ読んで勉強のうえ補正してちょ、きっといいことあるから、みたいな一歩さがったフィードバックを、本人が有用性を感じられる形でできないものか。

こういうの、たとえば自分が昔そうであったように、ランダムな新卒入社メンバーをメンターする、みたいな立場で組織から「新人教育」を期待され続けてきたなら、時間や労を割いて人に何か教える方法を考えるだろう。それを 10 年 20 年と続けていたら、バンとアドバイスの一つもできそうな気がする。そしてその先輩的アドバイスは組織と文化の力で割と聞き届けられがち。昔は先輩面してそういうことを考えていた時期がある。

しかしそういう身分を脱し 10 年ちかくヒラ暮らしをしているので、いざ誰かにアドバイスをしたいと思っても壁を感じる。他人のやり方に口を挟むことに強い抵抗があるし、その抵抗を乗り越えられる説得力ある言説を自分の中に積み上げられていない。

自分はオブジェクト指向なり関数型なりのデザインの本を一定程度読んでいるし、いわゆるプログラミング指南書もいくつか読んできた。ただ基本的には読んで感心して影響を受けて内面化して忘れる、というサイクルで消化しているため、他人のコードの傾向から適切な文献なり文献内の「ベストプラクティス」なりを論拠として引用はできない。

「引用できないなら身についたとはいえない/消化不良なのでは」という批判は、何割かは正しい。一方で他人を説得する必要がないなら、その場で納得して結論を受け入れコードの書き方を変えれば、それは内面化され身につく面もある。これは若干 cargo cult 的な危険を孕んでいる一方、少なくとも読んだ瞬間にはある程度批判的に評価しているはずで、その時点の前提が崩れない限り問題はない。そして問題があれば、それは体感できる・・・こともある。

こうした雑な学習はコストが低いので、かならずしも割は悪くない。人に教えられないのは雑さの対価といえる。逆に言えば、雑なまま前に進んでいけるのが人に教えずに済む強みである。

表題にもどると、人に教えないでいると仕事のプラクティスなどを説得力ある形で言語化できない、かもしれない。その機会が少ないから。結果としてチームメイトなどへの影響力が下がる、かもしれない。

しかしこの隣人のコードをなんとかしないと日々が厳しい。どういうオプションがありうるか。

• 適当にぐぐってでてきたアドバイスを鵜呑みにして伝える。職業倫理的に NG な感。
• いい機会だからと必要文献をばーっと買い集めて読み、整理してみる。これは興味深いプロジェクトな気がする一方「雑なまま進める」という自分の利点を損ねてしまう気もする。時間のない身に割が合うのか。
• 高位のフィードバックは諦め、必要に応じて適当に相手のコードをレビューしたり書き直したりしつつ付き合っていく。とりあえず書き直しても大丈夫な程度には関係性を維持できている、というか相手が不遜じゃないのが幸い。

なんとなく個人をピンポイントで先輩面するのは企業文化的にあわなそう。あと現状のコードのだめさはその同僚のせいだけでもないので、なんか言われると腹も立とう。もうちょっとこう、チームに対してなんかを提案する、プレゼンするのが筋に思える。そしてこれは主張の品質の bar を一層高くするなあ。しかし他人のやりかたに口を挟む以上、この高さは必要なものに思える。

最後のオプションすなわち現状維持で当面はいいとして。コード品質に関するアドバイスたちをレビューし、現時点での妥当解のスナップショットを研究するのは面白そうではある。しかし時間の無駄な気もする。なんかもうちょっといい切り口ないかな。うーむ・・・。

OS リリースという節目も来たことだし、まっとうな会社員としていいかげん OS の dogfood を再開(一年ぶり)しようと考えてみるが、どうにも gut feeling が拒絶してくるなあ。この胃の痛さの出処はなにか。

外出先でいきなりバッテリーが drain されるなどして Google Map が使えなくなる恐怖。通知まわりのバグで奥様からの緊急連絡に気づき損ねる恐怖。写真とって、といわれてカメラが動かない/あとで写真が消える恐怖。(カメラ周りは過剰反応している可能性がたかい点に注意されたし。）

これはリリース前の OS が理不尽に不安定なせいだけではなく、電話機というものが生活に密着しており、かつ自分の生活に精神的余裕がないという事実のあらわれに思える。となると、やはりバックアップにちゃんと動く安全なデバイスを持って piece of mind しつつ、地雷バージョンを日用したい。つまり、ふだんは不安定な子を使う。しかし鞄の中にはつねにちゃんと動く子が入っている。

最初の悩みは一枚しかない SIM をどちらに差すか。まあ答えはバックアップ機一択なのだが、そうすると地雷の子を使いつづけるよう自分を仕向けるのが難しい。SIM を複数使える MVNO に乗り換える, 会社から SIM を支給してもらう...  といった選択肢は色々人生をややこしくしがちなので今は保留する。SIM なしで日用できるのかというと、自分の平日はだいたい under Wi-Fi なのでだいじょうぶです。

たぶんバックアップ機からは本当に重要なアプリ(すなわち地図とテキストとカメラと写真)以外をすべて消し去り、机の上におかなくてもよいようにすることだろう。というか前そうやってた気がするのだがなぜやめてしまったのか・・・と考えるにそのデバイスでしか起きないとされるバグの調査で wipe してしまったんだな。そういうことは滅多にないんだけど年に一回くらいはあり、年に一回あれば dogfood の習慣を断つのに十分なのだった。

ついでにバックアップ機からはすべての BT ephemeral を消し去るのも良いだろう。

最近うまれた新しい問題: 自分はメッセージングを SMS に統一してしまった！なぜなら Hangout が滅びてしまったから・・・。これだと SIM のないデバイスで不都合がある。SMS 以外で奥様への負担の少ない選択肢を考えないとなあ。おとなしく FB Messenger を使うか。やだけど・・・Signal や Telegram つかいたいなー・・・しかしそういう話ではないのだよ・・・。

バックアップ機は Pixel 2 XL. 地雷機は新デバイス...はなくすとやなのでしばらく Pixel 3 を使い、新しいのが発売され次第そっちにスイッチするとしよう。そしてアプリのセットアップがめんどいので発売まではあまり色々インストールせず質素な電話機生活をしときます。

追記

二台持ち再開した。

Backyard Grilling の謎 のつづき。

持ち歩ける小型グリルおよび周辺機器を買い、家の patio で BBQ をしてみた。なおうちは二階建てアパートの一階で、表は駐車場と柿畑。

結論: 自宅で BBQ は無理。煙ですぎ。序盤の火を起こすところを乗り切れば何とかなるかとおもったけれど、肉汁や油が焦げるなど定常的にモクモクしまくる。タバコどころじゃない。ご近所ごめんなさいと胃が痛くなってそそくさと終わらせた。

それ以外はまあまあ楽しいし炭火で焼くと何でもおいしいので場所をみつけてやっていきたい。アパートにもいちおう BBQ エリアはあるので、そこに食材および火鉢を持ち込んでやるのが現実的かな。

焼いたものたち:

• 市販の冷凍バーガーパティ。チーズのせて溶かし、バンズも軽く焦がし、適当にはっぱなどを挟んでバーガーする。ふつうにうまい。
• ソーセージ。うまい。しかも失敗しにくい。Hotdog どうでもいい食い物だとおもってたけど BBQ の世界では上級市民だった。
• 野菜: ズッキーニ、ナス、ポテト。スライスし油を塗って焼き、塩胡椒。どれもうまい。
• 肉: Skirt Steak 1lb くらいをりんごと玉ねぎなどで適当につくったタレに漬け込み焼いた。味は良いが焼きすぎて固かった。火加減をちゃんとできる気がしない。

周辺機器

• Chimney starter. 簡単に火をつけられてよかった。
• 炭は近所の supermarket で適当に買ったもの。
• 点火用ブロックは Amazon で適当なのをかったが近所でも普通にうってた。
• ライターは必要。自宅にあったものを使った
• Tongue, Spatula セット. Tongue は炭をいじったりなんだりに必要。
• 網を掃除するブラシ。必要といえば必要だけど、Grill 用ではなく普通のタワシでよかった気がする。ムダな買い物だった。
• Foil. イモを包んで焼こうとしたけど面倒で使わなかった。次回は使いたい。
• 温度計。心の余裕がなくて使わなかった。肉を overdone してしまったので次回は使いたい。