はじめに
22卒エンジニアの木本です。Rettyに入社して早くも6ヶ月が経過したとのことで、振り返りTech Blogを書く企画の3人目となっています。
前回は中岡の「未経験でデータアナリストになり、半年が経ちました。」でした。 engineer.retty.me
自己紹介
出身: 国立東京工業高等専門学校 機械情報システム工学専攻(それぞれ「東京高専」「AS」と略してましたので名前の長さで困ったことは外部での自己紹介くらい)
好きな食べ物: ラーメン。博多系ラーメンや家系ラーメンが好きです。
好きな飲み物: コークハイ
入社するまでの自分
昔からパソコンオタクで、小学生の頃からJavaScriptで遊んでいました。そして高専の情報科に入りずっとプログラミングばかりしていたのですが、残念ながらチーム開発をほとんどしてきませんでした。
プログラミングといえば個人開発の素振りで、レビューを受けることも無ければ人に見せることもほとんどなかったし、成果物を人に見せることもあまり経験がありませんでした。学内のコンテストに出るときもほかがチームを組む中一人でモクモクと進め、卒業研究も一人プロジェクト。良くも悪くも自己満足の世界に浸っていました。
なぜRettyに入ったのか
そんな私がRettyに入った理由は以下の3つです。
1. 強そう
RettyはLeSSと呼ばれる開発手法を取り入れるなど、組織のあり方を変えつつ成長していく組織です。
ファーストキャリアとしては、変化しない大企業に入って頭数として仕事をこなすよりも、Rettyのような小さいけども変化していく組織にいる方がより多くのことをやらないといけないし学べそう
……というようなことを何倍もぼやかしたことを当時思っていました。もっと単純に言うと、「強そう」「強くなれそう」でした。
2. カルチャー
Rettyは率直に話しつつも建設的議論をするカルチャーがあり、それがしっかりと定着していました。心理的安全性のある職場で働きたいという思いがあり、その点も個人として合っていました。
3. ユーザーのことを考えるtoCメディアであること
Retty Wayといわれる3つの行動指針の中にUser Happyという言葉があります。これはユーザーがハッピーであるかをとにかく考えるという意味で、User Happyというあり方は明らかに役に立つと思えました。
企業は基本的にBtoC(一般消費者をターゲットとする企業)とBtoB(企業をターゲットとする企業)に分かれると言われますが、BtoC企業のほうがリターンは大きい代わりに難易度は高いと言われます。User Happyを掲げるBtoC企業であるRettyに入社することで、不特定多数の一般ユーザーにHappyを届けるための経験を得ることができると思いました。
Rettyのチーム開発で学んだこと
初めてエンジニアとしてフルタイムでチーム開発で働いてみて学ぶことが沢山ありましたが、その一部をまとめたいと思います。
Working Out Loud
今までの個人開発では、逐一報告しながら作業するという経験はほとんどありませんでした。
Rettyには内定者インターンという制度があり、このタイミングで自分は初めてチームのSlackに入って、細々としたコード整備のタスクをこなしていました。
しかし、先輩エンジニアに緊張してしまい、なかなかコミュニケーションをとることができなかったのです。
質問などをチームのチャンネルで聞くことが怖くてできず、分報チャンネルで聞いたり、ドキュメントを検索してなんとかしようとしていました。
そのため、バカでかいPRを出してしまったり、あまり良くない命名をしてしまったり……という良くない開発を続けてしまっていました。
そんな中で学んだのは、Rettyでも浸透しているWorking Out Loudという概念でした。大声で叫びながら作業をするという考え方です。チームメンバーがわかりやすいところで作業内容をどんどん出していき、詰まったらすぐに質問することで、すぐに手助けに入れるようにしておくという思考方式です。
そういった考えを身に着けることで、Rettyエンジニアの手助けを得つつ開発ができるようになっていきました。
また、より効率よく外のエンジニアから助けを求める方法としてペアプログラミングやモブプログラミングなどがあり、こちらも活用することで手助けを更に受けることができます。
フィードバックを受ける
Rettyでは、開発に携わるメンバーはプランニングするプロダクトマネージャー(PdM)と実際に実装するエンジニアに分かれており、開発物の振る舞いを最終的に確認するのは施策をプランニングしたPdMとなっています。
入社したての頃、コードを書くことが仕事の主で、GitHubなどでフィードバックを受けることは最後の確認だと考えていました。
しかし、失敗が起こりました。急いでいたページリニューアルタスクで、フィードバックを受けないまま仕事を進めたため、最終確認でPdMさんからの修正事項が沢山発生したのです。結局修正事項を急いで直していきましたが、広告について外部との連携が必要な部分は最後まで修正できず、2週間も掛かってしまいました。
この経験から、フィードバックを早めに受けることで手戻りを少なくすることができることを学びました。あらかじめ開発途中のページをPdMさんに見せておけば修正事項は開発中に直せただろうし、広告の連携についても早めに動けただろうと思います。
そこから他人や非エンジニアを巻き込んで仕事をすることを心がけるようにしました。非エンジニアを巻き込むには、できるだけ早めに見せる、そのためにできるだけ早めに見せられる開発が必要です。
例えば「バックエンドのデータベースを叩く処理を作る」→「フロントエンドを作る」というような方法を取っていましたが、これは早めに見せられる開発ではありません。
フロントエンド用にモックデータを作り、モックデータを読み込む設定でフロントエンドを作ることでデザインを最低限確認できるようにして、デザイン確認を早めに取ります。ここでフロントエンド関係の問題は9割方除かれます。その後バックエンドと繋ぎこみ、再度確認してもらうというような方法を取ることで、早めにデザインという手戻りが発生しやすい部分を単独で確認してもらうことが可能です。また、この方法ではバックエンドの部分を切り出してチームの他メンバーにお願いすることも可能です。
このようなチーム開発でのコツは実際に会社で開発することで初めて得られた経験になりました。
説明能力
プログラムを書く上で常に意識することは「『あるべき』がどこにあるのか」ということです。今まで個人開発などでは、「あるべき」は抽象的に頭の中で納得して実行すればそれで解決していました。しかし、組織内でそれを実行するのには別のノウハウが要ります。
それは、なぜそうしたいのかを説明し、建設的な議論をする能力です。その実装は本当に設計として正しいことなのかについてエンジニア間で議論になることもありますし、それを建設的な議論であるべき姿を探さなければなりません。
また、その「あるべき」には時間・工数というファクターも組み合わさります。そうすると、非エンジニアにも説明責任を果たす必要があります。例えば〇〇という機能をAという方法でやれば1日で終わるのに、Bという方法でやれば10日かかる。でもBの方が正しいやり方のようだ、という時に、その10日掛ける価値をPdMに説明する必要があるのです。
この能力は今も私が課題としている能力だと思っています。なぜAという実装方法はダメだと思って、Bという実装方法の方が良いと思うのか、そういった説明能力の不足により仕事が上手く行かなかったり、チームの合意が取れなかったりするということはままありました。建設的な議論もあまり上手くないので、今後も伸ばしていく必要のある能力だと思っています。
チームで開発するということ
上3つには共通点があり、すべてコミュニケーションに関するものでした。2つはコミュニケーションの量、最後の1つはコミュニケーションの質についてのものです。
アフリカのことわざに「早く行きたければ一人で進め、遠くに行きたければみんなで進め」という言葉があります。個人開発と違いチーム開発は遠くに行くことができます。人数をスケールさせることができ、各自がそれぞれ専門性を持つことで、巨大で複雑なものを作っていくことができます。
そんなチーム開発を進める中で最も重要なことは、コミュニケーションで目線をあわせることでした。
Rettyに入社するまで、エンジニアの仕事はソースコードに向き合うものだと思っていました。しかし実際は、コミュニケーションを取って技術力でチームに貢献する仕事でした。開発において最も重要な言語は、JavaScriptでもTypeScriptでもPythonでもPHPでもJavaでもKotlinでもRustでもGoでもCでも機械語でもなく、日本語です。「チームで開発するならコミュニケーションは思ってる倍たくさん取ろう」と今では思っています。
おわりに
エンジニアとしてのファーストキャリアとしてRettyを選んで本当に良かったと思っています。他の人から学ぶことがとても多く、いろいろなことを任せてもらえる環境です。
これからは一歩踏み込み、更に外部へも発信していく勢いと、設計議論にも入っていける深みを持つ立派なエンジニアになっていきたいと思っています。
Rettyへの入り口はこちら↓
