注目キーワード
  1. react
  2. docker
  3. インターン

3週間のフルリモートの新卒研修を振り返ってみる

新卒でCyberAgentに入社した@DragonTaro1031です。コロナの影響もあり前代未聞のフルリモートでの研修だったので、そもそもの研修の振り返りに加えてリモートという環境下で何を工夫したのかということを振り返ってみたいと思います。かなりの長文ですがお付き合いください。

研修の内容

研修の内容

研修は全体研修(4/1〜3)とチーム開発を行う技術研修(4/6〜4/24)にわかれていました。前半の全体研修に関しては、我らが技術人事のボス、みねさんが濃密な振り返り記事を書いておられるのでそちらを読んでみてください。

CyberAgent Developers Blog

こんにちは。技術人事本部の峰岸(@mine_roto)です。 2020年4月1日。サイバーエージェントには、77名の新卒…

このブログでは、後半の技術研修で自分がどのようなことを学べたのか、リモートという環境下でどのようなことを工夫したのかということを振り返っていきます。

 

技術研修の課題

技術研修では、SNSサービスを作ろうというお題でした。5人1チームでそれぞれ職種もばらばらです。(Unityエンジニアやデータサイエンティストも)

仕様は、

  • 投稿ができる
  • ユーザーをフォローできる
  • 投稿の参照やいいねができる

という最低要件さえ満たしていればあとはなんでもokというルールです。

また、役職がいくつかあって一人一つ必ず役割を担うという制約がありました。僕はその中でバックエンドのテックリード(技術的な意思決定や環境構築などに責任を負う役割)でした。

このような役割を設定した理由としてチーム開発におけるオーナーシップ(自分が指揮をとりみんなをまとめる能力)とフォロワーシップ(みんなをサポートしチーム全体を盛り上げる能力)という二つの能力を伸ばして欲しいという意図があったようです。

エンジニアとしてのプロフェッショナルよりもチームを主導していけるエンジニアを目指したい僕としては伸ばしていきたい能力だったので意識的に試行錯誤を繰り返してみました。

 

 研修を通しての個人の目標

どこかにまとめて書いていた訳ではないですが、チーム内で宣言して意識的に行動していた部分です。
エンジニアとして
  1. 新しい技術に挑戦しまくる
  2. その中で進捗を出し続ける
テックリードとして
  1. 技術に関わる意思決定を行えるようになる(オーナーシップ)
  2. メンバー全員に成長してもらえる環境を作る(フォロワーシップ)
その他
  1. リモート力を高める

多いですが上記6つのことを意識しながら研修に取り組みました。この中で一番大切にすると決めていたのは「新しい技術に挑戦しまくる」という目標です。おそらくこの目標を設定しなければもっと進捗を出せてもっと他の人をフォローしながら完成度の高いサーバーを構築できたと思います。

が、それでは何かもの足りずに退屈な3週間になってしまっていたと思います。また、自分に負荷をかけることで制約が増え、議論してめちゃくちゃ考えて意思決定したり工夫する機会が増えて結果として学びが3倍ぐらい多くなりました。

これはぶっちゃけ話なのですが、入社の直前ではコロナの影響で研修なくなっていきなり配属にならないかなぁと思っていました。実務経験も多くインターンとして配属された部署も2つあるので業務を遂行できる自信はあったからです。

でも、会社の判断として研修はやるということで決定しました。それでもなお「研修だる〜、適当にやろ。」なんてダサいことは絶対にしたくなかったので、用意された環境を100%使い切ってめちゃくちゃ有意義な3週間にしてやろうと心を入れ替えました。

本気でやって失敗しまくって最後になんとか形にして強くなった姿を見せるのが、このご時世必死に僕たちのために研修をできる状況を作ってくださった人事の方たちへの恩返しだと思ったのも理由の一つです。

結論として、とても有意義な3週間でしたしめちゃくちゃ失敗を繰り返して学びは大量にありました。

 

全体を通しての振り返り

エンジニアとして

先ほども書いた通り目標の中で一番大事にしていたのは、「新しい技術に挑戦しまくる」です。チームのスローガンも「で、今日は何を学んだの?」にしていたこともあってチーム全体として新しく勉強することにとても注力していました。
もともとフロントエンドエンジニアだったのですが、配属ではサーバーサイドを希望していたのでできるだけ多くのことを研修という期間を利用して勉強しようと決めていました。slackに毎日18:00にリマインドされるようにしていたので、学びを絶対に作る、作れるぐらいには背伸びするということを心がけざるを得ませんでした。
毎日18:00にくる煽リマインド
この制約をつけてかつ、チーム全体としての共通認識にすることができたおかげでエンジニアとしてめちゃくちゃ成長することができました。今回サーバーサイドで挑戦した技術のうち、チャレンジングだったものを上げてみましょう。
  • golang(個人開発で簡単なAPIサーバーを建てたことがあるレベル)
  • lambda(あー、サーバレスのあれね)
  • DynamoDB(聞いたことはあるかもしれん)
  • serverless framework(初耳)
  • cognito(初耳)
これだけあれば、新しいサービスを十分構築できますよね?
そうです、今回は全部新しい技術での構築チャレンジという形になりました。他のチームはメンバーの誰かが慣れている技術での構築というのが多い印象だったので、僕含めうちのチームではその分他のチームより技術的に成長できたと思っています。
これ以外にも採用に至らなかったものの選定のために調査したものをあげると、
  • Amazon Neptune(GraphDB, データベースを変えたかった)
  • RDS proxy(AuroraをLambdaで使いたかった)
なども調べて軽く触ってみて、ということをしていました。aws自体それほどがっつり触ったことがなかったので正直めちゃくちゃハードでした。
一方、反省点ももちろんあります。一番は、インプットに時間がかかりすぎたものがある、ということです。Lambdaの開発環境の構築を何からやったらいいのかわからなくなったり、DBの調査をして1日ぐらい溶かしてしまったり、、ということが挙げられます。新しい技術に挑戦しながら進捗を出し続けるというのは合格点にはちょっと届かなかったのかな、というのが所感です。
単にインプットの速度を上げられるぐらいに自分が強くなればいい話ですが、なんでも解決できるほどの基礎知識をつけるのは大変です。
なのでこれからは、
時間を区切って調べる → わかりそうな人に聞く or 他の手段を探す
という手順を踏んで無駄に消費する時間を最小化することを意識していきます。また、学習コストや導入コストを見極めて早期に断念するということも無駄な時間の削減につながるので意識していきたいところです。
もうひとつは、おそろしく汚いコードになってしまったことです。これは正直仕方ないと思っています。全員go初心者で動く物ができて機能の実装に影響がない程度の荒れ具合だったので、限られた時間の中での研修という環境下では合格でしょう。

エンジニアとしての総評

新技術への挑戦 95

進捗出すマン   70

 

テックリードとして

エンジニアとして成長するために上記に書いた負荷をかけてかつ、テックリードとしての役割を果たすというのはかなりしんどかったです。ただ、これもやりきるというのを目標として強く意識していました。

オーナーシップ

サーバーサイドのメンバー全員にとってチャレンジングな技術選定だったので、自分が率先して情報収集をしロジカルに議論を進めて迅速に意思決定を行うことを意識しました。この意識と責任感がインプットを加速させるという嬉しい相乗効果もありました。

議論の際はファシリテーターだけでなくタイムキーパーも行い、だらだらと議論をし続けたり話題が外れたりということがないように心がけました。これにより根拠に基づいた意思決定がスケジュール通りに行えたと思います。

 

一方、反省点もありそれは意思決定の議論が甘かったということです。

特にDynamoDB周りに関しての意思決定が後からミスチョイスだったということが判明しました。DynamoDBおよびNoSQLの経験や知識が不足していたことは確かですが、そこをカバーできるようなリサーチや実装前にもう少し試してみるといった工夫が必要でした。

また、開発工数を抑えるためにLambdaを用いたものの、経験がなく結局リサーチに時間がかかり手間取ってしまったのも反省です。ec2で構成したらうまく行ったのかはわかりませんが、経験があったので結局時間は変わらなかったのかもしれません。

フォロワーシップ

経験がないメンバー含めてバックエンドの全員がそれぞれの力量に見合ったタスクをこなし続けられる環境作りを心がけました。

これを実現するために最初はUnityエンジニアとペアプロをして自走できるようにサポートしました。最初はスループットが落ちましたが、僕のやり方がうまくいったこととその同期が優秀だったこともあり徐々に自走できるようになり、サーバーを任せて安心してDB周りの課題解決に時間を割くことができるようにまでなったのです。(ちなみにそのエンジニアはgolangもサーバーも初めての経験でしたが、最終的鬼にはS3に画像をアップロードできるエンドポイントの作成までやってくれました。)

これに加えて僕が楽したかったために、適度に責任感が大きくなるようにタスクをアサインしていたのですが、責任感からかこれをしてから成長速度が倍ぐらいになりました。具体的には、もう一人のインフラをメインでやってくれていたエンジニアのサポートをお願いしたりフロントとのやりとりをやってもらったり僕の書いたコードをレビューしてもらったりとしていました。

一方反省点としては、自分がわからないところのサポートを仕切れなかったことです。自分自身も負荷をかけている中で正直さらに負荷をかけるのが辛すぎてなかなかサポートに回れなかったのですが、そのせいもあってサーバーの進捗が大幅に遅れてしまいました。

一人のサポートならできても複数人となるときついという原因も考えられるため、時間の割き方も考える必要があったようです。自分の時間がとれない日もありましたが、常にチームとしてのスループットに注目して自分の時間を考えるということをこれからの目標にするのが最適だと考えています。

他人へのアサインを意識していたため自分に回ってくるタスクは、全く何もわからない課題に何日も立ち向かったりサーバーの遅れを取り戻すためにフロントに入って認証周りのreduxを全部実装するといったことが発生してカオスでしたw

負荷をかけまくって成長するということが目標だったため、自分にこのようなタスクを巻き取るのはむしろ本望でメンバー全員win-winの状況を作ることはできたと思います。(インフラを丸投げしてしまったのはほんまにごめん。。)

また、タスクのアサインを心がけたもののどうしてもボトルネックはできてしまって、自分が解決しないと他の人の手が止まってしまうという状況は作ってしまいました。環境周りは少し仕方なかったものの後半はそういうことがほとんどなかったので工夫次第でなんとでもなります。状況を言い訳にせずに解決策を探るように意識していきたいです。

テックリードとしての総評

オーナーシップ 80

フォローシップ 80

 

リモート力

最後にしてもしかしたら最大の学びだったんじゃないかと思っているのがリモート力です。もともと2年ぐらいほとんどリモートでの開発が中心だったので全く不安はなかったのですが、企画や設計をリモートでコンセンサスを取りながらやった経験はなかったのでリモートでの意思決定や進捗管理は正直すごく難しかったです。

制約が大きい中で試行錯誤しながら議論・開発を行うことで、今までやっていたことが実は無駄だったということに気づいたり、リモートでなくてももっと効率をあげられるという発見がいくつかありました。

時間意識

リモートの会議は次が詰まっていない限り場所の制約もないのでだらだらとすぎがちです。そのためタイムキーパーを行うことが非常に大事になってきます。また、ラグがあり話しにくくて速度も落ちてしまうので議題がずれないようにファシリテートすることも重要です。意識するだけでは時間がすぎてしまうこともあるので、slackのリマインダーを使って時間を管理するようにしていました。これはけっこう効果があったので今後も導入する価値がありそうです。

進捗管理

ちょっと気を抜くと誰が何をやっているのかすぐにわからなくなります。チケットをきったりトレロで管理することも試したのですが、いまいちうまく運用できませんでした。

そこでこれまたslackのリマインダーを使って今やってることを宣言するようにしてみました。すると、個人としても時間を意識して開発できるようになったし、他の人のタスクの進捗もわかるようになったので効果はかなりありました。ログが残って一個のタスクで詰んでいてもすぐ気づけるのでサポートにも入りやすいです。

毎回コマンドの記述量が多かったのでエイリアスを作成するなどの工夫は必要かもしれません。

discord常時接続

これは導入してよかったランキング1位です。discordで複数の音声チャンネルを作って簡単に行き来できるよにしました。

休憩部屋とフロント部屋・サーバー部屋・精神とテクの部屋を作っていました。正直音声で十分だったのと複数の音声チャンネルを作れてすぐに入れるということがかなりメリットでした。精神とテクの部屋は集中しているという意思表示で中ではミュートにしていました。

情報の集約化

これは達成できずかなり不便した点です。情報が分散してしまったりいろんなところで会話をしてしまっていたので、情報を探すのが大変でした。GitHubでもトレロでもesaでもなんでもいいからここを見たら全部解決するというものを決めるべきでした。

普段から大切ですが、リモートという環境下ではよりその重要性を感じました。どこにあるかを聞くだけでも普段の3倍ぐらいはコストがかかってしまうからです。

 

研修を通して気づいた自分の強み

オーナーシップ・フォロワーシップ

エンジニアとして仕事をしていく上で技術以外のチームビルディングや議論という部分は元から自信がありました。そして開発を進めて行く中でそれがやっぱり他の人と比較しも強みだなと思っています。

指揮をとることは今まであまり好まないタイプだったのですが、「苦手だから」ではなく「責任を逃れたいから」という理由で避けてきてたんだということが今回テックリードをやってみてわかりました。役につくと言い訳してる間も無く強制的に責任がのしかかってくるので自分と向き合うことができました。

また、フォローするのはかなり得意だなと思いました。教材を作った経験もあるので、自分が勉強したときどこがどうわからなかったのかを考えて説明したり、その人の力量から適切なタスクをアサインしたりするのはかなり得意だと再確認することができました。

 

技術面

フロントの技術力は現場で活躍していけるレベルにあると自負していましたが、サーバーサイドはあまり自信がありませんでした。一応、golangはかけるし、サーバーのアーキテクチャもなんとなくはわかるし、DBもなんとなくはわかるしインフラもなんとなくはわかる、、ぐらいに思っていました。

でも、実際にやってみて議論してみると案外自分の方が知識がある分野もあったりして、今までサーバーで配属されて活躍できるようにと勉強してきたことが実っているのだなぁと実感しました。とはいえ、息をするようにSQLを書けるレベルにはほど遠かったり、ちょっと複雑なインフラのアーキテクチャには蕁麻疹がでそうになったり、NoSQL何もわかってなかったりと課題は山積みなのでこれからどんどん吸収していきたいです。

あと、同じスタートラインで勉強を開始したらまず負けないなっていう自信もつきました。爆速インプットで複利的に知識を増やしていきます!

 

まとめ

この研修を通じて思ってたよりも技術的に成長できたし、思ってたよりもしょぼいものしか作ることができなかったし、思ってたよりもチームをリードすることができました。

至らない点も多かったけど、こんな僕に付いてきてくれてフォローしてくれたチームのメンバー、そしてこんな素晴らしい機会を提供してくれた人事のみなさん本当にありがとうございました!