Tabelog Tech Blog

食べログの開発者による技術ブログです

新卒エンジニアとして書いた1年前の記事を振り返って

この記事は 食べログアドベントカレンダー2023 の19日目の記事です🎅🎄

はじめに

こんにちは。 食べログのWEBエンジニアとして働き始めて2年目になる向島です。
私は食べログのウェブ開発部プロダクトチームでサーバーサイドの開発を担当しており、ここ半年で主に検索機能の改善に取り組んできました。

1年前のアドベントカレンダーで、「未経験の新卒が食べログのプロダクト開発の最前線で学んだこと」という記事を書いたのですが、今回は1年経ったいま、去年書いた記事を改めて読んで感じることをお伝えします。

ちなみに、1年前の記事ではこんなことを学びとして提示していました。

  • 成果を出すために周りの人をうまく巻き込む
  • 自分から要件に対して疑問を持つことが大切
  • 日々の学びを次に繋げていくために振り返りをする

もし興味のある方は、こちらから読んでみていただけたら嬉しいです。

今回は、3つの中から「成果を出すために周りの人をうまく巻き込む」と「自分から要件に対して疑問を持つことが大切」について思うことを詳しくお伝えします。

「日々の学びを次に繋げていくために振り返りをする」については記載していませんが、今も所属するチーム内で継続的に実施していることの1つです。
開発を進める中で良かったことや失敗したことも含めて、振り返りをすることで着実に次のアクションに繋げることができている取り組みだと感じています。

1年前の記事を読んでみて

周りの人を巻き込んで成果を出す

1年目だから必要なことではない

1年前の記事で挙げた学びの1つに、「成果を出すために周りをうまく巻き込む」というものがありました。
1年前は新卒として実務が始まって数ヶ月の頃で、わからないことがほとんどで悩む時間が多かったので、人に相談することで自分の頭の中を整理することが大切と感じていました。
特に、「自分はまだ知らないことが多いから」「新卒エンジニアだから」といった理由でとにかく人に頼るしかないと考えていましたが、周りの人を巻き込むことは今も非常に大切だと感じていて実践していることの1つでもあります。

私自身、今年度から所属するチームが変更になり、1年目に関わってこなかったシステムの開発を担当するようになりました。そのため、2年目ではありますが新しく1から学ぶことも多く、まだまだわからないことがたくさんあった1年でした。
こういった事情もあり、周りに相談してシステムの仕様や仕組みについて教えていただいたり、案件の方針検討についてアドバイスをいただいたりすることも多かったです。
特に今のチームに入ってすぐの時期は、実装されている既存のコードが複雑で、時間をかけて読んでも理解できないことが本当に多かったです。
しかし、その中でコードの仕組みを既に理解している方や実装の背景を知っている方に早い段階で質問するということを心がけており、その結果一人で悩むだけの時間を減らして、どんどん新しい知識をインプットしていくことができました。
改めて振り返ってみて、去年自分が書いた学びをそのまま継続して実践できた1年でした。

また、最近所属するチームの人数が増え、経験の多いメンバーも増えたのですが、誰かに質問を投げたときに「この部分は〇〇さんにも相談してみるのが良さそう」となってチーム内で連携して検討を進めることがあります。
私からするとみんな知識量が多く何でも知っていそうな方々ですが、こういった連携を通して、エンジニア歴が長いからといって一人で答えに辿り着けるわけではないということを実感します。
その場その場で適切な人をうまく巻き込んで協力してもらいながら開発を進めることがいつになっても必要になるやり方だと学びました。

コミュニケーション面を特に工夫する

こういった中で、自分のチームの人に相談することはもちろん、企画担当者に対して要件について質問したり、iOS/Androidアプリの開発エンジニアに対してアプリの仕様を確認したりする機会が多々ありました。

こういったやり取りが発生する際に特に気をつけていたのが、以下の2つです。

  • 一度で分かりやすく伝えること
  • 無駄なコミュニケーションが生まれないようにすること

私が担当していた検索関連の内部ロジックは複雑な箇所が多く、企画担当者やアプリ開発エンジニアにサーバー側の内部の仕様を正しく伝える必要がある場面が多く存在します。
そんな中で、はじめは内部ロジックを理解していない人に仕様を説明するということを意識したコミュニケーションが取れておらず、自分の伝えた内容の理解に相手が困っていると感じる場面が何度もありました。
実際にそういった場面では、「こういう理解であっていますか?」という確認のフェーズを挟む必要があったり、うまく伝えられていないがためにミーティングを開いて説明する必要が出てきたりしていました。
確かに今振り返ると、自分自身も理解することに苦労するような難しいシステムの仕様について、職種が違う方に口頭だけで伝えたり、長々と文章で説明したりしてもうまく伝わらないのは当たり前だなと感じます。

このような出来事から、相手の立場に立ったときでも理解できるようなわかりやすい内容で伝えることができているかを意識するようになりました。
実際に複雑な仕様については図や表にまとめたり、単純な文章でも記載の仕方を工夫したりするようになり、それだけでも相手にとってより伝わりやすいものに変化するということを実感しました。
その結果、伝えた内容についてミーティングで認識を合わせなければいけない回数も減り、お互いにとってストレスのないコミュニケーションに近づけることができていると思います。

例として、私が普段チャットを送る際に意識していることをいくつか紹介します。

  • 箇条書きできるものは箇条書きにする
  • 必要に応じて行間をあけたり、インデントをつけたりする
  • 特に伝えたい情報だけ太文字にする
  • 1行の文字数を30文字前後に抑えて改行を入れる

非常に簡単で時間をかけずにできることですが、上記を意識するだけで、同じ内容を記載しても視覚的に見やすくなったと個人的に感じています。 ちなみに、これらは「この人のチャット読みやすいな」というものを真似して自分なりに実践してみていることなので、周りにはそこを自然と考えられている人が多いのだと思います。

こういった工夫をすることで、自分が伝えたいことを一度で伝えることができれば、必要最低限のコミュニケーションでスムーズな案件進行に繋げられるということを新たに学ぶことができた2年目でした。

要件に対して疑問を持つことで開発の手戻りをなくす

気づいていることとできることは違う

1年目の学びの中に、「自分から要件に対して疑問を持つことが大切」というものもありました。
これに関しても、今も同じく大切だと感じることではありますが、正直この一年でうまく実践できていないことの1つでもあります。
改めて1年前の記事を振り返って、1年前の時点でこの学びが自分の中にあったのかと驚きましたが、表面的な学びにとどまっていて結果として実践できていなかったです。

一人一人が要件について考え、疑問点を解消していくことで手戻りが少なくなるというのが1年前に提示した学びでしたが、この1年間でも要件について深く考えられていないがために手戻りや追加開発が発生することが何度かありました。

私が開発担当になったある案件では、定義された要件を確認し実現できると考えて方針を立てたものの、あとからやっぱり本来の目的を達成するためには違う手段をとるべきだと判断されたことがあります。 この出来事も、「本来の目的」を把握できておらず、要件に対して疑問を持つ前に要件を実現させるための手段ばかり考えてしまっていたために起きてしまったことです。

漠然と「自分の頭でしっかりと考えよう」と思ってはいたものの、実際にどう考えるのか、何を考えられたら正解なのかがわかっていないままこの意識だけ持ってしまっていました。
一言で「考える」といっても、意識したところで全てが解決するわけではなく、自分で要件の不備や改善点に気づくことはとても難しいと今現在も思っています。

情報のキャッチアップを意識する

では、要件について考える上でどんな行動を取ったら、1年前の学びを日々の仕事にいかすことができるのか、考えてみました。
そこで2年目の開発を振り返って必要だと感じたことが、「自分から情報を取りにいくこと」です。

自分自身を振り返ってみたときに、案件について概要を伝えられて理解した気になっていても、細かい経緯などを把握できていないこともあり、それによって案件のどんな部分について自分の頭で考えるべきか判断できていないことが多かったです。 そこで自分にできることだと感じたのが、様々なコミュニケーションが行われる場に対してアンテナをはって、自分から案件についての情報をできるだけキャッチアップすることです。

これまで、情報の共有はチームメンバーからされるものという考えを無意識のうちに持っていて、直接与えられていない情報については把握しないまま案件を進行してしまっていました。 しかし、自分に直接与えられた情報でなくても、基本的に施策検討段階のやりとりはオープンな場所で行われています。
つまり、これらは周りに共有を求めなくても自ら得ることができる情報で、こういった情報によって要件について考えるべき観点が見つかることもあります。

上でお伝えした、施策の目的をしっかりと考えられていなかった案件でも、解消したい問題に関連するデータについてのやり取りが既にされており、そこの情報をキャッチアップできていれば方針を検討する段階で要件に対して疑問を持つことができていたのではないかとあとから気付きました。

実際に色々な情報を追うように意識してから、施策を実施する根拠となるデータについて把握できたり、規模の大きな案件では自分が関わる場所以外の全体像を掴むことで先を見越した開発ができるようになったりするなど、さまざまな観点で自分のためになる情報を発見できる機会が増えています。

こういった点に気づいてから間もないこともあり、手戻りなく開発するということはまだまだできていないですが、手戻りない開発を実現するためにできる自分の行動を見つけられたことが貴重な学びの1つだと考えます。
1年前の学びに比べてより具体的な行動が見つかったので、今後も実践していくことで結果に繋げていきたいです。

最後に

今回、1年前に学びとして紹介したいくつかの観点について、今だからこそ感じることをお伝えしました。

改めて振り返って、1年前に既に多くの学びが自分の中にあったことを実感しました。
実践できている学びもあればそうでないものもありましたが、学びに少しでも早く気付くことができていることはとてもありがたく、これも1年目から案件を任せていただける環境のおかげです。
また、日々たくさんの案件を継続的に経験していることで、自分が実践できる具体的な行動が見つかり、色々な場面で試してみることができています。

私自身まだまだ学ぶことが多く、自分なりに学んだことを行動に移してみている最中です。
今回お伝えした内容も人によっては当たり前に感じる考え方かもしれませんが、特に学生や新卒エンジニアの方などに少しでも役に立つ記事になれば嬉しいです。
学びを積極的に実践していくことで磨きをかけ、エンジニアとしてより成長していけるように頑張っていきます。

明日は @okt2420 の「食べログ新規サービスの開発チームにプロセスや考え方をインタビューしてみた」です。お楽しみに!