仕事の内容を自分で決めるのが、今のチームに引っ越してからの個人的な目標の一つだった。現状を記録しておきたい。

チームに入った当初、同僚からは二つの入門プロジェクトを提案された。ひとつはある種のキャッシュを実装するというもので、もうひとつは・・・わすれた。この段階では右も左もわからずやりたいこともない。とりあえずキャッシュ実装のプロジェクトをやってみることにした。

引き受けたは良いけれど仕事の全体像がわからない。そのキャッシュとやらをいれると何がどれくらい速くなるのか。そこでコードを読んだり、プロファイラを眺めたり、性能測定用の instrumentation を足したりした。調査によって段々と様子がわかってきた。まず、件のキャッシュがもたらす性能への影響は、あるにはあるが大したことはない。他にも色々遅いところがある。なのでキャッシュの仕事は適当にすませ、その他の遅いところを順々に直していくことにした。遅いところは細々たくさんあったので、修正にはけっこう時間がかかった。まだ完全に直し切れてもいない。ただ結果として「どこを速くするか」すなわち「やること」を自分で決めることにはなった。

性能周辺のインフラ、というと大げさだけど調査の仕組みも揃えていくことにした。まず Systrace ベースのユーティリティを書き、最初に足した logcat 依存の雑な instrumentation を置き換えた。そして自分が速くしたいシナリオで通るコードパスにトレースを足し、レイテンシの内訳をぱっと目で見られるようにした。

Systrace の結果を見せるとコードからは自明でない高速化の成果が一目でわかるようになるため、調査のみならずコードレビューが楽になった。そのほかベンチマークの自動化や性能測定向けデバッグオプションの追加など、細々と仕事のやりやすさを積み増した。

ユーザの手元で実際に速くなっているのかを確認するため、分析用のシステムにデータを送るコードも足した・・・というか既にそういうコードはあったので、自分に必要なイベントを追加した。

歴史的経緯から、自分のチームはこの目的にもっぱら Google Analytics を使っている。ところが Google Analytics のダッシュボードで見える性能の指標のうち説明のつかない値を示しているものがある。自分の高速化の成果もいまいちわからない。困った。

あるとき Google Analytics のデータを BigQuery にダンプできることを知り、試しにダンプしてヒストグラムを書いてみた。するとごく少数の outlier がダッシュボードに表示されている指標・・・すなわち平均値・・・を台無しにしていることがわかった。50 percentile をみると自分の期待した値になっている。

BigQuery を通じて GA の値が正しく読めるようになり、仕事の成果をアピールしやすくなった。SQL と Pandas の練習も兼ね、そのあとしばらくは BigQuery をつかった性能指標の分析に時間を割いた。おかげでいくつか新しいプロジェクトのアイデアも思いついたけれど、まだ実施には至っていない。ミーティングでグラフを見せるなどもした。

当初はある単一シナリオの性能改善に注力してきたものの、low hanging fruits の収穫がおわってしまった。残りを搾り取るために大きな変更をしてもいいけれど、むしろ他のシナリオを速くした方がよくないかと思い立つ。そこで目につく遅さから候補リストを書き出してチームにシェアしたところ、いくつか反応があった。なかでもボスの提案が的を射ていた: それまで見てきたオフラインでの性能ではなくネットワークの絡むところを速くするのはどうかという。仕事でさわっているアプリは世間の平均よりもだいぶオフライン寄りなのだけれど、それでもネットワークの絡むところはある。そして測ってみるとたしかに遅い。頻度はすくないもののユーザ体験の良し悪しに響く部分でもある。

といった経緯から、そのネットワークありシナリオの高速化を次の大きなゴールとすることにした。まずは適当にプリフェッチでもするか...とデザインの資料を書いて回覧したら、TL から思わぬ反応があった: ボトルネックにある遅い API コールがなぜそんなに遅いのか、サーバのチームに聞いてみてはどうか。そこで同じ資料をもとにサーバの人々と話をしたところ、プリフェッチもいいけどまずは API を速くした方がよくね？という。

速くしろっていうけどそれあなたたちのコードですよね…と思ったものの、サーバサイドのコードをさわるいい機会にも思えた。そこで教えを請いつついろいろ調べると、アプリとサーバの双方で少しずつ工夫すればレイテンシを減らせそうだとわかった。なのでそのまま教えを請う日々を続け、サーバのコードに変更を入れた。コードベースへの不慣れとなかなかのレガシーぶりに気圧され、作業にはおもったよりずっと時間がかかった。けれどなんとかリリースできた。

サーバサイドで使われている社内の奇妙なインフラに触れる機会ができたのはよかった。フロントエンドとバックエンド二つのサーバをさわる羽目になったおかげでシステム全体の見通しもよくなった。

そうしたプロジェクトとは別に、ある時期から性能関係のバグがぼちぼち回されてくるようになった。性能系ツールの使い方の相談もうけるようになった。チーム内での存在感に不安がある身なので、何らかの役回りが認知されつつあるとわかって安心する。最近は速度だけでなく、そのほかの性能上の指標も良くしたいと試行錯誤している。

1年半たった割には大した仕事をしてない。残念ではあるけれど、「自分のやることを自分できめる」という目標自体はまあまあ達成されていると思う。持ち回りの義務的なやつを除けば、いまのところ上司からあれをやれと指示されたことはない。

節目ごとに意見を聞き、チームやボスの意向を織り込んではいる。だから純粋に自分の意思とはいえない。ただ最終的になにをやるかは自分で決めている。プロジェクトの価値を完全に内面化できる。おかげで仕事への納得度が高い。ボスに乗せられているだけという可能性は否定しないけれど、そういうファンタジーは気分の良さに繋がるので気にせず踊ればいいと思う。

他の人のやりたいことを手伝う仕事は、プロジェクトの価値を必ずしも腑に落としきれない。ビジョンや方針に異論があるわけではない。ただ価値判断の根元が自分の中にないのでいつも方針に迷いがあり、自信を持てない。どこか責任も持ちきれない。自分で決めるとそんな歯がゆさがない。たとえそれがファンタジーでもね。

「速くする」というゴールはかなり単純でわかりやすい部類だと思う。ユーザに見える機能を自分で考えて作るとしたら、ただ速くするよりだいぶ解空間が広く難しそうに見える。製品開発のキャリアが長い人ならそれもうまくできるのだろう。そうした経験を持つ人と自分のギャップを埋められるとは思わない。ユーザの欲する機能を考えて作るのは、それはそれで長い道のりだとおもうから。

エンジニアリング専業に近い仕事をしてきた自分が考える仕事がユーザ視点の専門家と違ったものになるのは自然だと思うし、そこに何らかの価値があるならそれでいいと思っている。