自分の「やりたいこと」を会社の「やるべきこと」に結び付けてWin-Winに。SRE課でGitの改善に取り組む渡邉さんのお話 #ヌーラバーになりませんか

ヌーラボのインタビュー企画第19回目。今日はこれからヌーラボが強化していきたいBacklogのSREを担当するチームの中でもGit機能の改善・強化を担っているチームからなべさん (vvatanabe) のお話を伺います。

昨年はGoCon Sendaiで登壇するなど大活躍!Goという強みを持つなべさんに、今後のGitチームとしての取り組みについてインタビューしてみました!

 

今日のInterviewee

サービス開発部 SRE課 渡邉 祐一

2015年、ヌーラボにバックエンドエンジニアとして入社。現在はBacklogのGitホスティングにおける機能やミドルウェアに関する開発を担当。Goでの開発を得意としGo関連のイベントなど多数の登壇や技術誌への寄稿の実績あり。

 

東京から福岡へのUターン

— なべさんは東京で働かれたあと、Uターンで福岡に戻ってこられたんですよね!ヌーラボに入社してもう何年です?

丸5年くらいですね。福岡でWeb系のソフトウェア開発の経験を積んでから、東京で挑戦してみたくて一度は上京しました。東京では、SIer、受託開発、自社サービスの開発・運用・営業と手広くやっていました。その後、結婚を機に同郷の奥さんと一緒に福岡に帰ってきました。福岡に帰ってくる時に色々調べていたら、前職で使っていたBacklogやCacooの会社は福岡に本社があるということを知り、地方都市からインターネットを使って世界に向けて発信する可能性のようなものに感化されて、応募しました

 

— 採用選考の時に、ご自身のプライベートで作ったスマホアプリをたくさん見せてくださった…と選考に関わった人から聞いたことがあります。現在もカンファレンス等のイベントで登壇しているなべさんですが、当時から業務外でもアプリを手掛けていたのですか?

当時は、JavaでAndroidアプリを作っていたのでそれを見せたりしてましたね。今はもうGoogle Playストアから削除してしまって使用できませんが、Sound CloudのAPIを使って抽出した音楽データを使ってアプリ上で再生したり、自分専用のプレイリストを作成できるようなアプリでした。以下は思い出の画面のキャプチャです。再生するとアナログレコードが回転するターンテーブルっぽいUIがお気に入りでした。

当時開発していたアプリの画像

 

とはいえ、ヌーラボに入社してからの方が対外的な活動の量は多くなりました。むしろ昔は今と比べたら何もやれていなかったと思います。最近は対外的なアウトプットのやり方にも慣れてきて、活動量が少しづつ増えていっているのかもしれません。

 

ヌーラボ入社後のアウトプットの変化

— ヌーラボに入ってから何か活動量が増えていくようなきっかけを得たのですか?

今振り返ってみると、ヌーラボに入ってからは、自分の成果を積極的に社外へアウトプットする人が多くいる環境に身を置けるようになったのが大きな要因かと思います。

社内の技術ブログやイベント等への登壇だけでなく、WebDB Pressや書籍の執筆などをしているメンバーがたくさんいたので、僕は確実にその人たちの影響を受けています。実際に身近にそうゆう事をやっている人達がいると、今までどこか他人事だったアウトプットの選択肢が自然と自分事として考えれるようになっていました。

WebDB Pressの特集記事として[速習]gRPCを寄稿させていただいた時も、きっかけは社内で寄稿したことのあるメンバーからの紹介でした。その当時ヌーラボでもCacooが先行してgRPCが導入していて、ちょうど携わっているBacklogの開発プロジェクトでサービス間通信にgRPCを選択して進めていました。「書いてみる?」と声を掛けられた時は、挑戦したい気持ちも大きかったのですが正直不安な気持ちもありました。その様子をくみ取ってか、「絶対良い経験になるので、1回挑戦してみなよ」と後押しされ、私自身がその人のことをかなり尊敬していたということもあり決め手になりました。

この件だけではなく、自分がなにかにチャレンジしようと踏み切る一歩手前で悩んでいる時、相談しやすかったり、最後の一押しをしてくれる人達がヌーラボには多いと感じています。

また、多くの同僚達が自分が執筆したり登壇する内容の相談に乗ってくれていたのはとても助かっていました。時には壁打ちと言ってブログに書く内容を考えるところから会話して整理させてもらったり。

アウトプットをする癖が身についたのはそのおかげです。相談に乗ってくれいていた同僚達には本当に感謝しています。

 

ヌーラボアカウントからBacklog、そしてSREへ

— そうやっていまのなべさんが出来上がっていったのですね!ヌーラボに入った当時は現在所属されている部署である「SRE課」という部署はありませんでした。色々な部署を経験されていると思うのですが、入社直後はどんな領域を担当されていましたか?

まず、入社してからは研修の一貫でTypetalkに機能を追加することになりました。そこで作った機能が今も使われている「@all」や「@here」などのメンション機能です。TypetalkはScalaで動いているので、その時はScalaを覚えながら開発しました。

その後、ヌーラボのサービスを繋いでいるシングルサインオンアカウントを開発しているチーム「Apps課」に参加してパスワード強度測定機能を開発しました。よくサインアップでパスワードを決定する時に強度を示すメーターが表示されていると思うんですがアレです。

その時作ったパスワード強度測定のコアロジックをJavaのライブラリをnulab/zxcvbn4jとして公開してます。
詳細は「真のパスワード強度を測定する5つのアルゴリズム」で紹介しています。OSSとしてリリースから5年間、いまも地道にメンテナンスを続けています。

ちょうど去年のヌーラボのアドベントカレンダーで、「5年間のOSS活動で学んだエコシステムの広がりと多用な関わり方」という記事を書いて、このライブラリのメンテを通して学んだことを振り返ってみました。

 

— すごい。5年たった今でも使われているものばかり。研修…なの…?(笑)私が入った2016年頃にはAppsチームに所属されているイメージが強かったです。今はGoで開発しているなべさんのイメージが強いですが、当時は結構JavaやScalaも書いていましたよね。

当時、Appsの開発をしているメンバーは現開発部長の馬場さん含めても2名ほどしかいなかったので、そのチームを強化するためにも僕も参画しました。ヌーラボはJVM系の言語で開発されているプロダクトが多く、AppsはJava/Springで開発していました。

前述の研修も終り、改善活動を粛々と進めてAppsにある程度慣れてきたところで、ユーザーからの要望も多かったSAML認証を追加しようと調査を進めていたのですが、そもそもヌーラボの大黒柱であるBacklogがAppsと連携できていなかったので、SAML認証を届けたいユーザー層にリーチできなければ今作っても我々もユーザーをうれしくないよね、という話になりました。とういことで、SAML認証を実装する前に、Backlogとヌーラボアカウントを連携させることになりました。

(SAML認証が後にNulab Passという新たなプロダクトの一部としてリリースされるとはこの時は誰も想像していなかったと思います。)

Backlogとのアカウント連携ということもあって、AppsとBacklogの両方に手を入れることが多かったのですが、BacklogはもともとJava/Seasar2で開発されていて徐々にScala/Playに移行している時期だったので、必然的にScalaを書くことが増えていきました。そして、プロジェクトが終わる頃にはBacklogのドメイン知識の方が豊富になっていたので、そのままBacklogのチームに異動していました。

 

“Try First” Goを用いたプロダクト開発にチャレンジ

ちょうどその頃からGoを独学で勉強し始めたと思います。静的型付け言語でありながらコンパイルが早い言語と聞いたので、今後仕事でも役立つかもしれないと思って触っていました。2017年の3月くらいですね。

早速その後、2017年4月くらいにはTypetalkのAPIクライアントをGoで開発してリリースしました。TypetalkのPDMの吉澤さんが「ほしいな〜」と言っていたのでサプライズで作ってみたんですよね。書籍やドキュメントを見るだけでは覚えられないタイプなので、まずはなにか開発して知識を定着させようと必死でした。

 

— APIクライアントってサプライズで開発するものなんですか(混乱)。この辺からなべさんがGoと出会っていくのですね。

そうですね、だんだんGoの面白さに気づき始めた時でした。

また、Fukuoka Goのコミュニティの存在を知れたのもこの時期でした。最初は勉強会の参加者として関わりました。仕事でもGoを使うようになってからは積極的に成果を発表するために発表者として応募するようになりました。Fukuoka Goから学んだことは、ここでは全て書き切れない程たくさんあります。

昨年のコロナ禍でIT系に関わらずたくさんのイベントが中止を余儀なくされるなか、かなり早い段階でオンラインイベントとして切り換えていたのは記憶に新しいです。誰も予想しなかった目に見えない巨大な壁に、インターネッツを駆使して立ち向う姿にとても勇気をもらいました。運営の皆様はじめ心から尊敬するコミュニティの一つです。

2019年には福岡のエンジニアフレンドリーシティ主催のコミュニティアワードも受賞している
いい感じのコミュニティです

 

その後、業務でGo書いたのはBacklogのGitのサーバーの一部の機能をGoでリプレイスした時だったと思います。自分の中ではGoでリプレイスすることで運用面がより楽になると思っていたのですが、あくまでそれは仮説に過ぎません。Goでリプレイスする価値があるのか検証するために、まずはプライベート(趣味として)で実装して検証するところから始めました。

仮に思うような結果がでなくとも、自分が得るものは大きいと思えたことが最大のモチベーションになっていたと思います。プロダクションを意識したサーバーのコードを書くことでGoの基礎力を上げる、さらにGitの独特なプロトコルをコードに落とし込むことでプロトコルの理解やドキュメントを読む力を鍛えるといったところも目的の一つでした。

このリプレイスの詳細は以下のブログとスライドで解説しています。

 

— ひゃ〜!🥺 なべさんって趣味で学んだことを仕事の成果としてしっかりアウトプットするのがすごくお上手ですよね。やりたいことと、やるべきことをうまく結びつけて成果にしているというか。すぐ手を動かしちゃうし。

そこは私自身かなり意識していることです。仕事で求められていることを自分の勉強と絡ませていくようにしています。ただし、そういったマインドだと仕事とプライベートの境目があやふやになりがちなので正直良い所ばかりではないのですが、せっかくなら自分が携わるプロダクトとの関係性を築きやすい技術に学びの舵を取るのもわるくないなと思ってます。

 

SREとして本格的なGitホスティングの改善へ

— 色々なご自身の努力も重なって、2019年1月にSRE課が立ち上がる時になべさんもSRE課に異動したんですよね。

そうです。Backlog、Cacoo、Typetalkのインフラを横断で見れるようにすることを最終的な目標としたSRE課ができました。

最初は、Backlogが提供するGitホスティングを支える各種サーバーのリプレイスをGoで進めていました。前述のGitの一部の機能をGoでリプレイスしたことで得た知見もGoを選定した動機に大きく影響しています。詳しくは「Tech practice for replace Backlog’s Git services in Go」や「BacklogのGitを支える技術」で紹介しています。

その他にも、Gitが得意ではない大きすぎるファイルの処理によるパフォーマンスの劣化を解消すべくGit LFSの機能を開発しました

現在は、Gitホスティングでボトルネックなっているストレージの課題についても、調査や検証を進めています。Gitリポジトリを保持するストレージの冗長化をどのようなアプローチで解決するのかといったところが要になるのですが、様々なアプローチの内の一つをGo Conference ’20 in Autumn SENDAIで「GitホスティングにおけるGoとgRPCを用いた複製と分散のアプローチ」という形で紹介させていただきました。

 

— これからGitホスティングを専門で進めるチームを立ち上げていくことになると思いますが、Gitホスティングの開発や運用って一般的なのWebアプリケーションとどう言った違いがありますか?

必要なデータをなんらかの永続先から取得して、特定のフォーマットに成形してユーザーへ返却するといった点は同じです。

大きな違いは、そのデータの永続先と取得方法です。

一般的なのWebアプリケーションだと、RDBからSQLを使ってデータを取得してJSONなりHTMLに成形して返すことが多いと思います。

Gitホスティングの場合、基本的にリモートリポジトリから必要なデータを取得してます。その際、直接リポジトリのツリーを解析するプログラムを書いて抽出したり、場合によっては適切なGitコマンドを使ってデータを抽出することもあります。

また、Git独自のデータ構造やプロトコル、処理フロー、ライフサイクルを理解して規約に沿ってコードを書く必要もあります。例えば、HTTPやSSHを介してリポジトリへアクセスするためのプロトコルの実装、GitのSSHアクセスのためのスタンドアロンなSSHサーバーの実装、Git LFSを提供するために必要なサーバーAPIの仕様等が上げられます。

勿論全てフルスクラッチで書いているわけではなくOSSのライブラリも導入しているので、なにか問題が合った場合、ライブラリやGitコマンドのソースコードそのものを読んで調査する事もあります。時にはOSSのバグ修正や足りない機能の追加のためにプルリクエストを送ることもあります。調べながら少しづつ掘り下げて進めることが多いです。これからチームに入ってくれる人は、その過程を一緒に楽しんで取り組んでくれる人がいいなと思います。

 

— このタイミングでGitチームを強化できたら、チームとしてどんなことに取り組んでいきたいですか?

まずはチーム体制を強化したいですね。今は、アプリケーション寄りの開発をしている私と、インフラ寄りの 中野さんの2名体制でスタートしようと準備を進めています。Goを書いてもらいながら一緒にインフラ周りのことにも取り組んでくれるような人に参画してもらい、それぞれの強みを活かしつつ、3人共にバックエンドアプリ・クラウドインフラを扱っていけるようなチームにしていきたいです。

BacklogのGit自体はまだまだ機能は多くはないので、新しい機能の開発にも着手できるチャンスが多いチームだと思います。そして、Backlogは日本だけでなく海外にも展開しているサービスなので、今後の国内外含めて、非エンジニアでもキャッチアップしやすいGitホスティングの実現に取り組んでいけたら嬉しいです。

 

2021年の抱負、チャレンジしたいこと

— ありがとうございます!採用頑張りましょう!最後に、なべさんが最近気になっていることや、今後挑戦したいことはありますか?仕事・プライベート関係なく!

前述の通りGitチームの体制作りもそうですが、Backlogらしい「非エンジニアでもキャッチアップしやすいGitホスティングとは」というテーマについて考えを深めて行けたらと思っています。

それに関連して、競合他社のサービスを注意深くウォッチし続けたいです。特に最近はNotionが気になっています。昨年、タイムラインビュー(ガントチャート)をリリースしていたのは記憶に新しいです。タスク管理系のプロダクトの中では後発なだけあって、先発の我々のようなサービスの良し悪しも理解した上で作られていて、細かい部分の品質がとても高いです。使っていると危機感を覚えるような瞬間が多々あります。なので「自社サービスを使い込む」ことと同じくらい「他社サービスを使い込む」ことも大事だと思っています。やりたいこと・考えたいことは尽きないですが、欲張って行けたらと思います。

 

— なべさん、ありがとうございました!

開発メンバー募集中

より良いチームワークを生み出す

チームの創造力を高めるコラボレーションツール

製品をみる