🗻

エビリーに入社して一年が経ったので振り返ってみた

2022/12/26に公開

アウトプット

idea

tech

冬生まれなのに寒さが極めて苦手な人です☃
蓄えた皮下脂肪は何の意味も持ちません。

2021年12月に『kamui tracker』のエンジニアとして入社してから1年が経ちましたので取り組んできたことや感じたことを書いていきます。

はじめに

歩く壁と書いてごとーと申します。
前職はインターネット広告のプラットフォームを作っている会社におり、中途でエビリーに入社しました。

前職ではPHPやJavaをメインにRailsやVue.jsを少し触っていた程度です。

脳筋です。

エビリーに入社したのは社内やチームの雰囲気が良かったのとコーディングする機会が比較的多そうだったからです。
ベンチャー企業は初めてでしたが多くの経験をさせてもらえました。
すべてを書くことはできませんが一部ご紹介できればと思います。

この一年でやってきたこと（一部紹介）

1２月〜1月

kamui trackerのテストコードをひたすら書く

入社した当時は既にテストコードを書く文化になっていました（原則としてテストが通らないとレビューはしてもえません）。
しかし、過去に作成されたコードは一部テストが書かれておらず、テストコードが不足している状態でした。

そのため、最初の2ヶ月は「プロダクトの仕様の理解を深める」という目的もありテストコードを書くことになりました。
RSpecを本格的に触ったのも初めてでしたが書き方が慣れないと大変で個人的に苦しみました（一月で8kgくらい増えた、、、🤫）

とはいえ、ここでプロダクトについて理解が深まり何より後々テストコードの重要さを知りました。
今ではテストコードの無いリリースは心臓止まりそうになります。

1月〜3月

コメント分析機能の開発に関わる

kamui trackerではYouTubeに関する膨大なデータを保有しており、それらの分析結果をサービスとして提供しております。
以前、当社の栗原がコメントについて分析した記事を投稿しましたが、このようなコメントデータは「コメント分析機能」という形で提供しています（詳しくはプレスリリースをご覧ください）。

この機能の実装の一部を担当しました。
リリース日が絶対だったこともあり文字通りチーム一丸となって取り組んだプロジェクトでした。
入社して話を聞いてから携わりたかったプロジェクトだったので本当に楽しかったです。
個人的に大変だったのは例外処理の部分でした（いつか書く機会があればまた書きます）。

4月〜10月

バグ修正

この頃から仕様を理解してきたこともあってバグを見つけることが多くなり修正が主務となりました。
振り返ればつい先日までやっていた気がします。
バグと言っても色々ありますが全然携わったことのないコードや外部サービスを調べることが多く、特にAWSに関してはほぼ未経験に近かったですがこのバグ修正で触る機会をいただけました。
下記はこの期間で「大体触れる」というレベルになったものです。

EC2
RDS
S3
Lambda
ECR
ECS
Batch
EventBridge
SageMaker
Route53
CloudFront
CloudSearch

また、その原因を調べることが多く調査力が非常に身につきました。

でも調べて修正するだけでは面白くないのでついでに処理速度を上げてみたり。。。
こういう自由さを許してくれるところがこのチームといいますか会社の良いところです！

11月〜現在

バグ修正と新機能のAPI実装をGoでやる

バグ修正はまだありますが、だいぶ落ち着いてきました。
そういうのもあって現在は新機能の実装をGoでやっています。

1年前に入社した頃と比べると今夏からスクラムを導入してチーム体制が大きく変わっています。
タスクは増えていますがいい具合に消化できるようになり何より「誰が何をやっている」ということがわかりやすくなったのがチーム力を向上させたのではないかと思います。

スクラムについては以前、下記記事を書いた渡辺が主導で引っ張ってくれています。

以上がこの1年を通してやったことでした。
バグ修正に工数を使ったもののプロダクトの仕様理解からプロジェクトに関わるという一般的な流れを経ています。

この一年で感じたこと（学んだこと）

発言、提案って非常に大事

欧米では

発言しないのは、その場にいないのと同じ

という考え方が主流ですが個人的にそれを痛感した一年でした。
前職では開発チームに意思決定権がほとんどなくマネージャー陣で決まった仕様を実装することがほとんどでした。
ところがエビリーに入って驚いたのはメンバー自ら主体的に会議等を設定して議論を進めることが多いことでした。

体制が変わったこともありますが要件だけもらってあとは自分たちで仕様を考えたり、必要であれば自分たちからプロダクトオーナー等に「これをやりたい」という提案が可能な環境です。
むしろ提案しないことがもったいない感じで特にkamui trackerでは「手を挙げれば基本的にやらせてもらえる」ことが多いです（当然、提案を納得してもらえる根拠や説明力は必要ですが）。

年明けからデータ基盤の再構築プロジェクトがスタートする予定ですが、それらもメンバーから提案された内容でサービスの根幹に関わる大きなプロジェクトになると思います。
やりたいことをやらせてもらえる環境では発言や提案は非常に大きな影響力を持つんだなと実感しました。

ちなみに他のメンバーは私から見て非常に優秀な人たちで技術に対しての知見や経験が多いのですが、話を振ってくれたり何か質問したり相談したりすれば話を聞いてくれたりフォローしてくれたりと温かいチームです。

積極的に発言できる人間ではないですがメンバーとしている以上、少しずつ発言していけたらと思います。

テストコードほんと大事

開発過程で個人的にはテストコードの重要性を知りました。
書き方もほとんど知らない状態で冒頭に書いたとおり最初は苦痛以外の何物でもなかったですが、今となってはテスト様様です。

振り返ればバグでアラートが上がった場所のほとんどはテストコードがないかテストケースがないかのどちらかでした。
逆に言えばそれらがあればほとんど防げるようなものでテストコードを書くという文化を身に着けました。

外部サービス等はmockを介するので厳密なテストができない部分もありますが、テストコードがないよりは精神的に楽になります。

kamui trackerはYouTube Data APIありきなのでデータ取得から整形までの処理は最重要部分です。
外部サービスなのでAPIは直に叩けませんが、そういったテストコードでカバーできない部分はスタブやモックを作るなどして動作確認をできるようにして品質を保つようにしています。

一方で、ちゃんとテストケースを網羅しようとすると冗長的なテストコードになり遅くなるのが課題です。
kamui trackerではGitHub Actionsでテストを実行していますが体感的には結構遅いです。
これによってその後のレビュー依頼までに時間がかかったり急ぎのタスクの場合はテスト完了を待つなど作業効率が悪いなと感じることもあります。

スピードを取るか品質を取るかの問題かとは思いますがどこかで処理を見直す必要があるかもしれません。

本格的にTDDを学んだことは無いので冬休みの課題にしたいと思います。

相談しやすい

入社を決めた理由の1つでもありますが入社してから全然変わらなかったことの一つが相談しやすい環境です。
私が所属しているプロダクト開発本部はリモートが多いこともありコミュニケーションツールとしてgatherやSlackを使っています。

リモートは顔が見えないので話しかけにくかったり文脈が分からなかったりすることが多いのですが優秀で多忙なメンバーやCTOにも気軽に聞けます。
メンバーのタスクにもよりますが基本的にはSlackで一声かければgatherに集まりますしSlackでも質問チャンネルで気軽に聞けます。
レビューをお願いすれば当日中には何らかの返信やスタンプが来るので個人的には居心地の良い環境だと思っています。

レビュー力とは技術力

これはレビューを受ける側として思ったのですが、技術力がある人の指摘は、そこから議論が生まれていい方向に修正されていくなと体感的にわかりました。

例えば、書き方が複数通り考えられる状況で私がAというコードを書いた際、レビューする人はBを提案する状況を想定してください。
通常は以下のような記載になると思います。

「xxxなのでBの方がいいのでは？」

一方、技術力のある人の記載は以下になります。

「Aだとこういう部分があって、それだとこういうケースの場合○○を考慮する必要があると思いました。それならばBの方がその考慮をしなくていいと思うのですがいかがですか？」

本質的には同じこと指摘しているのですが、どちらのほうが心理的に受け付けやすいでしょうか？

レビューって非常に難しいと思っています。
その理由の一つが「コードの否定は相手の否定になり得る」からだと思っています。
これはコーディングという行為がその人の経験の集合体なのでコードを否定するということは、コードを書くために費やしてきた時間を否定するに等しいからです（明らかにバグを生む書き方は駆逐するべきだとは思いますが）。
私がそうですが技術的な視野が狭いとレビューはコードの書き方にフォーカスすることが多いです。
「そのif文、三項演算子の方がシンプルでは？」など。
レビューの対象となっているコードしか見てない結果だと思っています。

一方でkamui trackerでは技術力が高い人は基本的に致命的なバグ等で修正必須ではない限り、書き方について指摘することはあまりないです。
むしろ「どう変えたらもっと良くなるか」「今後サービスが変化したらどうなるのか」的な視点で見ているのでコードからは見えない視点で指摘をくれることが多いです。
ほぼ毎回気づきや考えるきっかけを与えてくれます。
とはいえ、こういうのって正解がない上にレビューを依頼した自分のコードをベースにして話が発展していくのでレビューを受ける側もコードを否定されたという感覚がなく逆に一緒に考えたくなります。
結果的にプルリクエストのコメント量が膨大になるのですが、今までコードの是非を問うレビューを受けることが多かったので精神的苦痛でしたがエビリーに入ってからは楽しみなイベントの1つとなっています。

どの分野でも謙虚な人ほど秀でている印象ですが技術もまた謙虚さが大事だなと思いました。
レビューは指摘する側の書き方とされる側の気持ちの問題という捉え方もありますが、技術力がある人は自然に相手を否定しない書き方ができていて、レビューされる側にもそれが伝わると感じました。
結局そこで生まれた議論からバグが少ないコードだったり、仕様変更に強いコードが生まれることが多かったのでレビュー力は技術力なんだなと思った次第です。

そこまで分かっていても、いざ自分がレビューする側になると心無い書き方をしがちなのでやはり技術力の足りなさを痛感します。

最後に

今回は技術的なことではなくエビリーに入社してやってきたこと、感じたことを述べました。

今年はチーム体制が変わったり修正が多かったりと予定通りに進まないことも多かったですが来年は更に楽しい職場にできたらと思います。

弊社に興味があったり、プロダクト開発チームのことをもっと知りたい
という方がいましたらお気軽にご連絡ください！

▼一緒に働いてみたい！という方はこちら
https://recruit.eviry.com/

▼kamui trackerを利用してみたい！という方はこちら
https://kamuitracker.com/

今年もありがとうございました、来年もエビリーをよろしくお願いいたします。
みなさまも良いお年をお迎えください！！