新卒エンジニアの仕事〜2020年入社のAndroidエンジニア編〜

はじめに

こんにちは。2020年04月に新卒入社した佐藤 柊一です。 学生時代は趣味やアルバイト共にWebアプリを開発していました。業務では、App Dev 3 チームに配属され、Androidアプリのバグ修正や新機能開発を行っています。

この記事では、LINEのメッセンジャーのAndroidアプリケーションの開発を担当するエンジニアとして、私が入社してから約半年間の中で、どんな業務や活動をしてきたのか紹介します。

App Dev 3 チーム

App Dev 3 チームはLINEのメッセンジャーのAndroidクライアント開発チームの1つです。7人のチームで、スクラムライクなチームプロセスで業務を行っています。また、ディスカッションが活発で気兼ねなく質問を行えるチームです。

図 1. 毎日12:00から始まる朝会の様子

業務内容

最初の業務はアプリ内の1つのアイコンのリソースを置き換えるということから始まりました。次に、トーク画面のスクロール位置を指定して表示する機能の実装を行いました。特に、後者のような機能の実装ではトーク画面の仕様をきちんと理解しなければ実装できませんが、現在のLINE Androidは、KotlinとJavaのソースコードだけで約220万行もある非常に大きなプロジェクトです。そこには様々な設計方針が入り混じり、混沌としているコードも存在します。そのため、仕様を理解したりデータの流れを追うことが難しいこともあります。

現在では既存の複雑なSQLiteのデータベースの理解や、影響を最小化する工夫をしながら実装する必要がある大きな機能追加を行っています。この機能の追加について説明したかったのですが、リリース前で全体の説明はできないため、”一部”について説明したいと思います。

要求事項

Android上のSQLiteに日々追加されるExistingDataが既に存在し、1つのExistingDataに対してNewFeatureDataが追加されるとします。ExistingDataとNewFeatureDataのデータは1対多の関係のため、ExistingDataのテーブルは変更しません。データベースサンプルを以下の図2に表します。

図 2. ExistingDataとNewFeatureDataのデータベーステーブル

私が担当した機能で必要だったことが、この図3のような複数のExistingDataに関連するNewFeatureDataの最新N件を取得するというものです。また、できるだけ高速に処理する必要があり、1クエリで処理するのが望ましいです。

図 3. 取得するデータの例

設計

まず初めにDesign doc という設計手法の基本方針を示すドキュメントを作成します。Design docを作ることにより、手戻りを防いだり理解不足を明確にできます。

今回のケースであれば、様々な手法が考えられたため、有効そうな手法いくつかをまとめて提案し、複数人で協議しながら決定していくことにしました。

図 4. Design docの例

このDesign doc で示した基本方針の妥当性を検証するため、私達のチームではDesign Docであったとしてもコードと同じようにチームメンバーによるレビューを行っています。私達のチームでは、レビューを2回に分けて実施し、特に2回目では1回目のレビュワーよりもシニアなエンジニアがより詳細にレビューを行い、1回目のレビュワーと作者にフィードバックを行います。指摘できなかったレビューをなぜその指摘をするのかという背景から説明し、次回のDesign doc作成やレビューに生かしていきます。チーム内ではこれを「2段階レビュー」と呼んでいます。

他のチームメンバーが作成したDesign docのレビューをすることもあり、フィードバックを通してDesign docの作成力やレビュー力の向上につながっています。

実装

Design docを元に実装を行い、GitHub上でPull Requestを作成し、Design docと同じように2段階レビューをします。また、レビュワーにもDesign docを共有することで実装の認識を合わせ、コードレビューの効率化を行っています。

Pull Requestを作成したとき、重複したコードを別の場所に書いていたが統合が可能であったことや、命名やコメントが適切でなかったり不十分であったりすることがあります。これらはPull Requestの作者が気づくべきですが、作者はコードに対して盲目になりがちなため、多くのミスを犯します。ここで二段階レビューを行うことで、ミスに気づくだけではなく、ミスを防ぐための考え方を共有することができるため、次回からミスを起こさないように意識することが可能です。

その他の活動

私たちのチームでは機能開発やバグ修正だけではなく、チームメンバーの育成や技術力の向上のために様々な活動をしています。その中から一部を紹介します。

Code readability session

コードの品質を向上するために、Code readability sessionというプレゼンテーションを行っています。こちらからLINE Engineering blogで紹介している記事をご覧いただけます。このプレゼンテーションは可読性の重要性や、命名、状態管理、依存関係、レビューなど様々な観点からコードの可読性を向上するためのアイディアをまとめたもので、8章構成となっています。

インターンや新たに入社したメンバーがチームに参加した際には、合計8時間のプレゼンテーションを行い、可読性や設計への認識合わせと意識向上を図っています。

レビューフィードバック共有会

コードレビューの品質のばらつきを抑えるために、レビュー済みのPull Requestに対して、より良い改善案がなかったかを評価する議論を行っています。この’レビューのレビュー’をレビューフィードバックと呼んでおり、毎週共有会を開いて他のチームも交えて共有を行っています。この共有会は1週間に1回行っており、現在は英語、日本語、韓国語でセッションを行っています。また、改善案をまとめたものを図3のようにWeekly reportとして共有しています。

図 5. Weekly reportの例

レビューの内容は先ほど紹介したCode readability sessionに反しているような実装や、コードやクラス構造のベストプラクティスなどを問題のあるコード例と理想のコード例を交えつつ、議論をしています。そのほかにもコーディングルールなどはこの共有会を用いて情報共有を行い、変更をすることもあります。

Study session

技術力の向上のために、Study sessionという勉強会を行っています。この勉強会はLINEアプリのクライアント開発者のうち、東京のオフィスにいるメンバーで行っています。1週間に1回、英語を用いて技術的な知識のプレゼンテーションを行います。

私は「LINEに新卒入社したら何をするのか」や「Kotlin 1.4の新機能紹介」などを行いました。この勉強会ではLINEやAndroidに関係のないプレゼンテーションも可能で、ESXiサーバーの知見の共有やFIDOの概要など、様々なトピックが取り上げられます。発表項目に対する意見や質問なども多く、非常に雰囲気の良い勉強会です。

English lesson

英語スキルの向上のために、English lessonという勉強会を一部のメンバーで行っています。この勉強会では、YoutubeのAndroid Developersチャンネルから40分程度の動画を参加者全員で視聴したり、学習サイトを用いて学習を行い、その後、表現方法や知らない成句について議論をしています。最近ではJetbrains主催のKotlin 1.4 Online Eventなども視聴しています。

このほかにも英語の語学講座を福利厚生として提供しており、英語学習の機会は多くなっています。業務の中では英語でのコミュニケーションがあるため、存分に学習内容を生かすことができます。

おわりに

昨今、新型コロナウィルスにより出社を控えている状態が続いています。私は入社式の1回しか出社していません。そのため、App Dev 3 チームのメンバーには一度も現実で対面したことはありません。

当初は不安もありましたが、チャットツールやビデオ会議ツールで質問やアドバイス等も簡単にできますし、Wikiなどを用いて情報を管理しているので不自由なく業務に従事できました。リモートであっても二段階レビューや勉強会などの学習機会は非常に多く、多くの学びを得ることができます。
新卒であっても大きな機能開発を携わることができます。もちろん最初はわからないことだらけなのでチームのメンバーにサポートをもらいながら、適宜質問をしつつ実装することにはなりますが、リリース後の達成感はひとしおです。

この記事を読んだ誰かがLINEに興味を持ち、インターンシップへの参加や入社していただけることを願っています。