Create Next App

夏休みの8/1から10/3までポケットサイン株式会社でエンジニアインターンをさせて頂きました。非常によくしてもらって満足度が高かったです。インターンで習得した技術スタックや技術以外で学んだこと等を列挙します。中で何やってたか詳細に書くと会社の方に迷惑かかるのであんま書きません。

ポケットサイン

※ポケットサインの方でもインターン体験記のブログを書きました。これです。業務内容自体はこっち見れば分かると思います。

Frontend

React Router

今までNext.jsしかフロントエンドで触った経験がなかったため新鮮でした。Next.jsはディレクトリ構造から向こうがよしなにルーティングを組んでくれます。一方React Routerではroutesでroutingを宣言し、より柔軟な設計が可能です(それでも僕はNext.jsで十分かなと思っちゃいました)。クライアントサイドで全部レンダリングするみたいなアプリであればToo Muchにならず、ぱぱっとフロントエンドが構築できて便利かなと思います。
ConnectQuery(Tanstack Query)

APIを叩く時のクライアントを提供してくれます。ConnectQuery単体で動作するわけではなくgRPC互換の後述するConnectRPCと組み合わせてrpc定義から型安全なクライアントが自動生成されます。今までREST APIを自前で構築し、フロントから叩くことが多々ありましたがAPI通信を定義するときはボイラープレートが多くなりがち且つ考慮事項が多いです。そのあたりを丸っと取っ払ってくれて非常に快適でした。

Backend

go

今までbackend開発はrailsを使っていましたが、静的型づけができて安心感がすごかったです。静的型付けができるというのはデータの安全性を保障するための余分なラッパーが要らないということでもあるので、プログラミングの防御的、契約的、攻撃的とかもそこまで考えずに済み楽でした。
chi

HTTPルーター
sqlc

sqlとgoコードの疎通を行ってくれるツールです。sqlからI/Oをgoコードで型安全に自動生成してくれ、CAの場合それをinfra層につなぎこみます。
goose

マイグレーションツール

RPC

ConnectRPC

gRPCをベースにgoogleが開発したRPCです。gRPCがHTTP2.0の通信を行い、全てバイナリー管理してプロキシの設置を強制させるのに対し、ConnectはHTTP1.1+JSONでの通信方式も許可されています。僕は今までAPI構築はREST形式でしかやったことがありませんでした。具体的にはNext.js x Prisma, Next.js x Rails x OpenAPIという形式です。こういったREST形式のAPIと比較してConnectRPCはリソースではなくメソッドベースで且つ上述したようにクライアント定義を全てprotobufから生成してくれ、フロントとバックでそれに対応する口をつなぎこむだけでよく非常に開発体験がよかったです。一方Conenctの欠点としては不特定多数に公開するAPIとしては機能できないこと、キャッシュを強く持ちたいアプリには不向きなこと等があります。一つ目はConnectはクライアントがprotobufが生成したもので固定されてしまい、各ユーザーがそれを自前でダウンロードしてきてgenerateして初めてバックエンドとの疎通ができるのでRESTのような誰もが叩けるAPIにはならないということです。二つ目はRESTはリソースに対してGET, POSTなど特定のメソッドを定義でき、GETには情報を取得してそれ以外の処理は何もしないというセマンティクスがつくので通信中の複数のレイヤーでキャッシュを強力に持たせることができます。その点でBFFなアプリではConnectは強いですが、APIを公開したりキャッシュを強く持たせたいアプリでは不向きです。

Architecture

Clean Architecture

細かく責務の分割ができ全てが最終的にEntityに依存する、更新に強いソフトウェアが作れます。今までアーキテクチャを強く意識することはありませんでしたが、開発の全ての工程に影響するため、今後もっと勉強していきたいです。Clean Architecture自体は今後長期にわたって運用したり、大規模チーム開発で大きな力を発揮するアーキテクチャだと思います。細かく責務を分割して構造が分かりやすいですが、チームメンバー全体がその思想を理解する必要があったり、ボイラープレートが多くなりがちなので一長一短だと思いました。ただボイラープレートは今はAIが書いてくれるしその部分のレビュー負荷は高くないので開発をしているときはあんまり気にならなかったです。
Container/Presentationパターン

こちらはフロントエンドのアーキテクチャです。CAほど有名でないので参考記事を貼っておきます。https://zenn.dev/buyselltech/articles/9460c75b7cd8d1 フロントエンドのアーキテクチャで行くとAtomic Designが有名だと思います。これはcomponents群をAtoms、Molecules、Organisms、Templates、Pagesの5階層に分けるやり方です。Atomic Designは責務を切り分けすぎてToo muchになりがち、かつチーム全員でどの層に切り分けるかの基準が曖昧になり、崩壊しがちだったと聞きます。一方Container/Presentationはpagesコンポーネント(Container)が制御のロジックを握り、components(Presentation)は制御の関数と状態を受け取り、それ通りにUIを表示するだけというやり方です。責務が明確になり、僕は結構好きでした。

以下ポエム

インターン期間中の2か月間、自分の将来やエンジニアとしての在り方について考えていました。CLI型のAIが登場し始めてから、「AIがエンジニアの仕事を奪う」という言説が現実味を帯びるようになり、かなり不安をあおられていたからです。

僕の場合、技術の勉強は好きですが、それは知的好奇心を満たすためだけではなく、その先に金銭的なものを求めていて、純度100%の興味だけでプログラミングをしているわけではないです。だからこそ、「第一線で活躍する現職のエンジニアは、この状況をどう捉えているのだろう？」とずっと気になっていました。それが、今回のインターンシップに参加した動機の一つでもあります。

インターン先のエンジニア組織は、東工大のサークル発で、所属する方々は修士のCS学位を持ち、常に技術のキャッチアップを欠かさない、誰が見ても強いエンジニアばかりでした。

そんなバックグラウンドを持つメンターや社員の方々と働く中で、二つのことに気づきました。一つ目は、直近でAIがエンジニアの仕事を完全に奪うのは不可能であるということ。意思決定の主体が人間である以上、AIに全てのコンテキストを伝えきる必要があり、現状それは不可能、もしくは時間がかかりすぎて非効率からです。この点は、フロントエンド開発をしていると特に実感します。もう全部俺がやった方が早いわとなりがち

二つ目は、どんなに優秀なエンジニアでも、5年後、10年後にAIが市場をどう変えるかは誰にも分からないということ。このテーマについては、ネット上の言説も、現場のエンジニアの方々の意見も様々でした。

結局のところ、将来AIが市場に与える影響を今議論しても水掛け論に過ぎません。そして、もしエンジニアの仕事がAIに完全に奪われる場合、現在のホワイトカラー職が全滅します。その時は潔く自宅警備員にでもなろうと思いますw。

このような現状認識に至ったので、もう将来に対して漠然とした不安を抱くのをやめ、目の前のこと(大学の勉強、インターン、チーム開発、コミュニケーション能力の向上)に集中しようと決めました。

あと、インターンやチーム開発を夏休みの間ずっとしていて思いましたが、僕は自分が思っていたよりも技術が好きで技術が好きな人が好きでした。プログラミングがオワコン的なことが世間一般に言われるようになっても好きなので割と最後の方までやってるんだと思いますw

まとめ

2か月の間でしたが週3フルタイムの出社形態だったこともあり、本当に学ぶことが多かったです。待遇もよく充実した就業体験を過ごすことができて感謝しています！自分はまだまだ弱いことを実感したのでもっとエンジニアとして強くなりたい🔥