Tabelog Tech Blog

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

食べログの新卒エンジニア1年目が考える「学生時代にやっておけば良かったこと」について

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

本記事を書く目的

2022年の4月に新卒として入社しました高橋です。

この記事を書くきっかけは、私が就職活動をしていた時に遡ります。就職活動をしている際に、様々な企業が開催する説明会において、学生から社会人に対して頻繁に行われていた質問があります。

それは、「学生時代にやっておけば良かったことはありますか?」でした。

それだけ、初めての仕事に向けた準備を積極的に行いたい学生が多いということだと思います。 そのため、社会人1年目の私が率直に「学生時代にやっておけば良かった」と感じたことをまとめれば、これから就職する方にとって少しでも参考になると思い、この記事を書きました。

本記事の対象

  • 実務は未経験だが、今後エンジニア職に就く予定がある方
  • 特に、食べログのように自社でサービスを運営している会社に就職する方
  • エンジニア職に就くに向けて、仕事に関する準備を行いたい方

私が就職前にやっていたこと

就職後に向けて、Ruby on Railsを用いた簡単な掲示板サイトを作成していました。 長期インターンシップに参加した経験はありません。

学生時代にやっておけばよかったこと

私が学生時代にやっておけばよかったと感じることは下記の3つのスキルを身につけることです。

  1. 他の人が書いたコードを解析する。
  2. 設計書を作成する。
  3. 読みやすい文章を書く。

そこで、それぞれのスキルについて下記の3つをご説明します。

  • 仕事において求められる場面
  • なぜ上手くいかなかったのか
  • 具体的に学生時代に何をすれば良いか

1. 他の人が書いたコードを解析する

仕事において求められる場面

既存のコードの動きを調査するときです。

就職前の学習としてWebサイトやアプリの開発を行う場合、「新しく掲示板を作る」といったように、1人で0から開発することが多いのではないでしょうか。

しかし、仕事においては完成済みのサービスの開発を複数人で行うことが多いと思います。 そうすると、他人が書いたコードを解析した上で、そのコードを修正する必要があります。 また、自分がコードを修正したことによって、他の人が書いたコードに影響が出ないかを即座に確認する必要があります。

なぜ上手くいかなかったのか

上手くいかなかった理由は、他の人が書いたコードを読むためのノウハウが自分の中でまとまっていなかったからだと思います。

具体的に学生時代に何をすれば良いか

下記の2種類のコードを読み解いてみるのがオススメです。

  1. 他人が開発したWebサイトやアプリのコード
  2. フレームワークやライブラリのコード

また、コードを読む際には、下記の3点を意識すると良いと思います。

  • 就職後に利用する予定の言語やフレームワークに関連するコードを選ぶ。
  • Webサイトやフレームワークにおいて、任意の機能を利用する際の一連のコードを追う。
    • ログイン機能のあるWebサイトであれば、ログインするまでの一連のコードを追う。
    • Ruby on Railsであれば、Active Recordのtakeメソッドの一連のコードを追う。
  • 読んだコードの処理の流れを、簡単でよいので箇条書きでまとめる。

コードを解析する経験が増えるほど、「理解できなかったコードが、この方法で理解できた!」といった体験を蓄積できます。 そうすると、そういった体験から、自ずとノウハウを構築できると思います。

2. 設計書を作成する

仕事において求められる場面

新たな機能の開発を行うために設計を行うときです。

なぜ上手くいかなかったのか

設計工程では、開発する機能の実装方針を決める必要があります。 また、仕事で扱うような機能は複雑であることが多いです。 上手くいかなかった理由は、それらの複雑な機能の実装方針を決めることに慣れていなかったからだと思います。

「実装方針は開発しながら決めれば良いのではないか?」と思う方もいるかもしれません。 しかし、実装方針は決して1つではなく、複数存在します。 その中から、保守性や拡張性といった観点から最も良いものを選ぶ必要があります。 開発しながら実装方針を決めようとすると、その方針が最適でなかった場合に手戻りとなってしまうのです。

具体的に学生時代に何をすれば良いか

就職に向けた学習としてWebサイトやアプリを開発する際に、設計書を作成することで、開発する機能の実装方針を決めることに慣れるのが良いと思います。 設計書を書く際には、下記を意識するのがおすすめです。

  • 作成・修正するファイルの名前、作成・修正する意図を簡潔にまとめる。
  • 作成・修正するメソッドを箇条書きでまとめる。
  • 作成・修正するコードの処理の流れを箇条書きで簡潔にまとめる。
  • データベースに新たなテーブルを作成する際にはER図を作成し、きちんと正規化を行う。
  • 最後に、設計書全体の内容を「概要」として簡潔に数行にまとめる。

さらに、設計書の具体例を下記に記載します。例としてRuby on Railsを利用する場合について記載しています。

■ファイル名: hoge_controller.rb

■メソッド1: index

<処理の流れ>
1. ログイン済みのユーザーによるリクエストであることをチェックする。未ログインであれば、トップページにリダイレクトする。
2. Hugaサービスクラスのcallメソッドを呼び出す。引数にはログイン中のユーザーのidを渡す。
3. 2で呼び出したcallメソッドの返却値をインスタンス変数@piyoに入れる。
4. /app/views/hoge/index.html.erbをレンダリングする。

3. 読みやすい文章を書く

仕事において求められる場面

設計書といったドキュメントや報告・連絡・相談の文章を書くときです。 これらの文章は他の方が閲覧するため、わかりやすく書く必要があります。 私の場合は、報告の文章について「少しわかりにくい」という指摘を受けることが多かったです。 読みやすい文章を書く力があれば、自分の言いたいことを伝えることができ、指摘を受けることも少なかったはずです。

なぜ上手くいかなかったのか

上手くいかなかった理由は、読みやすい文章の基準が自分の中でまとまっていなかったからだと思います。 参考として、これまでに私が考えた読みやすい文章の基準の例を下記に記載します。

  • 一文が過度に長くなっていない。
  • 他のドキュメントの内容を引用する場合は、そのドキュメントのURLも添付されている。
  • 適切に段落が分けられており、文章全体の話の流れが理解し易くなっている。

「学生時代に論文やレポートを書く中で、文章が読みやすくなるように工夫した経験があるから大丈夫」と思う方もいるかもしれません。 もちろん、その経験が仕事において全く役に立たないわけではありません。 しかし、論文やレポートには文章の書き方に関する細かなルールが存在します。 それに対して、仕事においては文章の書き方に関するルールが存在しないことが多いです。 ルールが存在しなければ、それだけ文章が読みやすくなるように工夫できることが増えます。 そのため、論文やレポートを書く経験だけではなく、仕事と同じような状況において、工夫して文章を書く経験が必要なのです。

具体的に学生時代に何をすれば良いか

自分が書いた文章を何度も読み直して、読みづらい部分を修正する練習を行うのが良いと思います。 読みづらい部分を何度も修正していると、「こうすれば読みやすいよね」といった基準を考えることができます。

しかし、そもそも自分が書いた文章が存在しないという方も多いと思います。 その場合、前項で述べた通りに設計書を作成し、それを題材にするのが良いと思います。

具体的には下記の流れで、何度も修正を行うのがおすすめです。

  1. 前項で述べた通りに設計書を作成する。
  2. 作成後に何度も文章全体を読み直し、読みづらい部分を修正する。
  3. 可能であれば他の人にも読んでもらい、読みづらいと指摘を受けた部分を修正する。

おわりに

この記事の内容を簡単にまとめます。

私が学生時代にやっておけばよかったと感じることは、下記の3つを行う事です。

  1. 他の人が書いたコードを読み解けるようになるために、他人が開発したWebサイトやアプリのコードやフレームワークのコードを読んでみる。
  2. 設計書を作成できるようになるために、就職に向けた学習で開発を行う際に、設計書を作る。
  3. 読みやすい文章を書けるようになるために、自分が書いた文章の読みづらい部分を修正する練習をする。

明日は @h_sakura の「アプリインストール直後の離脱を防ぐためにDeferred Deep Linkに対応する」です。お楽しみに!