やっていること

まず、勉強会と映画鑑賞会の内容について説明します。

勉強会

3人で毎週木曜20:00-21:30
自分が読んでいる技術書を約1章分それぞれ説明し、その後みんなで議論
1人あたり30分かかるので、毎週90分

映画鑑賞会

3人で毎週火曜21:00-24:00
順繰りで担当者を変え、担当者が映画を選ぶ
みんなで映画を観て、観終わったら感想を話す

メリット

楽しい

知らない技術を知ることや、映画を見ること、技術や映画について議論することは楽しいです。

継続できる

私は技術を学ぶことが好きですが、難しい技術書を読み進めるのは結構大変です。さまざまな誘惑がありますし、忙しいからです。しかし、毎週発表しないといけないので読まざるを得ず、読むことを継続できます。

映画に関しては継続と少し違いますが、観たいけど1人で観るには重い映画などに挑戦できます。

領域が広がる

勉強会では、私では選ぶことのなかった技術書を、他の人が読んで説明してくれます。領域が広がります。

映画も同様です。私では選ぶことのなかった素晴らしい映画に出会えることがあります。私にとってはスイス・アーミー・マンがそうでした。

まとめ

私は週1で友達と勉強会や映画鑑賞会をやっています。楽しいし、継続できるし、領域が広がります。メリットが多いのでオススメです。

2022-03-27

23卒Web系ソフトウェアエンジニアの就活体験記

はじめに
なぜLINEなのか？
やってよかったこと
まとめ
参考

はじめに

23卒サーバーサイドエンジニア(予定)のwadayamadaです。

LINEに内定承諾して就活を終えました。

以下について話します。これから新卒で就活する方の参考になると嬉しいです。

なぜLINEなのか？
就活の際にやってよかったこと

なぜLINEなのか？

自分はありがたい事に3社から内定をいただき、そのうちのLINEを含む2社で1ヶ月くらい悩みました。最終的にLINEに決めた理由は大きく3つです。

強いエンジニアになれそうだと感じた
サービスが生活に浸透している
雰囲気・事業領域が合っていると感じた

強いエンジニアになれそうだと感じた

勿論、強いエンジニアになれるかどうかは、本人の努力や能力に強く依存すると思います。しかし、環境も重要だと考えます。

LINEは以下の点が魅力に感じました。

優秀なエンジニアが多い
- インターンや面接・面談で関わった社員さんの知識がとても広かった
- 選考が難しかったので同期に優秀な人が多そう
技術的な知見がたくさん溜まっている
- LINEメッセンジャーなどの超大規模かつグローバルなサービスを開発・運用している
- オンプレミス
- ISUCONを運営している
様々な経験を積む機会がある
- LINEメッセンジャーなどの超大規模サービス
- LIVEBUYなどの新規事業

サービスが生活に浸透している

LINEメッセンジャーは、日本でスマホを持っているほとんどの人が使っているサービスだと思います。自分も日常的に使ってます。

そのようなサービスの開発に関わる*1のは、やりがいがあり、楽しそうです。

雰囲気・事業領域が合っていると感じた

インターンでメンターの社員さんや他の参加者と関わりました。また、面接・面談でも社員さんと何度かお話をする機会をいただきました。とても話しやすく、入社後も楽しく働けそうだと感じました。

また、自分はゲームなどのエンタメ系よりは、生活を便利に快適にするサービスに興味があります。LINEはそういったサービスが多いです。

やってよかったこと

就活の際にやってよかったことを3つ話します。

逆求人イベントに参加したこと
インターンに参加したこと
面接の準備をしっかりしたこと

逆求人イベントに参加したこと

私は修士1年の5月に2回ほど以下のような逆求人イベントに参加しました。

逆求人イベントとは、1日で8社ほどの人事・エンジニア社員さんとお話できるイベントです。

流れは、スライドを使った自己紹介プレゼン->質疑応答->逆質問です。内容は面接に近いです。

talent.supporterz.jp

メリットはいっぱいあります。

面接の練習になる
自己紹介スライドを作成するため、経験・能力の棚卸しができる
いろんな企業の雰囲気を知ることができる
評価されると選考スキップできる*2
支援金がもらえる

インターンに参加したこと

私は、学部4年の2月から修士1年の10月にかけて、長期インターン・短期インターン含めて、9社ほど参加しました。*3

メリットはいっぱいあります。

開発経験を積める
新しい技術に触れられる
無知の知ができる
楽しい
友達ができる
企業の雰囲気がわかる
開発に対する適性がわかる
給与がもらえる

面接の準備をしっかりしたこと

私は面接が苦手です。可能であれば、1つの質問ごとに、近所を5分ほど散歩して考えをまとめて、それから回答したいです。

流石にそれはできないので、準備をすることが必要です。

エンジニアであれば、聞かれることは技術力・人柄・志向性だと思います。これらについて想定質問を作成し、答えられるようにした方が良いと思います。

また、私はもっと模擬面接をして練習すれば良かったなという反省があります。実際に面接をしてみてわかることは多いです。

答えられるようにしたい質問をいくつか挙げてみました。

技術力
- 開発経験はありますか？どんなことをやりましたか？何が難しかったですか？
- 最近どんな技術を勉強していますか？その技術のメリット・デメリットを教えてください
- TCP/UDPってなんですか？配列とリストの違いはなんですか？
人柄
- チーム開発の経験はありますか？どんな役割をしましたか？何が大変でしたか？
- 強みや弱みはなんですか？苦手なことはなんですか？
- どんな時、楽しいですか？どんな時、頑張れますか？
志向性
- なぜエンジニアになりたいんですか？
- 志望動機はなんですか？就活の軸はなんですか？
- どんなエンジニアになりたいですか？将来やりたいことはなんですか？

まとめ

LINEに決めた理由と就活の際にやってよかったことについて話しました。

LINEに決めた理由は以下です。

強いエンジニアになれそうだと感じた
サービスが生活に浸透している
雰囲気・事業領域が合っていると感じた

就活の際にやってよかったことは以下です。

逆求人イベントに参加したこと
インターンに参加したこと
面接の準備をしっかりしたこと

自分の選択を正解にできるように今後も頑張りたいです。

読んでいただき、ありがとうございました。また就活の際にお世話になって皆様、ありがとうございました。

参考

就活の際に参考になった記事です。

*1:実際に関わるのはLINEメッセンジャーではなく、LINE NEWS、LIVEギフト、LIVEBUYなどのLINEファミリーサービスの予定です。

*2:自分は、サポーターズの逆求人経由で、楽天、サイボウズ、dely、ワンキャリアの選考スキップを経て、インターンに参加させていただきました。

*3:GitHubのプロフィールで具体的に説明しています。https://github.com/wadayamada

2022-03-21

個人開発の際に生じた課題とその解決

はじめに
課題
解決
まとめ

はじめに

Imairuというサービスを友人と5人で開発しています。私はサーバーサイドを担当しています。

開発の際に生じた課題とそれをどう解決したか、話します。

課題

バグが生まれやすかった

Socket.IOを使って、クライアント<->サーバで通信を行います。

クライアント側の動作に不具合がありました。エラー的にクライアントに問題がありそうでした。しかし、クライアントでどれだけデバッグをしても直りません。

結局、問題はサーバー側にありました。私が担当した機能の実装漏れが原因です。背筋が凍りました。

仕様書や進捗が把握しにくかった

問題は3つありました。

API仕様書が見にくかった

API仕様書をマークダウンで書いていました。時間がなかったですし、それ以外の方法を使った経験がなかったためです。

文字だらけですし、型も書いてませんでした。ですので、とても見にくいです。

進捗管理を口頭でしていた

進捗管理はもっと酷いです。チームで仕様を決めた時に、必要な機能仕様はドキュメントに書いてあります。

しかし、その実装の進捗管理は、ミーティングで口頭で管理していました。

DBのER図を書く手間が大きかった

DBのER図にも問題がありました。draw.ioで書いたER図を画像化し、ドキュメントに貼っていました。書くのに時間がかかりますし、変更の手間も大きいです。

コードがいじりにくかった

問題は3つありました。

型がついていなかった

サーバーサイドの実装に動的型付け言語であるNode.jsを使いました。

型がついていないと以下の問題があります。

コードが読みにくい
機能追加・変更がしにくい
バグを生みやすい

モデル層はSQLを直書きしていた

また、データベースを抽象化するモデル層はORMを使わず、SQLを直書きしました。

機能追加の度にSQLを書く必要があり、手間です。書き間違いも起こり得ます。

Controller層の責務が大きすぎた

私たちのアーキテクチャは、Controller, Modelのみです。Controllerに通信周りの実装、ビジネスロジックが混在しています。

読みにくく、変更がしにくいです。

解決

バグを生まれにくくする

テスト駆動開発する

プロトタイプの開発ではテストを書いてませんでした。

テスト駆動開発(TDD)をすることにしました。

流れは以下です。

実装前にイシューでテストケースを書き出す
テストの実装を行う
テストを通せるように機能の実装を行う

実装前にテストケースを書き出すことで、実装漏れを防ぎやすくなります。また、テストによりコードが正しく動作することも保証されます。

コードレビューを入れる

プロトタイプの開発では、レビューをしてませんでした。

コードレビューをすることにしました。

コードレビューにより、以下のメリットがあります。

バグや実装漏れを防ぐ
書き方を揃える
コードの理解が深まる

自動テストとレビューによってブランチを保護する

GitHub Actionsを使って、自動テストを行うようにしました。

また、GitHubの機能を使って、自動テストとレビューを通過した場合のみ、マージができるように設定しました。

仕様書や進捗を把握しやすくする

API仕様書をStoplightを使ってOpenAPIで書く

StoplightはGUI的にOpenAPIのAPI仕様書を書けるツールです。

f:id:wada0421514:20220321120915p:plain

API仕様書通りのレスポンスを返すモックサーバーも自動で立ててくれます。

また、APIはRESTに従うREST APIに設計し直しました。

GtiHubのProjectsを使って、kanbanでタスク管理する

issueやPRと紐づけることができるので便利です。

f:id:wada0421514:20220321115236p:plain

dbdiagram.ioを使う

dbdiagram.ioを使うと、SQLチックなコードからER図を作ることができます。

リンクをドキュメントに埋め込むだけで、ER図を表示することができるため、非常に便利です。

f:id:wada0421514:20220321115446p:plain

コードの保守性を高くする

TypeScriptでNode.jsに型をつける

TypeScriptを導入することで、Node.jsに型をつけるようにしました。

TypeScriptに慣れるまで少し時間がかかりました。

型をつけるメリットは以下です。

型がドキュメントがわりになる
型によるエラーチェックができる
型による入力補完が効く

ORMを使う

TypeScriptと相性の良いORMであるTypeORMを導入しました。

ORMにより、SQLを書く必要がなくなり、実装の手間が減ります。

責務を分ける

ビジネスロジックを書く、Service層を導入しました。

また、Controller層、Service層において、コードを複数ファイルに分割するようにしました。

Controller層であれば以下のような感じです。

Group.ts
GroupUser.ts
GroupUserSetting.ts
User.ts

API仕様書からコードを自動生成する

swagger-typescript-apiを使って、OpenAPIのAPI仕様書から型を自動生成するようにしました。

また、oas3-toolsを使って、OpenAPIのAPI仕様書からルーティングもするようにしました。

まとめ

バグを生まれにくくする
- テスト駆動開発する
- コードレビューを入れる
- 自動テストとレビューによってブランチを保護する
仕様書や進捗を把握しやすくする
- API仕様書をStoplightを使ってOpenAPIで書く
- GtiHubのProjectsを使って、kanbanでタスク管理する
- dbdiagram.ioを使う
コードの保守性を高くする
- TypeScriptでNode.jsに型をつける
- ORMを使う
- 責務を分ける
- API仕様書からコードを自動生成する