Voicyのテックリードの仕事紹介

はじめに

こんにちは、Voicyでテックリードをしている、みっきーです。 今回はVoicyのテックリードがどんな仕事をしているのかという話をしたいと思います。

 テックリードは職能の一つです。その仕事内容はVoicyのようなスタートアップの場合、投資ラウンドやエンジニア組織の大きさによって仕事の内容が変わっていきます。昨今さまざまなテクノロジーを活用したスタートアップが出てくる中で、会社によってテックリードの実際の仕事内容は変わってくるとは思いますが、Voicyの一つ事例としてご紹介します。Voicyのプロダクト開発組織は、執筆時点で27人です。この中には、PdM、デザイナー、エンジニアなどが含まれていて、テックリードの役割は私1人です。Voicyでテックリードの役割になったのは私が最初ですが、簡単にテックリードになった経緯を説明すると、2020年1月の入社当初はバックエンドエンジニアとして入社しましたが、様々な出来事があり、3ヶ月後にプロダクト開発のリーダー(開発責任者)をすることになりました。仕事内容としては、エンジニアリングマネージャーという役割をしていてエンジニアの採用やエンジニア組織作りを中心にしていましたが、テックリードらしい役割もしていて、将来、Voicyが音声プラットフォームとして安定して品質がよく長期に成長し続けられるように、開発生産性を上げるための技術の標準化、技術選定、情報セキュリティ(ISMS)、監視強化など、主に非機能要件といわれるようなところを中心にマネージメントをおこなっていました。エンジニア組織全体が20人を超えてきたところで、自分よりもピープルマネージメントに長けていたのと、組織全体がデータドリブンで動けるようになったこともあり、データ基盤を作っていた当時、データチームのリーダーであったやまもとにピープルマネージメントのバトンを渡し、私がテクノロジーマネージメントに注力していくことになりました。

 マネージメントというと、ピープルマネージメントをイメージする方が多いと思いますが、急成長していく組織においては開発をしていく上で必要な役割が3つ必要です。わかりやすい説明として、広木大地さんが、クネビンフレームワークを元に説明したツイートをご紹介します。

 クネビンフレームワーク(Cynefin Framework)とは、VUCA(Volatility、Uncertainty、Complexity、Ambiguity)の世界において、実際の世界をどのようにとらえて、どのように考えて行動したらいいかを体系づけたものです。創業当時はChaoticな問題がほとんどなのでその役割をになう人がCTOの役割として行動し、プロダクトマーケットフィットが上手くいくと組織が大きくなっていきComplexな問題が多発していきます。こうしていくるとエンジニア組織づくりを得意とした専任のVPoE/EMの役割の人が必要になってきます。サービスが順調に成長していくと、今度はさまざまな難易度の高い技術的な課題(技術的負債など)の解決が必要になってくるため、テックリード的な仕事が必要になってくるということが、実体験からもわかります。Voicyでは、創業時は共同創業者の窪田がChoticの時代をすすめ、シリーズAのComplexな時代なってくると様々なEMがエンジニアリング組織づくりをおこない、いよいよシリーズBになってくるとComplicatedな時代になってくるので、テックリードを専任で割り当てていくとバランスのよいエンジニア組織になっていきます。

前置きは長くなりましたが、実際にVoicyでやってきたテックリードの仕事を1つご紹介します。

ライブラリの標準化

 入社したときに最初に着手したのはGoライブラリの標準化です。入社して驚いたのが、バックエンドAPIで利用しているORMのライブラリが3種類あったことです。それは、xorm、 gorm、sqlboilerでした。前職ではRailsを使っていたのでActiveRecord一択しかなかったのですが、当時のGo開発はデファクトスタンダードがない状況だったのと、個人のエンジニアが好きなライブラリを選んで作られており、その時に決済サービスの新規開発やバックエンドAPIのリプレイスが必要だったため、このタイミングでライブラリの標準化をおこないました。また、これらのライブラリを用いたレイヤードアーキテクチャ構成のAPIサーバーの標準テンプレートも作成しましたが、私はライブラリ選定だけおこないました。

主な利用ライブラリ

注: 2020年時点の選定です。

 Webフレームワークはechoを採用しました。これはすでに同じフレームワークを利用していたこともあり、学習コストの面で継続しました。ORMは、1つのデータベースが複数のサービスから呼ばれていることもあったため、スキーマから自動で構造体を生成してくれるSQLBoilerにしました。それ以外はすでに使われていたライブラリでしたが、似たようなライブラリも存在するため固定することに意味がありました。

社内で利用実績があるというのも大事ですが、自分が自身をもってライブラリを選定するときに、私が参考にしている情報をいくつか紹介します。

実際に利用して習得しやすいか?

社内の利用実績があったとしてもすでに使っていた人が退職している場合もあって聞けないこともあるでしょう。そのため、実際に似たようなライブラリと比較して使いやすいか、コードを読んで理解できるか、修正可能かコードリーディングをします。

Githubスターの数

利用者が多いと不具合の改善が早いことが多いです。testifyはテストモジュールの中でもスター数が多く、テストコードを完結に書けます。

ソースコードの更新頻度が高い

リリースマネージメントが定期的におこなわれているかが大事です。もし、コードに脆弱性が見つかったとしてもセキュリティーパッチが早く適応される可能性があります。

コピーレフトなライセンスのソフトウェアを利用する

代表的なのは、MIT LicenseとApache License 2.0です。利用は自己責任ですが、商用利用が可能です。凖コピーレフトLGPLや、コピーレフト型のGPLは改変したソースコードの開示が必要ですので気をつけましょう。

個人スポンサーや企業がサポートしている

OSSはそれ自体が利益を生み出すことが難しいですが、エンジニアは無給メンテナンスはいずれ限界がきます。Githubの個人スポンサーや企業がメンテナンスしているとお金に余裕があるため安心感があります。もちろん、企業経営に左右されるコードが突然ダウンロードできなくなることもあるため、利用する場合はフォークしておくのがおすすめ zapはUber社のOSSです。またVoicyで利用しているフロントエンドフレームワークはAngularでGoogleが開発しているフレームワークです。

後方互換性をv2、v3などで明示されている

echoとsqlboilerです。長期にメンテナンスされるということは、後方互換性を維持していくのは大変困難になってきます。ライブラリをインストールするときに明示的に選べるほうが、利用する側もバージョンを固定できるので利用しやすいです。

コントリビューターの数

ライブラリによっては1人で開発されているのはありますが、長期的に見たときには作者の心が折れて更新が止まってしまうことがありそうするとセキュリティーパッチの対応もできなくなります。コントリビューターの数が多ければ、改善もされますし、オリジナル作者がギブアップしたときもバトンタッチされることもあります。

マイナーだけどどうしても使いたい

それでも、自分でライブラリは作りたくないが、どうしても作者1人しかいないときのライブラリを使いたい時はどうすればよいでしょう? それは自分自身の信頼度を上げれば良いので、責任を持って全部のソースコードを読んだ上で使うか判断するのと、後任のためにドキュメントを残しておくとベストです。 でテックリードになりました。

最後に

他にも、話せることはたくさんあるのですが、もっとテックリードの話しが、聞いてみたいという方、ぜひMeetyでお話しましょう

meety.net

そして、これからのキャリアを考えるときに、どの道に進んでいくか具体的な役割について知りたい方は下記の書籍を読むのをおすすめします。

www.oreilly.co.jp この本は、テックリードとは何をする人なのか説明した数少ない本です。

www.oreilly.co.jp テックリードは、普段の仕事をしているだけでは必要な知識を身につけるのは難しいです。何事も基礎は大事ですので、この本では効果的なソフトウェアアーキテクチャの設計、構築、維持をするために必要なスキルや知識が体系立てて解説されています。全体を俯瞰してみるのにとても良い本ですのでおすすめします。

それでは、また次回、投稿されるのをお楽しみに!