チーム開発で活躍するために、自分の庭を作れると良い

チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。
巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。
思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。

庭とは

現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。
大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知られている。
庭は、どこに何があるか分かっていて、地図を見なくても安心して歩いていって活動できる場所。そういう、守備範囲というか、足場がチーム開発においてもあるとよい。

まずは得意な技術から庭をつくる

新卒だったら学生時代にやったこととか、異動してきたなら前のチームでやっていたことがあるはず。ポートフォリオとして持っている技術でなくても、最近本で読んだとか週末に調べていたことでもいい。
Dockerが得意だったらDockerイメージをより良くします、とか、プログラミングが得意だったら、一般的なプラクティスに沿ってちょっとずつコードを読みやすくするとか。
技術の発揮というのはコードを書くことだけでもなくて、現状のサーバーの構成図や、各サーバーの役割説明ドキュメントを作ってくれた人がいてありがたかった。
そうやって触ったところは庭として認識できているので、どこに何があって、次のイマイチな点はこれである、ということが頭に入る。すると、ちょっと暇があったらちょっとずつ直していけたりする。
暇になったからといって未開の地に冒険に出ていくんじゃなくて、知っているところのちょっとした改善をちょっとだけやっていく、という姿勢を身につけられると、この人はゴミを拾ってくれていてよい人だ、という形でチームに貢献していける。

品質の低いところを庭にする

たびたびエラーが発生しているバグのある箇所があるとする。あるいは、テストが全然ないけど重要なコンポーネントがあるとする。
そういう箇所をちまちま直したり、こつこつテストを書いていくと、その分野には詳しくなれるし、プロダクトとしては重要なコンポーネントが壊れにくくリファクタリングしやすくなるのでお得。
ここで気をつけるべきは、どこでもいいから手当たりしだいに手を付けるべきと言っているのではない。打ったパンチを当てるためにはよいところを狙わないといけない。
社内的には金脈というスラングがあって、今はほったらかしにされているけど、手を入れればすごく良くなる、という意味。サーバーコストを劇的に下げられる可能性がある、とか。
ほったらかしになっていた荒れ地を整えれば、開拓者としての信頼を得られる。

荒れた庭

得意になりたい分野から庭を広げる

しばらくディレクターをやっていて数年ぶりにエンジニアに戻ったメンバーは、しばらくはインフラスキルを高める、という目標を持って、サーバーのメンテナンスだったり、DBの遅いクエリを直したり、といったissueを拾っていってもらっている。そういう目標なしに手当り次第に手を付けていくと果てしない世界になってしまうので、まずはレイヤ別に下の方から掴んでいって土地勘を得ましょう、ということになっている。
この人はここを強みしたいと動いている、というのが周りから見えてれば、このタスクはあなたの勉強になりそうなのでおすすめですよ、って回していける。
得意になりたい、ということは、まだ得意ではないことを意味している。得意ではないけど任せてもらえるためには、まずは得意技術で活躍して信頼を得ていることが必要だと思う。とはいえ、規模が大きかったり、人数に対してやることが多いチームだと、得意なことを得意な人がやらなくても、ただ目を配ってもらえるだけでありがたいという状態になったりする。

チームも庭

ソフトウェアがどういう構成になっているか分かってくると、ソフトウェアが動くことだけでなく、それをどうスムーズに作るかという、チーム開発が関心になっていくと思う。
今所属しているチームでは、正式なメンターメンティー、という関係もあるし、雑談したり、野良1on1をやったりして、誰が何をやってて、どこにどんな問題があるか見るようにしている。
blog.sushi.money

最近自分がやっていることだと、今はベテランが気にかけていることで担保されている機能を、人からチームに移していこうと、いくつか作業部会を立ち上げたりしている。
小学校には図書委員があって、週に何時間か貸出業務を任されたり、本にラミネート加工をする仕事があったりする。こういう仕組みがなくて本好き小学生のボランティアでやっているのでは図書室は崩壊すると思う。
同じような形で、これらの作業部会でこのあたりを見ていればプロダクトの品質低下を防げるであろう、というような整理をしている。これはチームの中でどういう人が何をやっているかが庭になっていて、役割分担を整理して冗長性を高めたような形。

整った庭

庭の所有権

庭として触って詳しくなっても、自分のものになるわけではないことに注意する必要がある。チーム開発での成果物はみんなのもので、誰がいつ触ってもよい。自分の許可なしの変更は許さない、と言い始める人はいないと思うけど、知っているからと言って権威的な振る舞いをしてはいけない。
リファクタリングという本を読むと、リファクタリングを妨げるものとして、コードの所有権が分かれていること、が挙げられていたと思う(いま手元にないので違ったら教えてください)。

リファクタリング 既存のコードを安全に改善する（第2版）

庭 vs 盆栽

社内では盆栽というスラングがある。過剰な品質を持っていて、作った本人だけが満足しているという意味。裏庭で輝いているとされている。
庭があるのはいいけど盆栽を触っているだけではだめで、あまりに小さいところにこだわってやっていると、他にやること無いのか?という印象になっていく。
自分の学生の頃はGitHubでOSSをいじくり回すのがただ楽しいという時期があって、当時触っていたリポジトリのカバレッジ100%を目指して一泊二日の合宿を企画したりしていた。
楽しかった思い出だけど、週末に友達と宿泊して風呂にも入らずテストを書き続けるのは完全に盆栽を愛でるときの行動で、それによってプロダクトの魅力が劇的に上がったかというと、その時間があったら重要なコンポーネントの重要なタスクに取り組んだほうが実があったかもしれない。

さらに進むと

エンジニアのためのマネジメントキャリアパスを読むと、キャリアを積んでいってCTOになるまでの道が記されているので、あとはこの本を読んでください。
この本ではインターンメンターになるところから始まるけど、その前に、どこから活躍していけばいいか、ということを今日の日記では書いてみました。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド