オンラインでも技術習得は可能!出前館におけるエンジニア同士の連携について
コロナ禍の真っ只中で入社した2021年新卒エンジニアのKさんは、リモートワーク主体の中で技術を習得し、著しい成長を遂げました。そこにはどんな工夫があったのでしょうか? Kさん(写真中央)を含む Review Service チーム(Aさん、Oさん、Hさん)に、オンラインでの技術習得のコツと、出前館エンジニア同士の連携について聞きました。
チーム開発未経験からいきなり現場へ
入社前はどのような経験を持っていましたか?
K:高校生の頃に趣味でゲームなどのプロダクトを作ったりはしてきましたが、とくにチームでの開発や業務経験はありませんでした。
入社後、チームに配属されてどのように仕事をされたのでしょうか?
K:出前館のインターンのころからAPIを書いてはいましたが、入社してすぐにエンジニアとしての開発業務がスタートしました。最初は何もわからない状態でしたが、先輩社員にフォローしてもらいながら実務にあたることになりました。
チームとしてはKさんに最初に任せる仕事に何か意図があったのでしょうか?
H: Review Service (出前館でレビュー表示をするための機能)を開発することになった際、その機能をフロントチームが使える形で提供するAPIの開発をKさんに担当してもらいました。
有料の研修を受けてもらうことも可能でしたが、Kさんは最初からプログラミングの素養があったので、上長とも話して、実務に参加してもらったほうが成長できるだろうという思惑でそうなりました。
K:実際にコードを書きながら覚えたというのはその通りです。同じような実装内容でも、最初に書いたAPIより3つ目、4つ目に書いたAPIのほうがスマートに書けていたなという感覚がありました。ほんの1~2か月前に書いた1つ目のAPIも書き直したい!と感じるくらいの成長スピードではあったと思います。
リモートワーク主体で困ったことも
コロナ禍で新卒エンジニアとしての業務開始。困った点はありましたか?
K:インターンもすべてオンラインでしたし、入社後も主にリモートワークです。これまで出社した回数を両手で数えられるくらいなので、オフィスがすごく新鮮に感じます。......出社するときはいつもドキドキしています(笑)
O:私もリモートワークが中心ですが、 Review Service チームは私以外がLINEからの出向社員で出前館プロパーがいなかったので、なるべく出前館の先輩のような立ち位置で出前館のことを色々教えてあげないといけないと思っていました。ただ、Kさんの入社当時は自分もまだ入社して1年くらいしか経っていなかったので、そんなに多くを語れるものはなかったんですよね。でも一番近い存在として、会った時にはなるべく会話したり、一緒にご飯に行ったりと、困った時に話しかけてもらえるようには意識しました。
リモートで週3時間のペアプロが奏功
新卒エンジニアの技術習得に向けて工夫した点はありますか?
H:オフラインでの新卒の受け入れだとコミュニケーションの敷居が低いので、実際に画面を見せながら直接口頭で話す形でオンボーディングしやすいのですが、リモートでは気軽に質問もしにくいだろうし、コミュニケーションをとれる時間も増やす必要があるなと。その対策として、週に3時間はオンライン上でペアプロ(ペアプログラミング)の時間をとるようにしました。
課題がある時にペアプロをやるとすごく良いのですが、課題がないとペアプロが機能しないこともあったので、KPTという形で振り返りをして、後期からはオフィスアワーという時間を作る形にしました。チームの皆が集まって、何か質問があれば気軽に聞けるような時間で、その中でペアプロがしたい時はするという感じです。
K:1つのコードは基本的に一人で書くのが一般的ですが、ペアプロは先輩と後輩の2人で書くことによってノウハウを共有できる場です。最初は本当にどう書けばいいのか全く分からないという状態だったので、こういう機能を実装するために、ここにこういうコードを書いていくんだよというのを、画面共有で説明してもらいながら学びました。
O:Review Service のメンバーで一緒の時間にやっていたので、ペアプロというよりは実質モブプロ(モブプログラミング)でしたね。
K:Slackに専用スレッドを作ってもらって、そこにぽんぽん質問を投げて返してもらえたので、気軽に聞ける環境はありました。ただ画面共有したほうが早いよねという時とか、何が分からないかが分からず、スレッドに投げるまでの文章にもならない時には、ペアプロみたいな場はとても助かりました。
Slackの専用スレッドで質問と回答を重ねた
逆にオンラインだから良かったところもありましたか?
K:Slackのリマインダーで「Kさん作業スレッド」というのを毎日作成してもらっていました。毎朝10時にぴょこんと現れるので、そこに今日は何をしますとか、何をしようとしているんだけどこれがよく分からないですとか、そういうことを書いておくんです。メンションをつけて聞くのは何か気が引けるような内容も、お手すきで見てくれたらというような気持ちでふんわり投げられるので、私としてはこのスレッドにすごく助けられました。そうすると、チームのAさんがいつも本当にすぐに回答をしてくれて。
A:書き込みがあるかなってたまに見てて。定期的にチェックしていました。
H:めちゃめちゃ書いていましたよね。スレッド数も50とか60とか増えるくらい。
プロジェクトに入ってステップアップ
実際にプロジェクトに入ってみてどうでしたか?
K:最初は、先輩の書いた設計書どおりに実装することすらおぼつかなかったところからスタートしたので、設計書に書いてあるようなSQLを自分が書けるようになる未来が想像つきませんでした。Curl投げて動作確認とかもCurlの文法が分からなくて 社内Wikiで探してコピペするみたいなダメなことしていたんですけど......。
それがだんだんと、これができたら次これやってみようという感じで実装するAPIの難易度が上がっていって、次は設計書から書いてみようねと。そういう感じで徐々にステップアップして、気が付いたらSQLも一応書けるようになっていました。遠くまで来たなというか、元がダメすぎたのかという気持ちになりました(笑)
H:ある程度本人とも話しながら見積もりをとってスケジュールを決めてという形では進めていたので、そういう意味だと本人のちゃんとした見積もりもとれるようになってきたというのがありますし、かつ、スケジュール的に厳しい時もあったのですが、そういう時であっても「自分が頑張ります」と言ってくれたのも結構大きいなと思っています。
やりますって言ってくれたし、スケジュールもちゃんと納めてくれたというのがすごく良かった。途中で厳しいなと思ったら他の人にふることもできたけど、そういうこともなくしっかりやり遂げてくれました。
後半のプロジェクトのほうではとくに、Aさんに技術サポートという形で工数をちゃんととって入ってもらったというのもあって、助かったのかなというふうには思っています。
A:一から教えるっていうよりは、Kさん側から色んな質問をしてきてくれたりとか、わからないところまで自分で実装して自分で進めてくれたりというのがあったので、こちらの仕事としてはすごく楽に進んだんじゃないかなと思いますね。心強いチームメイトとして楽しく仕事ができています。
K:助かりました本当に。時間が空いた人、分かる人がさくっと答えをくれるという感じだったので、私もすごくやりやすかったです。テキストのやりとりだと、メモしたメモしてない、聞いた聞いていないというのがなかったので、私としては本当にスレッドが一番助かりましたね。対面だとメモしきれなかったらおしまいですが、Slackなら読み返して復習しやすいし、認識違いも発生しないので、テキストベースなのが本当に良かったなと思います。
先輩おすすめの技術書を読んで技術習得
チームメンバーから見て成長につながったと思う部分は何かありますか?
O:技術的なところではKさんには、AさんHさんという強力なチームメンバーがいたので、私はメンバーとして近い距離にいた分、何か質問には素早く回答できるところは対応しようという感じのサポートをしていました。
最初の一歩二歩は会社の業務で知識を蓄えてもらったと思いますが、その後の伸びに関しては、Kさん自身が、皆からおすすめされた書籍をちゃんと自分で消化し、自身で学習して伸びていったところも大きいと思います。最初のきっかけが仕事だっただけで、以降の伸びは自分でどんどん突き詰めていったのかなという印象があります。
K:Oさんから色んな技術書をおすすめしてもらって、図書館には今でもよく通っています。港区立図書館は技術書が豊富で、新しい技術書がわりといち早く入るイメージが強い。品川区立図書館は最近行ってみたら思ったより技術書があったし、新宿区立図書館もわりとそうですね。同じ内容についてもいくつか読んでいくと、共通して書いてあることは大事だと思うし、逆に1冊の本にしか書いてないことは、正直あまり理解できてなくてもいいんだなって分かるので、私自身の濫読家で色々と読む性質は活きたかなと思っています。
具体的にはどんな書籍を読みましたか?
K:『SQLアンチパターン』『達人に学ぶDB設計徹底指南書』、あとはOさんに教えてもらったUdemyのAWSの有料講義も役に立ちました。今は『ソフトウェアアーキテクチャの基礎』を読んでいます。あとElasticsearchについては、LINEの社員が書いた同人誌『検索だけじゃない Elasticsearch 入門』を読みました。
最終的に設計もするようになったので、設計の時に見事にアンチパターンを踏みまくっていた気がして。「これ読んだら?」って『SQLアンチパターン』を渡されて、「すごい、私きれいに地雷踏みまくっている!同じようなことを考えて失敗している先達がいっぱいいる!」と一周回って感動しながら設計書を書いた記憶があります(笑)
業務に必要なものを必要なだけ図書館の返却期限までに読む感じだったので、最近エンジニアの同期社員2人が業務外のIT関係の知識も吸収しているのを見て、すごいなと。私は業務で使う技術を吸収するのに精一杯だったなというのは思いますね。
最後に
後輩ができたらどんな取り組みをしようと思いますか?
K:
その時のその人の理解段階によって対策を使い分けるのがいいと思いました。文章での質問が出てこないくらい何も分からないという状態のときには、ペアプロやモブプロが利くと思います。私自身、ペアプロやモブプロにとても助けられましたし、ある程度分かってきたら、作業スレッドやオフィスアワーに移行したのもすごく良かったです。オフィスアワーまでに質問事項をまとめようとメリハリもつき、オンラインでもコミュニケーションが取れ、何より私にはテキストベースが性に合っていたのかなと思います。