フリーランス時代は時間単位でのコミットで、かつ短期集中型で半年続くかどうか、場合によっては1ヶ月で終わるみたいな感じだったので、総合的にチームの開発の最適化みたいなところは考えることはあまりなかった。

一方で「こここうすればもっと楽なのになあ」というところはたくさん発見できて、それはそれでとてもポジティブなだった。

現職では本当にチーム開発で、僕はSREという立場でみんなのイテレーションをサポートしていく立場。長期的にみて「こうじゃないと僕が過労死する」みたいな個人的な気持ちと「これこうしないとマジでプロダクトやべーじゃん」みたいな危機感が同時に沸く事が多い。そうなると改善に時間をかけたくなる。

具体的に何やったかは現職のエンジニアブログに書いたし、11月に登壇が決まっているPHPcon2016で話す予定なのでここでは省いとく。どちらかというと僕がいろいろ考えてて見出した本質みたいなの書きたいなあ、と思った。

チーム開発における効率化

まずこれってなんぞやっていうのなんだけど、コードの属人性をなくしていく、というのはアプリケーション開発をしているエンジニアにお願いするとして、僕が書く効率化を進めるためのコードの方向性は「どういうアクションがあればみんなの開発 / リリースを素早く回し、人数が増えてもかける時間を毎日同じに保てるか」っていうことに限る。SREの仕事はデプロイフローの改善も含まれるので、そこらへんの修正は必要。

だから僕が考えたチーム開発効率化の本質は以下の三つだ。

• 素早くリリースできて
• Pull Requestが増えても少ない時と時間は変わらず
• 自分たちの負荷をさげることができるか

ということだと思う。会社のエンジニアの人数は採用するにつれて増えていくし、エンジニアの数とPull Requestは比例して増えていくので、時間が毎日同じようになっていく、というのは非常に重要なんだと思う。

効率化をするときにやっちゃいけないこと

その中でもやっちゃいけないのはチームの流れを破壊することだと僕は思う。流れを壊せば、チームの開発は滞留する。それだけはプロダクトの未来を考えたとき絶対やってはいけないって思ってる。

流れの中でみんなが不安になっているようなところなどはちょっとだけ変えさせてもらったりしてもいいんだけど。基本的な流れを途切れることなくベターなやり方にしていくには開発メンバーとの徹底的な会話が必要かなって。

そうしないと効率化どころか、逆に非効率にしてしまう場合もある。それは前職で結構学んだ。

僕は基本新しいものがすきだし、破壊的なところをやるともしかしたらよくなるかも！！！って勝手に妄想することはあるんだけど、いやいやそれ諸事情によりできないっすよ、やりたいけどね、っていうことを理解してもらうのはとても大事だと思うし、一歩一歩ひとつずつ改善を進めていくことが大切かなって。

そんなことを考えてたら現職のCTO氏＆リードエンジニア氏の顔が頭に浮かんだけど、彼らはその辺のバランスがとれてて、とてもいいなあ、って思ってる。僕もあんなエンジニアになりたいな。

まとめたい

今まで言語化できなかったんだけど「結局人が増えても問題ないっていう状況を維持できること」っていうのが本質なんじゃなかろうか、と僕は最近感じた。

改善のためのアプリケーションコード書く方針さえ決まって入ればどう書くかは個人の裁量なので、チームに人が増えても安心、安全。そういうのを続けて僕がいるSREチームが人が増えてもポジティブに成長していけるといいな。