はじめに

こんにちは、学生エンジニアのMasamichiです。最近大阪に引っ越したのですがあまりのアクセスの良さにびっくりしてます。ただ車を運転したいなとは思わなくなりました()

今回は、2023年11月〜2024年2月まで株式会社プレイドにてエンジニアインターンに参加してきたので、その体験記を書いてみました。

インターンについて

ポジション

僕が今回ついたポジションはカスタマーエンジニアという職種です。
※僕はこの部署の中で特にソリューションエンジニアという配役だったので、今回はソリューションエンジニアという職業について言及しています。

仕事内容

社内では自社SaaSである「KARTE」のソリューション開発をするという仕事をしました。具体的には、導入企業からご意見をいただいたり社内で新たな使い方を検証したい機能を、設計・実装・発信するという一貫したプロセスを体験できました。以下に自分が実装したソリューションの一覧を載せておきます。

気づき・学び

PRの粒度

会社のリポジトリに入りメンターの方にコードレビューを受ける中で、そのPR粒度の高さに驚きました。業務を行うときは、ベースの完成像のイメージがズレて行かないように細かく認識を擦り合わせる機会があり、それがコードレビューにも現れていました。

仕事に慣れていく中で、次の流れが仕事をしやすくなりました。

ソリューションの設計
設計におおまかに沿ったミニマムを作成する
実装ベースでコードレビューを受ける
コアを完成させる
コードレビューでコードをクリーンにする
仕様を変更・追加する or 完成
5に戻る

また、コード管理を行う上で、Github Actionsを使ってESlint, Prettierなどを使用することでフォーマットを統一でき、コードレビューのコストを減らすための工夫ができていて、レビュアーが構文とロジックを指定するだけで良いという状態になっていました。強いていうなら構文まで統一してPR前にチェックしてくれるともっといいなと思いました。

テンプレート化を意識したコード

前述で少し触れましたが、全社的にコード管理はかなり徹底されていた印象です。とりわけ自分がいたカスタマーエンジニアチームでは、実装したコードがそのまま導入企業で使われるテンプレートになるので、特に品質管理の意識が高かったです。

レビューを受けていく中で、注意された・意識を向けた点の例を少し上げてみます。

ロジック

ユーザーがセグメントから外れたときにメイン関数からすぐに脱出しているか
- セグメントから外れたときにreturnしないとメインの一番下まで処理を読み込んでしまうため
メイン関数を読むだけで処理の流れが完全に掴めるか
- 複雑なロジックは関数に切り出す、必要な処理はメインで見せるようにするなどの工夫をする
read/writeなどの負担がかかる処理を呼び出し過ぎていないか
- 処理速度が下がりそうな処理に対して適切にasync/awaitの使用ができているか、ネストし過ぎていないか、など

など

コード管理

よりストレスフリーに読めるコードフローを意識する
- 何でもかんでも三項演算子を使えば良いというわけではなく、三項演算子を使って一行で書いた方がわかりやすい時のみ有効、など
ロギングが使用時に有用であるか
- ロギングを行うときに、「何」が「どの部分」で「どんな値」を取得して「何」に「成功/失敗」したのかが一撃で理解できないロギングは修正する、またdebugで出すのかinfoで出すのかもロギングの実行回数から逆算して記述する
処理のフローに沿わないものは、メインの最初に記述する
- データの取得やAPI認証など

など

設計の難しさ

働いてわかったことは、実装以上に設計が難しいということです。自分も仕事をするときは、実装に入る前は必ず設計のレビューを繰り返ししてもらいました。

具体的には、企画で出た要件を設計に落とし込んでいくだけなのですが、よく起こりがちな「設計しているうちに要件が膨らんでいく」ということを防ぐために、一機能の設計ができたら認識を擦り合わせる、ということを繰り返し行うことで、他にイメージの焦点がずれないように工夫をしました。

終わりに

今回は自分がエンジニアインターンとして働いた成果・活動についてまとめましたこの記事への感想やコメント・評価をTwitterなりDMなりでいただけるととても喜びます。ほなまた

大学1回生がソリューションエンジニアとして働いてわかったこと