個人的には Zach Holman がいた頃の GitHub のような、マネージャー不在でもうまくいく超フラットな組織が理想だと思っているが、いろいろ、いろいろな事情を鑑みると、伝統的な組織の形にする必要性も十分に感じていた。マネージャーになりたいなどとは思っていなかったけど、チーム全体のことを考えると、誰かがそういう役割を担ったほうが良いのは明らかだった。できれば俺ではない、誰かが。
チームの一員として、立場とか肩書とか関係なくプロジェクトの成功のためにすべきと思うことはやってきたつもりだ。その中には、会議をファシリテートしたり、議論のイニシアチブをとったり、開発者以外のステークホルダーと対話したり、何かを決断したり、という行動も含まれていた。そういうことを専らやるのだ、単にそういう役割なのだと思えば、やってやれないこともないと思い、話を受けた。
最大の誤算は People Management の仕事の重さだった。人事関連の業務も権限委譲されたので、人事評価をする上で必要な目標設定なども Engineering Manager が行うことになった。これは大仕事だ、ということを、マネージャー側の仕事をやってみて思い知った。
まとまった、どころか細切れでもプロダクトコードを書く時間を捻出できなくなり、自分が開発タスクを担当してもスケジュールに間に合わせられる自信が無いので、プロダクション環境で動く「一軍」のコードを書く仕事からは手を引くようになった。社内向けの運用業務などで使う「二軍」のコードはかろうじて書いているが、そう遠くないうちに「一軍」のコードにキャッチアップできなくなり、「二軍」のコードすら書けなくなってしまうのだろう。こうして「コードの書けないマネージャー」の出来上がり、だ。
開発リソースの配分も気が進まない仕事だ。そもそも「開発リソース」ってなんだよ、って話だし、「この人は○○担当、この人は○○チーム配属」とか、誰かがそんなことを決めたりしなくても各々が自律的に動いて物事を成し遂げる、そういうものに憧れていたんじゃなかったのか、なのになんで真逆のことをやっているのだ、という矛盾を感じずにはいられない。これ一番嫌な仕事かもしれない。
ずいぶん昔から、「マネージャーの最後の仕事は、自分より優秀な後任者を見つけて自分をクビにすることだ。そのような新陳代謝が行われるのが健全な組織だ」と考えてきた。今もその考えは変わっていないが、後任者が自分と同じように苦労し、同じように悩むのかと思うと、気の毒すぎて押し付けるのが憚られる。「そうやって耳障りの良い言い訳を口にしながら、保身が本音ではないのか？」と自問することで、どうにかダークサイドに堕ちないようにと気をつけている。そう考えること自体が excuse なのかもしれない。わからない。