あるとき人事考課の自己評価に「自分はもうちょっと他人のコードをレビューした方がいい気がする」と書いたら、同僚の一人から「自己コードレビューから始めるとレビューの練習になるしレビュアの負担も減らせるよ」とフィードバックされた。タイポなどのへぼいミスが多い自分は耳が痛く、それ以来自己レビューをするようになった。

なぜかはわからないが、手元で diff を見るよりウェブのレビュー UI でコードを眺める方が間違いが見えやすい。自分は気の利いた diff ツールでなく素の git diff を使っているから、レビューツールの方が視界が広いのかもしれない。レビュー UI は気づいたことを逐一記録しておき後からまとめて直せるのも良い。自己レビューをはじめたあと改めて周りを見ると、チームの他の人々も同じことをしていた。

こうして初版パッチからはしょぼいエラーを減らすことができたのだが、指摘と修正のイテレーションを進めるにつれ段々とエラーが増えていく問題があることに気づいた。瑣末な、あるいは気に入らない指摘をされると不愉快さが募りコードが雑になる。この大人気なさをなんとかしたい。

言われた場所だけを直すかわりに何かを指摘するに至った背景について考え、コードをがばっと書き直す方が良い場合もある。指摘をうけるコードに何か良くない部分がある可能性は高い。けれど指摘の提案が正しい割合はもう少し低い。レビュアの臭覚は当てにしつつ、それ以上を期待せず自分でよく考え根本から直す。そんな態度でいる方が、細かい指摘をはいはいと直すより前向きになれる、こともある。

ベイエリア、けっこう人の出入りがある。入ってくるのはさておき、知り合いがどこかに行ってしまうのは淋しい。東京にいたときは周りの友達がいなくなることなんてそうそうなかった。この churn は外国人でいる寂しさの一部なのだろう。

ベイエリアでは、というかきっとベイエリアに限らないと思うけれども、新しくやってきた人はよく「永住ですか駐在ですか何年ですか」と訊かれる。聞く側にしてみればあとで淋しい思いをしないための防衛線なのかもしれないけれど、感じの悪い質問だとも思う。自分たちだっていつ挫けるなり飽きるなりクビになるなりして引っ越す羽目になるかわからないのだから、相手の身の上を詮索せずに付き合えれば良いのにね。

この地に家を買うと、それは永住にむけたコミットメントと見ることができる。子供が進学して学校に友達ができると、親の意思とは無関係にある種の強い関係が生まれ、出て行きづらくなる。だから相対的に永住側へ傾いた人はいる。それでもいざとなったら帰ってもいい国がある自分たちは恵まれていると思う。生活水準が大きく違う emerging な国から来た人々からは帰りたくない切実さを感じる。外国ぐらしをしているうちに生まれ故郷が内戦などで危ういことになってしまう人もいる。そんななか帰れる場所があるありがたさといったらない。景気動向を踏まえると日本がいつまでも平和で暮らしやすいという確信はけれど・・・。

寂しさは、淋しいより辛い思いをしなくていい恵まれた身分の証なのかもしれない。せいぜい cherish しておきたい。

自分は丁寧に(大げさに)コードを書きすぎる傾向があって、それは premature-optimization であったり over-engineering であったりしてよくない。でもガっとでかい関数を書いたりクラスを定義せず tuple で済ませたりする脳の負荷が苦手で、大げさに書く方に逃げてしまう。結果として見通しの悪いコードができあがることが多々ある。

逆の傾向を持つ人もいるだろう。雑に書きすぎて、いわゆる「汚いコード」になってしまう。世の中的にはこっちが多いことになっているけれど、自分は大げさサイドなので正直そうなる人の気分はわからない。

そのバランスは最終的にはリファクタリングして正せばいい、というのはその通りなのだけれども、自分の傾向を把握して意識的に初期値を決めてやるのも自分のバイアスを治していく上では必要に思える。大げさに書く傾向のある人は意識的に雑に書き、逆もしかり。

あと使っている言語によって「望ましい大げささ」はかわるので、環境ごとに自分がどちらにバイアスされているのか気にするのも良さそう。たとえば Java は大げささが似合う言語で、Java に慣れた人は大げさに書きがち。でも Ruby なり Python なりで書くなら雑に書けないと損だよね、みたいに。

Code retreat はコードが雑になりがちという前提で丁寧に書く練習をする。たぶん anti-code-retreat みたいに雑なコードを書く練習というのもありうるのだろう。

意識的に大げさにしたり雑にしたりするのはナンセンスで、常に「正しい」バランスを心がければいい、みたいな主張もありうる。でも自分は無意識のバイアスが大きな力をもっており、ただ「心がける」だけではそのバイアスと戦えないと考えている。だから少し極端なやり方を試し、その体験から学ぶのがいいのではないかと思う。

というわけでさっき作った小さなクラスを消し、バリっとでかい関数に書きなおそう。

しばらく前から仕事のログ解析に Google Analytics をエクスポートした BigQuery を使っている。BigQuery を Jupyter 経由の Python から呼び出し Pandas で整形可視化する。久しぶりにするモダンぽい仕事で楽しい。

アプリのログ解析は大半が内製のシステムを使っているのだけれど、クライアント側の開発者が勝手に使う部分では歴史的経緯で GA が使われている。自分はもともと GA のダッシュボートなんてしょぼすぎて使い物にならないと思っていた。でも BigQuery にエクスポートできると知り試したら別物のツールになった。

SQL と Pandas を組み合わせて使うのはちょっと不思議なかんじだ。たとえば histogram を描きたいとする。Pandas だけなら hist() を呼ぶわけだけれど、SQL を使うと bucketing は BigQuery 側で済ませてしまう。だから同じ関数は使えない。histogram はともかく scatter plot とか hexbin を描きたくなったらどうすればいいのか、StackOverflow プログラマたる自分にはよくわからなくて困る。

何が SQL の仕事で何が Python の仕事なのか。自分の中にはっきりした境界はない。どちらも得意な言語ではないけれど Python の方が若干マシ。だから SQL を直す代わりに BigQuery の結果が入った DataFrame を Python で適当に加工してしまったりする。あるいは SQL 上でテーブルを join するかわりに手元に DataFrame を２つ持ってきてからマージしたりとか。

世間からはデータサイエンティストが書く長大な SQL にエンジニアが目を丸くする話が聞こえてくるけれど、一人でやっていると他人の SQL を目にする機会がない。SQL の力を引き出したいと思いつつ、いつまでも進歩せず Python に逃げてしまう。BigQuery が RDB と違うせいでいまいち世間のノウハウを生かせないせい・・・と言い訳したくなる。分析に特化した SQL の教科書が読みたい。できれば  BigQuery ベースで。まあそれは高望みか・・・。

Thinking in SQL vs Thinking in Python という記事は、 R 出身のデータサイエンティストが Python と SQL ハイブリッドの世界にやってきて感動した様子を綴っている。この人は Python より SQL がずっと得意で、かつさわっているデータセットも自分よりはだいぶ複雑なのだろう。Python を手探りで触っている感じが面白い。自分は SQL が手探りだから、データが DataFrame になった後のほうが安心して作業できる。SQL が得意だと違う感覚なんだろうね。「でも慣れたツールにしがみつくのは愚かなことだから変化を受け入れよう」と締めくくられる文章に襟首を正した。

SQL と Pandas の間で戸惑うのは impedance mismatch と言えなくもない。でも ORM をつかうときに感じたギャップはない。DataFrame はデータベースのテーブルに限りなく近いから。そして SQL を書くのも思ったより退屈じゃないね。むかし SQL をつまらなく感じたのは CRUD アプリみたいな定形作業ばかりだったからなのだろう。調べたいことを色々集計するのはアンケートみたいで楽しい。そして Pandas や Seaborn で色々な図を描くのもいい。基本的に絵が出る仕事は楽しい。ほんとは ggplot2 が羨ましいけれど、そのためだけに R をつかう気力がない。Altair にはがんばってほしいもんです。

北海道で法事を済ませたあと、雑用がてら三日くらい東京に寄り道している。おくさまは都合がつかず家で留守番のため今回はひとり旅。懸念だったいくつかのペーパーワークはさいわい速やかに片付いた。東京での一人の時間！貴重な何かがいま手元にある。

友人と合う。普段会えない人に会えると嬉しい。一方で声をかけてまで会いたい相手が片手で数えるほどしかいないとも気づく。面識のない、あるいは数度合っただけの誰かに声をかけて会いに行く身軽さや社交性がない。夏休みに帰省するまわりの人々が日々忙しく誰かに合う様を目にして自分もかと思ってたけど、気のせいだった。自分の社交性に関する不都合な事実。

普段食べられないものを食べる。おいしい。けれど普段の食事に満足しているのを再確認しもする。美食家じゃないせいか「どうしても食べたい！」というものがない。強いて言えばカツ丼。でもトンカツと親子丼はたまに食べているから要素単位での食欲は満たされている。今日は昼飯にカツ丼を食べた。美味しいし満足したものの、ああやっと食べられた、うまいー、幸せー、またしばらく食べられないなんて悲しいーみたいにダンスするかんじでもない。強い飢えがない。

晩飯は特段食べたいものが思い浮かばず、引越前に住んでいた街にあるおくさまお気に入りの餃子屋で定食。餃子写真をメシテロする。平和さの象徴としてのテロリズム。帰省時にシェアされるメシ写真は別に感極まった食欲の発露ではなく単なる生存報告の ack なのかもしれない。

大型書店に行く。本屋はいつだって気持ちが高ぶる。カゴを手に、あれも読みたいこれも読みたいと店内を彷徨う。気がつくと一時間、二時間と時が過ぎている。そういえば独り身の自分にとって、外出イコール本屋に行くだった。札幌、新宿、神保町、あわせて五軒くらいハシゴしてしまった。池袋に行けないのは少し無念だけどまあいい。歩きまわると暑いし。

けれど買うに至る本は案外少ない。技術書はもう日本語で読まないことにしている。どのみちもうキューがいっぱい。まんがもほとんど読んでいない。大判で作家別に並んでいるサブカルまんがのコーナーをひやかし、そういえばこういうまんが好きだったけどあまり電子化されてないな、もっとされないかな・・・とかぼんやり考える。

自分で読むものは保留し、おくさまに頼まれていた本と、きっと好きだろうと思える鳥の写真集、翻訳小説を一冊ずつ、そして友人へのおみやげになりそうな雑誌を一冊買う。

なんかこう、本の選び方ってもっとランダムじゃなかったっけ。ハシゴ先の札幌ジュンク堂でそう思い立ち、棚を眺めなおす。Uber 撤退以後アメリカ人が色めきだっている中国系テック企業群についての本を探す。シャオミの本を一冊買う。これは東京への飛行機内で読んでしまった。そこそこ面白かったけど、業界の理解が深まるというよりシャオミを応援したい気持ちになる類の自伝だった。

神保町三省堂ではエコノメトリクスに入門したいとランダムに思いたつ。そうそう、リアル本屋は思いつきで行動できるのがいいんだよと一瞬浮足立つが、立ち読みをしたら気楽に入門できる気配が微塵もなく落ち込む。仕方なく GDP の歴史について書かれた読み物を買うだけで気を済ます。そういえば思いつきで買った本は読まないまましばらく積んだ末に捨てることが多かった。都合の悪い記憶がふたたび蘇る。

気をとりなおし、本屋はしごの帰りによく立ち寄った喫茶店に入る。そうそう、買った本をすぐ読むのが楽しいのだよね・・・とページをめくるも、背後に陣取る女性ふたり組の声が大きく気が散ってはかどらない。そんな大声で実父の terminal care について話さないでおくれ。そういえばこの喫茶店、内装が好きなせいでつい足が向かうけれど喫煙者がいたり声のでかい客がいたりで長居の読書ははかどらないことが多かった。逃げ出すように店を出て、かわりを探しさまよった末にあきらめて失意のまま家に向かった日々を思い出す。

自分には確実に本を読み進められる場所がなかった。目につく喫茶店やコーヒー屋はどこもタバコ臭かったり席が狭かったり声のでかい客がいたり、たまに気に入る店があっても満席で入れないのがオチ。なんとなくそれが正しいように思えて従おうとしたけれど、たぶん家の外で本を読むのが苦手だった。自分のアパートも狭いし壁が薄いしであまり快適ではなかった。引越しのたびに部屋を狭くしていった自分は社会人生活のどこかで本を読む場所を失い、それは壊れたままだった気がする。

近所にコーヒー屋が少ない不満は今もある。でもどのみち自分は店の中で本を読めないんじゃないか。どうせならコーヒー屋でなく公園で読めばいいのかもしれない。公園には声のでかい客も喫煙者もいない。アパートだって昔よりは随分快適だ。だてに家賃が狂ってない。

本屋に行って読むかどうかわからない本を買って落ち着けるコーヒー屋の見つからなかった自分は、家に帰ったあと何をしていたんだっけか。たぶんマンガを読んだりインターネットをしたり数少ない友人とくだを巻いたりしていたのだろう。コードは大して書いてなかった。たまにブログを書くこともあり、それはまあまあ生産的だった。でもブログだって月に一度くらいがせいぜい。自分の週末はあまり生産的な時間とはいえなかったらしい。

結婚をしたあとは、週末を含め自分の好きにできる時間はずっと小さくなった。平日は炊事を含めた家事があるし、週末も掃除食料買い出し常備菜準備やおくさまと一緒につきあう野鳥観察などを差し引くと手元には半日しか残らない。一方で転勤に伴う社会資本のデノミと言語障害をうけ被雇用能力は危うい水準まで下がっている。

そんな焦りから、ここ 1-2 年は限られた時間の中でプログラマとしてのまともさを取り戻そうと試行錯誤した。時間や体力が足りない無力をいつも感じている。でも改めて見直すと、いまの自分の課外学習強度はたぶんここ 5-6 年で一番高い。結婚以前のヒマさを考えるとにわかには信じがたいものの、大企業の雇用を得たあとはいつの間にかサボりが板についてダラけてばかりいたのだろうな。ふたたび都合の悪いことに気づいてしまった。別に勤務先のせいと言いたいわけじゃなく、我ながらだめだという話。

そういえば会社員になったばかりの頃にも同じことを考えていた: 学生の頃の方が圧倒的にヒマだったはずが、会社員になってからの方が勉強している。怠け者の学生たる自分を恨みつつ、学生時代を懐かしがってばかりよりは良いとも思った。

今も独身時代の怠惰な自分を恨めしく思う。けれど独り身の自由や東京の暮らしに思っていたほどの未練はないことにも気づく。ヒマさを使い切れる器じゃなかったのかもしれない。持て余すほどのヒマさという贅沢を堪能していた、とも言えるけど。

週末みたいな東京の平日に、週末らしかったはずの週末を思い出す。こうして短い夏休みを終えた。

黒人差別/Racial justice の話がいまいちよくわからくて困る。メディアを通じ緊張感が高まっており、勤務先もおまいら racial justice 大事だかんなというのだが、外人から見るとなぜこうもこじらせてしまったのかと困惑する。こういうのとか。ベイエリアはアフリカ系の絶対数がすくなく、自分もアメリカリテラシーがない。だから白人が黒人差別をする感覚がピンとこない。差別しなきゃいいじゃん、それよか銃やめようぜ、と脊髄反射してしまう。日本にも韓国人差別などがあるけれどおおむね頭のおかしい人のやることだし、どちらかというとイクゾフォビア、未知/異質さへの恐怖だと理解している。黒人差別はもっと偏見がくっきりしており、根深く見える。

このあいだ法事で親戚の集まりに顔を出したあと、ふと女性差別は黒人差別に似たところがあるのかもなと思い至った。女性差別をする人というのは（自分が黒人や韓国人のことを知らない程度には）女性のことを知らないわけではない。むしろ結婚してたりする。そのうえで偏見を持ち、ひどいことを言ったりしたりするのが女性差別というもの。程度の差はあれこれはちょっと黒人差別と似ていないか。

自分は女性差別ダメ絶対側のリベラルだけれど、自分の中に unconcious な偏見があるのはわかる。今までの社会生活を通じ染み付いてきた偏見だ。無意識な偏見はいくらリベラルぶってもふとした拍子に顔を出し embarrassed な思いをする。差別しなきゃいいじゃん、と言われるといやそうなんですけどすみませんね・・・・と語尾が濁る。社会全体でもこれを正すのが手強いゴールなのは想像できる。

アメリカの黒人差別も、ある面ではそういうものなのだろう。時間をかけて積み上がった偏見があって、偏見に reinforce された差別的現実があって、差別する側は無闇に entitled で、被差別側は stigmatized になり、恐れが武器を握らせて、それが更に事態をこじらせて。

Racial justice 課題図書の一つである Between the World and Me のハイコンテクストかつバイオレントな文章は、正直けっこう読むのがきつい。でも上野千鶴子や小倉千加子みたいなものと思えば腑に落ちる。そういうスタイルが望まれる話題なのだな。

無知なりに少しは racial justice と relate できた気がした。

クレカに適応した身から見ると、東京や札幌で目にするスイカ系カードの普及っぷりはすごい。自分はあまり現金を持ってこなかったのでなるべくクレカで払おうとするが、けっこう使えないが店が多い。でもスイカは使える。悔しい。自分も前は使ってたはずだけど、間をあけてから見直すと驚く。

レガシーテクノロジたるクレカと比べスイカは色々優れている。プリペイドだからサインはいらないし、一方でチャージもできる。そして見える数字で識別しないから紛失してもまあまあ安心。詐欺師やかっぱらいの跋扈するクレカとは違う。クレカの利点なんて海外で使えることと Mint くらいな気がする。

アメリカはレガシーが足を引っ張り次の世代のテクノロジ競争では苦戦するだろうという話を何かで読んだ。クレカはそんなレガシーのひとつ。たとえば Apple Pay や Android Pay, イマイチ流行ってない。そして実際クレカと比べるてものすごく便利ではない。だからか導入がすすまず、今のところ一部の気の利いた店でしか使えない。日本はクレカが流行らなかったおかげで新しい世代のスイカ族が広まる余地があった。

もっともアメリカ人が競争相手として恐れているのは日本でなく中国。自動運転車にしても、国民が既に一人一台車を待っているアメリカより車がそこまで普遍的でない（が国土の広さ故に需要はある）中国の方が流行る下地がある。そういうものが色々あるという主張。今はグレートファイアウォールがあるから向こうも外に出てこれないけれど、なんらかの形でパンドラの箱が開いたらと恐れているアメリカ人は多そうだ。最近の Uber 撤退以来そんな論調をよく見る。

アメリカにはがんばってほしいもんですが、どうなるのかね。そして日本はいま中国からタイムマシン商法をやると一山当たりそう…とおもいながらシャオミの本を読むのだった。

離脱時間なる指標を計算しようとしたけどできなくて悔しい。という話。

アプリの画面のロードが遅いとユーザがよそに行ってしまうのでロードは速くしたいですね。そんなゴールのもと一年近く細々と仕事をしているんだけれど、ふとこの前提が正しいのかを調べたくなった。ウェブサイトだとページロードの時間が売り上げやエンゲージメントに直結するみたいな話がある。それと同じ。ただし自分の場合は売り上げもエンゲージメントも直接速度と相関をとる良い方法がわからないので、とりあえず「よそに行ってしまう」について調べることにした。

Android には画面単位に Activity や Fragment というものがあり、ふつうこいつらがデータをロードし画面を書く。Activity は自分が画面手前にくる、また画面奥に追いやられる瞬間を知っている。背後に追いやられるタイミングでまだ画面中身のロードが終わっていなければ、その時点で「ユーザがよそに行ってしまった」とみなして良い。おおむね、近似的には。

そんなかんじでデータを集め、いま手元には「画面の中身をロードできた @s millisec」という"Success event"と「画面ロード前にユーザがどこかにいってしまった @t millisec」という"Fail event" の二種類が集まってきた・・・とする。

このデータから、「ユーザは X 秒くらい待ってもだめだとよそに行ってしまう(からもっと速くしたいですね)」と言いたい。少し厳密にいうと、ロード時間 t に対し「ユーザは t 秒しても画面がロードされなかったらいなくなる」という意味の確率変数 F(t) を算出したい。この F が離脱時間。ユーザの辛抱強さと言ってもいい。

全ての画面ロードが一律同じ時間で終わるなら fail event の分布がほぼそのまま離脱時間になる。けれど実際のロード時間には大きなばらつきがあるから離脱時間の算出は自明でない。たとえば「ある success event の時間が 1 秒だった」という情報からは、その「その試行の離脱時間が 1 秒以上だった」ということしかわからない。ある fail event の時間が 5 秒だったならその試行の離脱時間はたしかに 5 秒だけれど、一方で fail events だけを集計するのは biased すぎる。

人工的なデータをつかって考えてみる。

10k 件の画面ロード時間がだいたい以下のような分布だったとする。Exponential distribution をオフセットしたもので、mean=2(sec). 実際のロード時間も大まかにはこの手の long tail な分布だとおもう:

離脱時間 F は仮にこんな分布だとしよう。mean=4 sec, stdev=1.5 sec の normal distribution:

実際にはロード時間も離脱時間もわかっていない。なおここでいうロード時間はユーザが離脱せず辛抱強く最後まで待ってくれたらの数字。離脱分を含まない success events とは違う。

さて上の二つのデータから仮の success events と fail events を合成してみる。まず success events. もとのロード時間とだいたい同じだけれど、tail がやや短くなっているのがわかる。ユーザが離脱してしまったから:

Fail events  はどうかというと、もっとよくわからない形をしている。そしてロード時間の分布にひきづられ、頂上が 2 秒ぶんくらい左にずれた:

ならべてみる。

これら success, fail の分布から離脱時間の正規分布を復元したい。ただし情報が失われており厳密には計算できなそう。近似するなりモデルをたてて予測するなりしないといけない、ということで試行錯誤してみた・・・

けど、わからん・・・はーがっかり・・・。

データから全体の離脱「率」は計算できる。だからロード時間を高速化した前後で離脱率を比較し、これだけの人がいなくなる前に画面が出るようになりましたねよかったですね、という話をすればいいと言えばいい。けどできることなら自明でないかっこいい数字を計算してデータサイエンティストぶりたかった。しかし逆にデータサイエンス力のなさが露呈したのだった。悲しい。

10 年後に読み返して「当時は未熟だったな」と思えるよう挫折を書き残す所存。誰かいい方法を教えてほしいです・・・。

Notebook はここ。

少し前から Harry's のひげそりをつかっている。ATP のスポンサーで知った。小奇麗なパッケージに包まれた小奇麗な髭剃りが届く通販。まあまあ満足。

このあいだ Dollar Shave Club というひげそり通販業者が大手髭剃り業者に $1B で買収されるニュースがあり、Harry's に同業他社があったことを知る。たぶん Harry's  は DSC のおしゃれバージョンなのだろうな。ひげそりを通販するだけのスタートアップがそんな大仰な話になるとは信じがたいけれど・・・。

似たようなコモディティスタートアップは何かできないか、と考えて真っ先に思いつくのはマットレス。自分は値段から Tuft&Needle で買ったけれど、CM などで名前を聞くのは Casper. でも Casper, そんなに安くない気がする。

何を買うにもちょっと探せばスタートアップが見つかるのをみて、アメリカ景気いいなと思うのだった。

TPM / Technical Program Manager という職種がある。以前 Rebuild.fm では "JIRA 職人" として紹介されていた気がする。検索すると各社の求人が見つかるので、そこそこ広く知られた職種らしい。ただ Manager というくらいでそれほど数はいない、ちょっとめずらしめの仕事。最近、そんな TPM と仕事をする機会が続いた。

メタバグ管理

TPM の主要な仕事の一つは、組織のプロセスがきちんと機能する状態を保つこと。プロセスというと身構えがちだけれど、組織の規模がある程度より大きいと、良いプロセスは助けになる。だからプロセスがあるのはいい。一方で下手なプロセスが官僚化に繋がるのも事実だ。TPM にはうまいさじ加減で組織を回す期待がある。

あるとき自分のいるクライアントチームの週例ミーティングにあたらしい TPM がやってきた。サーバ、クライアントからアナリティクスまでを横断的に見る立場だという。しばらくは特にしゃべる事もなくミーティングに参加していたそのひと ... R 氏と呼んでおく... は、数ヶ月後のミーティングでこう切り出した。「バグトラッカーの使い方について提案があるんですけど、聞いてもらえますか」

恥ずかしい話なので詳しくは書かないけれど、それまでチームのバグトラッカーはいまいち機能していなかった。優先度の定義が人によってまちまちだったりで、次のリリースまでの積み残し作業、次になにをすべきかがバグトラッカーからよくわからない。うんざり。トラッカーが仕事の管理に使えないフラストレーションはありつつも既存の担当バグも仕事の締め切りもない自分はすごく困りもせず、適当にやりすごしていた。ただこの環境で締め切りつきの仕事をするのはやだな、とは思った。チームの他の人々がどうしていたのかはわからない。

自分はこの乱れを自社製バグトラッカーの不出来からくる症状だと思っていた。いろいろな機能が足りていない一方で、たとえば優先度をつけるパラメタに P (priority) と S(severity) の二つがある。P/S スタイルのバグ管理ツールはとうに滅びていたと思っていた自分は、これをダメなツールの指標とみなしていた。

「多くのチームはこんなかんじの方針でやってます」そう言って R 氏は短いドキュメントを回覧した。極めてまともな内容。たとえばその文書は S(severity)欄を使わないよう勧めている。紛らわしいから。全体として自分は諸手を挙げ歓迎したい提案だった。ところがチームの一部からはいくつか懸念の声が上がった - どんなプロセスにも支持者はいる。そんななか R 氏はバグトラッカー相手に SQL を書いて集めたデータをもとに反対する人々を懐柔説得し、元の提案もフィードバックをうけ手直ししつつ、プロセスの書き換えに成功したのだった。

使い物にならないと思っていた内製バグトラッカーも、その新しいプロセスなら思ったより使える。悪いのはツールじゃなかった! この発見は relieving だった。ストレスが減り、仕事のやる気が 15% くらい改善した。元反対勢の手前ミーティングでは黙っていたけれど、休憩室ですれ違った R  氏に感謝の気持ちを伝えた。

インテグレーション

また別のあるときのこと。自分はとあるインテグレーション仕事を引き受けた。全社的に使われている便利ライブラリを自分のアプリに組み込む小さなプロジェクト。クライアントサイドのコード書き自体は簡単に終わったものの、たとえばインテグレーションの方法を近隣製品と一本化したいだとか、サーバサイドのデータフローも全社的に使われているパイプラインに便乗しつつ製品単体としてのカスタマイズもしたいとか、全体としては話をつける相手が多く面倒な仕事であることがあとからわかった。

インテグレート担当者ミーティング、のようなものに呼ばれたので顔を出してみると、司会は件の R 氏だった。そのほかの参加者は近隣製品アプリやサーバサイドパイプライン、および共通ライブラリの担当者。自分の製品は特にカスタマイズが必要なくパイプラインも他人任せのため作業はすぐに終わったものの、他の人々は辻褄合わせで苦労していた。

自分からみると、このインテグレーションは全力で妥協しつつさっさと済ます類の仕事だった。でも一部の参加者は独自のこだわりを発揮し、ミーティングのたびに終わらない議論を繰り広げていた - そういう人はどこにでもいるのだよね。R 氏はそのたび適当に割り込んで結論をだしミーティングを切り上げ、その後は議事録の AI フォローアップなどをしつつプロジェクトを進めていた。最終的に何らかの結論は出たが、これ R 氏が仕切ってなかったらそもそも話し合いにならなかったのでは・・・。そんな気配がうかがえた。さっさと済ました自分の実装もちゃぶ台返しをされそうな場面が何度かあった。けれど R 氏が適当にかわしてくれたおかげで余計な仕事をせずに済んだ。

官僚化しない世界の官僚

エンジニアリングプロセスの立て直しや組織横断的な技術仕事の調整。上に書いた二つのシナリオは TPM の仕事をうまく捉えていると思う。この記事で説明されている Facebook の TPM も、大まかには同じような仕事と読める。こういう仕事をできるともしたいとも思わないけれど、たしかに何らかの役割は果たしている。というか、上の二つの場面ではだいぶ助かった。

自分の勤務先は、たぶん規模の割に官僚化してない。でもそれは必ずしも効率的というわけでなく、無秩序ゆえの非効率があちこちにある。そんな組織で歯車のあちこちに秩序の油を差して回るのが TPM なのだろう。良い意味で官僚っぽいとも言える。もっとシステマティックな、官僚的な、あるいは効率的な組織での TPM はまた違った働きをするのかもしれない。あるいはそもそも TPM が必要ない組織やチームもある。自分が以前いたチームにも TPM はいなかった。でも今の部署にはいた方が良さそうだとは思うに至った。

これって管理職/上司の仕事じゃないの？そういう指摘はありうるし、そんな会社も多かろう。実際 R 氏も前職では Engineering Manager をしていたという。TPM は「上司」という伝統的な役割を Team Lead や Engineering Manager といった複数の職種に分解するテック企業らしい手口のひとつと言えるのかもしれない。仕事の細分化が良いとは必ずしも思わないけれど、過剰な権力を備えがちな「上司」業を modularize するのは嫌いじゃない。TPM はあまり権力を持っていない。だから頭ごなしに意思決定はできず、関係者を説得しないといけない。このくらいがよさそうじゃん。

おまけ

雑談中に R 氏が漏らした一言 -「前の会社では JIRA という freaking good なバグトラッカーを使っていたのに、ここにはそれがなくて最初はどうしようかと思ったよ」...なお社内のバグトラッカーは Dremel から叩けるので、できる (T)PM はバグトラッカーの機能不足をDremel 用のダッシュボードで補っている...という噂。

2016 は 10 年くらいサバ読んでるかもしれない。がそれはさておき・・・。

Bug tracker はバグが主役なので、一番目につくところにはバグの症状が書いてある。そして症状覧を書くのはふつうバグを報告する人である。バグを登録した直後は報告された症状が一番大切だから、それが一等地にあっていい。でも時間が経つほど必要な情報と一等地にある情報がズレていく。

修正中のバグなら、たとえば「いつ治る」とか「一時的な workaround」が知りたい。複合的なバグなら「他の症状」が知りたいこともある。修正されたバグなら「どのバージョンで治ったか」「どのように治ったか」「原因が何だったか」などを知りたい。

最初のバグ報告が正確でなかったり、情報が不十分だったりすることもある。開発者はバグの報告者と対話しながら情報を集めたり、正したりしていく。そうやって集めた情報の snapshot がほしい。あるいは紛糾した議論の最中に適当な三行まとめがほしい。

最初のバグ報告のあと時間をかけて集まってくるこうした情報は bug tracker のスレッドの中に埋もれている。現状を理解するためにはスレッドを通して読まないといけない。そしてスレッドには数十のコメントがあったりする。つらい。特に原因解明や責任の所在が二転三転したあと突然自分に assign されてきたりするとつらい。

ほぼ全ての bug tracker は bug の summary line を書き換えることができる。最近の bug tracker は一等地のレポート本文を更新することもできる。でもそれが生かされることはすくなく、大切な情報はスレッドに埋もれている。GitHub なんかはスレッド内の色使いを工夫して必要な情報を見つけやすくしている。でもさ、できれば一等地に大切なことをまとめて書いておいてほしいよね。

Bug tracker のテンプレ項目を増やせという話、ではないとおもう。Stack Overflow は質問と回答の対を添削する文化をつくり、それがサービスの価値になった。同じことが bug tracker にも起きてほしい: 追記ではなく書き直しを促してほしい。バグの初期症状と open/close だけじゃなく、workaround や原因なんかも書かせておくれ。商用製品の KB にはそんな面があるけれど、あの簡易版を開発者が草の根で作れたらいい。 bug tracker はユーザにそれを促してほしい。機械的に支援してくれるとなおいい。もう長いスレッド読むの疲れた・・・というのは大規模プロジェクトで働くとある友人の弁。

まあ Stack Overflow が bug tracker 業界に進出してくればそれでいいのかもしれない。誰でもいいからがんばれ。

異国ぐらしに適応してきたと思うことがたまにある。二年も住んでいるのだから適応してしかるべきなのだが、仕事ばかりしてると思ったほど適応しない。たまに、なのはそのため。

最近の適応モーメントは、何かの予約で躊躇なく電話を使った自分に気づいた時。英語がうまくなったわけではなく、オンライン窓口の信頼のおけなさに見切りをつけた。多くの small business がウェブサイトを持ち form なりメールなりの窓口を設けている。が、だいたいちゃんと機能しない。反応が遅かったり無視されたり。

一方で電話は確実に通じる。しかも反応がリアルタイム。ちょうべんり。英語は未だにひどく通じないが、一方で自分は客だし、相手も（地元の企業の場合は特に）英語のできない相手に慣れている。

引っ越してきたばかりの頃は電話が嫌なばかりに頑張ってオンラインの窓口を探した。さらに昔を振り返ると、10年ぐらい前に海外出張でホテルの領収書をもらい忘れ、コピーを送ってもらうべく電話をしろと上司に催促されたものの腰が引けたまま数日放置、最後に嫌々電話をしたあとは心底疲弊したのを思い出す。遠くに来たような、あまり来られてないような・・・

予約や苦情など oneshot な電話ですぱっと話が通じることは滅多になく、自分の発音のひどさを思い知る。他方で話が通じなかった同僚にはだんだんと通じるようなっている。これは相手が自分のひどさに適応したのだろう。適応されてしまうのは語学的フィードバックとしては台無しだけれど仕事の生産性は上がる。週に一回ビデオ会議をするだけだとこうはいかない。引っ越してきた甲斐があったモーメント。

Systrace に about:tracing. Tracing ツールの威力を目の当たりにするたびに宣伝しなければと思いつつ、機を逸したまま数年が過ぎた。書くことを考えても退屈な論点しか思い浮かばず、どうせつかっている人にとっては当たり前だし…などと盛り下がるループ。でも最近 Dapper をつかう機会があり、また少し tracing 熱が高まった。この盛り上がりを逃すと二度と書くことはなさそうなので、わかりやすさは無視しても何か言っておきたい。

Tracing とは、プロファイリングとモニタリングの中間に位置する性能解析のツールだ。プロファイラは主に関数の実行時間を調べてくれる。そしてほぼ全ての関数がプロファイリング対象になる。コード行単位で実行時間がわかるものまであるミクロなツール。モニタリングはよりマクロな指標、たとえば HTTP リクエスト単位のレイテンシなんかを記録、集計する。

ノート

Tracing では、コードの中で興味がある(=遅そうな)処理の流れをプログラマが明示的にマークする。ひとつの「処理の流れ」は必ずしも関数一つで表現されなくてよい。たとえば結果を非同期に受け取る API コールのレイテンシが気になるならリクエストの直前とコールバックの先頭を開始や終了としてマークする。そんなマークをコードのあちこちに埋め込む。実行時に通過したマークはログに記録が残り、そのログを専用のビューアで表示し、性能問題を調べる。

Tracing は汎用のプロファイラよりデータのノイズが少なく、オーバーヘッドも低い。一方でモニタリングよりは詳しいデータが取れる。明示的にコードをマークする手間を通じ自分の関心をツールに伝えるおかげで、Tracing は開発者にとって興味のある情報だけを浮き上がらせることができる。眺めるだけだと理解が難しい教科書を読むときノートをとるのと似ている。もっとかっこよくいうと、 Tracing ではツールが用意したインフラの上にシステム、ドメイン固有のプロファイラをつくる。

ドメイン固有プロファイラというと、たとえばブラウザの DevTools 類がある。実際 DevTools のデータを集めるフックとブラウザ内 Tracing のフックの多くは同じ場所にある。ゲームエンジンの多くも画面にオーバーレイできる性能メーターを持っている。これもドメイン固有プロファイラの一種。アプリケーションのドメインが成熟すると、このようにプラットホームやフレームワークが抽象度の高いプロファイラを提供しだす。

Android も正直 Systrace より色々できる性能追跡ツールを提供してくれてもバチは当たらないと思うけれど、今のところそうなっていない。ま、仕方なし。

分散システム用の Tracer である Dapper や Zipkin は、 Tracing を名乗りつつ大半はデフォルトのトレーシング、すなわち RPC の追跡で足りる。その点ではフレームワーク提供のドメイン固有プロファイラに近い。一方で専用のプロトコルをしゃべるサーバとの通信をマークしたり、通信とは無関係な遅い処理をマークすることもできる。そこには Tracing らしさもある。

松明

分散システムではリモートアクセスを追跡できれば多くのことがわかるので、リモートアクセスを自動で追跡する分散トレーシングツールのデザインは悪くない。そして社内ほぼすべてのリモートアクセスを Stubby などの限られたライブラリに押し込んだ Google はえらかったなと今更思う。

先の説明では追跡マークをつける作業を通じコードの理解を深めることが Tracing の価値だと書いたけれど、今回 Dapper をさわって感じた驚きは実のところ逆だった。Tracing の結果をみると、そこからシステムの作りがわかる: どんなバックエンドに依存しているのか、ストレージシステムは何か。分散システムのように実行主体が散らばっていると、コードだけから全貌を理解するのは難しい。 分散 Tracing はコードの裏に隠されたそんな迷路を照らしだす。

自分が Dapper で調べていた API も、その API を提供するフロントエンドが呼び出している (ややレガシー気味の) バックエンド...が呼び出している他所のサービスの API が遅く、その他所の API のせいで遅いバックエンドの API をフロントエンドが複数回叩いており、大変遅い、みたいな結論だった。自分はそのバックエンドのコードは一行も読んだことがなかったし、手前のフロントエンドすら以前読んだ時によくわからないまま半ば投げ出していた。「めんどっちいからとりあえずこの遅い API はプリフェッチしましょう」と提案したところ、とりあえず Dapper で見てみ、とサーバのボスに諭され渋々使い方を調べたら一気に見晴らしがよくなって感動した。それがが今回 Tracing について書こうと思うきっかけなのだった。調べてわかるなら速くしといてくれよ・・・とは言うまい。

重い腰を上げて読んだ Dapper マニュアルの FAQ には「誰が Dapper をつかうべきですか」という項があり、答えは「すべてのエンジニア」だった。読んだ時はうぜえなと思ったものの、いまや心の底から説得された。すべてのエンジニアには Tracing ツールが必要だ。難しいものじゃないから手元にあるなら使ってみるべきだし、既成品を使えない環境ならしょぼくても自作する価値がある。自分も一時期は自作していた。可視化には Catapult を使えるから、データを吐くところだけ作ればなんとかなる。Tracing ツールを使おう。マーキングを通じシステムを学ぼう。先人の残したマークを灯し、システムの闇を照らし出そう。

補足。

Tracing ツールが性能解析のすべてではない。あたりまえ。トップレベルでの高速化が済んで細部の詰めが必要なときはマイクロベンチマークや CPU プロファイラのお世話になる。既存の Tracing ツールが提供する可視化の情報では足りないなら手の込んだドメイン固有プロファイラを作りたくなる。あるいは Tracing 結果を R や Python にロードして統計的に眺めたくなる。コードをさわれないバイナリには Dtrace 的な prober が欲しくなる。一旦速くしたら遅くしないためにモニタリングしたい。そんな道具の一つに Tracing も混ぜてあげてね、という話。

ベンチマークではよくcold startとwarm startを区別する。Warm startというのはキャッシュとかに欲しいものが入っている状態。Cold startは初回起動などでなんの準備もできていないケース。多くの高速化はwarm start をターゲットにしている。なぜなら事前に準備のできるwarm startの方が成果を出しやすいから。

あるときAndroidはデスクトップよりもwarm startしにくいことに気づいた。ディスクもメモリも帯域も少ないからキャッシュの使いどころが難しい。たとえばキャッシュをprewarmすべく裏で色々なものをダウンロードしておきたくても、下手にやるとユーザの帯域を浪費して苦情が来たりする。オンメモリのキャッシュも難しい。メモリ上に色々抱えているとプロセスが殺されやすくなる。だからうかつにデータをpreloadできない。どのみちメモリの少ないデバイスではforeground以外のアプリはすぐに殺されてしまう。事前に蓄える余裕がない。

最近、必要なファイルを少し早めにpreloadするコードを書いた。リリース後に速度をモニタリングしてみると、手元の計測よりずっと速くなっている。測定方法を間違えたかと不安になったあと、別の仮説に思い至った: ファイルのpreloadは、そのファイルがOSのpage cacheに載っていない方が効き目が大きい。自分の手元のベンチマークは同じシナリオを繰り返し実行し合計をとっていたけれど、おそらく初回以降はprefetchするファイルがOSによってcachedだった。つまりwarm startを計測していた。でもユーザの手元ではファイルがpage cacheから追い出されたcold startが支配的、なのではないか。ほんとはpage cacheの有無を記録して実証したいがそれを知るすべがない。無念。

ベンチマークのスクリプトにpage cacheをクリアするcoldオプションを足そう。

追記

ベンチマーク結果（実行時間）がめちゃ安定した。おすすめ・・・といいたいところだけれど root  をとったデバイスじゃないとだめなのが惜しい。adb とかでできるとよいのにね。

スケーラブルな仕事をするには、スケーラブルな問題を扱う方が都合が良い。プログラマにとってのスケーラブルな問題は、時間をかければかけただけ、沢山のプログラマがいればいるだけ、成果がでる問題と言える。そういう問題はあまりない。でも大きなテック企業はそうしたスケーラブルな問題を解くことで成り立っている、気がする。

プログラマにとってのスケーラブルな問題には大きく2つの特長があると思う。一つは部分問題の直交性が高いこと。開発者やチームの間で多くの協調作業を必要とする問題はつらい。個々のプログラマ、とまではいかないけれど、個々の小さなチームが、それぞれ勝手に部分問題をみつけて解く。その総計が全体の答えになる。機械学習のアンサンブルみたいなかんじ。個々の部分解が互いに矛盾、衝突しやすい問題だと調整が必要でスケールしにくい。

もうひとつの特性は、最終的な成果（たとえば売上）がプログラマにとって扱いやすい指標と強く相関していること。検索連動広告や推薦アルゴリズムはその精度が高ければ売上に直結する。ブラウザはページのロードが速いほど人気が出る。など。プログラマにとって戦いやすい問題を解くことがそのまま成果に繋がるなら、経営者は良いプログラマを集めてプロジェクトにつっこめばよい。プログラマは目の前にあるエンジニアリング上の問題を次々にとけばよい。スケールする。

問題のスケーラビリティについて思い至ったのはUberについて書かれた記事を何かで読んだ時だ。Uberは配車のアルゴリズムを改善すればしただけサービスがよくなり、売上も増える。配車アルゴリズムを評価する指標はそれほど自明でもないけれど、賢い人がよく考えればうまく定義できるだろう。たとえば配車リクエストから自動車到着までのレイテンシが主要な指標の一つなのは間違いない。そしてレイテンシはソフトウェアの問題に帰着できる。そんな風に問題全体を定義できたなら、あとはばんばんプログラマを雇えば良い、気がする。

ウェブ検索は、たぶんすごくスケールする問題だった。ブラウザ開発も、検索ほどではないにせよスケールできる性質はあって、その部分はどんどん良くなった。一部のソーシャルメディアも何かそんな問題を見つけたのだろう。それがなんなのかはわからないけれど。

UIを変えるとか機能を増やす仕事はスケールしづらく見える。画面のreal estateは機能同士が奪い合う資源だから直交とは程遠いし、新しくなったUIや増えた機能と最終的な成果(ユーザ数、売上など) の関係もはっきりしない。洗練されたユーザトラッキングやデータ分析の手法を使えばわかることも多いのだろう。でも精度とかレイテンシとかの方がわかりやすいよね。

Lean 一族をはじめ、起業家精神あふれる人々は問題を見つける難しさをずっと議論してきた。異論はない。一方で大きな問題の袖を掴んだあとに何をすべきかはよくわからない。工学上の指標として問題を定義し、直交した部分問題に分割し、その上に問題解決のプラットホームを作り出す方法。組織論にはそんな話がありそうだ。ソフトウェア開発の言葉でそれを説明したものがあるなら読みたい。Microservices なんかは近いかも。

Kent Beck が不景気に備えろと説き、話題になっていた。

自分は臆病なのでいつも不景気のことを考えてしまう。でも最近はたまに逆を考える: 景気がいいなら冒険してもいい。あるいは、冒険は景気がいいうちにしたほうがいい。

冒険の種類は問わない。会社をつくる、大学に入り直す、結婚する、子供を持つ、あるいは文字通り未開の地へ冒険に出かける。何らかのリスクをとるのは、景気のいい時がいい。自分が失敗したとき、それを受け止めてくれる余裕が社会にあるだろうから。景気が悪いとそうもいかない。

自分は普段の性格とは裏腹に思いつきや衝動でランダムに冒険してしまう。タイミングについて考えていない。でもタイミングがよければ楽なことがあったかもしれない。世の中がサブプライムから立ち直りハイテクブームに突入した2010年からの数年間、自分はぼんやり暮らしていた。そして華やかさの裏で陰りが噂されだした頃からばたばたと冒険にでかけた。これが数年早かったらといつも思う。

何も考えてないのだから都合よく物事が運ぶはずはないし、そこに大きな後悔もない。でも景気の波に乗るのが上手い人はきっとどこかにいて、そういう人は時代の力を使って大きな冒険を成し遂げるかもしれないね。

いま仕事をしているチームのリードはレビューの反応が速い。レビューに限らずメールの返事も速い。リード以外の人々もだいたい反応が速い。時差のある仕事をしていた頃は反応に一日かかるのが当たり前だったし、時差がなくなったあとも反応の遅い相手との仕事が多かった自分には新鮮だ。

一方、自分がこの速さを期待されたらしんどいと正直なところ思う。誰かに反応するには自分の作業を中断しないといけない。集中が途切れる。他人の仕事をブロックしないために自分の進みを犠牲にする。フォーカスやらフロー状態やらを重視する一方で反応の速さに美徳を見出す。共同作業のジレンマといえばそれまでだけれど、レイテンシ・スループットのトレードオフがレイテンシ側に倒れすぎていると思う。もう少しスループットに倒せる世の中になってほしい。

時差のある仕事では、待たされる前提でいくつもの仕事を同時に進めていた。一つをレビューに出したら、別の仕事に取り掛かる。コンテクストスイッチは悪というけれど、割り込まれてスイッチするのと待つためにスイッチするのは少し違う。待つタイミングは予測できるし、自分で決められる。他にやることがある限り、（そして締切が迫っていない限り）待つのはさほど苦痛でない。そして、やることはいつもそれなりにある。長く待つ前提でいくつもの仕事を受け持つのは、待たされる側がレイテンシを受け入れスループットにバランスを倒す一つの手管といえる。

待たされる苦痛というのはある。でも苦痛の大きさは、かならずしも待たされる長さに比例しない。むしろどれだけ待たされるかわからない不確定性や不透明さが辛かったりする。待てど暮らせど返事がないと、忘れられていないか不安になる。

反応が速い人々は、レイテンシのばらつきを小さくすることで不確定性を小さくしている。でも、他の方法で不確定性を減らしてもいいはずだ。たとえばメールでの問い合わせに対し「明日見ます」と締め切り付きの ACK を返せと説く仕事術師は多い。行列のできる人気店の電光掲示板には予測待ち時間がきらめいている。見通しに透明性を与えるこうしたアイデアは、もっとシステムやツールが後押ししてくれていい。相手ののメール、レビュー、バグ退治の待ち行列が目に見えるだけで、どれだけ人々は救われるだろう。

もっといえば、私達は待つ必要のないものを待っているかもしれない。たとえば Facebook は(少なくともある時期まで) コミット後のレビューを認めていた。コミット後レビューなら、コードの書き手はレビューを待たずに作業を続けられる。同様に GitHub の PR はレビューの単位をコミットからブランチに広げることで、ある程度の先行開発を書き手に許している。これらの方法には固有の難しさがあるけれど、実りも大きい。

並列性を使いレイテンシを隠す。わずかなレイテンシと引き換えに大きなスループットを得る。これらはソフトウェアエンジニアリングと少し似ている。割り込みでなく待ちを起点に仕事を切り替えるのは協調的マルチタスキングだし、ブランチ単位レビューや先行開発はバッファリング、あるいは投機的実行だ。コミット後レビューは Eventual Consistency と言えなくもない。

そんなエンジニアリングの眼鏡を通すと、これはみなスケーラビリティの問題に見える。返事の速い TL はスケールしない。自分は無茶なスケールの求めに引き裂かれたくない。システムとしてうまくやってほしい。世の中にはリアルタイム性が大切な仕事もあるだろう。けれどスケーラビリティに意味がある仕事も多いと思う。

個人的にはリアルタイム性よりスケーラビリティ重視の方が働きやすいので、世の中そういう仕事が増えて欲しいものです。

今年はブログを書かないつもりでいたけれど、何も書かないのは精神衛生に悪すぎるので何か書く場所を持つことにした。最初は Simplenote で書いていたものの、あまりの閲覧性の低さにくじけたのだった。

人目についてほしいわけではないので見かけてもほっといてください。