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 についてはなんかもうちょっと書きたい気がしていたが、また今度。