自分のいるチームは特定電話機シリーズ向けのアプリを開発しているので、年に一回ある新しい電話機のリリースが主要なリリースターゲットである。それ以外のタイミングもいれると年に何回かリリースはするが、基本的には電話機のお披露目を中心に一年周期で物事が進む。近隣にある platform の人たちも、同じく年に一回の新バージョンのリリースに向けて一年のサイクルで仕事をしている。

これは daily, weekly あるいはせいぜい monthly か bi-monthly くらいで継続的にリリース/デプロイしていく近代的なソフトウェア開発とはだいぶ違う。昔のソフトウェア開発に近い。外から見ていたときはあいつらダメだなと思っていた。中の人となった今もダメだと思う。しかし自分がどうこうできる問題でもないので適応しないといけない。

サイクルが長いと具体的にどう困るか。今となっては珍しい体験な気もするので、慣れ切らないうちに様子を記録しておく。

締め切りの対価

サイクルが一年だと、ある締め切りを逃すと次は一年後である。自分はある新機能を unblock するために直してほしい platform のバグがあった。けれど二ヶ月くらい風邪で休んだりなんだりしているうちに締め切りをのがしてしまった。なんとか master branch では直してもらったのだけれど、それをリリースブランチに cherry pick してもらえなかった。なんとかしてくれとゴネるも交渉は成り立たず、結果としてその修正に依存していた機能達は軒並み drop された。厳しい。

自分が締め切りのインパクトを内面化していたら、もうちょっと優先度をあげて頑張っただろう。これが毎月リリースだったら翌月出せばよいだけなのだが・・・。もう締め切りというものを体が忘れてしまったよ。

締め切りは一つでなく「とりあえずデモできる程度に動く」「API 確定」「Dogfood できる」「バグなし」など複数のマイルストンにわかれている。レイヤによっても締め切りが違い、たとえばアプリのような事後的に空から撒きやすいやつは platform に比べると少しあとにずれている。なのでアプリのバグだとおもったら platformの バグだった、とわかったときには手遅れになることがありうる。

締め切りの前には駆け込みで変更が殺到し、ツリーが不安定になりバグトラッカーの流動が増し、機能を入れたい人々とツリーを安定させたい人のあいだに緊張が走り、チームの空気が殺伐としてくる。これといった新機能を持っていない、というか早い段階で drop されてしまった自分は、読み物で見聞きした世界だなー・・・などと眺めている。

長いブランチ

リリースブランチの寿命がながい。リリース間隔がながいからといって必ずしもツリーの安定化にかかる時間が長い必要はないが、長い。たぶんリリース間隔がながいと QA のプロセスを短縮する動機が弱まってしまうのだろう。結果として前のリリースブランチが死ぬ前に次のリリースブランチが切られたりして、カオス。

ようやく canary を撒いてみつかった crash report にでてきたクラス、リファクタリングされちゃって master にはないんですけど・・・みたいな事態が起こる。しかも社内のツール群は short living branch を前提としているため long living な branch で作業するのがすごい面倒。辛い。

それでも昔よりはよくなったらしい。昔はどうだったのか知りた・・くはないな別に。

手持ちぶたさ

リリースが近づくと ToT でもあまりでかい変更ができなくなる。ブランチを切ってあるから理論的にはできるわけだけれど、まわりの人たちがリリースにむけたバグ修正モードで仕事をしているところで実験的なコードを書いたりしてると肩身が狭いし、下手にでかいリファクタリングをして cherry pick の邪魔になっても気の毒だから気が乗らない。

まあ手持ちぶたさというのは語弊があり自分もバグ修正大会に参加しているので仕事はある。ただ自分の新機能は drop されている手前コードは動いておらず、バグもでてこない。なので他人の球拾い的なバグ修正が中心になる。バグ修正はきらいじゃないけど、それなりに大きな成果を求められる立場なのに細かい作業ばかりしてる不安はある。

まわりのシニアなエンジニアをみると、難しいバグを直したり遅れている機能を手伝ったりしている。なるほど。実力不足で手伝えなくてごめんね・・・

計画性

一方、来年にむけての計画のもようなものもどこかでは始まっているらしい。そこでちゃんとクビを突っ込んでおかないと、また必要な変更が締め切りに間に合わず先送りということになりかねない。

ただ自分は一年前ここにいなかったため、この序盤の計画フェーズがどう進むのかいまいちよくわからない。一方で目の前には pile of bugs がある。なのでついバグ修正を優先してしまうが、計画に時間と頭を使わなくていいのか不安。しかし何をすればいいのかわからない。落ち着かない。

長い坂道

一歩下がると、一年サイクルの問題点は学習の iteration が長いことである。

まず自分のような新入りがプロセスを見届けるのに一年かかる。自分の仕事が一年かかるだけでなく皆が同じサイクルで動いているため他人を見て学ぶのも難しい。しかし会社の勤務評定は年に二回容赦なくやってくる。ひどい。一周するまで待ってちょ・・・。

新入りだけでなく組織の学習サイクルも長くなってしまう。何かを変更して結果を見届けるのに一年かかる。外から見ていたときはこのひとたち全然よくならないな・・・とおもっていたが、納得。

構造的問題ゆえ自分がどうにかできるものではないけれど、適応の過程で近代的とは程遠いこのサイクルを当たり前と思わないようにしないとなあ。

といったところで適応のために必要なことを書き出してみると:

• 様々な締め切りへの awareness を高める。Platform や電話機のリリースがずっと先でも、プロセスのマイルストンはそのもっと手前にやってくる。締め切り関係のメールを見落とさず、印刷して壁に貼るなりノートの冒頭に書いておくなりして目に入るようにする。
• 各フェーズでやるべきことをやる。
  • リファクタリングが継続的な所作である、という理想は妥協し、でかいリファクタリングは序盤に済ませておく。後半で気づいた smell はどこかに記録して次のリファクタリング期に片付ける。
  • バグ取り期にはバグをとる。人のバグ取りを手伝う。
  • 新機能は早めに end-to-end で動かして下のレイヤのバグを特定する。（これはインクリメンタルな開発でも一緒だけどね。）
  • 計画・・・についてはどうすべきなのかまだわからん。

若干 sigh ではあるけれど、現実として受け入れます。はい。

通院の帰り、Uber の車内に Pixel2 を落としてしまう。

Uber のヘルプページから運転手に電話をつなぐことができる、が、電話がない。友達の電話を借りなさいというのでそうする。電話がつながり、届けてくれるようお願いする。はー・・・。チップを目一杯つけてお礼とする。Uber/Lyft は運転手の身元が割れているのでこの手のトラブルには強いねえ。

自分は電話機部門にいるため開発中電話機の dogfooding を推奨されているが、絶対になくす自信があったので決して持ち歩かないことにしていた。やー正解だったね。うかつ税率高すぎデバイス、持ち歩くべからず。

なおチップを目一杯つけたあと "手数料 $15 ドル課金しときましたよ" と Uber からお知らせが来た。なんだよー。まあいいです。うかつ税。

普通にインストールし、普通に動いている。自分は LTS で粘る方針なので前回は 16.04. Unity ではなくなったわけだけれど、特に良くなってはいない。各種の細かい annoying な部分は治っていない。特に悪くなってもおらず、それ以上は期待してないのでいいんだけれど・・・。

最近 Apple が Macbook のキーボードの不出来を認めたので、次の Macbook は安心して買えるものになるかもしれない。一方で MacOS の Unix-like usage は年々締め付けが厳しくなっているし、自分は Mac 無しで生活する妥協策をだいたい確立したし、Macbook は高いし、お金は節約したいし、ほんとうに買い換えるガッツが湧くのかは未知数。

まあ Laptop 投資に気が乗らない最大の理由は対して使っていないからで、Blog や日記を書くのと Podcast の準備くらいにしか使ってない。あとたまにコード読むとか。もっとばりばりとコード書いたりしていたら違うんだろうけれども。更にコード書くなら別に Linux でもいいんじゃね、という話はある。

自分の仕事日記を見るとどうも色々気が散っている。気が散る原因は色々だけれど、バックグラウンドノイズとしてインターネットよくないな、という定期的な結論に。しかし細かいスキマ時間にやる比較的生産的な代替活動を前もってよく考えておかないと負けてしまう。なにするか。

• Bug tracker からの通知を消化する。たぶんこれがやる「べき」ことである、が、まったく楽しくないというか若干苦痛なので隙間に挟みたくない。やると決めてもやらないだろう。なのでパス。Bug の通知はまとめて読む。
• 自分のアプリのコードを読む。これもやるべきだが・・・。やはりいまいち気が乗らないなあ。アプリというのはランダムによむには退屈すぎるのだよな。目的を持って読むならいいのだが・・・
  • TODO(morrita): を検索してプチプチ潰していく、とかはいいかもしれないが、そうすると Android Studio を２つ起動せねばならず不安定になりそうな気もする。が、どうだろうか・・・。
• コードのかわりにコードレビューの通知（自分宛以外)を読む。バグよりはこっちの方がまだやる気になるかもしんないね。これも通知がメールベースで自分はメールを憎んでいるという欠点はあるけれども・・・。
• 細かいツールとかのコードを書く。これは一見よさそうだが、経験上あまりよくない。なぜならその脇道コードに気を取られすぎて本題に戻りにくくなるから。コンテクストスイッチのコストがあるとも言える。コンテクストを必要とせずある程度ダラーっとできるものがよい。
  • ツールを作るのに必要そうな社内ドキュメントを読む。まあ、それは、ありかもな。本題のツール開発が進まないとすぐやることなくなりそうだけど。
• Systrace を睨む。これも集中力いるのでパス。
• Platform のコードを読む。これはアプリのコードよりはやる気になるな。
• 購読している社内メーリングリストを眺める。これはインターネッツと変わらない。ボツ。

まとめると...

• TODO(morrita) 検索してプチプチを試す。
• Ongoing なコードレビューの通知およびコード自体を読む。
• Platform のコードを読む

といったところか。

面識のある東京の同僚氏が問題ジェンダー発言をしたどっかの若者プログラマを指して「やめちまえ」的なことを tweet しておりり、はーという気持ちになり reply しようともおもったが Twitter で議論してもいいこと無いと思いとどまり、メールしようかとも思ったがそれもなんか違うなと思いとどまり、郷に入りては郷に従い見解を tweet してみた

• Hajime Morita on Twitter: "日本語圏のジェンダー問題に攻撃的な発言をされている米国資本企業勤務の皆さんは、自分たちが雇用を通じて得た教育その他のリテラシー資産を自覚した上でドメな世界に生きる若者の立場を想像し、そうした人々が耳を貸すような語りを工夫する方が有意義なのではないでしょうか。エンパシーを大切に。"
• Hajime Morita on Twitter: "米資会社員が問題の女性蔑視スライドにどう反応するかというと、序盤からヤバすぎて頭の中でアラームが鳴りまくり脈拍があがって辛くなり通読できずそっ閉じ。そのくらい表層的なレベルではっきりやばい。と判断するよう訓練されてるので脊髄反射で罵詈雑言ししまう気持ちはわかなくもないけどね・・・"

が、結果としては発言に対する言葉尻を捉えたがっかり反応を目にしてしまい、消耗してよくなかった。インターネットにおけるがっかり反応への耐性が年々さがっている身に Twitter は過酷すぎる。字数制限のせいでがっかりされない配慮を織り込めず、システムにがっかり反応を強制されるから。

そして字数制限に限らず Twitter は人を troll にしてよくないね。件の東京同僚氏もあって話せば普通に良い人なのだが、Twitter 上では感じの悪い外資ヤクザみたいになっている。自分の二つ目の tweet にしても本題とは関係ないのでなくてよかったはずだが、歓心の引力に負けつい感じの悪い外資トロル芸を発揮してしまった。そして案の定アンチトロル反応がおきた。自分にいたってはもはや外資ですらなく豊田市で働くトヨタ社員みたいなガチドメ勢だというのに・・・。

結局自分としては東京同僚氏に感じの悪さにともなうコミュニケーションの失敗をリマンドしたかったわけなので、メールをしておくくらいがよかったのだろう。他人の目のあるところで意味のある議論ができるはずがないとわかっていたはずなのに attention addiction に負けた。

中毒予防という意味では日本語のインターネットを見るのがよくなかった。Podcast を発端になし崩しで日本語インターネットを摂取してしまっていたけれど、また detach して暮らします。はい。Twitter もやりたくないけど Podcast のアナウンスがなー・・・。Buffer でも使うか。

今は主に性能改善の仕事をしていて、代表的なメトリクスについて性能改善をしたり regression を直したりしている。が、ある種の退屈さがある。たぶん自分の実力不足のせいなので文句は言えないのだが。

自分はやっている性能改善は、たとえばアプリの起動のような一瞬で終わるべきものがちゃんと一瞬で終わるようにする、という種類のものである。どうにもならないくらい遅いものをガツンと速くするような仕事ではない。

アプリ開発だと、こういう「すでにまあまあ速いものを速く保つ/更にもう少しだけ速くする」仕事は、割と打ち手が決まっている。投機的になんかする。逆に不要な処理(特に初期化)を lazy にする。クリティカルパスを見つけて不必要なものを別スレッドに追い出す（並列化する）。ラクするためにさぼっていた部分を汚く速くする (例: Layout XML の inflate をやめて Java にハードコードする, 無意味な future chain をまっすぐなコードに直す)。キャッシュする。要するに Systrace を睨んでブロックを移動したり、さぼりででかいブロックを縮めたり。なんというか、割と定型的。そしてガツンとは速くならない。

もちろん他人よりツールに精通することで遅さへの視力を高めることはできるのだけれど、視力を高めても細かいところが見えるようになるだけなので、より細々した高速化ができるようなりはすれどガツンとはしない。たとえば自分は Systrace やプロファイラ, dumpsys などは詳しい方だと思うしベンチマークの流し方もまあまあわかってる。それはそれでいいことなんだけど、どうしてもけちくさくなりがちなのだよな。

前のチームでは、人手不足で速度を見る人がいなかった。だからガツンと速くなることがあった。そして自分のブラウザ知識を WebView に転用して傍目には自明でない高速化をすることができた。サーバ側ふくめ end-to-end でさわるのも効いた。今のチームのコードはもともとそれなりに速いし、チーム内で自分しか持っていない知識というのもない。チームの境目を越えて動き回る力もない。だからガツンと速くすることも、自明でない高速化もできない。

アプリに改善の余地がない、という話ではない。たとえばある UI のまわりには以前からちょっとした遅さがあった。それが遅いことは自分ふくめみな知っていたのだが、interaction 仕様の都合であまり速くできなかった。けれどある日 UI を中心にみているプログラマがその遅い UI の挙動自体をちょこっと変えて速くなるプロトタイプを作り、UX のひとと話をしながらぱぱっと iterate して整合性を整え、コードを入れた。結果その機能ははっきりと体感できるほど速くなり、めでたしめでたしとなった。

こういう変更がしたいよなー。自明でない形で目に見えるくらい何かを速くしたい。

ただそのためには、アプリ本体やその依存先のコードに詳しくならないとダメだよなあ。読むだけでなく、書くのにも参加してないときびしい。ある程度 big picture をもち、上からガツンを書き換えて速くするみたいのが必要。速くなった UI にしても速くしたエンジニアは a lead としてコードをレビューしており、デザインをよくわかっていた。たぶんバグもぼちぼち直していた。

そういう意味では高速化ばっかりやっていないで機能開発もやってコードを内面化し、それから速度について振り返るほうがよいのかもしれない。

Platform の中の人としての performance team というのもあって、これはサーバサイドの同種の仕事にけっこう似ている。ブラックボックスである沢山のアプリの相互作用をシステムとして分析/推測し、なんかわからんが遅いとかいう問題の原因を探り当てる仕事。難しい仕事だしクライアントサイド性能改善の専門家として尊敬できる人たちだけれども、自分がやりたいのはこれではないとも思う。

アプリケーション側のプログラマとしてスタックを細部まで理解し、そいつの力を引き出すようなコードを書く。それが速い。パフォーマンスの専門家に頼らず、自分のコードは自分で速くする。そういうのがよい。

が、これは自分の今の仕事とはだいぶズレてるね。いまの自分はパフォーマンスの専門家のしょぼいやつ、というかんじだから。ほんとはもっとたくさんコードを書いて重要なサブシステムを own し、その上でちゃんと速いアプリにする、というのがあるべき姿なのだろう。今の自分からはだいぶ遠い話なあ・・・・。

Sigh.

ウェブの Dogfooding

ウェブ開発では dogfooding の重要性、というか特異性が際立たなくなったと感じていた。ただ今のチームはウェブ開発と違うところが多く、dogfooding を見直した。

ウェブ開発での dogfooding は簡単である。開発中のソフトウェアを配るのに特別な仕組みがいらず、適当にホストした dev.example.com みたいなバージョンにアクセスすればいいし、開発もインクリメンタルでリリースが頻繁なため開発版とはいえそれほど派手に壊れない。使いはじめるバーも、使い続けるバーも低い。

そしてユーザの行動履歴を集めて集計するのが簡単。なので自分で使って良し悪しを判断するよりたとえばベータ版やインクリメンタルなデプロイ, dark launch などを使い実際に撒いて試す方が良い部分が増えていく。エッジケースでのクラッシュでもユーザにちょっと配るだけですぐわかる。逆にテストについても、dogfood とか言う前に自動テストでカバーしといてくれや、という空気がある。

もちろん実際のユーザに配る時点でわかっても手遅れな問題は沢山あるし、自動テストでは捕獲できずデプロイしないと現れないバグも沢山ある。だから dogfood に意味はあるし、やったほうがよい。ただなんというか、騒ぐような特別なものではない感じがする。「ドッグフードしてます！」とか言われても、あっそう、くらいにしか思えなかった。自分は勤務先アカウントでさわる職場のウェブアプリはすべて dogfood 版なはずだが、だからどうという感じもしない。UI が刷新されたとき、たまにオッとなるくらい。

OS の Dogfooding

自分のチームが開発しているのは OS 付属品というか特定電話機付属のアプリで、いちおう Play Store 経由でアップデートできるがそれでも年に数回しかリリースしない。そして下で動いているOSは基本的に年に一回しかリリースしない。フォローアップのマイナーリリースが追加で一回くらいとセキュリティパッチはあるけれど、とにかくリリースが少ない。そして複雑な割に自動テストが手薄。これらせいだけではないけれど、リリースから遠く離れた時期の開発バージョン OS は割と派手に壊れる。

テストがしょぼいのはさておき、リリース頻度が低いのはスマホの OS という性質を考えると割と仕方なく、同情の余地はある。更に OS とアプリ群の interaction はアプリ単体とは桁違いに複雑なので、ちょっとプログラマが自動テストを追加したくらいでは全然カバーできない。

ちょっとではなく沢山自動テストするというアプローチはありうる。たぶん Windows のような歴史のある OS は色々とがんばっていることだろうし、他の OS も成熟の過程で同じ進化を遂げるだろう。でもここはまだ進化の手前というか途中。

そういう世界では dogfooding が未だに特別な意味を持っている。つまり、テストではカバーできない問題を見つけてくれる。そして被験者として dogfood に手を染めるは普通に大変である。よく壊れるから。ウェブとは違うし、単体のアプリとも違う。自分のいるチームが作っているのは単体のアプリだけれど hardware への依存が高い上に resource intensive なので OS の人々と協力して問題にとりくむ機会が多い。

Be Good At Dogfooding

アプリほど気楽に撒けない制限だけが dogfooding の価値を高めているわけでもない。プライバシーやら帯域やらの理由で、ユーザから集められるデータには限りがある。そしてクラッシュみたいなわかりやすい問題のデータは集めることができるけれど、なんか遅いだとか UI がおかしいみたいな相対的に小さいが無視はできない問題のデータを集めるのは不可能ではないにせよ難しい。

Dogfooding はこうした自動で見つけたり集めたりするのが難しい問題をみつけるのに役立つ。Dogfood をしておかしな挙動に気づいた時、開発者はすかさず bugreport 情報をダンプし、あわよくば Systrace もキャプチャしてバグを file する。

これも「ユーザフィードバックの UI つければいいじゃない？」と思うかもしれないけれど、Dogfood ビルドの OS は一般のユーザからは集められない sensitive な情報をたくさん bugreport につっこむし、Systrace に至っては問題を再現しなおさないといけない。そして dogfooder は file した bug を通じて議論に参加し、必要に応じて追加の情報を提供することを期待されている。こういう込み入ったやり取りは、自動化されたエンドユーザからの情報だけでは実現できない。

個人的にはもうちょっとちゃんとデータを集め解析インフラも整備して dogfood への依存を減らした方が良いと思っているけれども、とはいえ dogfood でないと見つからず、直せない問題はあるとも思う。

Dogfooding には上手い下手がある。普段から奥の方のコードをいじって性能バグなどと戦っている人は傾向として dogfood がうまい。つまり、目の前で問題がおきたときにすかさず必要な情報を集めて適切な bug を file できる。練度の低い dogfooder は bugreport をとらずに曖昧な bug を file し、triage の質疑のなかで不完全なデータをもたもたと提供して開発者を疲れされる。もっと質が悪いのは社内 social media 上に文句を書くだけで bug を fileしないひと。おまえはなんのために dogfood してんだ、という気分になる。そんな troll はごく少数だけどね。

組織の VP みたいのがビシっとわかった感じの bug を file してくるとそうした exec への評価は高まる。モバイル OS 部門の higher management が管理職としてどのくらい立派なのかここでの評価を控えるけれども、少なくとも bug の filing ability はみなおしなべて高い。その点はすごく偉いなと思っている。

見方を変えると、制度としての dogfooding にだって出来不出来があると言える。参加者に対する適切な onboarding 教育はあるか。bug reporting を支援するツールは充実しているか。Bug tracker に何かを投稿するというのは、たとえばスマホのバグならモバイルの開発経験がないとプログラマであっても敷居が高いし、まして開発部門の外から参加している人にとっては恐怖さえあるかもしれない。開発者は未熟な dogfooder による bug を appreciate し、親身になって参加を encourage しているだろうか。

など、モバイルでの dogfooding は難しく、しかし得るものもあり、その運用を目の当たりにすると発見がある。先に書いたとおり自分はもともと dogfood をそれほど重視していなかったけれど、考えを改めた。私物の電話機に開発版 OS をインストールした。アプリも手元でビルドして入れた。

そしてインストールの前に二段階認証のバックアップをとりわすれておたおたする火曜日。

論文発表とか聴いても微塵もわからないだろうと思っていたのだが、Tutorial もあるのだね。これは受けてみたいかもしれないなあ。仕事の役にはまったく立たないが・・・。

値段は早期申込で $800. プラス宿代が仮に $200, 4 nights で $800. ヒコーキがこれも仮に $300. 家族で行きたいとかなると $600-$900. プラス食事, 交通費などで $2000 くらいか。妥当な値段なんだろうけど、完全な道楽であることを踏まえるとあまり justifiable でもないなあ。そんだけカネかけるならもっと楽しいとこ行きたいでしょ、という話になるだろうし。まあアカデミアでもないのに学会にいきたがるというアイデアが良くないのだろう。

去年のチュートリアルの資料は・・・と調べるとちょっとだけオンラインにあった。

• CVPR'17 Tutorial on Deep Learning for Objects and Scenes
• Zero-Shot Learning Tutorial | CVPR 2017
• An Introduction to MXNet/Gluon | Towards Next Generation Deep Learning Framework

真面目に会社員プログラマをする活動の一貫として、社内バグトラッカーのうちチームが own するカテゴリのアップデートを購読することにした。新規登録からコメントまで、何らかの更新があるたびにメールベースで通知が来るのを読む。今までは自分が assign されたやつにだけ反応していた。TL, Manager, TPM などはこのバグを実際に triage している。自分は自明なやつは別として特に triage とかには参加せず skim するだけ。

まあ良し悪しだなと思う。良いところとしては、チームというかプロダクト全体の温度感がわかる。どうもやばい変更が platform 側に入って燃えているらしいとか。どうも特定の人の持っている機能がずいぶん立て込んでいるらしいとか。人々が締め切りに殺到してるせいで不安定だとか。プロダクト全体としてどういう類のバグレポートが多く、それはどういう原因を持つ傾向があるとか。人々がどうやって原因を判断しているとか。

自分のやっているアプリはジャンルの性質なのかコードのせいなのかわからないがとにかくクラッシュが多い。しかし傍目には同じクラッシュでも原因は多岐に渡る。そのほか画面に何も表示されないなど、バグの主要な症状は原因のバリエーションに対しごく限られた種類しかない。人々はその原因をどう判断しているのか。

特に platform / HAL レイヤの TL はバグを次々に triage して自分のチームに割り振っているのだが、一体どうやっているのだろう。まあ bugreport ファイルを読んでいるのだろうけれども、自分の製品に限るとそんなに intellient な automation があるようにも見えないので、時間をかけている以外の方法を想像できない。

話がそれたけど、そういう感じでバグトラッカーは製品の weather を伝えてくれる。そういうのを把握するのは be prepared でよい。

その他に、バグの重複に気付けるというのがある。自分に assign されたよくわからんバグ、実は同じ原因のバグが他に file されていてそっちで議論が進んでいた、ということはよくある。そういうときはさっさと mark as dup すれば手持ちのバグが減る。逆に自分の見ているバグに巻き取ることもある。こうした dedup 作業は理想的には triage している人の仕事なわけだが、実際に問題の中身を知っている実務者（自分）の方が正しく判断できることはあるし、強い動機もある。

重複削除だけでなく、自分の知見によって原因を判断できる（場合によっては直せる）バグがあったりもする。そういうのは他人の triage を待たずさっさと引き取る。

とまあいいこともあるのだけれど、欠点もある: とにかく時間がかかる。そして自分にとって大半の updates はノイズなのですごく効率が悪い。これはツールの不出来という面もあるし、非生産的な文化の面もあるし、単にプロセスのまずさという面もあるし、表面的な原因は一緒なのに原因はフルスタックという製品の性質からくる大変さももあるし、tracking 以前に debug 支援の弱さからくる辛さもある。とにかく disentangle して負担を減らす方法がぱっと思いつかない。辛い。

単純に skimming の雑さを増すことで一定程度は速くできるけれども、今度は取りこぼしが増えて結局単位時間あたりの効率は変わらないようにも思える。いっそ triage に参加して使った時間の元をとろうともしてみたが、今度はかかる時間が倍増しすぎマジで仕事ができなくなってしまい早々に諦めた。

ツール志向な身としてはメールベースはきつすぎるので Jasper みたいのがあればなあと思うわけだが、トラッカーが内製なせいでこういう素敵ツールが現れる見込みは極めて薄い。ただでさえ内製ならではのできの悪さがあるというのに・・・。

この手の notification stream を消化する作業は直接の成果には繋がらないからやりたくないし、特に楽しくもない。自分の従来のポリシーにも合わない。ただ会社員としての成果を出すという今のフェーズでは必要かもしれないと試しにやっている。たしかに発見はある。しかし辛い。マネージャとか TPM とかよく burn out しないなと感心する。続けるべきか否かと悩みつつ、今のところまだやっている。消耗のダメージを最小化するため、午前中の生産的な時間には読まないことにしている。まあ決意しないと読めないのでうっかり時間をつかってしまう類のものではないのだが。

と書き出すと何か思いつくかとおもったけど、残念ながらそうでもかった・・・。しいていえばバグトラッカーは consumer product としてエンジニア資源を突っ込んで作らないと非効率すぎて辛い、くらいろうか。GitHub 使わせろとはいわないけれどせめて Jira とかだったらよかった人生だった・・・。

Jasper みたいな素敵 UI をつくるのはムリだけど、たとえば一定の期間内に発生したイベントを縦に連結した HTML に render するバッチスクリプトくらいなら隙をみて作れないかなあ。

追記

Dogfooding の本格化や新しいデバイスの dogfood 投入などに伴い流量が増えてついていけなくなり、一ヶ月くらいで挫折した。

So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love: Cal Newport: 8601420220263: Amazon.com: Books

Kzys が読んでいるのを見て興味を持った。Audiobook だと 6 時間半の薄い本。

基本的にはモダン根性論のバリエーションで、自分の好きなことをやるといっても実力 すなわち "Career Capital" がないと成功しないからまずは努力して実力アップに励もうな、という話。典型的なモダン根性論との違いは capital を構築した上でそれをどう invest するかにも重きを置いているところ。根性論者はつい努力してればいつかうまくいく、という話になりがちなので、努力の成果をどうやってやりがいのある仕事に繋げていくかを議論しているのは面白い。

というか、このひとそもそも読者の entrepreneurship を全然疑ってないのよだね。「おまえら cubicle に縛られた社畜なんてイヤだから会社やめて独立したいと思ってるだろ？ちょっと待て、今それをやると失敗するからまずは修行だ。しばらく修行したあとにどうやって自由の扉を開ければいいか教えてやんよ」みたいな論調。じっさい著者は高校生だった dot-com 時代に web design の会社を作って小遣い稼ぎをしていたという。そこから MIT で CS の博士取ってるんだから、勢いのある人なのですね。

自分もおおむねモダン根性論者なので基本的な主張に異論はないが、一方で entrepreneurship は全然ないのでいまいち対象読者じゃない感はあった。たぶん期待されている感想は career capital 稼がねば、だと思うのだが、自分はどちらかというと career capital の investment についてもうちょっと考えればよかったな・・・と反省した。

プログラマたるもの career capital をどう積み増すかについては普段から考えているわけだけれども、使い方は、自分はそんなに深く考えてなかったね。そしてチマチマ貯めこむことばかり考えていたせいでガツっと増やす機会を逸したとも思う。結果だけ見ると、自分が二十代に溜め込んだ career capital でやったことといえば大企業への転職なわけで、そこにまったく entrepreneurship はない。そして大企業勤めの最初の数年で貯めこんだ career capital の使いみちは本社への転勤に使った。これらの選択をしたときはそれなりに冒険したつもりだったけれども、振り返ってみると国債買うようなもんだよな。もうちょっと他になかったのかね・・・。などと career capital について思いを馳せたりした。まあ大企業そこそこいいとこだし自分は臆病者なんでファンタジーですが。

日本語のコミュニティだと「やっていき」とかいってる人々からはこういう肝っ玉を感じ、割と尊敬している。

それはさておき、気に入らないところも多かった。

著者は "Passion Hypothethis" すなわち follow your passion then everything follows みたいな考え方はダメだと主張し、典型的には blog で micro-celebrity になって食ってく、みたいなのを強く批判している。自分も microcelebrity は普通にダメだと思うが、一方でそういう人生ドロップアウト路線に入りそうな人が MIT の Ph.D からストレートで full-time の academia に進むエリートの権化みたいな人の努力信奉に耳を貸すだろうか。人生ドロップアウトしたくなってしまう人というのは努力して報われると信じにくい立場にいることが多いわけで、本書のメッセージは人生行き詰まって博打で一発逆転に走ったりコミュニストに転向しかかってるひとに向かって資本家が「金を稼ぐといいよ」といってるようなもの。相当感じ悪い。自分だったらうっせー黙ってろ、と思って投げ捨てるね。本気でそういう人を説得したいなら他の語り方があると思う。

あとは "Knowledge Worker は努力しない" という話を繰り返すのだが、別に肉体労働者もサービス労働従事者も努力してないよ！というか knowledge worker は普通に雇用されているいわゆる労働者の中では努力してる方じゃね？著者がと実際に比較しているのはスポーツやエンタメ産業など競争が激しく半自営業的な振る舞いを求められる仕事をしている人々と雇用され給与で生きてる労働者であって、要するにボンヤリ労働者やってると搾取されるから頑張って自由な資本家というか career capitalist を目指そうな、という話じゃん。White collar とかいっておけばまだ角が立たなかったのに、オレ定義で knowledge worker とか言ってると Drucker に祟られるぞ。

あと職業的成功で行き着く先のイメージが若干 Soft Skills の人みたいで夢がないというか、いまいち憧れが刺激されない。著者はせっかくエリートなんだからもうちょっと高尚なビジョンみたいのがあってもよくね？全体的な意識の高さに反した motive の selfishness がやや白ける。これは趣味の問題かもしれないし、素直で良いという見方もあるとは思うけれど。個人的にはモダン根性論にはそういうキラキラ成分を求めているのであった。

著者はモデルケースとして色々な人々にインタビューし、それを語りに取り入れている。(Amazon のレビューにはこれを emulating Malcolm Gladwell と評しているものがあり、わからんでもない。) ただこうした語りの常として我田引水感が強い。

特にひどかったのが冒頭と結末に登場するアンチ・モデルケースのエピソード。就職した銀行員の仕事に早々に嫌気がさしアジアに飛んで職を転々としたある若者は放浪の果て仏道に入り、座禅や公案などの修行を重ねる。あるとき数ヶ月がかりの難しい公案を乗り越えたあと、若者は気づく。環境が変わっても自分は変わらないのだと。彼は林の中で泣く。そしてしばらくのち仏道を去って元の銀行員に復帰し、ハードワークを重ね出世し世界を飛び回るのだった・・・・

・・・という話なんだけど、著者はこのエピソードを「ほら経験なしに世界に飛び出してもいいことないでしょ、でもキチッと働いて成果を出せば世界を飛び回るような仕事ができるようになるよ。だから Career Capital 貯めてこうな」と解釈している。でもさ・・・普通に考えてこれ仏教のおかげで小さな悟りを開き煩悩をすてたからキャリアに集中できたって話じゃね？むしろ放浪の成果じゃね? ほんとにキリスト教圏の住人は他の宗教への敬意がなくてひどい。だからお前ら戦争ばっかしてんだよまったく・・・と呆れた。

などと writing や storytelling の浅はかさにはケチをつけたくなる面もあるけれど、全体として著者の切迫感は伝わってきた。著者が批判する lifestyle guru / microcelebrity をふくむ多くの自己啓発本著者は、自己啓発自体を生業にしている故の胡散臭さ、信頼できなさを拭い切れない。著者の Cal Newport はたぶん本当にアカデミアとして成功したいと思っており、この本もそのための "quest" なのだと言っている。だから浅はかさはあれ嘘くささは無い。

一歩下がってみると、全編を通じ自身が lifestyle guru に堕ちる誘惑と闘いながらアカデミアとしてのキャリア的成功に obsess する様が伝わってくる。そこには憎めなさがある。続編の Deep Work は書き手としての成熟を感じ、それはそれでよい。というかんじで Cal Newport への理解を深めました。

The Manager's Path - O'Reilly Media

テック企業におけるマネージメントというかマネージャ業の薄い本。たまにはこういうのも読んどくかなということで。

マネージャ何してくれる人なの、という一章, mentoring, TL, managing people (Engineering Manager), Managing Teams (Director) と続き、最終的に CTO にまでたどり着くという壮大なストーリー。後半は完全に他人事すぎて目が滑ってしまった。ただ本業にならない限り tech 企業 management の本はもう読まなくていいかなと思う程度には漏れなく広く浅い構成だった。

よくかけていた。まず自分の勤務先のようなテック企業の実態をきちんと反映している。Generic な management の本ではなく、ほんとに software company で tech side の management をする人向け。話の前提に身に覚えがあり、したがって説得力もある。

全体的にすごく常識的で、ぶっとんだところがない。やたらと組織を変えろ！とか熱り立った主張はせず、立場に応じてできること、すべきことが説明されている。たとえば engineering manager とかには大した権力がないわけで、そういう実態を反映している。あとは management ladder に行く前に tech をそれなりマスターしておかないと厳しいよ、などともいう。そうでしょうな。

個人的に関係ありうるのは TL の話くらいまで(TL 業はしないけど、下っ端とはいえ年をとると一定程度 leading 色のあることをしないといけない)。Engineering Manager の話は上司のやってることを知る、という意味では良い。

先日読んだ Crucial Conversation にしろ、マネージャ大変だなと思いました。

後半は Director とか VP の話に進むわけだけれど、これちゃんとできるひといるんかな・・・というか、そのレイヤは経験的にぱっとしない人が多い印象を持っているが、書かれている仕事の大変さを考えるとそれも仕方ないなと思った。

やはりエライ人がすごい権力を発揮しなくても下々がよろしく働いて前にすすめる組織の方がいいよなあ。エライ人がぱっとしないのは、なんというか仕方ない・・・。

Director/VP でそれなりにうまくいっているパターンとしては、もともとスタートアップの社長でしたとか、競合/同業で TL だったけど色々あって移ってきました、という人たち。あとはチームがでかくなるにつれて上にずり上がっていった人も、そこそこちゃんとしている。一方で会社の中の関係ないところから異動してきたパターンにはあまりよい印象がない。

チームのプロパーが出世した場合、組織やコードベースの内情に通じている強さがある。競合やスタートアップから来た人は、チームが持っていない（が必要としている）何かを持っている。しかし会社の中から滑ってきた人には特に何もない、気がする。なにかある場合もあるんだろうけれども・・・。

まあ下っ端の戯言なんでエライ人はばかめ・・・とか思いつつそっとしておいてください。

Learned Optimism, Mindset, Grit, Outliers, Deep Work などに示されるストイックかつ自己決定的な自己啓発の世界観を、自分はモダン根性論と呼んでいる。そしてまあまあ影響を受けている。

モダン根性論とは、成功するには才能よりも時間や労力をかけて全力でがんばり続けるのが大事なんだよ、という根性論的価値観がまずベースにあり、その上でがんばり続けるとはどういうことか、その難しさ、がんばり方、頑張りを支える考え方、頑張りを成果につなげる戦略などを色々と理論武装していく一派である。

自分はかつて、根性の有無について考えるのはよくないと思っていた。「根性の無さ」というのを才能のように捉えることで、自分の才能の無さを言い訳にしてしまいそうだったから。でもこの態度は良くなかったと今は思っている。これは結果として根性全体から目をそらし、方法論としての根性というものを見出す機会を逸しているから。

さらにこの態度は、ある種の才能主義を自分の無意識に植え付けてしまう。努力以外でなんとかなる、たとえば要領の良さみたいなものがあるという考え方は、はっきりとそう言わないだけで才能のようなものを想定しているからね。

要領というものはある。けれど大前提として努力は必要。モダン努力家はそれを努力とは呼ばないかもしれないけれど、沢山の時間や労力をつっこんではじめて要領を議論できる。元本なしに利息を考えても意味がないのと同じで。

という見方をすると sustainable かつ efficient な根性の運用方法、すなわち「方法論としての根性」について議論するのがモダン根性論とも言える。

自分は根性の playground である大学受験をスキップしてしまったせいで、根性について理解を深める機会を逸した。というと言い訳がましく、まさに自分の根性の無さへの恐れから大学受験をスキップしたのだと思う。当時は特にそう考えてはいなかったと思うけれど。

けれどあるとき仕事のやる気がない時期の現実逃避で割と熱心に英語を勉強したらそこそこできるようになったので、ああ時間と労力を割くと効果あるなと思い直し、そのあと冒頭にある本たちを読んだ際に convince されたのだった。

情報産業で成果を挙げたいなら素朴な根性、すなわち長い期間取り組むだけだといまいちだな、と思う。時間が全てを解決してくれるとは思えない。たとえば自分が今から余暇の全てをなげうって機械学習を勉強し、十年後に現段階の state of the art を完全に理解できたとする。自分は <AI 人材> になれるだろうか。あまりそういう気がしない。

なぜかというと、10年の間に世の中が前に進み、変化してしまうから。時の流れでうつろいゆくのは情報産業だけではない。とはいえ変化の速さは情報産業の特長の一つであるとも思う。なので時間をかければよいというものでもない気がしている。

自分に何が足りてないかといえば、まず絶対的な時間の不足はある。そして intensity も足りてないなと思う。単位時間あたりのがんばり不足。世の中のエリートを見ると、つっこんでる時間も多いけど密度も高い。モダン根性論のジャーゴンではこれを Delibrate Pratice と呼ぶ。エリートたちの Delibarate Practice への耐性は、人生のどこかの段階（大学受験、修士および博士過程など）での訓練を通じて身につけたものに見える。

情報産業の中で前の方に居続けたいと思うなら、時間をつっこむだけでなく密度も必要。自分はどちらも足りていない。ただまあ、今や世界の富が流れこむ競争の激しい世界なので仕方ないとも思う。The stake is high すぎというか...

十分な密度を持たない場合の選択肢として「前の方にいる」ことを諦める方法がある。今やそんなに流行ってもいないけれど、廃れてもいないテクノロジというのは沢山ある。そういうものの一つに詳しくなる。そのテクノロジが愛せるなら悪い選択肢ではない。典型的には、若かりし日に流行っていたテクノロジの第一人者になり、旬を過ぎた後も見捨てず第一人者であり続けるというスタイル。この道を選ぶ人はけっこういて、それなりに成果を出している。それはそれでいいとおもう。

自分がこの道を選ぶ気になれないのは、ひとつには愛せると思っていたテクノロジが目の前で失われる様を見たからだと思う。あとは特定のテクノロジよりソフトウェア産業のダイナミズムや時代性、軽薄さみたいなものに興味があるのかもしれない。

あるいは色々言い訳しているけれど、単にぜんぜん根性ないだけかもね。

追記

Grid に関するいくつかの反論:

• The Problem With Grit - Learning Deeply - Education Week
• MacArthur 'Genius' Angela Duckworth Responds To A New Critique Of Grit : NPR Ed : NPR

しかし自分は、根拠が薄いのに「科学的」と特定のアジェンダに熱狂突撃していくモダン根性論のアメリカ人ぽさが好きなのであった。

ここ 10 年くらい年末に annual review 的なものを書いている。そうした記録や blog などを読むと、昔の自分は随分と心を病んでいる、というと大げさだけれども精神衛生はあまり優れていなかったなと思う。昔の日記も探すとどこかにあるはずだが、それに至っては怖くて読めない。

人生に思い悩むのは若さの特権と言えなくもないけれど、鬱っぽいと日常の生産性をすごく下げてしまうので程々にしたほうが良い。グジグジしている時間というのは何も前には進んでいないし、そうした気分からの現実逃避にマンガ読んだりしててもやはり前には進まないので、自分のしょぼさを、例えば他人と比べて失望したり絶望したりで消耗しているのはよくない。持てる駒の範囲でベストを尽くしていると信じ、できる範囲で前に進むほうが良い。他人の姿がくっきり見えるこの時代に、それは未だにしばしば難しいことだが。

という心境に至れたのは、ひとつはやはり運動による脳内麻薬の力であり、これがないと再び depression になってしまう危険は若干感じている。なので運動の確保は自分の中ですごいプライオリティが高い。あとは結婚して転勤して子供ができて本来の自分のリスク予算をだいぶぶっちぎってしまっているため、開き直りの境地に達した面もある。思い悩む余裕すらないというか・・・。

40才を口実にダラダラ書くシリーズ。

自分のボンクラさがさすがに無視できなくなった。過去を振り返ると、自分が中心になって成功したプロジェクトはない。いちおう納品した、みたいなやつはあるので完全に失敗だけとはいわないけれど、成功はない。受託開発していた頃はどれもプロジェクトの存在がダメだな、と言い訳していたものだが、HTML Imports を機にやはりこれらの失敗は自分のボンクラさなのだと納得した。

結局のところ何事にも成功のための障害はあるわけで、それらをなんとかして克服するのが実力なわけじゃん。HTML Imports の難しさは初期デザインの不味さだったわけだが、自分はそれをひっくり返してまともなものにできる立場にいた。というかそれが暗に求められている仕事だった。しかしできなかった。いまいちな初期デザインのまま仕様を書いて、なんとか実装して、出荷して、誰にも使われないまま数年後に消えるゴミとなった。どんなデザインなら良かったのかは未だにわからないが、きっといつか誰かが正解にたどり着いて答えを見せてくれるだろう。

ボンクラさに納得した後、この意見を変えるに至る証拠を生み出すには至っていない。

どうしたらボンクラでなくなるのだろう。失敗したものを成功まで持っていくのが答えなのかもしれないし、派手に失敗しないようにする手管が必要なのかもしれない。自分は仮説を持っているが、その仮説は自分にとって特段 helpful なものではないので今ここには書かない。

最近無事 40 歳になった。

節目の年齢を記念して色々キャリアについて振り返ったりする人もいるけれど、自分はキャリアについては普段から思い悩んでいる時間が長いのでそれほど書くこともない。感想としては 1) 昔の自分の期待とは良くも悪くも違う状態になった。合計すると少し良い側に振れているとは思う。 2) 自分の節目節目での判断は、良いものも悪いものもあった。というか原則から見ると悪いものの方が少し多かったと思うが、運の良さに救われた。3) 自分のボンクラさを受け入れるに至った。というところだろうか。

まあそれでもなんか書くかな。一箇所に長々と書くと永遠にドラフトのままになりそうなので、ぼちぼち小出しで書いていきます。

Xen and the art of virtualization

なかなか良い論文だった。が、世間的には Xen は下火らしい。Hypervisor は CPU 側の支援も含めもうちょっと詳しくなりたいけれど、何読めばいいのかよくわからんな。新しい Linux の本でも読むと出てくるのかね。

Crucial Conversations Tools for Talking When Stakes Are High, Second Edition: Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler: 8580001040288: Amazon.com: Books

Audible できいた。難しいが重要な会話 = Crucial Conversation をちゃんとするにはどうするか、という本。自分はなんとなく交渉事が苦手な気がしていたので、何かの足しになればと思って読んだ。なんとなく tactic というか selfish なかんじで強引に話を片付けるみたいなものかと思っていたら、ずっと principled でまともな内容だった。

自分や相手がムカついた気分だったり過剰に警戒していたり感情的になっていたりすると難しい話はできないので、相手もまともな人間であるという前提で敬意を持って接し、自分の主張を開示しつつ相手の主張や意向を丁寧に汲み取り、合意できる部分を強調しつつ互いの着地点を探っていこうな、というような話。

こう書くとすごい精神論ぽいけれど実際にはそのためのステップが色々議論されている。ただステップを教えてくれるからといってうまくできる気がするかというとそんなことはまったくなく、文中に登場する沢山の胃が痛くなるような舞台設定や会話例にこりゃ難しいわ・・・という気持ちになる。

最初のステップとしては、会話の中で自分が感情的になる瞬間が crucial conversation の始まりなので、それを正しく検知して crucial mode に入る、というくらいはできるようになりたい気がした。

仕事よりは夫婦の会話の方が出番は多そう。今の仕事、よく考えるとそんなに crucial moment は無い気がする。マネージャとかだと出番も多そうだが。夫婦の会話、別にしょっちゅう crucial moment があるというわけではないけれど、自分たちは夫婦関係の stability に高い優先度をおいているので、こういうのは大事。

ふと翻訳あんのかなと Amazon.co.jp をみたらあるにはあるが全然読まれてなさげ。なぞ。

ジコケーハツ本を読んでばかりのダメな人になって久しい。役に立たないんでしょ、とかまあそういう話はそっとしといてもらうとして、次に読む本を探しながら思うことがある。

ジコケーハツに求めるものとして、目先の生産性を良くしたい人と人生や仕事をマクロに良くしたい人がいると思う。「人がいる」というとよりは、その時々でどちら側を求めているかが違う。自分はいま仕事の進捗がぱっとせずクビ/減俸に近づいてしまったため目先の生産性をよくしたい。長期的にどんな仕事をしたいとか何を成し遂げたいとかいうのは、今はどうでもよい。それよりも、今の自分の責任範囲でやらないといけない仕事をいかにさっさと片付けるかが重要。

世の中のジコケーハツ本は個々が混ざっていて良くないと思う。もちろん最終的なゴールというものをちゃんとしないと目先をどうこうしても意味ないのは事実ではあるが、一方で最終的なゴールというのはそう頻繁にいじるものでもない一方で目先の生産性というのは試行錯誤で切り開くものだから、頻度としては目先のことを気にした方がよい。世間のジコケーハツは、目先のミクロな話から段々でかい話になっていきがち。その後半はいらないんだよ！

もっというと世の中の自己啓発はマクロな話をするやつの方が人気がある気がする。まあ人生ドカっとよくしたいという気持ちはわかるが、そういうのっていまいち actionable でないことも多い。Actionable でない話でいい気分になっておわりというのは、まさにジコケーハツがバカにされる理由なわけで、それよか目先の仕事がんばろうぜ、という気分。

いや、大局的な話を読んで先のことを考えるのは意味はあると思うし、自分もそういうのを読みたい気分のときもあるのだが、目先の話を探しているときその手の本はノイズである。ミクロなジコケーハツとマクロなジコケーハツは別ジャンルにしてほしい。

・・・とか書いてて割ながらバカっぽい話してんなと思う。そんなもんです。

自分を勤務先にリファーしてくれた東京の同僚が辞めて景気のいいスタートアップに行くという。その人はもう 10 年以上勤めている古株で、いかにもすぐいなくなりそうなタイプなその人を長く引き止められているところに勤務先の力を感じていたが、それも終わった。

彼のような実力者が移る気になる会社がちゃんとあるという事実を含めこれはいい話なのだが、取り残されたようで寂しい気持にもなる。

最近の自分はカネのために働いていると思う。Financial Freedom がない以上ずっとカネのために働いていた面はあるわけだけれども、それでも一時期、カネは最重要でなかった。でもいまなぜこの勤務先で働いているかと聞かれたらカネのためだと答えるだろう。

カネのため「だけ」に働いているわけではない。仕事で手伝っている製品は割と好きだし、仕事には楽しい面もある。でも資産が二倍・・・だとちょっと厳しいかもだけど三倍くらいあったら違うことをしている気もする。けれど自分はカネを稼ぐための手段を多く持っていない。もっというとやりたいことをやって稼ぐ選択肢はない。今の収入からしてほとんど運みたいなもので再現性を感じないし。まあ三倍はいらないな資産。二倍でいい。別にリタイアしたいわけではないから。

この事実は受け入れているけれど、それでも稼ぐ能力のある人が謳歌する自由を目の当たりにすると眩しくて伏目がちになってしまう。だからどうって話じゃないので、まあこのくらいの愚痴は許してよな。

"Pytorch" とかで Twitter を検索すると、様々な人々がいろいろ遊んでいる様子がわかる。別に ML 大学生や研究者ばかりでなく、普通にたとえば React Native をさわるようなノリで遊んでいる。

自分も Hello World よりもう少し先のことをしてみたいけれど、今の生活にはそんな隙間がない。きびしい。仕事と家の時間を引くと、あとは Podcast の準備と後始末ですべてが終わっている。

Misreading Chat の、毎週一本なにかを読むという縛りはけっこう大変。実際には周辺の論文も読まないとわからないことが多いし、編集にもまあまあ時間がかかる。そしてもう少し深掘りしたいとおもっても次週の準備に追われ踏み込めない。

こうしたフラストレーションから、やはり衝動で podcast  をはじめたのは失敗だったかと思うこともある。一方でそもそもたとえば PyTorch さわりたいなという気になったのも Autdiff 論文のついでにコードを読んだからだし、時間があったところで自分が有意義に使ったとも限らない。締め切りの力で毎週なにか読めている事実はあり、そのバランスの sweet spot はまだはっきりしない。仕事を真面目にやるという縛りの影響もあるし。

いずれにせよやりたいことができない事実はあるわけで、そのフラストレーションは精神衛生を損ねない程度に感じておくのが健全なのだろう。

20% プロジェクトというアイデアは、様々な人が様々な持論を支持する論拠に使われている。ただその理解が自分とはだいぶ違うように感じるのでここに個人的な見立てを書いてみる。

勤務先における 20% プロジェクトの由来については諸説あり、様々な corporate folklore を形成している（つまり決定的な証拠はない）。自分が好きなバージョンはこんなものだ: ある日、エンジニア部門のトップから社員たちにメールが届いた。「みな色々なプロジェクトに首を突っ込んで楽しくやってるみたいだけれど、本題のプロジェクトが進まないのは困るから他のとこに首をつっこむのは 20% <まで> にしといてね」

このバージョンは、自分が勤務先に対して抱いている文化感を反映している。つまり、

• 良いプログラマは制度や仕事がどうであれ隙をみて面白いことをやろうとする。
• マネージメントは雑で、細かいことは言わない。

こういう価値観というのは、良しにつけ悪しきにつけ色々と consequence がある。たとえば Disagree and Commit みたいのと（必ずしも矛盾はしないにせよ）相性が悪そうなのがわかると思う。

この視点でみると、マネジメントが 20% 制度を推奨するだとか 20% の成果も人事考課に組み込まれるなんていう主張は的外れに感じてしまう。もちろんタチの悪いマネージャの下についてしまった人が「権利としての 20%」を勝ち取るために制度が応援してあげるのはいいとおもうけれど、そもそもコソコソ勝手に何かするヒマがないほどキチキチに管理されている時点で cultural norm からは外れている・・・と思う。

つまりゆるくて雑でボトムアップなのが勤務先の良さだと思うのだよね。そこに 20% というラベルを付けて hiring のだしにするのはよいとおもうけれども、 それを 20% project という「制度のおかげで」なにか面白いことが起こると解釈されるとソワソワしてしまう。制度に頼るようになったらおわりだわ。

こうした文化や価値観は、会社や製品が巨大化するにつれその効力を失い、むしろ組織の足を引っ張ることすらある。それはよくないことで、正されるべきなのだろうか。わからない。似たような好き勝手文化を持つ DEC は滅び、正した IBM は生き延びた。でもこんなのは anec-data に過ぎない。

組織が成熟するなか, 文化的シンボルとしての 20% が制度としての 20% に姿を変えることはあるのだろうか。自分はそれを全く望んでいないけれども、他のオプションがよりマシとも限らないし、どうかね。

続きを書いた。

定期的にマルチスレッド辛いという話を書いている気がする(前回)が、またそういう話です。

仕事のアプリはかなりマルチスレッドで、そのせいでしばしばスレッドまわりのバグがおこる。アプリケーションの性質上 compute intensive な部分や I/O (Binder) bound な部分がくまなくあるため、マルチスレッドを頑張っている事実はよい。しかしデザインが厳しい。

アプリは UI まわり以外はだいたいどこかの worker でコードが動く。そして UI 以外のコードは沢山ある。そうしたコード、というかクラスは thread-safe に書かれている。

でも thread-safe なコードを書くって大変じゃん？それよりは thread-safety というか concurrent access は一部の shared state 管理クラスにまかせ、あとは並列アクセスが発生しないように messaging based で作るほうがいいべ・・・。世の中サーバ側は割とそういう風になっている気がするのだが、クライアントサイドはなぜそうならないのだろうね。

前のプロジェクトは、所属するスレッドをあわらす context オブジェクトみたいのを持ち回るアーキテクチャを強いることでコードの実行スレッドを制限していた。Scala  だったら implicit parameter でやるようなことを手でやる雰囲気。これは機能していたが、一方でコードの古さから制限の仕方の筋が悪く、生産性は低かった。

オブジェクトの所属するスレッドを決める (広い意味で) actor 的なアプローチとは別に、Rx とかは状態をなるべく immutable にすることで thread-safety を実現している。これはこれでよい。アプリだとすべての状態を immutable にするのは現実的でない (Flux とかの連中はほっとくとしましょう) ので、Rx と actor をいい感じで使い分けて thread-safe なデザインを生み出してほしいものであることよ。

まあ世の中の大半のアプリのように background に追い出したいのが File I/O と Network プラスアルファくらいなら actor 的な部分はほとんど必要なく, Rx だけでよい。仕事のアプリはもうちょっと色々あるせいで話が単純でないから現状に至った結論を責める気はない。が、辛いことに代わりはない。

今のプロジェクトと前のプロジェクトに共通する問題。本来 thread-sanity をまあまあ実現できるデザインの意図があったことを読み取れる一方、その本来の意図が守られていない。architectural violation が発生しまくっている。そのせいで (たとえば thread context の持ち回りなど) 強制的な制限が残る一方で (immutability など) すり抜けやすい soft-constraint はすり抜けられ、バグがおこる。

これを architecture を守らないコードを書くやつが悪い、というのは簡単だけど、コードを書く側が守る気になれないようなデザインが悪いという方が自分の感覚に近い。デザインを決めた人 (TL とか) と下々のエンジニアの間に大きな実力差があり、かつ TL が micro-managing で下々が大人しい独裁的プロジェクトでは多少理不尽でも architectural constraint / contract を守り抜くことはできるけれど、もうちょっと下々がまともだと押し付けは成立しない。なので従うことにありがたみが感じられるようなデザインでないと生き残れない。そしてそういうデザインは、経験的には稀である。

のでかっこいいデザインを考えたい人は下々の気持ちになってがんばってちょ、と思うのだった。

隣のチームにいるフランス人のおっさん M と会話をすると英語が(比較的)うまく話せる。一方で同僚のアメリカ人 P 相手だとはかどらない。あるとき理由に気づいた。M は喋る速度が遅い。一方 P は速い。そして自分は話す速度が相手に引きづられる。つまり M と話すときはゆっくりはなせるのだが P 相手だと早口になる。しかし P のような早口で話せるほど脳も舌もスループットがないのでしどろもどろになる。うーむ。どうすれば相手に引きづられず速度を低く保てるのだろうか・・・。

そしてこの現象は日本語を話すときも起きているのかなあ。Podcast, あまりに頻繁に舌がもつれるので話す速度を下げたいのだけれど、気がつくと早くなってるのだよなー・・・。

Android P では on-device tracing すなわちデバイス上で Systrace をとる機能が追加された。これは性能バグ担当者からすると割と game changer である。

...というのを上司がファイルしてきた性能バグで学ぶ。この上司はもともと Android の中のひとだっただけあって色々よくわかっており、性能バグに bugreport ファイルだけでなくデバイス上で採取した ctrace ファイル(圧縮 Systrace ダンプ) を添付してくれた。たくさんのアプリを起動しまくり、かつネットワークも怪しい環境での Systrace. 今までに見たことのない現象が色々記録されている。すごい。こりゃいいわ。まあそういう厳しい環境下で怪しい挙動をする、とかいわれても直せないのだが・・・。

ところで Systrace が出力する HTML はでかい。でかすぎると Chrome が crash するため、事実上 Systrace ダンプの大きさを制限していた。自分も今まではでかい Systrace の閲覧を諦めてきたのだが上司のバグを無視するわけにもいかず重い腰をあげて回避策を調べてみた。

結論としては  V8 の heap size を大きくするフラグをわたして Chrome を起動すればよい。--js-flags="--max-old-space-size=10000" みたいな。Chrome のバグ参照のこと。

追記

500MB くらいになるとこのトリックをもってしても Chrome が死んでしまう。みんなどうしてんのこれ・・・。