読者です 読者をやめる 読者になる 読者になる

Viibar Advent Calender 2015

はじめに

こいつは Viibar Advent Calender 24日目の記事です。

自己紹介

Viibarではリードエンジニアをやらせてもらってます。
エンジニアとしては10年オーバーですが、若手に前線を譲って便利な器用貧乏にはならないぞ!が合言葉で頑張ってます。

技術的にかっこいいこと書こうとも思ったのですが、ちょっとエモい話をしようかと思います。

リードエンジニアとして気をつけていること 

GithubでPRを出してもらいレビューでOKがでたらmasterへマージしてリリースしてOKという、シンプルなルールで運用しています。

ところがどうしてもゾーンに入ってしまったり、自分の仕事で手一杯でPRを見る余裕がなかったりして、なかなかレビューされない、みたいなことがあるんですよね。

打開策として16:00から1時間をレビュータイムにして積極的に見る時間を設けたりはしていますが、とはいえそれでも漏れたり、急ぎのPRとかもあったりはするので、積極的に拾っています。

「誰かのレビュー待ちでこの機能をリリースできない」というのは機会損失以外の何物でもないので、そうならないように心がけています。

またそれをなるべく実践できるように「そこは自分ではレビューできない」という領域を作らないように、フロントも含めて、すべてのPRは目を通すようにしています。

もちろん現実すべてのPRにコメントをつけることは無理で、マージ後に見ることもありますが、コミットログを見るのが趣味な自分的には、楽しいです。

全体設計の方向性を示す

複数人で開発をしていると個別最適化がされて全体としての最適化がおざなりになることがありがちです。

Railsで言えば適切に concern 化したりする必要がありますし、サービス全体にかかわるコアなモデルをどう扱うかだったりは、どうしても1機能開発だけを考えると「とりあえず」を繰り返してしまいます。

特にエンジニアの人数が増えて1サービスで5人を超えたあたりからこの傾向は顕著になると思ってます。

個別最適化は、それはそれで大事なのですが、「ここの設計はこうするべきだ」という道筋を決めるのは大事です。

ただ全体設計の方向性というのは、時に変化するものですし、プロダクトがピボットすると0から考えなおす場合もあります。なので大きな転換や整理をする場合はgithub issueで話し合ったり、ログに残すことを意識しながら行っています。

 

あと意識的に「これって今は流れでこうやってますけど、本来はもうちょっと考えたいですよね」的な波風を現場が混乱しない程度にPRにコメントすることはあります。

過去の流れでよくない設計になっていて、それは絶対正しくないんだけど、今負債を返すタイミングじゃないし、みたいな時はあえて直さないという選択を取るんですが、それをやりすぎると「本来はどうあるべきか」みたいな思考を持たずにどんどん追加して行って傷口が広がる場合があるので、それの防止ですね。

特に最初からいるメンバーならそういった小さな傷もわかっているのですが、後から入ったメンバーはわからなかったり、逆に「え?これなんでこうなっているの?」みたいな不満にもつながるので、レビューを通して共有できるようにしていますし、「え?これなんでこうなっているの?」って思った人が直す時に手を上げやすくするという意味もあります。

 

それはやりたくないとは言わない

いわゆるスタートアップなので、いろんなものが降ってきます。

サービスのドメインSSLを自分で取ることもあるし、
情シス的な仕事もあるし、
社内要望をまとめてexcel管理しなければならないこともあるし、
インフラも当然見るし、
CSSやJSも必要ならば修正するし、
営業が使っているCRMをさわることもあります。

最近はメンバーも増えたので、いろいろ楽にはなりましたが!

ただ最後の砦じゃないですが、誰もやりたくないってなったらやるよという覚悟はあります。

「開発においてCSSからAWSまで」

はモットーです。

開発において誰よりも怠惰であろうとする

やっぱやりたいことがたくさんあります。全部やっていたらきりがないし、リソースは限られているので、「それは自分たちで作るんじゃなくて、外部サービスでできないか」とか、「楽に手間なくする方法は他にないのか」みたいなことは常に考えるようにします。

時に、エンジニアとして話し合うより、作るのが簡単な場面はあります。ただそれは単なる自己満足でしかないですし、作らずに目的を達成できたら万々歳ですよね。

 HRT を大切にする

Team Geek で紹介されている
Humility(謙遜)、Respect(尊敬)、Trust(信頼)

ですね。

特にSlackなどのチャットサービス上での会話やレビューにおいてはどうしても残るものなので、丁寧には心がけていて、なんかどうしてもカッとなったらまだ口頭で話したほうがこじれないかなと思います。

エンジニアリングに置いてのコミュニケーションはもちろんですが、開発者以外に対してのコミュニケーションにおいても大事にしています。スタートアップなんて狭い人間関係の中で仕事をしていますし、「あいつと合わないから」なんて理由で違う部署に異動とかも無理ですし、あいつとあいつが喧嘩しているなんてもうわかちゃうんだもん。

 

もちろん単なる仲良しこよしをしても意味はないので、HRTは大切にした上で言うべきことは言います。

 

もちろん聖人ではないのでテンションが落ちている時や飲み屋で愚痴ることはありますけどね!!!

 

その他

リードエンジニアの役割は会社によって様々で、個人的には

d.hatena.ne.jp


を参考にしています。

マネージメント的な役割やもっとビジネスサイドを踏まえた戦略に関しては弊社には歴戦の経験を積んだCTOとか 

www.wantedly.com


、他にも開発マネージャーもいるので、テックリード的な役割に集中できるので色々楽です。


 最後に

明日の 最後の締めは Viibar CEO にとってもらいます!