テクニカルな理解が低いと良い意思決定ができない。でもそういうのが必要な場面はしばしばあって辛い。という話。

去年の今頃、テストやベンチマークの自動化を強化するプロジェクトをはじめた。そのときは隣に QA チームがいたのでおすすめの自動化フレームワークを聞いたところ、彼らの作っているツールを勧められた。QA チームが保守しているベンチマークを自分たちの都合良いように書き直したい思惑もあったし、彼らはこのツールでテストを書き直すというし、他によい当てもなかったのでそのツールで自動化に着手した。

のだが・・・とにかく使いにくい。やばいレベルで使いにくい。ほんとにこれでテストとか書き直せるの？無理じゃね？どうしてこんなものが存在してるの？と思ったものの、専門家であるはずの人々がそれでいくというのでがんばって使い続けた。しかし全く捗らない。ツールを自分に勧めてきた A 氏は席を外していることが多かったので、その隣にいた同じ QA チームの B 氏に、ほんとにこれでいくの？どういう予定なの？などとたびたび質問した。しかし B 氏の反応もいまいち煮え切らない。

自動化にあわせてアプリ本体のコードに入っている計測のフレームワークも整理する必要があり、自動化作業自体はしばらく保留して製品側のコードをいじっていた。そのころチームに新しい TLM の X 氏が入ってきて、彼らの自動化業のためのスタックを評価しはじめた。件の QA 部門推薦フレームワークも評価し、これは全然ダメだからやめた方がよくね？というドキュメントを書いてチームに回覧した。あ、それ言っちゃうの？という外交的配慮と、まったくその通りだよ、という安堵が同時に頭をよぎる。なお自分も少し前に似たような評価のドキュメントを書いて「こいつは若干いまいちだが隣の QA の人たちからのサポートもありそうだし足並みそろえた方がいいのでこれにしましょう」という結論を書いていた。

一方、別のオフィスにいる比較的最近はいってきた別のプログラマ Y 氏が、また別の目的で自動化作業をはじめていた。 TLM の X が書いたドキュメントから実際の自動化コードがリンクされていたので見てみると・・・よさそうじゃん。（自分が作業をはじめた頃はまだ計画だけでコードは見当たらなかった。）

自分は隣接 QA 部門との間でスタックを断片化したくないのでいまいちなツールを使い続ける気だったが、同じチームの Y は既に別の（よさそうな）ツールを使い始めている。つまりどのみち断片化してる。そして自分が保守したくないとおもっていた自動化インフラの boilerplate なども Y がぜんぶ片付けてくれている。この船に乗るしか無いとそれまでに書いたいまいちバージョンのベンチマークを捨て Y の選んだフレームワークで書き直した。これまでの苦労はなんだったのかというくらい色々なものがあっさり解決し、そのいまいちツール対応のためにアプリ側に入れたワークアラウンドも削除することができた。その前の 1-2 ヶ月の苦労は何だったのか・・・。

ベンチマークは今でも動き続け、たまにリグレッションをみつけたりしている。

自分に自作ツールを勧めてきた QA チームの A は、気がつくといなくなっていた。他の部門に異動したらしい。隣でツールへの評価に口を濁していたテストエンジニア B も、しばらくするといなくなった。たぶん機能不全なチームだったのだろう。

この事件のあと、自分はなぜ正しい決断ができなかったのだろうと考えていた。ツール自体への評価（出来の悪さ）は明らかだった。新しくやってきた TPM の X は早々にダメだしをした。別のオフィスにいた SWE の Y はダメツールには（たぶん）一瞥もせずマシなフレームワークで作業をはじめた。なぜじぶんは嫌な予感を押し切ってダメツールを選んだのか。

最初に考えたのは「政治的意向で技術的判断をするのがよくなかった」という反省。つまり QA チームと足並みを揃えたいという気遣いが判断を曇らせたというもの。これは一理あるが、一方で純粋に政治的判断というわけでもない。同じツールを使えばインフラの保守を相手に任せられるという潜在的な利点がある。

じっさい出来のよい自動化フレームワークを使うためのインフラのセットアップはけっこう大変で、Y がやってくれたからよかったけれど自分でやりきれた自信はない。一方で保守をしてくれるはずだった A と B は QA チームからいなくなってしまったので、彼らのインフラに載ったとしても人の入れ替わりに際して自分が尻拭いをする必要にせまられた可能性もある。

次に考えたのは「人を見る目がなかった」というもの。出来の悪い自作ツールをピッチしてきた QA エンジニアの A は信じるに足る相手だったのか？謎のオレオレ再発明が跋扈する厳しい社会を生きるには信頼できる相手を見抜く目が必要なのでは？この論点にも理がないではないが、一方でテクノロジを評価するのに人を見る目を養うというアイデアは自分の価値観に合致しない。そういうのは VC のひととかががんばることだと思う。

最終的に自分の腑に落ちた結論は、自分の会社員モバイルエンジニアとしての実力不足とコミットメント不足だったというもの。

たとえばダメだし文書を書いた X はその前にまともなでかいチームで働いていて、なんらかのマシな自動化インフラがあることを（自ら作業した経験がないにせよ）なんとなく知っていた。

出来の良い自動化フレームワークを導入した Y は、その後チームの自動化担当としてほぼ専任でインフラの面倒をみている。そのインフラはよく壊れる（当人の問題ではなく組織の問題）ため、保守は大仕事。じっさい彼のいるオフィスはテストやベンチマークなどのインフラを一手に引き受けるサブチームへと発展していった。

判断を下した時点で、自分にはより良い答えがある確信も、インフラの保守ふくめ全部自分の正しいことをやり切って引き取る覚悟もなかった。（後者は今もない。）ただしい判断を下すには X のような「正しい環境で働いた経験」か、 Y のような「ぜんぶ自分でやる覚悟」のどちらかが必要だった。どちらも自分にはなかった。

今は覚悟を決めた Y およびその周辺の人々のおかげでインフラが整備され、自分は「正しい環境」を知ることができた。チームを異動して似た仕事をする機会があったら正しい判断を下せるだろう。つぎはもうモバイルやりたくないけど。

この会社員的な視点から一歩下がって考えると、一人前の Android プログラマとして知識が足りてなかったように思える。もうちょっと勉強しとけや、というのがより一般的な教訓かもしれない。

でも実機でベンチマークを自動化する環境づくりとか、仕事じゃないとやらない気がするね。趣味で mobly を使える気がしない。なんかもうちょっと普通に使える host driven な E2E のモバイル向けベンチマークツールないのだろうか・・・。