ランダムなマネージメントの話。マネージャはコードを書くべきか。

なおここでいうマネージャは Engineering Manager で、TL は他にいるものとする。この前提だと、conventional wisdom は「マネージャも重要なものはともかく少しはコードを書いた方がいい」くらいな気がする。

自分は個人的にはマネージャにはコードを書いてほしくない。全然。なぜならマネージャの書いたコードは扱いがめんどくさいから。そしてどうせならコード書き以外の面倒に時間を使ってほしいから。

例。あるとき上司の上司が crash bug の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。

問題の特定まではよかった。でもコードをみると直し方がいまいち。コードベースの抽象やパターンに従わず、力技で片付けている。全体のデザインを正して似たような問題が起こらないようにするといった配慮がない。しかし通りすがりの上司の上司に正しいデザインのあり方を説明しコードを書きなおしてもらうなんてやりたくない。気を使うし、コードベースに対する理解の程もわからない。忙しい相手だけに素早いイテレーションも期待できない。ただバグを登録してくれるだけでよかったのに・・・。

うげーめんどくせーと顔をしかめる同僚たち。結局心臓の強い同僚の一人が容赦なくダメだししてパッチはお蔵入りとなり、その強心プログラマが自らマシな修正をした。チームメイトに同じことをしたら喧嘩になるところだけれど、この時に限っては正しい対応だったと思う。

上司のコードをレビューするのはそれなりに気を使う。相手がまともな人間でコードレビューに手こずったくらいでは気分を害さないくらいは期待していい。それでも自分にそう言い聞かせ権力構造から心を切り離さないといえないのは疲れる。

しかもマネージャには他に本業があり、結果としてコード書きの対応は遅れがち。一方でレビューは間隔があくほど認知の負担が上がるので、イテレーションの遅いレビューはそのぶん疲れる。普段コードを書いておらず共有するコンテクストが少ないのもコミュニケーションの敷居を上げる。

更に言うと、管理職は必ずしも良いプログラマではない。才能の優劣ではなく、下々のプログラマに比べて読み書きしている仕事コードの量が違う。頼れるチームメイトである度合いと言ったほうが良いかもしれない。片手間でコードをみているマネージャよりより、プロジェクトのコードベースに馴染んでいる現場のプログラマの方がよくコードをかけるのは当たり前。それが役割分担じゃん。

要するに: 権力を無視して正しく振る舞うのは疲れる。通りすがりの相手も疲れる。ぱっとしないコードを読むのも疲れる。だからコードはプログラマにまかせマネージャは本業に専念しておくれ、と思う。

Good First Bug

コードを書いては欲しくない。でもコードは書けて欲しい。少し理不尽な言い分だとは思う。でも現場に近いマネージャであるほど、下々が上司に巻き取って欲しい仕事にはコードを書けないと現実的でないものが多い。

例。とある夕方、翌日の UX レビュー会議で動くデモが必要とわかる。一応コードはあるものの、まだコードレビューがおわっておらずマージされてない。担当者はもう帰ってしまった。しかも明日の会議で必要なパッチは二つ。こいつらを手元でマージし、アプリをビルドしないといけない。

このとき職場に残っているプログラマにビルドの雑用を頼むのでなく、自分でささっとビルドできる・・・くらいはマネージャに期待したい。似たような場面はいくらでもある。

そしてちょっとした雑用にプロダクション以外の書捨てコードで自動化や分析ができると便利な場面は多い。そんな仕事に上司が手作業で時間を無駄にしてたら、ちょっと興醒めでしょ。

コードを書かないとコードを書けるようにはらなない。プログラマからマネージャに転身した身であっても、時がたてばコードやインフラは変化し、昔の知識は使えなくなってしまう。

そんなマネージャがプロジェクトのコードを学ぶためにコードを書く。これは必要なことだと思うし、現場のプログラマとしても協力してあげたい。コードそれ自体がプロジェクトの役に立たなくていい。たとえば優先度の低いしょぼいバグをなおすとか、あってもなくても大差ないちょっとした API を生やすとか、入門のためにかけるコードは色々ある。Open source でよくある good first bug というやつ。

マネージャが書くコードの面倒くささは、有用なコードをキメたつもりになっている本人と現実のギャップに起因することが多い。学びのためのコードにそうした勘違いはない。むしろちょっと応援したくなったりもする。

それに、マネージャが通りすがりで雑用をさばけないのはコードのデザインやインフラが腐っている兆候かもしれない。そうした歪みや技術的負債の痛みを体験したマネージャなら、負債返却や自動化強化を求めるチームからの声にも意味のある形で応えることができるだろう。

コードをめぐるプログラマとマネージャの関係は、そのくらいが円滑じゃないかな。

この文章はマネージャに向けたものではなく、自分とおなじそこらへんのプログラマを読み手として念頭においている。上司の書くいまいちなコードを見て複雑な気持ちな人に自分の感覚を信じて欲しい。下々のプログラマも声を出そう。これを読んだマネージャは一定の割合でムカついているとおもうけれども、そういう人は世に溢れるキリッとしたマネジメント語りを読んで元気だしてね。