(Twitter での6年間 2 からの続き)

秋になると、上のほうが「Twitter は mobile centric company になる」という方針を打ち出した。つまり、それまではずっとウェブ中心の会社だったのを、これからはモバイル中心にシフトしていくという決意表明だ。その方針に従い、新機能を作るときにはまず iOS か Android に実装することが必須になった。もちろんプロジェクトに十分なエンジニアがいれば、ウェブも同時に実装してもいい。だが、これまでのようにウェブを先に作ってリリースしてから、あとで iOS と Android の実装を進めてリリースするということはしないことになった。その後のウェブトラフィックのかげり具合とモバイルユーザー数の伸びを考えると、いい時期のいい判断だったと思う。

そのころ、1人の男性エンジニアが育児休暇で10週間の休みに入っていた。少ししてからテックリードにも子供ができたらしく、さっそく育児休暇をはじめるということでチームに2人の欠員が出ることになった。これは厳しい。マネージャーは何も言ってこなかったので、ぼくがテックリードの役割を代わりに果たそうと自分で勝手に決めた。テックリードはリモートで働いていたので、オンサイトで働いていて小回りの効くぼくは普段からリリースカット前の駆け込みのコードレビューや QA のコーディネートなどを勝手にやっていた。その範囲をちょっと広げるだけで、テックリードの不在をカバーできると思った。2人が不在の間は少し負荷が高めの期間がつづいたが、大きな問題もなく無事にリリースを重ねていった。テックリードが休暇から復帰したとき「いいリリースだったね」と言ってくれたので、きっとうまく役割を果たせたのだと思う。

テックリードが不在だったころ、通知タブにページネーションギャップ処理を入れてほしいという要望が上のほうから届き、ぼくが担当することになった。ギャップとは、ホームタイムラインで200件以上の新しいツイートがあると、最新のツイート200件を表示して、その下に「さらにロードする」と表示されるセルのことだ。このギャップセルをタップすると、その間にあるツイートをさらにロードすることができる。当時はこの機能はホームタイムラインだけに実装されていて、通知タブには実装されていなかった。そのため、有名人など大量の通知を受け取る人は通知をもれなく確認することができなかった。その当時のホームタイムラインのギャップ処理はアドホックなもので、クライアント側がサーバ側に200件要求して160件以上返ってきたらギャップを表示するというようなロジックになっていた。通知タブにも同じロジックを実装してみたのだが、どうもうまく動かないことが多い。当時サーバー側では Ruby on Rails から Scala への書き換えが進んでいたのだが、どうやら通知タブの API はまだ Ruby のまま動いていたらしい。API のバックエンド担当のエンジニアに聞いてみると、Ruby のフロントエンド側からさらにバックエンドの Scala の内部 API を呼んで多めに通知のデータを取得して、 Ruby 側で同じ種類の項目をまとめる処理をしてからクライアント側に戻しているらしい。通知タブでフォロー、いいね、リツイートがたくさんあってもまとめて表示されるやつだ。このとき、いくら多めに通知のデータを受け取っていても、たとえば全部同じ種類だと1件になってしまい、それが iOS クライアント側に返されてしまう。そうすると、iOS クライアント側ではさらにロードできる状態なのかどうなのかがわからない。本来は JSON レスポンスのトップレベルがオブジェクトになっていて、そこに has_more=true のようなアトリビュートを追加できればいいのだが、あいにくトップレベルは配列なのでそのようなことはできない。そのバックエンドのエンジニアと話し合った結果、とりあえずの対応策として Ruby のフロントエンド側でアグリゲートした結果の件数が足りない場合には、さらにバックエンドからデータを取得するという処理をループして、iOS クライアント側が要求した件数を満たすデータを返してもらうことになった。その結果、通知タブにも無事ギャップ処理を追加することができた。

そろそろ冬になろうかというころ、それまではソフトウェアエンジニアは全員 Software Engineer というタイトルだったのが、下から Software Engineer 1、Software Engineer 2、Senior Software Engineer、Staff Software Engineer というレベルに細分化され、各人の社内プロフィールに表示されるようになっていた。たぶん、それまでは会社の成長に人事制度の整備が追いついていなかったのが、ここに来てようやく整備されはじめたということらしい。この時点でテックリードたちは Staff Software Engineer に、ぼくは Software Engineer 2 に分類されることになった。一応タイトル的にはまだジュニアの扱いだ。たぶんベースの給料に基づいて一律に分類されたのだと思う。

年が明けるとそれまでの半年分の相互フィードバックが始まった。Coding/Engineering、Architecture/Design、Scope/Impact、Initiative/Follow Through、Teamwork、Hiring の6分野に分けて、それぞれのレベルに期待される振る舞いが規定されている。たとえばぼくの場合、1つ上の Senior Software Engineer の欄に書かれている振る舞いがきちんとできていれば昇進する可能性があるというわけだ。ぼくからは、ぼくの挙げた成果とその影響をよく知っていると思われる同僚5人にフィードバックをお願いした。ぼくもたくさんの同僚からフィードバックのリクエストを受けた。それぞれの人について最低1〜2時間かけて半年間にコミットしたコードのクオリティ、レビュー数、レビューのクオリティなどのエビデンスを集めて慎重にフィードバックを書いていった。しばらくしてマネージャーとの 1 on 1 で Senior に昇進したことを告げられた。新しいベース給料の額と追加の RSU (株式) の割当も知らされる。この RSU の量が予想以上に大きく、US の会社で成果を挙げて昇進することの金銭的な意味の大きさをこのときはじめて実感した。

(Twitter での6年間 4 に続く)