旅先の宿で夜中に目が覚めた。頭をよぎったことを書く。

しばらく前から自分のキャリアが下り坂に入った手応えがある。職業的なピークは過ぎて、あとは何かが下がっていくだけなのだというぼんやりとした重量加速度。

学生時代に人生のピークがあった人物が、哀れさのステレオタイプとして世の中の物語に時々登場する。自分がそんな風でなくて良かったとたまに思う。人生の楽しい瞬間は会社員になってからの方が多かった。退屈な学生時代だっただけかもしれないが。

もしピークが過ぎたのだとしたら、いよいよ自分は楽しかった過去を惜しむばかりの哀れなステレオタイプに成り下がったのだろうか。だとしたらピークはどこかと振り返る。しかしこれといった山場は見当たらない。一方で道が平坦だったというのにも違和感がある。

気分だけでいうと、確かにピークはあった。一つは外資系の会社に雇われてオープンソースの仕事をはじめた瞬間。もう一つは外国に引っ越した瞬間。でもこれを人生の、あるいはキャリアのピークと呼ぶには抵抗がある。どちらの瞬間でも何かを成し遂げてはいないから。

何かを成し遂げた瞬間、たとえばあるソフトウェアの大きな機能を世に送り出した実績はあるか。おそらく 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 で話す準備として掘り起こしてみたが、話す時間なさそう。