手元ではまったく再現しないバグを bugreport だけを頼りに直す、という作業を延々としており、辛い。

まず直らない。なにしろ再現しない。しかし症状は(発生した場合)そこそこ深刻である。ログ(adb logcat のダンプ)には証拠がある場合もあるしない場合もあるが、いずれにせよひと目で分かるようなものではない。じっと睨む。しかしわからない、を繰り返す。一日が終わる。

結局「すみませんがよくわからないですね・・・」と close することもしばしばある。あるいは、すみませんが自分にはよくわかんないので見てもらえませんかね、と他人にたらい回す。どちらもストレスがたまるし、報告されたバグを無碍にされたユーザ(多くは dogfooder)も、わけわからんバグを押し付けられたりした同僚も不愉快。押し付けた自分の株は下がる。だからなるべくやりたくないし、できるものなら自分で解決したい。結果としてひとつの bugreport のログを睨むのに丸一日あるいはそれ以上を費やしたりする。

現実に、それはアプリでは直せないバグのこともある。

（大局的にみると）幸いなケースとしては、報告してきた人は古いバージョンの {アプリ, OS, ハードウェア} を使っていて、問題は修正済みである場合。これはまあ、自分の時間が無駄になる以外の問題はないのでマシといえばマシである。

（局所的に見て）幸いなケースとしては、症状がおきた瞬間のログが ring buffer の彼方に消えてしまっているとき。これはどうしようもないことが客観的に明らかなので「情報不足で直せません。ごめんね。」と言って終わり。自分が無駄にする時間は少ない。問題が治ってないのはダメだが。

高負荷時におかしな挙動をするというバグ。これは platform の問題であるケースも多い。そして人間のストレスも高い。Platform の人にたらい回したい誘惑に駆られるが、レイヤが下のひとは自分のようなアプリの人から次々にバグを押し付けられて既に疲弊しきっていることが知られている。そういう人に何かを頼むのは emotional な地雷度が高いし、濡れ衣だった場合は自分の株を下げる。バグ修正以外の仕事でも付き合う相手なので関係を悪くしたくない。だから確実性が高いときだけたらい回すことにしているが、確実性を高くできりゃ苦労しねーんだよ。

ログに捉えられたおかしな挙動をみつけた。そのおかしな挙動が自分の守備範囲を超えているなら、他のチームメイトにたらい回す。他人にバグをたらい回すのは自分の株を下げるし相手のストレスを高めるのでほんとは直してあげたい。ただ状況証拠がある場合は相手もなんとかできる可能性があるのでマシといえばマシである。

ログでみつけた怪しい挙動が自分の守備範囲である。その場合はコードを睨む。でも正直、その怪しい挙動から問題をつきとめて直せた記憶がない。はーわからん・・・となる。

ログに怪しい挙動が見られない、あるいは怪しい挙動の原因を突き止められない。問題が深刻かつ頻繁であるなら、自分よりシニアなチームメイトにたらい回す。シニアなチームメイトが必ずしも問題を解決できるわけではないが、自分よりは判断がマシである。しかしそうしたシニアピープルは自分以上にたらい回されたバグが溢れているものなので、これ以上相手の心労を増やしてもなあと気が引ける。頻度や深刻さがそこまで高くない場合は、なんとなく放置して風化するのを待つ。しかしそれはそれで TPM や上司につつかれたりする。

というような負け戦ワークフローを、やってきたバグごとに繰り返している。ひたすら時間が溶けていく。ここ数ヶ月くらい、仕事の時間の半分かそれ以上を治ることのないバグを睨んで暮らしている。辛い。たまに直せるバグがあるとそれだけで嬉しい、みたいな期待値のどん底に到達している。

こうした作業を bug triage と呼んでいるが、bug triage 自体は税金みたいなもので仕事の成果として評価されづらい。製品を前に進めていないから妥当ではあるが、仕事の成果がでないのは事実。税金の支払いで財布がカラになる気分。これで人事考課とか下げられた日にはもうどうしょうもない。リアルに財布がカラになってしまうよ（誇張あり。）

どうしたもんかね。と考えるに 3 つの軸がありうる。

1 つ目は、ダメな会社員としての軸。すなわちバグは放置するなりすかさず他人にたらい回すなりして労をかけずに自分の手から離す。こういうと倫理的に NG ぽいが、一面では真理をついている。つまり、直せないことが明らかだったり他人の守備範囲であることがはっきりしているならさっさと手放すべきである。

自分は自らコードを書いてバグを直したい強いバイアスがあり、そのバイアスにある種の自負すらあるけれど、自分の未熟さやシステムの複雑さ、組織の構造や文化や締切といった現実と戦えてない。別の言い方をすると今は bug fix でなく bug triage に重点を置くべきで、質と速度を高めた方が良い。これは結局のところ、バグをすばやく閉じるなり他人にたらい回せ（ただし説得力のある形で）と言っているのに近い。これは、自分の価値観としては引き続き NG だけど、人としてダメというほどではなく思える。個人の価値観は現実の厳しさに負けました、ということで。

そんな流れから、残り 2 つの軸は triage をどうするかという話。

2 つ目の軸。bugreport のログの読み方を改善できないか。社内にはログのテキストをインタラクティブに正規表現でフィルタできるビューアがあるのだけれど、それだけだと不十分。もうちょっと色々支援して欲しい。支援の方向性としては人間の診断を手伝う（たとえばより良いビューアを作る）路線もあるし、ツールに診断させる路線もありうる。それ以前に、ログを読むプロセスを構造化する、たとえばチェックリストを作るとか、も必要に思える。ビューア強化はがんばってコードを書かないといかんので、まずチェックリスト的なプロセスの明文化と、それを支援する診断スクリプト書くあたりからスタートかなあ。我ながら引き続きクソみたいなこと言ってると思うけれど、ボンクラたるものしばしばクソさを受け入れざるを得ない。仕方ない。コードで色々な問題を解決するのはできるプログラマの特権です。

3 つめの軸。アプリの出力するログをマシにする。現状のログは android.util.Log の流儀でクラス単位でタグづけしてアドホックにエラーとかを出してるけれど、これはダメだね。もうちょっとアプリケーションのフローがぱっとみてわかる感じにしないと。adb logcat のバッファというのは根本的に unreliable でよくドロップされたりするし構造もないしで、なるべく依存したくないと目をそらしてきた。しかしバグとして自分の目の前にやってくるのはこのログなので、unreliable だろうと unstructured とか文句いってないで使ったほうが良い。自分の価値観に反するが以下略ということで。あと Platform より下のログは直せないが、それは仕方ない。

2 と 3 は数ヶ月前にやっているべき話な気がしてきたけど、バグがやってきてログを見ているとゾンビみたいに意識レベルがさがって問題解決マインドになれなかったのだよね・・・。

Elephant in the room として、アプリがなぜこんなに不安定なのか、安定性を高めるべきでないかという話はある。この問題にも対処したいと思っているが、そうした仕事をするためにはとりあえず目の前にやってきて時間を奪っていくバグを捌く即効性のある処方が必要なのだよ。汚職の片棒を担いでる下端官僚みたいな言い訳ではある。なお汚職はしてない。残業もしてない。

自分の理想が厳しい現実にやられていくのは若干 soul crashing だけれども、そういえば昔は仕事ってこういう感じだったなあと思い出す。理想のためにがんばる力が自分にないところが昔と違い、それは悲しい。しかしそれは自分の問題なので愚痴はともかく文句をいう筋合いはない。