２月〜８月までの約半年間、かなりフルタイムに近いペースでインターン生として働かせていただいていました。

本当に色んなことを経験させていただいたんですが、その中でもタスクをこなすということに対する理解が以前よりも少しは深くなったような気がしています。
ここでは半年の学びのまとめとして、ソフトウェアエンジニアとしてタスクをこなすとはどういうことなのか、何をするべきなのかということを現状の自分の理解でまとめたいと思います。

:::message
「できる様になったこと」ではなく「分かったこと」です。
まだまだこれらを完璧にできる様になったとはお世辞にも言えません。
これからも頑張ります！
:::

# タスクをこなすとは何か
まずそもそも「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だと思います。

ソフトウェアエンジニアとして働いている方々からしたらとても当たり前のことだと思うのですが、この事実にちゃんと意識を向けられていませんでした。

と言うのも、今までのインターンでは「丁寧に切り分けられた細かなタスク」が主だったので、「仕様通りに実装してマージすること = タスクをこなすこと」と認識してしまっていましたし、それで特に支障もありませんでした。ただ、この半年間でその認識は間違っていたんだと理解しました。
 
この感覚は小さい頃に母の料理を手伝っていた時の感覚に近いような気がします。僕は小さい頃、どうしても料理をしてみたくて母の料理の手伝いをすることがありました。その時は人参を切ったり鍋をかき回したりして、すっかり料理をした気分になっていましたが、今考えてみればそれは「料理をしている」とは言えなかったなぁと思います。

母がいつも行なっている料理は「レシピを考えて、具材を買って、調理器具を用意して、調理して、盛り付けて、食べてもらって、後片付けをする」までを含んだ料理です。僕はその数ある工程の中でも「調理」の部分だけを、しかもお膳立てされた状態でこなしただけで料理全体をした気になっていましたし、それで問題ありませんでした。しかし、本当に一人で料理をするのであればその感覚は捨てなければいけません。

ただ作るだけではなく後片付けまでに責任を持つ必要がありますし、買い物に行く時間が無いなら家族に頼んでおく必要もあります。

ここで言うところの「調理」は、ソフトウェア開発における「実装」だと思います。今までのインターンでのタスクではPdMやEM、メンターの方々にお膳立てしていただいた規模の小さいタスクの実装だけを行っていたため、そこまで深く考えずともタスクを問題なく進めることができていました。

しかしタスクの規模や複雑性が上がり、関係者も増えていくとそう簡単な話ではなくなります。

そのようなタスクだと、実装だけをしてユーザーに価値を届けられるかというとそんなことはなく、たとえば実装前に仕様がユーザーの課題を解決するための最適解なのかを考えたり、実装後にユーザーに届けるまでにエッジケースなどで問題が起きないか観点を洗い出してQAを行ったりと実装以外に必要な要素がどんどんと増えていきます。

全てを一人だけでやる必要はありませんが、それら全てをハンドリングしてユーザーに価値を提供できる段階まで持っていくことには責任を持つ必要があると感じました。

この半年間でプロフェッショナルとしてのエンジニアの働き方の一端を感じられたのがとても良かったです。

# 具体的に何をすればいいのか
では「ユーザーに価値を届けることに責任を持つ」ためには何をすれば良いのでしょうか？自分の中で大事だと思った要素がいくつかあったのでそれを書き出してみます。

## ユーザーに価値を届けるまでにどうなっていればいいかを洗い出す
まずタスクを始める前に設計をすると思うのですが、この段階が本当に大事だとこの半年間で深く実感しました。

このタイミングで最初にやらなければいけない事は完了条件をリストアップする事だと思います。
実装が完了してデプロイされた後にユーザーがどのようなユースケースで使用されるかを考えてそのパターンを洗い出します。

例えばブログの記事投稿機能を実装するというタスクなのであればこんな感じかなぁと思います。
```
- 記事が投稿した時にDBにデータが保存される
- 投稿に成功すると記事一覧画面に遷移する
- 遷移した後に成功した旨をトーストで表示する
- タイトルが入力されていない場合にバリデーションが出る
- バックエンドでエラーが出て投稿できなかった場合にエラートーストが出る
- 記事が変更されている時に画面遷移しようとするとダイアログが出る
```
本当はもっと構造化した方がいいとは思うのですが一旦例としてはこんな感じです。

このようにリストアップして正常系、異常系ともにユーザーが取りうるパターンが洗い出せると目指すべきゴールが明確になりますし、実装完了後のQAでも確認が容易になるのでまずやるべきことかなと思います。

ここで意識した方が良さそうなのは「このタスクにおける変数が何か」ということです。
例えばタイトルの有無や本文の文字数、ユーザーの動線などユースケース中の代わり得る値にどんなものがあるかを把握できているとエッジケースへの考慮漏れが少なくなります。全ての変数の全組み合わせを考慮し切るのは不可能に近いと思いますが、どんな変数があるかを把握するだけでも十分に効果があるんじゃないかと思います。

## 頭を使わずに実装できるところまで設計を詰める

目指すべき場所が分かった後はその完了条件を満たすためにどのような実装をしたらいいかを考えて実際に設計をします。
ユーザーストーリー単位で切ってもいいと思いますし、別の切り方でもいいと思うのですが、コミットと一緒で「最小限の意味あるまとまり」に切れると実装の進捗が確認しやすくなるほかレビューも容易になるので目指した方がいいとは思います。
僕はそこまでできませんでしたし、タスクの大きさによっては小さく切らない方がコスパが良かったりもすると思うのでいいバランスを考える必要はあるとは思いますが。

設計する時に意識した方が良さそうなのは「この設計であれば頭を使わずに実装できそうか」を考えることだと思います。

僕はインターンの途中まで実装中に悩んで手が進まないということが非常に多かったのですが、メンターに相談したところこれを意識すると良いということを教えていただきました。

設計通りに手を動かすだけで頭を使わない状態にまで持っていけばスムーズに実装を進められますし、何より予想外や考慮外のパターンが出てくることが減るので手戻りも少なくなります。途中からこれを意識できたので少しはスピードが上がったかなと思います。

## 適切に人を頼る
設計が終わったら実装に入ると思うのですが、タスクが大きくなればなるほど自分一人では実装し切るのが難しくなると思います。

特に僕の様なインターン生であればドメインの知識も乏しいですし、技術力も伸び代しかない状態なので様々な人の手を借りながらタスクを進めていかなければならないと思います。

設計が終わった段階で自分だけでできないことは十分に見えていると思うので、実際にできる人を頼る必要が出てきます。

人を頼るというのはとても当たり前のような気がしますが、意外とできていなかったです。特に適切なタイミングで頼るということが難しかった記憶があります。

就業型インターンとして働いたことのある人なら分かる人は多いと思うのですが、人に頼るというのは想像以上に難しいことだと思います。
自分よりも圧倒的に難易度も分量も多いタスクをこなしている社員の方の時間を奪ってしまうのは申し訳なく感じてしまいますし、何よりこんな簡単な事で頼ってしまっていいのかと考えたりして時間を溶かす事が僕も多かったです。

そのせいで実装が後手に回って引いたスケジュールからビハインドしたり、締切ギリギリになって無理な状態で頼ることになった事も何度もありました。

ただここで考えなければいけないのは、「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だという事です。

その中にはスケジュール通りに実装を終わらせることも含まれています。しかし社員の方の時間を取らないことは要件として入っていません。

つまり人を頼る事がタスクを進める上で最適解なのであれば申し訳なさなどは感じずに積極的に頼っていく事がむしろベストだという事です。

質問したり頼ったところでそれに対して怒ってくる人は稀だと思いますし、特にインターン生であれば分からないことばかりなのが前提なので引け目を感じずに頼るべきだと感じました。

設計段階で誰かの手を借りる必要がある事が発覚したらそれを先に伝えておいたり、いつまでにそれを完了しなければいけないかを意識していつ頼むのかを考えたりしておくことがスケジュール通りにタスクを進めることにつながるため、頼るべきタイミングを見逃さないことが大事だと学びました。

ただ頭では分かっていても引け目を感じてしまうが多かったので「自分でできる限りのことはしているからしょうがない」という気持ちを持つことにしています。

例えば質問する時であれば「自分が今こんなことをやっていて、今はこんな状態で、目指すべきゴールはここで、その間にこんなギャップがあります。これを埋めるためにはどうすればいいでしょうか？」の様に、可能な限り相手の認知負荷を下げられる様に質問の仕方を考えるなどです。

頼る時も「必要な情報を揃えて後はそれ通りに手を動かすだけ」の状態に近づける努力をする様にしました。

それをすることで多少は相手の負担が減った様な気がするので今までよりは人を頼りやすくなった様な気がしなくもないです。

## 自分の状況を知ってもらう
実装に入る前にはチェックを貰ったり人の目が入る機会は多いと思いますが、一度実装に入ると中々今の自分の状況を他の人に把握してもらうことが難しくなります。

しかし、「このまま行くとスケジュールからビハインドしそう」だとか「現状の実装だと漏れてる観点があるかも」などの途中で気付いてもらうことがとても大事だったりもします。

実装が終わってから「あれこの観点抜けてない？」「これだと動かなくない？」などの指摘が入ると悲惨なことになりますからね...

定期的なsyncの場がプロジェクトのメンバーや所属しているチームにあればいいのですが、全てのタスクでそのようなsyncの場が用意されている訳ではないですし、チーム全体の夕会などではそこまでタスクについて深く話す場は設けられていないことが多いと思うので不十分だと思います。

正直これに対するクリティカルな解決策はあまり見つけられていないのですが、チームのslackチャンネルがあるのであればそこで定期的に勝手にsyncするとかが良いのかなと思っています。ただ、他チームと共同で進めている場合などではそれでも不十分だと思うのでそれは自分からアクション取ってメンションしてでも見てもらいに行くべきだと思います。

どれだけ考えても自分一人の観点や思考には限界があるので(特にインターン生であれば尚更)、こまめに人の目を入れて常にブラッシュアップできるチャンスを作ることが大事だと学びました。

# 終わりに
この半年間で分かったことはたくさんありましたが、それを息をする様にできているとはまだまだ言えないなぁと思っています。
それが胸を張って出来ると言える様になってからがプロフェッショナルのエンジニアなのかなと思うので上記の事を胸に刻んで来年から働いていきたいです。

この半年間めちゃくちゃ充実していましたし、この会社を選んで本当に良かったなと思えました。これからもエンジニアとして活躍できるように知識と経験を積んで恩を返せる様にしていきたいです。

２月〜８月までの約半年間、かなりフルタイムに近いペースでインターン生として働かせていただいていました。

本当に色んなことを経験させていただいたんですが、その中でもタスクをこなすということに対する理解が以前よりも少しは深くなったような気がしています。
ここでは半年の学びのまとめとして、ソフトウェアエンジニアとしてタスクをこなすとはどういうことなのか、何をするべきなのかということを現状の自分の理解でまとめたいと思います。

:::message
「できる様になったこと」ではなく「分かったこと」です。
まだまだこれらを完璧にできる様になったとはお世辞にも言えません。
これからも頑張ります！
:::

# タスクをこなすとは何か
まずそもそも「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だと思います。

ソフトウェアエンジニアとして働いている方々からしたらとても当たり前のことだと思うのですが、この事実にちゃんと意識を向けられていませんでした。

と言うのも、今までのインターンでは「丁寧に切り分けられた細かなタスク」が主だったので、「仕様通りに実装してマージすること = タスクをこなすこと」と認識してしまっていましたし、それで特に支障もありませんでした。ただ、この半年間でその認識は間違っていたんだと理解しました。

この感覚は小さい頃に母の料理を手伝っていた時の感覚に近いような気がします。僕は小さい頃、どうしても料理をしてみたくて母の料理の手伝いをすることがありました。その時は人参を切ったり鍋をかき回したりして、すっかり料理をした気分になっていましたが、今考えてみればそれは「料理をしている」とは言えなかったなぁと思います。

母がいつも行なっている料理は「レシピを考えて、具材を買って、調理器具を用意して、調理して、盛り付けて、食べてもらって、後片付けをする」までを含んだ料理です。僕はその数ある工程の中でも「調理」の部分だけを、しかもお膳立てされた状態でこなしただけで料理全体をした気になっていましたし、それで問題ありませんでした。しかし、本当に一人で料理をするのであればその感覚は捨てなければいけません。

ただ作るだけではなく後片付けまでに責任を持つ必要がありますし、買い物に行く時間が無いなら家族に頼んでおく必要もあります。

ここで言うところの「調理」は、ソフトウェア開発における「実装」だと思います。今までのインターンでのタスクではPdMやEM、メンターの方々にお膳立てしていただいた規模の小さいタスクの実装だけを行っていたため、そこまで深く考えずともタスクを問題なく進めることができていました。

しかしタスクの規模や複雑性が上がり、関係者も増えていくとそう簡単な話ではなくなります。

そのようなタスクだと、実装だけをしてユーザーに価値を届けられるかというとそんなことはなく、たとえば実装前に仕様がユーザーの課題を解決するための最適解なのかを考えたり、実装後にユーザーに届けるまでにエッジケースなどで問題が起きないか観点を洗い出してQAを行ったりと実装以外に必要な要素がどんどんと増えていきます。

全てを一人だけでやる必要はありませんが、それら全てをハンドリングしてユーザーに価値を提供できる段階まで持っていくことには責任を持つ必要があると感じました。

この半年間でプロフェッショナルとしてのエンジニアの働き方の一端を感じられたのがとても良かったです。

# 具体的に何をすればいいのか
では「ユーザーに価値を届けることに責任を持つ」ためには何をすれば良いのでしょうか？自分の中で大事だと思った要素がいくつかあったのでそれを書き出してみます。

## ユーザーに価値を届けるまでにどうなっていればいいかを洗い出す
まずタスクを始める前に設計をすると思うのですが、この段階が本当に大事だとこの半年間で深く実感しました。

このタイミングで最初にやらなければいけない事は完了条件をリストアップする事だと思います。
実装が完了してデプロイされた後にユーザーがどのようなユースケースで使用されるかを考えてそのパターンを洗い出します。

例えばブログの記事投稿機能を実装するというタスクなのであればこんな感じかなぁと思います。
```
- 記事が投稿した時にDBにデータが保存される
- 投稿に成功すると記事一覧画面に遷移する
- 遷移した後に成功した旨をトーストで表示する
- タイトルが入力されていない場合にバリデーションが出る
- バックエンドでエラーが出て投稿できなかった場合にエラートーストが出る
- 記事が変更されている時に画面遷移しようとするとダイアログが出る
```
本当はもっと構造化した方がいいとは思うのですが一旦例としてはこんな感じです。

このようにリストアップして正常系、異常系ともにユーザーが取りうるパターンが洗い出せると目指すべきゴールが明確になりますし、実装完了後のQAでも確認が容易になるのでまずやるべきことかなと思います。

ここで意識した方が良さそうなのは「このタスクにおける変数が何か」ということです。
例えばタイトルの有無や本文の文字数、ユーザーの動線などユースケース中の代わり得る値にどんなものがあるかを把握できているとエッジケースへの考慮漏れが少なくなります。全ての変数の全組み合わせを考慮し切るのは不可能に近いと思いますが、どんな変数があるかを把握するだけでも十分に効果があるんじゃないかと思います。

## 頭を使わずに実装できるところまで設計を詰める

目指すべき場所が分かった後はその完了条件を満たすためにどのような実装をしたらいいかを考えて実際に設計をします。
ユーザーストーリー単位で切ってもいいと思いますし、別の切り方でもいいと思うのですが、コミットと一緒で「最小限の意味あるまとまり」に切れると実装の進捗が確認しやすくなるほかレビューも容易になるので目指した方がいいとは思います。
僕はそこまでできませんでしたし、タスクの大きさによっては小さく切らない方がコスパが良かったりもすると思うのでいいバランスを考える必要はあるとは思いますが。

設計する時に意識した方が良さそうなのは「この設計であれば頭を使わずに実装できそうか」を考えることだと思います。

僕はインターンの途中まで実装中に悩んで手が進まないということが非常に多かったのですが、メンターに相談したところこれを意識すると良いということを教えていただきました。

設計通りに手を動かすだけで頭を使わない状態にまで持っていけばスムーズに実装を進められますし、何より予想外や考慮外のパターンが出てくることが減るので手戻りも少なくなります。途中からこれを意識できたので少しはスピードが上がったかなと思います。

## 適切に人を頼る
設計が終わったら実装に入ると思うのですが、タスクが大きくなればなるほど自分一人では実装し切るのが難しくなると思います。

特に僕の様なインターン生であればドメインの知識も乏しいですし、技術力も伸び代しかない状態なので様々な人の手を借りながらタスクを進めていかなければならないと思います。

設計が終わった段階で自分だけでできないことは十分に見えていると思うので、実際にできる人を頼る必要が出てきます。

人を頼るというのはとても当たり前のような気がしますが、意外とできていなかったです。特に適切なタイミングで頼るということが難しかった記憶があります。

就業型インターンとして働いたことのある人なら分かる人は多いと思うのですが、人に頼るというのは想像以上に難しいことだと思います。
自分よりも圧倒的に難易度も分量も多いタスクをこなしている社員の方の時間を奪ってしまうのは申し訳なく感じてしまいますし、何よりこんな簡単な事で頼ってしまっていいのかと考えたりして時間を溶かす事が僕も多かったです。

そのせいで実装が後手に回って引いたスケジュールからビハインドしたり、締切ギリギリになって無理な状態で頼ることになった事も何度もありました。

ただここで考えなければいけないのは、「タスクをこなすこと」は「ユーザーに価値を届けることに責任を持つこと」だという事です。

その中にはスケジュール通りに実装を終わらせることも含まれています。しかし社員の方の時間を取らないことは要件として入っていません。

つまり人を頼る事がタスクを進める上で最適解なのであれば申し訳なさなどは感じずに積極的に頼っていく事がむしろベストだという事です。

質問したり頼ったところでそれに対して怒ってくる人は稀だと思いますし、特にインターン生であれば分からないことばかりなのが前提なので引け目を感じずに頼るべきだと感じました。

設計段階で誰かの手を借りる必要がある事が発覚したらそれを先に伝えておいたり、いつまでにそれを完了しなければいけないかを意識していつ頼むのかを考えたりしておくことがスケジュール通りにタスクを進めることにつながるため、頼るべきタイミングを見逃さないことが大事だと学びました。

ただ頭では分かっていても引け目を感じてしまうが多かったので「自分でできる限りのことはしているからしょうがない」という気持ちを持つことにしています。

例えば質問する時であれば「自分が今こんなことをやっていて、今はこんな状態で、目指すべきゴールはここで、その間にこんなギャップがあります。これを埋めるためにはどうすればいいでしょうか？」の様に、可能な限り相手の認知負荷を下げられる様に質問の仕方を考えるなどです。

頼る時も「必要な情報を揃えて後はそれ通りに手を動かすだけ」の状態に近づける努力をする様にしました。

それをすることで多少は相手の負担が減った様な気がするので今までよりは人を頼りやすくなった様な気がしなくもないです。

## 自分の状況を知ってもらう
実装に入る前にはチェックを貰ったり人の目が入る機会は多いと思いますが、一度実装に入ると中々今の自分の状況を他の人に把握してもらうことが難しくなります。

しかし、「このまま行くとスケジュールからビハインドしそう」だとか「現状の実装だと漏れてる観点があるかも」などの途中で気付いてもらうことがとても大事だったりもします。

実装が終わってから「あれこの観点抜けてない？」「これだと動かなくない？」などの指摘が入ると悲惨なことになりますからね...

定期的なsyncの場がプロジェクトのメンバーや所属しているチームにあればいいのですが、全てのタスクでそのようなsyncの場が用意されている訳ではないですし、チーム全体の夕会などではそこまでタスクについて深く話す場は設けられていないことが多いと思うので不十分だと思います。

正直これに対するクリティカルな解決策はあまり見つけられていないのですが、チームのslackチャンネルがあるのであればそこで定期的に勝手にsyncするとかが良いのかなと思っています。ただ、他チームと共同で進めている場合などではそれでも不十分だと思うのでそれは自分からアクション取ってメンションしてでも見てもらいに行くべきだと思います。

どれだけ考えても自分一人の観点や思考には限界があるので(特にインターン生であれば尚更)、こまめに人の目を入れて常にブラッシュアップできるチャンスを作ることが大事だと学びました。

# 終わりに
この半年間で分かったことはたくさんありましたが、それを息をする様にできているとはまだまだ言えないなぁと思っています。
それが胸を張って出来ると言える様になってからがプロフェッショナルのエンジニアなのかなと思うので上記の事を胸に刻んで来年から働いていきたいです。

この半年間めちゃくちゃ充実していましたし、この会社を選んで本当に良かったなと思えました。これからもエンジニアとして活躍できるように知識と経験を積んで恩を返せる様にしていきたいです。

タスクをこなすとは何か

最近気づいたことを備忘録としてまとめておきます。

僕はreactを触り始めて１年くらい経ちましたが今まで配列の分割代入をuseStateなどのHooksでしか見たことがありませんでした。

正直今まで全く気にしてもおらず何となく使っていたのですが、TSのタプル型を勉強している時にふと「なんでuseStateとかだけタプル的な返し方なんだろう...?」とふと気になりました。

正直あんまり調べてないので僕の意見になるのでご注意ください。

# なぜオブジェクトの分割代入ではダメなのか

結論から言うと、「名前が被りまくって冗長すぎるから」だと思ってます。
同じコンポーネントないでuseStateを複数回呼び出すユースケースっていくらでもあると思うんですが、もしこれがオブジェクトだった場合どうなるでしょうか？

```js
// 通常のuseState
const [ title, setTitle ] = useState('')
const [ description, setDescription ] = useState('')

// useStateの返り値が配列だったら
const { getter: title, setter: setTitle } = useState('')
const { getter: description, setter: setDescription } = useState('')
```

useStateからオブジェクトが返り値として返ってきた場合、仮にプロパティ名がgetterとsetterだとするならば、毎回別の名前を命名して代入する必要があります。冗長ですし不便ですね。

配列であればインデックスアクセスで済むので毎度再命名せずとも好きな名前で返り値を定義することができます。便利ですね。

# なぜuseStateでこれが起こって、通常は起こり得ないのか
ではなぜこのユースケースがあまり見られないのでしょうか？
その答えは「関数の返り値を同じスコープ内で複数回呼び出して、別の名前で分割代入したい」というパターンが極端に少ないからだと考えています。

基本的に関数の返り値を分割代入したいのはHooksであったりapiなどからオブジェクトを取得したい場合だと思うのですが、その場合同スコープ内で何度もそれらが呼ばれることはない様に思われます。少なくとも僕は見たことがありません。

TSのタプル型があまり見られないのも同様の理由かもしれませんね。

逆にuseStateやuseCallbackなどは、同じ関数で別の状態を定義するため「関数の返り値を同じスコープ内で複数回呼び出して、別の名前で分割代入したい」となるわけですね。

タプル型を知った時に「こんなのどこで使うん？」と思ったんですが身近なところで有用性のある利用法が見つかってよかったです。


useStateが配列で返ってくる理由に気づいたかもしれない

こんにちは。やたです。
就活が一段落し自分の進路が決まりました。
今回は、そもそもどこに行くのか、なぜそこにしたのか、そこでどんなことをしていきたいのかなどを忘れない内に纏めておこうと思いこれを書くことしました。
あまり誰かの役に立つためになどは考えていないのですが、26卒以降の就活生の方に役立つことがあればいいなぁ。

# そもそもどこ行くねん
僕が新卒で入社する企業は**株式会社LayerX**です。
もしかしたら知ってる方もいれば知らない方もいらっしゃると思うので軽く紹介しておきます。
https://layerx.co.jp/

## LayerXの概要
- ミッション：「すべての経済活動を、デジタル化する。」
- 2018年創業
- 社員数約250人(2024年１月時点)
- 法人支出管理SaaSのバクラクが中心プロダクト
- バクラク以外にもFintech事業、AI・LLM事業を行っている
- 三井物産とのジョイントベンチャーもある

# 選んだ理由
僕がLayerXを選んだ理由は当たり前ですが就活の軸に最も合っている企業だったからです。
その軸は３つあります。
## 人との繋がりを感じられること
正直ふわっとしている曖昧な要素なんですが、僕にとっては一番重要なことでした。

就活を始める上で「自分って何が一番幸せなんだろうか」と考え過去を振り返った時に人との繋がりを感じることが一番の幸せなんじゃないかという結論に至りました。

では具体的に人との繋がりが何かというと、僕の中では２つ要素があります。

1. インフォーマルなコミュニケーション
2. 他者への貢献

この二つの要素から、ある程度出社する人がいて、雑談があって、toBの事業を行っている企業に就職したいなと考えるようになりました。

これだけであれば該当する企業は多いんじゃないかなと思います。
ただLayerXではこれらの要素が他の企業に比べても多い気がします。
例えば僕がインターンしていた時の話ですが、出社した日には必ず社員の皆さんとランチに行っていました。しかもこれはインターン生の有無に関わらずです。こんなに仲が良いんだと驚いた記憶があります。
他にも、行動指針に「徳」や「Trustful Team」があるように、僕の考える人との繋がりに必要だと思われる要素が特に多かった印象があります。

## 職能で分かれていないこと
これはかなり企業が絞られる要素だと思います。

フロントエンドやバックエンドなどの１分野に縛られず、フルスタックな開発ができる環境に身を置きたいという考えです。

基本的に多くの企業(特に大企業)では職能で分かれていることが多いので、自分の求めるものとは少し違うかもなぁと考えていました。
:::message
採用の観点から考えれば企業規模が大きくなるにつれて職能別になっていくのはむしろ自然なことだと思います。
:::

僕はエンジニアとしてキャリアをスタートさせますが、将来的にPMとしての働き方にも挑戦したいという気持ちがあったので、幅広い技術の知識や経験を積むことができるフルスタックな開発環境を求めていました。

探してみてびっくりしたんですが、職能で分かれていない企業ってほとんどありませんでした。

LayerXではFEBE関係なくタスクでチケットが切られているので、幅広く技術に触れられる機会が間違いなくあるんじゃ無いかと思います。

## 新卒で入って成長することができること

これ自体が目的というよりも、自分の幸せである「人との繋がりを感じられる」様な環境に身を置き続けるために、またPMを務められるような技術に対する造詣を深めるためには成長するしか無いと考えているため副次的な軸としてこれを置いています。

これから先ジュニアレベルのエンジニアの需要はどんどんなくなって行きそうだなぁという思いもあります。

LayerXには本当に優秀すぎるエンジニアの方々が多く(といっても自分から見たらどの企業のエンジニアも強すぎて違いが分からないのですが...)、また企業規模がまだ小さいことからチャレンジできる環境が多いので成長できる気しかしません。
もちろん僕の頑張り次第ではあるのですが...
# その他良いと思ったところ
ここからは就活の軸とは関係なくLayerXの良いと思った点を列挙してみます。
## 企業文化が浸透している
これはLayerXの人なら誰もが口を揃えていうことだと思います。
行動指針や羅針盤のキーワードが普段働いている中で自然と出てきます。こんな会社他に見たことがないです。

↓行動指針
https://speakerdeck.com/layerx/company-deck?slide=10

↓羅針盤
https://speakerdeck.com/layerx/compass_202209

企業の体現したい姿を社員が常に意識して、それが行動にも表れている所が僕はめちゃくちゃ好きです。

## 仕様にも口を出せる
これは就活の軸とも被る話ではあるんですが、プロダクト全体に広く携われるのはとても良いなぁという印象があります。

実際僕がインターンしていた時もPMの方、デザイナー、僕の３人で仕様を検討して(と言っても僕は基本大枠が決まっているものを聞く立場でしたが... もっと頑張りたい...!)タスクが決まることもありました。

エンジニアでありながらプロダクトを決定づける当事者になれるのは、正に僕の求めている要素です。
## 渋谷にない
地味にでかいです。
メガベンチャーとかだと割と渋谷のスクランブルスクエアとかにオフィスがあることが多いと思うんですが、正直渋谷は人も多いし何よりあまり綺麗ではなくて好きになれなかったので人形町(現オフィス)だったり東銀座(移転先)にオフィスがあるのは個人的にめちゃくちゃ嬉しいです。

# 少しの懸念点
良い点ばかり挙げていると信者感が出てしまう気がするので懸念点も挙げておきます。

## 同期が少ない
やはり企業規模が小さいので他社と比べて採用人数が多くないことは致し方ないことだと思います。

ただ同期ができるのは新卒だけです。
その点は少し勿体無いかなぁと考えてます。

## 椅子が硬い
オフィスの椅子が硬くて腰が痛くなるので、次の移転で良い椅子になることを祈ってます。

# 最後に
正直自分の技術力にはそこまで自信がなく、就職も上手くいくか自信はありませんでした。ただ結果としては、第一志望の企業から内定をいただけて、心から満足して就活を終えることができて本当によかったです。

まだ入社までに１年以上あるので先の話にはなりますが、バクラクをより良いプロダクトにできるようなエンジニアになれる様精進していこうと思います。

ここまで読んでくださりありがとうございました。


【LayerX】就職先を決めました。

一旦就活が落ち着いたやたです。今回はソフトウェアエンジニアとして新卒就活をしてみて「これはやっておいてよかったな」「これはあんま意味なかったな」ということをざっくりまとめておこうと思います。

これからソフトウェアエンジニアとして就活する26卒以降の方の参考になれば嬉しいです。

# 略歴
まず僕がどんな属性でどんな就活をしていたのかをざっくり紹介しておきます。

## 属性
- 文系の学部３年
- プログラミングは高校から触っていたが、本格的に開発をやり出したのは大学に入ってから
- 全く技術オタクとかではない
- フロントエンドメインでバックエンドの経験はあまりない
- 就活の時はメガベンチャーのソフトウェアエンジニアを中心にしていた

## ざっくりとしたスケジュール
詳しい話はまた別の記事で書きたいと思うのでここではざっくりとだけ紹介します。

- 大学入学〜２年５月
基礎的なプログラミングの勉強と個人開発に時間を使っていました。

- ２年７月〜３年５月
とあるベンチャー企業で長期インターンを始めて実務経験を積みました。

- ２年２月〜３年６月
サマーインターンに向けての選考を受けていました。

- ３年７月〜３年12月
色々なインターンに参加して経験や企業理解を深めました。

- ３年１月
本選考を何社か受けました。第一志望に内定を頂き就活終了。


# やってよかったこと
いっぱいあります。

## 1. 長期インターンに早くから参加したこと
前述の通り僕は２年の７月から長期インターンに参加していました。このタイミングで長期インターンを始めておいたことのメリットは本当に沢山あって、是非みなさんにもこれくらいの時期(もっと早くてもいいと思います)から参加してみることをオススメします。

何がそんなに良かったかというと、ざっくりこんな感じです。
- エンジニアとして働くための基礎の基礎を学ぶことができる
プログラミングそのものというよりも、社員の方とのコミュニケーションだったり、Gitの実践的な使い方、仕事をどうやって進めていくかなどを学ぶことができます。
- サマーインターンの選考の時期に実務経験が１年近くになっている
実は就活イベントには参加するために選考を通過しなければいけないものがあります。その選考を通過する際に実務経験の有無はかなり重要で、半年以上実務経験を積んでいるか否かで大きく通過率に差が出ます。僕は技術的に強かったわけでもないですが、実務経験を積んでいたことで一度も落ちたことはありませんでした。選考ありの就活イベントはその分恩恵も大きいのでこのメリットは大きいと思います。
- 職業体験ができる
そもそも、働いたこともないのになんとなくプログラミングをやっていたからエンジニアに進むのは危険だと思います。実際に働いてみて楽しいかを体験するとより自分のキャリアに対して考えが深まるんじゃないかと思います。

## 2. サポーターズの1on1面談イベントに参加したこと
先ほども出てきましたが、就活イベントには選考アリの特別なイベントというものがあります。サポーターズの1on1面談イベントもその内の１つです。

こんなの↓
https://talent.supporterz.jp/events/77a08c14-6bbf-4b58-8471-ecd26ab32dd6/

このイベントは企業の人事やエンジニアの方と1対1で直接話すことができるというものです。大体15~30人くらいの学生が選抜されて１日に最大10社と30分ずつ話すことができます。大体３月から始まって５月くらいまでやっていた気がします。(本選考の時期にもある)

それの何が良いかと言うと、
- 企業の情報を効率よく集めることができる
就活生の最初の課題として「そもそも企業をよく知らない」というものがあります。仕方がないのですが、一般的に有名な企業でもない限り就活を始めた人にとってはどの企業も同じに見えてしまいます。このイベントでは信頼できる企業が集まっていますし、その企業についての説明を聞いて直接話すことで理解を深めることができるのでとても良い機会でした。

- インターン選考の優遇を貰える
このイベントに参加した人は基本的にサマーインターンの選考優遇をもらえます。もちろん企業によりますが、ES免除だったりコーディングテスト免除などの特典が多かった印象です。正直ESを書くのが就活の中で１番面倒なことだと勝手に思っているので、ESを免除してくれるこのイベントは本当に助かりました。

- お金もらえる
下世話な話ですが、このイベントに参加すると何故かお金がもらえます(?)。しかも結構な額。回によって違いますが1万〜１万５千円ほどもらえます。なんで？
それに加えて面談した企業からスペシャルオファー(企業が特に気に入った学生数名のみに出す特別なオファー)を貰うと１つにつき3000円プラスでもらえます。意味が分かりませんね。
丸一日使うとはいえ、時給換算しても明らかに普通のバイトより割りがいいのでとてもありがたかったです。

ただこれだけメリットがあるこのイベントですがとんでもなく疲れるのでそれは覚悟しておいた方がいいです。本当に毎回死ぬかと思うくらい脳が疲れた状態で終了した記憶があります。(ただ、選考優遇とお金に釣られて３回ほど参加しました...)
## 3. サマーインターンに沢山参加したこと
割と普通のことではあるんですが、サマーインターンはできるだけ沢山参加しておいた方がいい気がします。少しでも気になっている企業であれば参加する価値はきっとあると思います。

良かった点としてはこんな感じです。
- 企業理解がとんでもなく深まる
インターンに参加すると企業を中から見れるのでめちゃくちゃ良かったです。社員の方にお話を伺う機会は何回も用意されますし、面接や面談では見られない普段の姿を見ることができるので、企業の雰囲気や文化をより強く実感できるのではないかと思います。
特にランチの場とかではぶっちゃけた話とかも聞けたりするのでオススメです。
- 本選考前に選考の経験が積める
これから就活を始める方で、面接などに関して経験が豊富な方ばかりではないと思います。そんな方が選考の概要を掴むことができる練習の場としてもインターンは良い機会だと思います。面接での話し方、自己分析、お祈りメールとの向き合い方など、サマーインターンの時期に経験しておくことで本選考が明らかに戦いやすくなります。サマーインターンに落ちたところで人生に与える影響は本当に少ないので早めに失敗しておくことは本当に有意義だと思います。
- 技術力が上がる
プロとして働いている社員さんや周りの優秀な学生エンジニアの話を聞いて知識やノウハウを吸収することでかなり技術力の向上に繋がった気がします。
- お金もらえる
これまた不思議な話なんですがエンジニア就活はすればするほどお金が貰えます。総合職の就活ではありえないですね。特にサマーインターンは各社が値段の釣り上げ競争をしているので普段のバイトでは貰えない時給を貰えたりします。勉強しながらお金ももらえるので最高の環境ですね。
- エンジニア友達できる
次で詳しく書くんですが、サマーインターンに行くと友達が増えていい感じです。

## 4. エンジニア友達を作ったこと
サマーインターンなどに参加すると同じ学生エンジニアと関わる機会がグッと増えます。特にインターンでは雰囲気や志向が似ている人が採用されやすい印象があるので仲良くなりやすい印象があります。

「それほんとに必要なのか？」って話だと思いますが思わぬメリットが沢山あります。

- 情報交換ができる
これが最も大きいと思います。
就活は情報戦です。情報を得られるかどうかで結果に大きく差が出ます。インターンの情報を仕入れるのもそうですし、面接ではどんなことが聞かれたか、この軸で就活するときにどんな企業が合っていそうかなど、知っているだけで得をすることが非常に多いです。それを気軽に聞ける友達がいるだけで就活のしやすさが数段変わってくるのでオススメです。
- 技術の話を対等にできる人が増える
これは非情報系学部の人に限った話かもしれませんが、僕のような人間は基本的に大学で技術の話ができる人がほぼいません。僕はプログラミングサークルに所属しているので辛うじて話せる人はいるのですが、それでも多くはありません。そんな時にエンジニア友達がいると気軽に話せてとても良かったです。
- 将来に向けても有益そう
打算的になってしまって申し訳ないのですが、サマーインターン(特に有名企業の)に参加しているような人は総じて優秀な人ばかりです。僕の周りのエンジニア友達も錚々たる企業に就職が決まっていますし、これからもどんどん活躍していくんだろうなと言うのが容易に想像できる人しかいません。そんな人たちと仲良くしておくことで将来的にもいいことが多いんじゃないかなと勝手に予想しています。
- 普通に楽しい
最終的にはこれに尽きるのかもしれないんですが、気の合う友達が増えることはシンプルに嬉しいことです。実際僕もインターンで知り合った友達とインターン後も何度も会っていますし、これからも会うんだろうなと思っています。技術関係なく話していて楽しい人ばかりなので純粋に良かったなと感じます。

## 5. あくまで主体的に選ぶという意識を持ち続けたこと
これは気持ちの持ち方でしかないんですが、「あくまで自分のキャリアを決めるのは自分であって、集めた情報はただの情報でしかない」と意識し続けることが割とやっていて良かったと思っています。

やはりどの企業の方もいい方ばかりですし魅力的な企業ばかりなので、話す度に「この会社いいなぁ」と目移りしがちです。特に企業の魅力をアピールされた際には。しかし「あくまで企業の人は多かれ少なかれポジショントークをしている」ということを意識しておくと惑わされずにキャリアを決めようという気持ちになれます。人事の方も自分の会社に優秀な人材を集めることが使命ですし、エンジニアの方も他社を勧めるようなことはしません。となると、悪気があるないではなくどうしても実態よりも企業はよく目に映るものです。受け取った情報から何が事実で何が意見か、本当にそれは実態を表しているのかということを疑い続け取捨選択することでより良い選択ができると思います。

# やらなくてよかったこと
ここからは逆にやらなくて良かったことです

## 1. 就活エージェントを何個も登録すること
これはマジで無駄だったなと思います。
僕は累計で３つ就活エージェントに登録したんですが、最終的には１つ以外は使いませんでした。就活エージェントは謎ルールがあり、「別の就活エージェント経由で接点をすでにもっている企業を紹介することはできない」らしいのです。

であるならば１つに絞って使い倒した方がいいとは思いませんか？特にメガベンチャーなどの誰もが認める有名企業に入りたいと考えている方であれば複数個使う意味は特にないと考えて良いと思います。

個人的にはメガベンチャー志向の人はサポーターズさえ使っておけばいい気がしました。(この記事はプロモーションを含みません)


## 2. ポートフォリオを作り込むこと
振り返るとあんまり意味はなかったなぁと思いました。僕はポートフォリオに関してはかなり時間を使って作ったんですが、それのおかげで選考が上手く行ったことはあまりなかった気がします。面接での質問でもどちらかと言えばチーム経験の方をより重点的に聞かれた印象がありますし、過去の制作物に関する質問も50%くらいでしか聞かれませんでした。

もちろん技術的に語れるプロダクトが何もないと質問された時に詰んでしまうので、何かしらは用意しておく必要がありますが、そこまで大量の時間を投下して作り込むよりかはその時間を使ってハッカソンなどに参加して主体的なチーム経験を積んだりした方がいいのではないかと思います。

# さいごに
以上が僕のやって良かったこと、やらなくて良かったことですが、これはあくまで僕の経験談でしかないので他の先輩の話も聞きつつ良い就活生ライフを送ってくれたらと思います。ここまで読んでいただきありがとうございました。

【エンジニア就活】やってよかったこと、やらなくてよかったこと

お手伝いサークル公式サイト開発者のやたです。
今回、今年の３月から９ヶ月ほど稼働しているお手伝いサークル公式サイトのリプレイスを行いました。
それに伴ってどのように変更したのか、どんなところを改善したのかなどを紹介していこうと思います。

# お手伝いサークル公式サイトって何？
横浜国立大学に存在するお手伝いサークルの活動を支援するためのWebアプリケーションです。学生生活や授業を始めとした大学に関する質問をX(Twitter)を通して回答することができます。

## サイトURL
https://otetsudai-circle.com

## X URL
https://x.com/PALDOW2022

## GitHub
https://github.com/arfes0e2b3c/q-box-next

# 技術スタック
以前まではNuxt.jsで書かれていたものをNext.jsにリプレイスしました。詳細な技術スタックの変化は以下の通りです。

| 種類 |Before|After| 
| ---- | ---- |---- |
|ホスティング|Google App Engine|Vercel|
| フロントエンド |Nuxt.js v2.15.8| Next.js  v13.5.6| 
| CSS |Sass| vanilla-extract | 
|Fetch|axios|react-query|
|状態管理|-|Zustand|
|認証|Firebase Authentication|Firebase Authentication|
|ストレージ|microCMS|S3, microCMS|
|CDN|-|Cloudfront|
|CI|-|GitHubActions|

# システム構成図

ざっくりとしたシステム全体の流れです。
複雑な処理も多くないためかなりシンプルな構成になっています。

![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/e1b9cc29e11544d0bb456e9e8215e4ca/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%A7%8B%E6%88%90%E3%81%99%E3%82%99%20(3).jpg)
*システム構成図です*

# 修正点
旧お手伝いサークル公式サイト(以下旧サイト)ではいくつかの問題が発生しており、今回のリプレイスに伴っていくつかの修正を行いました。
##  よく検索されるキーワードを追加
検索ボックスにフォーカスした際に「よく検索されるワード」が出るのですが、旧サイトでは僕が開発初期に適当に入れたものがそのままになっていました。
![image](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/8d2058e48e33483ab0d82aa4af753f2a/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2013.22.06.png)

これらのワードは実態と乖離していたので、それに合わせるようにリストの修正を行いました。

具体的には過去の質問1000件の質問文を取得し、単語の頻度分析を行った上で妥当なものをお手伝いサークルさん側に選択してもらいました。

![image](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/2ffeb1ce0a4e4ac980f2e5508b2f396a/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2013.28.17.png)

## サムネイルの文字とtwitterのリンクが被っている

最近のX(Twitter)の~~改悪~~アップデートによってサムネイルの表示方法に変更がありました。それによって既存のサムネイルでは文字とリンクが被ってしまっていたのでサムネイルの文字を右側に寄せることにしました。

|Before|After| 
| ---- | ---- |
|![image](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/8866433a641648d2b0ca861412ab04dc/6O8J0_rw.jpeg)| ![image](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/545c5ce2d98d429fb7fd157a306ae1ac/kpgijxf3m20.webp)| 

## apiのリクエスト回数が分からない
現在Twitter APIを使用してサイトからツイートを行なっているのですが、これも~~改悪~~アップデートによってFreeプランではツイートが1500件/月、50件/24時間までと制限されています。

平常時では問題にはならないのですが、新入生入学前後では質問箱の投稿は非常に多く可能性としては50件を超えることは十分考えられます。その対策として管理者画面に24時間以内のリクエスト数の表示を追加しました。

内部的にはtwitter apiにリクエストを送るたびにmicroCMSにログが蓄積され、それをここでカウントしている形になります。
![image](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/cba4eb25f7274099abc7fec339795372/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2013.40.30.png)

## 情報提供欄から新規質問への移動
Xでリンクを押した際に遷移する詳細ページには、その質問に対する情報提供を送信できるテキストボックスがあります。

これは完全にこちらの設計ミスではあるのですが、この情報提供欄から新規で質問を投稿される方がいらっしゃるそうで、旧サイトではそれを手作業で新規質問として投稿し直し回答するということをお手伝いサークルさん側に強いている状況でした。
![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/c94a7bb1d1dc4b4fbaabf1654869d349/www.otetsudai-circle.com_.png)
*情報提供欄*

それを管理画面から移動できる機能として追加しました。



## スマホだと検索できないことがある

未だに原因はわかっていないのですが、旧サイトではスマホで検索しようとすると正常に動作しないというものがありました。

推測ですが、旧サイトでは検索結果を表示する画面でmount時にURLのクエリから検索ワードを取得していたため、検索ワードをもとにしたapiのリクエストとの実行の兼ね合いでエラーが発生していたのではないかと考えています。

現サイトでは画面遷移時にuseSearchParamsを使用して検索語句を取得し、その後react-queryで取得し問題なく検索ができる様になっています。

# 工夫したこと
## 実際の開発に寄せた開発環境の構築
今回は全体的に実務を意識したものにしようという気持ちで開発を行いました。
その中でも何点かを紹介します。

### ステージング環境の構築
以前までは開発環境と本番環境のみで開発を行なっていたのですが、機能改善の際に本番環境でテストする必要があったりと怖さや不便さがあるタイミングが多く、改善が必要だと感じていました。
そこで今回はステージング環境を用意し手軽で安全に継続開発を行えるようにしました。
具体的には以下のことを行いました
- mainブランチと作業ブランチに加えてdevelopブランチの作成
- Vercelでmainブランチをproduction環境、developブランチをpreview環境に設定
- microCMSを本番用とステージング用の２種類用意
- (以前から)twitter apiの検証用アカウントを利用

これにより開発者体験がかなり向上しました。

### GitHubActionsを使用したCI
Pull Requestを出した際に自動でlintなどを確認できるよう、GitHubActionsを利用したCIの構築を行いました。Vercelが自動で行なってくれるテストも含めて常に３つが動作しています
1. Vercelの自動テスト
2. lintやbuildに問題がないか確認するテスト
3. lighthouseによるパフォーマンスの監視テスト

3.に関しては後述します。
### Pull Requestのdescription
今までインターン、特に就業型のインターンに参加させていただいた際に教えていただいたようにdescriptionを書くことを意識しました。

正直に言うと最後の方やGitHubActionsに苦戦している時はかなり適当(というか書いていない)ことも多かったので全てのPull Requestを書ければよかったなぁと反省しています。
![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/3dcebe3770f7429596cccfff113ceaab/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2015.44.05.png)
*思ったよりも書いてなかった...誰も見る人がいないと書くモチベ下がりますね*
## パフォーマンスの考慮
今までの一番大きな課題はパフォーマンスでした。
このアプリケーションの特徴として「詳細ページのみの遷移がとても多い」というものがあるのですが、その詳細ページのパフォーマンスが低く画面が表示されるまでに時間がかかっていました。というのも、ページを訪れるたびにmicroCMSにリクエストが走る上、取得したデータからクライアント側でcanvasに画像を描画するという非常に重い処理をしていたためです。
これらパフォーマンス関連の課題を解決するために以下の２つを行いました。

### SSG
詳細ページに関しては基本的に静的なページだったのでSSGであらかじめ生成しておいたHTML(とその他ファイル)を配信する形に変更しました。
これによりapiリクエストをせずにページを高速に表示できる様になりました。

### 画像配信の最適化
前述の通り、旧サイト内の画像は基本的にmicroCMSから受け取ったデータと背景画像をクライアントサイドでcanvasに合成して表示していました。しかしそれではクライアントサイドに負荷がかかりすぎてしまうことに加え何よりパフォーマンスがデバイス依存になってしまう部分が大きいので、クラウドのストレージから取得する形に変更しました。

ストレージとして使用しているのはS3で、imgixを利用して生成した画像データをS3に格納し、Cloudfrontを経由して画像を取得しています。これによりキャッシュを効かせて画像を取得できるため早ければ１桁ミリ秒(平均20~30ミリ秒)で画像を取得しそのまま表示ということができる様になりました。

最終的なパフォーマンスは以下の通りです。
> 条件：/x7qg4ftjvrのページをlighthouseで計測

| 種類 |旧サイト|新サイト| 
| ---- | ---- |---- |
|モバイル|![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/64ff385b862948478653079fcd19b837/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2016.28.02.png)|![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/ea74d20a280e455981c3e43107a01d71/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2016.35.57.png)|
|デスクトップ |![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/cdadf48c372144398c373b04e6667f3f/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2016.28.47.png)| ![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/151b2335dec64b05bc0654d02989b8d0/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2016.37.11.png)| 
:::message
当たり前ですが、何回か計測して一番良さそうなやつを持ってきています。大目に見てください。
:::

## APIの切り出し
旧サイトの大問題として「クライアントサイドで外部APIを叩いている」というものがありました。ですので言ってしまえば開発者ツールからAPIキーが完全に見える状態だったということです。やばいですね。

ということで今回のリプレイスに伴って通信を隠蔽することにしました。

Next.jsのApp RouterではRoute Handlerという機能を使用して通信をバックエンドに切り出すことができます。これを使用して外部APIをバックエンド側に切り出しました。

バックエンド側には全く詳しくないのでざっくりとした構成ではありますが以下のようになっています。
![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/bb227c1ced634d829355431320f269d1/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-17%2017.39.02.png)
*命名は適当です...*

ViewとModelは関数の呼び出しだけを行い、具体的なロジックはViewClientとControllerに寄せる形にしています。

依存性などにはあまり関心を払えていないんですがコード全体として割とスッキリしたと思います。特にView部分がシンプルになっているので満足です。
# 大変だったこと
## lighthouseをGitHubActionsで自動実行
今回初めてGitHubActionsを使ったんですが、試行錯誤が大変でした。というのも下の記事にもある通り、issue_commentのトリガーが動くのがデフォルトブランチにあるコードのみで作業ブランチのコードは実行されない様でした。

https://www.arfes.jp/article/8slf8dwtufpn

つまり動作確認の際に毎回mainマージをする必要がありました。動作確認のたびにPull Requestを出すのが煩雑でしたし何よりトリガーや動作が不明確で何度も何度も繰り返してエラーメッセージも十分に出ないのでかなり苦労しました。

## ツイート用に文字を分割すること

Twitter APIを使用してサイト上からXにポストを行なっているのですが、140字を超えた場合にツイートを分割してリプライとして繋げなければいけません。その際に必要な文字の分割で苦労しました。

というのもポストの文字数というのは一律１文字１カウントというわけではなく、アルファベットや記号であれば0.5カウント、日本語では１カウントなどと文字種別ごとにカウント数が決まっています。

それに加えてツイートの最も困難だったのはURLのカウント方式です。URLに関しては一律23カウントと決まっており実際の文字数に依りません。つまり実際は文字数制限内に収まっているにも関わらずURL全体を表示することができず、途中で次のポストに切り替わってしまうという問題が発生していました。

![](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/db4c0508d931497585b8aab5a2e1bd42/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-12-20%2013.22.05.png)

その改善のためにtwitter-textというX用の文字数カウントが可能なライブラリを新たに使用することに加え、URLを含めたとしても１ポストに最大まで文字を含められるように以下の様な実装を行いました。

:::message
なんで今までtwitter-textを使わなかったんだろうと後悔しています...
:::

```ts
let currentTweet = ''
if (countTweetLength(testTweet) <= MAX_LENGTH && !willSplitLink) {
  currentTweet += char
} else {
  if (isInsideLink && willSplitLink) {
    let link = links.find((link) => i >= link.start && i < link.end) as {
      start: number
      end: number
    }
    currentTweet += text.slice(i, link.end)
    i = link.end - 1
  }
  tweets.push(currentTweet)
  currentTweet = char
}
```

１文字ずつ判定していって、その文字が140カウントを超えてかつリンク内にある場合はリンクの最後の文字まで自動追加するという処理をしています。

これによって正確に文字数をカウントすることができる様になりましたし、リンクが途中で切れる問題も無くなりました。


# 課題点、今後修正したいこと
一旦開発は終了したのですが、問題がある部分が何点かあるので最後にそれをまとめてこの記事を終わりにしたいと思います。
### キャッシュの問題を解決する
新サイトでは全体的にreact-queryを使用して非同期処理に関する状態管理を行なっているのですが、一覧画面全体で画面遷移をした際にキャッシュを保持できないという課題が残っています。

例として一覧ページから詳細ページに遷移し、その後改めて一覧ページに戻るとなぜかキャッシュが保持されず、それに伴って再度APIリクエストが走りスクロール位置も上に戻されてしまいます。これではあまりにUXが悪く一覧性に欠けすぎているので、しっかりとキャッシュを保持できるように修正を行いたいです。

試してみたこととしてはreact-query-devtoolsを使用してキャッシュを監視したり、キャッシュキーを確認してみたりuseInfiniteQueryからuseQueryに変更してみて挙動を確認してみたいしたのですが、なぜか開発環境(`next dev`)では正常にキャッシュが保持されて、本番環境(`next build && next start`)の時には保持されなくなっているという状況です。

現状では原因がよく分からないのでApp Routerやreact-queryのバージョン周りの何か何だろうなとは考えているものの一旦保留にしています。

### 画像の文字サイズや行間隔を調整する

前述した通り、このサイトでは画像の生成はimgixで行なっています。
これはAPI経由で画像を生成できるというもので、以下の様な形式で生成しています。

```
https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/690434409f8a4b2f9e53fe9f8dd23102/answered-right.png
?w=1200&h=630&blend-mode=normal&blend-align=middle,center
&blend=https%3A%2F%2Fassets.imgix.net%2F%7Etext%3Fw%3D1000%26txt-color%3D333%26txt-align%3Dcenter%26txt-size%3D44%26txtfont%3DZenMaruGothic-Regular%26txt64%3D
```

概要としては１行目の部分がmicroCMSに格納されている背景画像のURLで２行目が画像合成時の設定が続きます。
重要なのは３行目で、背景画像に合成するオブジェクトの指定をしています。

ここでは文字サイズも設定できるのですが、現状は一律で44になっています。しかしこれでは合成する文字数や行数が多くなると画像をはみ出して見切れてしまうという問題があります。

画像以外で質問を確認する手段がないのでこれは早急に解消する必要があると感じています。

画像生成の際に文字数と行数をカウントして画像内に収まるように修正したいと考えていますが、あまりに長文になると最終的には視認できなくなるほど文字数を小さくするかはみ出すかの２択になってしまうので、検討の余地があると思います。

:::message
追記 2024/01/10
追加開発で行数によってフォントサイズを変更する機能を追加しました。
:::

# 最後に

初めてフルリプレイスというものを経験したのですが、過去の自分から成長した点を感じられて感慨深かったです。

ただ今回の変更がユーザー側の目に見える要素がほとんどないせいで全く伝わらないのが悲しい限りですね...

まぁ楽しかったからいっか！






【質問箱】お手伝いサークル公式サイトをNext.jsにリプレイスしました

## やりたいこと
Pull Requestを出した時にVercelが自動生成するプレビューサイトのパフォーマンスを、lighthouseで自動計測すること

## 技術スタック
- Vercel
- GitHubActions

## 元コードの実装の流れ
基本的には以下の記事を参考にしつつ、一部修正する部分を紹介します。

https://dev.to/oskarahl/automated-lighthouse-score-on-your-pr-with-vercel-and-github-actions-2ng2

まずは元のコードがどのように実装されているかをポイントごとに見ていきます。
コードを読めば理解できるという方は以下のリンクからご覧になってください。
読んでみて特に疑問点などなければこのパートはスキップしていただいて問題ありません。

完成したコードも下に掲載していますのでお急ぎの方はそちらをご覧ください。

https://github.com/OskarAhl/Lighthouse-github-action-comment/blob/main/.github/workflows/lighthouse-on-vercel-preview-url.yml

### ステップ１：トリガー
```yml
on:
  issue_comment:
    types: [edited]
```
まずこのワークフローが実行される時はPull Requestのコメントが編集された時です。
その理由は、Vercelのプレビュー生成のフローを見てみるとわかりやすいです。

1. コメントがつく
    Pull Requestを出した際にまず最初にVercelがコメントをつけます。
    ![スクリーンショット 2023-12-09 17.47.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025861/31134717-2362-3b37-9986-270d056d7848.png)
    
    ここからプレビューのビルドが開始されるというわけですね。
　
2. ビルドが完了する
    ビルドが終わり次第先ほどのコメントが編集されて以下のようになります。
    ![スクリーンショット 2023-12-09 17.48.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025861/c98ed09e-b87c-d597-f3cc-6bfc5048c67c.png)
    
    こうして完全なプレビューが見れるようになるというのが一連の流れです。
    
    このようにPreviewが生成されるのですが、私たちがパフォーマンスを確認したいのはビルドが完了して完全な状態になった後のPreviewなので、Pull Requestを出し始めた瞬間に計測しにいっても意味がないわけです。
    
    そのためビルドが完了し、Previewが完全な状態となった瞬間である、「Pull Requestのコメントが編集された時」にトリガーされる設定となっています。
    　
    ですが逆にコメントが編集された時ならいつでもトリガーされるのでその点には注意が必要です(コメントした人が誰かで条件分岐するなどの対策はありますが)

:::message 
このトリガーはデフォルトブランチにコードが存在している時にしかトリガーされません。
作業ブランチから動作確認することができないので、毎回デフォルトブランチにマージして動作確認するようにしてください。
:::

### ステップ２：プレビューURLの取得
```yml
 - name: Capture Vercel preview URL
    id: vercel_preview_url
    uses: aaron-binary/vercel-preview-url-action@v0.0.3
    with:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
次に重要となるのはプレビューURLの取得です。

方法は至ってシンプルで、先ほど登場したVercelの自動コメントを読み取ってリンクを抽出するというものです。

これに関しては１行書くだけで中身を意識する必要はありません。

### ステップ３：lighthouseによるパフォーマンス計測
```yml
  - name: Audit preview URL with Lighthouse
    id: lighthouse_audit
    uses: treosh/lighthouse-ci-action@v3
    with:
      urls: |
        ${{ steps.vercel_preview_url.outputs.vercel_preview_url }}
      uploadArtifacts: true
      temporaryPublicStorage: true
```
プレビューURLが取得できたら、そのURLを使っていよいよパフォーマンスの計測を行なっていきます。

これもライブラリにURLを渡すだけなので特筆することはありません。

残りのステップは文字の整形などなので割愛します。

## 修正箇所
以上が元コードの説明なのですが、現在(少なくとも僕の環境では)このコードは動作しません。
ここからは、そんな元コードを何点か修正して動作するようにしていきます。
### 使用するライブラリの修正
これは動作するために必須かと言われると微妙なんですが、ライブラリの修正を行います。
具体的には以下の通りです。

:::message 
vercel-preview-url-actionに関してはライブラリそのものが変更されていることに注意してください。スター数やメンテナンスの頻度的にこちらが良いと判断しました。
:::

:::message
バージョンは執筆当時のものですので適宜バージョンを変更してください
:::

| 修正前                                                | 修正後                                              |
|------------------------------------------------------|----------------------------------------------------|
| actions/checkout@v2                                  | actions/checkout@v3                                |
| **aaron-binary**/vercel-preview-url-action@v0.0.3    | **aaimio**/vercel-preview-url-action@v2.2.0        |
| marocchino/sticky-pull-request-comment@v1            | marocchino/sticky-pull-request-comment@v2          |
| treosh/lighthouse-ci-action@v3                       | treosh/lighthouse-ci-action@v10                    |


### `secrets.GITHUB_TOKEN`の修正
コードの中で`secrets.GITHUB_TOKEN`という、GitHub APIにアクセスする際に必要なトークンを使用する箇所が何箇所かあるんですが、僕の場合これを変える必要がありました。

というのも、どうやら`secrets.GITHUB_TOKEN`では書き込み権限が付与されていないことがあるそうです。

つまり、URLの取得などのREADに関しては`secrets.GITHUB_TOKEN`で行えるが、コメントの追加などは行うことができないということです。

ということで、コメントの追加を行なっている箇所とスコアの整形を行なっている箇所の修正を行います。
まずは書き込み権限を持つトークンを発行しましょう。

1. [GitHub](https://github.com)にアクセスし、Settings > Developer Settingsと進む
1. サイドバーに表示されているPersonal access tokensを選択
1. Tokens(classic)を選択し、Generate new token > Generate new token(classic)を押す
1. Noteの欄に見分けが付く文言を入力(リポジトリ名とかが良いと思います)し、workflowにチェックを入れ、Generate tokenを押す
1. リダイレクト後にトークンが表示されるのでコピー

ここまでできたらコピーしたトークンをリポジトリで使えるようにするために登録しましょう。

1. リポジトリのSettingsからSecurity > Secrets and variables > Actionsと進む
1. New repository secretを押す
1. シークレット名(今回の場合は`SECRET_TOKEN`)と先ほどコピーしたトークンを入力しAdd secret

これで準備は完了したので、`secrets.GITHUB_TOKEN`を`secrets.SECRET_TOKEN`に修正すれば完了です！


### Vercelのリダイレクトによるスコアの低下を解消
バージョンを上げてトークンを登録すれば一旦動くようにはなると思うんですが、やけにスコアが低く表示される気がしました。
そこでlighthouseの結果をみるとこんな表示が,,,

![スクリーンショット 2023-12-09 18.36.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025861/04ca1c35-dcec-5ead-4776-cf358ca9b9d0.png)

どうやらプレビューURLは別のURLへとリダイレクトされて表示されているようです。

実際に確認してみると元URLが
> https:// vercel.live/open-feedback/[リポジトリ名]-git-[ブランチ名]-[ユーザー名].vercel.app?via=pr-comment-visit-preview-link&passThrough=1

なのに対し、プレビューURLは
> https://[リポジトリ名]-git-[ブランチ名]-[ユーザー名].vercel.app/

と表示されていました。

ということでlighthouseで計測するURLをリダイレクト後のものに修正します。

方法は至って簡単で、「元URLにアクセスして、リダイレクトで最終的にたどり着いたURLを取得する」と言った方法です。

下のコードを「Capture Vercel preview URL」と、「Audit preview URL with Lighthouse」の間のステップに追加してください。

```yml
  - name: Capture Redirected URL
    id: get_redirected_url
    run: |
      PREVIEW_URL="${{ steps.capture_preview_url.outputs.vercel_preview_url }}"
      REDIRECTED_URL=$(curl -Ls -o /dev/null -w %{url_effective} "$PREVIEW_URL")
      echo "REDIRECTED_URL=$REDIRECTED_URL" >> "$GITHUB_OUTPUT"
```

加えて、リダイレクト後のURLで計測するように「Audit preview URL with Lighthouse」のコードを以下の様に修正してください
```yml
  - name: Audit preview URL with Lighthouse
    id: lighthouse_audit
    uses: treosh/lighthouse-ci-action@v10
    # 環境変数からリダイレクト後のURLを取得する
    env:
      REDIRECTED_URL: ${{ steps.get_redirected_url.outputs.REDIRECTED_URL }}
    with:
      urls: |
        # リダイレクト後のURLを使う
        $REDIRECTED_URL
      uploadArtifacts: true
      temporaryPublicStorage: true
```

以上のことをすればリダイレクト先のURLで計測してくれるようになっているはずです。

## 実装のステップ
かなり断片的に紹介してしまったので改めて全体的な実装の流れです。
1. .github/workflowsディレクトリにymlファイルを追加(今回であればcheck-lighthouse-score.ymlなど)
1. そのymlファイルに今までのコードを格納
1. デフォルトブランチにそのコードをマージ
1. 適当にPull Requestを出してみて、計測がなされることを確認

## 課題点
最後に、現状できていない課題点です。

- SSGに弱い
    - 現状プレビューのURLが毎回異なるので、キャッシュを用いるサイトだとどうしてもパフォーマンスが低く出てしまいます。
    - できればURLを固定できたら良いなと考えています
- モバイルでしか計測できない
    - lighthouseのデフォルト設定がモバイルなのか、現状だとモバイルの設定で計測しています
    - できれば両方もしくは切り替えができるようにして計測したいと考えています。
- 誰のコメントでもトリガーされてしまう
    - 本来ユーザーで条件分岐するのがベストなんですが、現状だと全てのコメントに対してトリガーされているのでそれを修正したいです。

## 完成コード
先ほどあげた修正点以外にも日本語化をしたり多少のマイナーチェンジをしています。
このコードをコピペしてもらえれば一旦動くと思われます。

```yml
name: PRのLighthouseスコアチェック

on:
  issue_comment:
    types: [edited]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    name: Lighthouse分析と結果コメント投稿
    steps:
      - name: チェックアウト
        uses: actions/checkout@v3

      - name: プレビューURLを取得
        id: capture_preview_url
        uses: aaimio/vercel-preview-url-action@v2.2.0
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: リダイレクト後のURLを取得
        id: get_redirected_url
        run: |
          PREVIEW_URL="${{ steps.capture_preview_url.outputs.vercel_preview_url }}"
          REDIRECTED_URL=$(curl -Ls -o /dev/null -w %{url_effective} "$PREVIEW_URL")
          echo "REDIRECTED_URL=$REDIRECTED_URL" >> "$GITHUB_OUTPUT"

      - name: コメントを追加
        id: loading_comment_to_pr
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          GITHUB_TOKEN: ${{ secrets.SECRET_TOKEN }}
          number: ${{ github.event.issue.number }}
          header: lighthouse
          message: |
            Lighthouseで分析中...

      - name: Lighthouseでページを分析
        id: lighthouse_audit
        uses: treosh/lighthouse-ci-action@v10
        env:
          REDIRECTED_URL: ${{ steps.get_redirected_url.outputs.REDIRECTED_URL }}
        with:
          urls: |
            $REDIRECTED_URL
          uploadArtifacts: true
          temporaryPublicStorage: true

      - name: スコアを整形する
        id: format_lighthouse_score
        uses: actions/github-script@v3
        with:
          github-token: ${{secrets.SECRET_TOKEN}}
          script: |
            const result = ${{ steps.lighthouse_audit.outputs.manifest }}[0].summary
            const links = ${{ steps.lighthouse_audit.outputs.links }}
            const formatResult = (res) => Math.round((res * 100))
            Object.keys(result).forEach(key => result[key] = formatResult(result[key]))
            const score = res => res >= 90 ? '🟢' : res >= 50 ? '🟠' : '🔴'
            const comment = [
                `[Lighthouse分析結果](${Object.values(links)[0]}):`,
                '| 項目 | スコア |',
                '| --- | --- |',
                `| ${score(result.performance)} パフォーマンス | ${result.performance} |`,
                `| ${score(result.accessibility)} アクセシビリティ | ${result.accessibility} |`,
                `| ${score(result['best-practices'])} ベストプラクティス | ${result['best-practices']} |`,
                `| ${score(result.seo)} SEO | ${result.seo} |`,
                `| ${score(result.pwa)} PWA | ${result.pwa} |`,
                ' ',
                `*分析したURL: [${Object.keys(links)[0]}](${Object.keys(links)[0]})*`
            ].join('\n')
            core.setOutput("comment", comment);

      - name: Lighthouse結果をコメント
        id: comment_to_pr
        uses: marocchino/sticky-pull-request-comment@v2
        with:
          GITHUB_TOKEN: ${{ secrets.SECRET_TOKEN }}
          number: ${{ github.event.issue.number }}
          header: lighthouse
          message: |
            ${{ steps.format_lighthouse_score.outputs.comment }}

```


VercelとGitHub Actionsでフロントエンドのパフォーマンスを自動計測したい

1週間ほど前から最近流行りのCursorを使い始めているんですが、VSCodeで使っていたショートカットが使えなくなっていたのでメモとして残しておきます。

# `⌘K`
VSCodeでは様々なショートカットの導入に使う`⌘K`ですが、Cursorでは基本機能であるAIによる編集機能を使用する際のプロンプトバーを呼び出すコマンドに割り当てられています。

僕は`⌘K+U`でタブを消したり`⌘K+⌘⌥S`で部分的にステージングに上げたりしていたので結構困りました。

このコマンドは`workbench.action.keychord.leader`で設定されていて、Cursorのデフォルトは`⌘R`になっています。
ですのでこれを従来のVSCodeに戻したければ

1. Keyboard Shortcutsを開いて`Cursor: Open Inline Edit and Generate Prompt Bar`を適当なコマンドに変更する(僕は一旦`⌘G`にしました)
2. `workbench.action.keychord.leader`を`⌘R`から`⌘K`にする

という手順を踏めば大丈夫かと思います。一旦競合するコマンドも現状では見当たらないので問題ない気がします。

# おまけ
**気のせいかもしれないのですが**、いくつかのショートカット(恐らく`⌘⇧F`とか`⌘⇧G`とか)がvscodeと違って競合するコマンドがあるような気がして、サイドバー(正確にはワークベンチ？)を開く時に困ったのでもし試してみて期待通りに動かない様であればコマンド検索で競合しそうなものを排除しておくとよさそうです。

CursorでVSCodeの⌘Kが使えなくなった

【翻訳】Webの未来(と過去)はSSRだ。

１ヶ月ほど前から唐突にVSCodeの自動フォーマット(editor.formatOnSave)の機能が効かずに困っていたんですが、解決したので備忘録として載せておきます。

# 忙しい人のための結論
以下のどちらかを試してみてください(どちらかで大丈夫です)
1. settings.jsonのeditor.prettierPathを削除する
2. VSCodeの拡張機能であるPrettierのバージョンを9.14.0以下に落とす

どうやら9.15.0の変更から今回のバグが発生していた様です。
![prettier@9.14.0の画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/0b67cf5d9b874e23b8dab0288932d048/prettier-9.14.0.png)
# 環境
マシン： MacBook Air (M1, 2020)
OS： MacOS Monterey 12.6.3
VSCode：1.80.1

# 状況
- 6月の途中ごろからいきなりフォーマットが効かなくなった
- `npm run format`は使える
- 画面の右下のPrettierがずっと赤く表示されている
![prettierのエラー画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/2f737134ad9e45b79b379af0b702dbde/prettier-error.png)
- エラー出力としては以下の様に出ている
```
["ERROR" - 16:04:37] Failed to load module. If you have prettier or plugins referenced in package.json, ensure you have run `npm install`
["ERROR" - 16:04:37] Cannot find Prettier package.json
```

# 試してみたこと
1. 以下の記事を参考にprettierをグローバルインストールし直す

https://qiita.com/hppRC/items/6670d91b1209f0c576ea

2. 拡張機能の再インストール
3. node_modulesを消して`npm install`
4. VSCodeの更新、再起動
# 解決方法
繰り返しになりますがVSCodeの拡張機能であるPrettierを9.14.0以下に落とすと直りました。9.15.0のリリース時期と僕が自動フォーマットが使えなくなった時期が一致しているので納得です。

やり方としては
1. 拡張機能のPrettierのページで、「アンインストール」の横の矢印をクリックして、「別のバージョンをインストール」
![Prettierの修正1の画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/c83a9fcf624c4240b59684a68b36acee/prettier-fix-step1.png)
2. 選択肢の中から9.14.0以下の好きなバージョンを選ぶ
![Prettierの修正２の画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/1b9a6dc03081431486af2c97f85f818a/prettier-fix-step2.png)
3. 再読み込みして修正されていることを確認

で完了です。

正直ただバージョンを戻しているだけなので付け焼き刃感が否めないんですが、調べた限りでも根本的な解決方法などはありませんでした。
以下が調べた記事一覧です。

https://github.com/prettier/prettier-vscode/issues/3036
https://github.com/prettier/prettier-vscode/issues/3037
↓これを見ると9.19.0がリリースされる前にprettierPathに関するコミットがrevertされているので直感的には9.19.0で直っている様な気がするんですが、なぜかダメでしたね...
https://github.com/prettier/prettier-vscode/pull/3042
https://github.com/prettier/prettier-vscode/issues/3071

# 分からなかったこと
先程のこちらのPRに関してなんですが、prettierPathを修正しているだけなんですよね。
https://github.com/prettier/prettier-vscode/pull/3042

なんですが、9.14.0以下の環境でprettierPathを適当に設定しても動きます。
なんでなんでしょうか...

## 追記
どうやらprettierPathを削除しても解決する様です。
prettierPathに関する参照でエラーが発生していた様なので、それを削除してしまえばエラーも発生しないという論理です。
これなら最新バージョンでも問題なく動作しますね！

周りに同様のエラーを出ている人がいなかったのはそもそもprettierPathが設定されていなかったからの様ですね。
僕はprettierのonSaveが機能していなかった時にprettierPathを設定したのでそれが原因でこうなっていたみたいです。

# 終わりに
結論はめちゃくちゃシンプルだったんですが１ヶ月以上も苦しんでしまいました。
今まで拡張機能のエラーに遭遇したことがなかったので「PATHが通っていないんじゃないか」とか「nodeの管理をvoltaにしたことで不具合が発生したんじゃないか」とかを考えてしまって関係ないところを模索し続けてしまいました...
あと拡張機能のエラーはググるよりもリポジトリのissueやPRで検索した方が早いかもしれないですね。

やっとストレスフリーに開発ができます。
嬉しい！

VSCodeのPrettierで自動フォーマットがいきなり効かなくなったんだけど...

こんにちは。
インターンの参加エントリ以外も技術的な記事をちゃんと書きたいと思いながらも全く実現できていないやたです。

今回はクックパッドのTech Workshop Courseというインターンに参加してきたのでどんなことを学んできたのかなどを書いていけたらと思います。

## 概要

7/1,2,8,9の計４日間でクックパッドの社員の方々から講義を受けることができるというインターンです。

学べる内容はiOSアプリ開発、サーバーサイド開発、サービス開発の３つでそれぞれかなり濃い内容でした。

今回はクックパッドがあるWeWorkオーシャンゲートみなとみらいで完全オフライン開催でした。

レイオフが選考に影響を与えたこともあり、11人という少人数での開催になりました。

## 参加の経緯

僕は元々このインターンではなく通年で行なっているTech OJT Courseの方から選考に参加しました。
https://internship.cookpad.jp/jobtraining
こちらの方は合格を頂けたのですが、配属予定で僕の経験が浅いサーバーサイドにも触れる可能性があるということもあり、その知識を補うという目的で招待していただけました。

タイミング的にも余裕があったり、講義形式のインターンに参加したことがなかったことが参加の決め手です。

## 選考

ざっくり選考の内容です。

::: message
これはあくまで僕が選考を受けたTech OJT Courseの選考内容であることにご注意ください。
:::

### プログラミング課題
恐らく最初はESを提出した気がするんですが、その次の段階としてプログラミング課題が課せられました。

問題の詳細などは出せないんですが、内容としてはアルゴリズムとSQLでした。それに加え自分の開発経験について書く欄もあり合わせて120分とかなり時間がタイトな印象でした。

### 面接
面接は１回で、僕の場合はエンジニアの方が２名でした。
聞かれた内容は一般的な質問とプログラミング課題についての掘り下げが聞かれました。もしこれから選考を受ける方がいたら、プログラミング課題で自分が書いたコードを説明できるようにしてから面接に臨むことをお勧めします。

## 内容
### １日目
最初はSwiftUIを使用してのiOSアプリ開発の講義が行われました。
僕はSwiftを人生で一度も書いたことが無かったので少し不安だったんですが、言語の基礎から講義してもらえたので全くの無知でも問題ありませんでした。
::: message 
実際は超高速で講義が進む＆Swift以外のことは全て分かっているのが前提のような内容のため、僕は結構置いていかれました...
:::

それだけ高速でエッセンスが詰まった講義だったため、たった１日とは思えない密度でSwiftの知識を得ることができました。完璧には全ての課題を完了させることができなかったんですが、それでも満足できる内容だったと思います。

### ２日目

２日目は一転してRuby on Railsを使ったサーバーサイド開発講義が行われました。

Webフロントをメインでやっている人間からするとモバイルよりはこっちの方がまだ理解している部分が大きいかなと思ったんですが、正直言うとあまり変わらない寧ろ苦戦した印象でした。
今回に関してはRubyの基礎的な部分についての講義が15分くらいで終わってしまってあんまりよく分かっていないまま開発の講義に移ってしまっているのが原因だったと思います。

>入門から始めるので全く初心者でも大丈夫です。

と事前に伝えられていたので油断してチュートリアルをほとんどやらずに参加したんですが、当日の基礎的な解説の少なさに鑑みるとある程度言語やフレームワークに触れた状態で臨めたらもっとパフォーマンスを出せたんじゃないかな〜とぼんやりと感じました。

### ３日目

１日目、２日目は開発そのものに関する講義だったんですが、ここからの２日間はサービス開発に関する講義で課題の発見やその解決をする上でのソリューションを学びました。

今回は３人１組でチームを組んで「一人暮らしの料理課題を解決するアプリや機能を開発する」というテーマのもとでサービスのプロトタイプ作成までを行いました。

インタビュイー(１人暮らしの社員さん)に１時間のインタビューをしてその中から解決すべき課題を選定するというところまでを３日目に行なったんですが、インタビューで十分に課題を深ぼることができずに明確な深い課題を設定することができずかなり苦労しました。

初対面の人に対して「なぜ？」を繰り返していくのは普段行わないタイプのコミュニケーションでとても難しかったです。

この日は正直あまり結果を出せずに終わってしまったため、帰りの電車や寝る前にアイデアをめちゃくちゃ詰めて次の日に臨みました。

### ４日目

前日の反省を活かして課題設定からアイデアを見直して持ち寄った結果、比べ物にならないほどのスピードで進んで行きました。

インタビュイーの課題の本質を分析し、その解決策を比較検討していくことで自然とクリティカルなアイデアを出すことができたと思います。

インタビュイーにFigmaで作ったプロトタイプを検証してもらうユーザーテストでも、かなり満足のいくフィードバックを得ることができました。

当初の絶望とは打って変わって最終発表まで到達できて個人的にはとても満足のいく結果になりました。

## よかった点

### 新しい言語、フレームワークを触ることができたこと
自分では触れることが無かったものを１日で簡易的にでも触れる機会はとても貴重なものだったと思います。

### 少人数で開催されたこと
意図したものではなく最終的にそうなってしまっただけだとは思うんですが、11人という少人数での開催だったおかげで全員と仲良くなることが出来ました。インターン後にご飯に行ったり出来て深い交流することが出来た点も個人的に良かったです。
意図しない贅沢をさせてもらえてラッキーでした...!

### ノベルティが豪華
インターンに参加する楽しみの１つにノベルティがあると思います。今まであまりインターンに参加してこなかったので「何かもらえるといいな〜」と思いつつ参加したんですが、思ったよりも色々頂けて嬉しかったです。
#### ノベルティ一覧
![クックパッドノベルティの画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/7a10af6effd44e789d33a4e0c511390c/cookpad-novelty2.jpg)
![クックパッドノベルティの画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/edc8bfd3aecc410eb3ff3c0851887269/cookpad-novelty1.jpg)
- Tシャツ：やっぱりノベルティと言えばこれですよね
- トートバッグ：丁度MacBookが入るサイズらしい
- ネックストラップ：入館証つけられるやつ。使う機会があるかは謎。
- うちわ：LGTMうちわ。シールを貼れて楽しい
![クックパッドうちわの画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/e19c28d22c314141a823fcb2e5a309f6/cookpad-fan.JPG)


### ご飯に対する気合い
やはり食事をテーマとする企業なだけあって食に対するこだわりはとても感じました。お菓子や果物、飲み物の用意が大量にありましたし、いつでも好きな時に飲み食いできる最高の環境で講義を受けられて本当に幸せでした...!

ランチも素晴らしく、近くの美味しいお店の弁当をデリバリーして頂いたり外に食べに連れて行ってくださったりと毎回お昼の時間が楽しみでした。

一番美味しかったのは３日目に連れて行って頂いたパスタ屋さんで、しめじ入りパスタが絶品でした。

#### しらすパスタ

![しらすパスタの画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/f9eeb7887b72406f8a303ef1ed4d5111/cookpad-lunch.JPG)

#### ３日目のスタバデリバリー
![３日目のスタバデリバリー画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/9a459c7542ea45239cce4878944adc06/cookpad-starbacks.JPG)

#### ４日目のお昼ご飯
![４日目のお昼ご飯画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/9bc7fc86812e4196b64cd40d354c0c85/cookpad-lunch-4.jpg)

#### ４日目の懇親会
![４日目の懇親会画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/f930c825e88248f28f89f3b55f313781/cookpad-farewell.jpg)

 ### 最優秀賞を取ることができたこと
チームとして課題の分析とその解決策を最も深く考えることができた点を評価されて、最優秀賞をいただくことができたのはとても良かったと思います。正直選ばれるとは全く思っていなかったので本当に驚きました。

![最優秀賞画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/1717d728aa2044f38bc6f8210e634ab1/cookpad-mvp.PNG)

### オフィスでスマブラができたこと
僕の最大の趣味は大乱闘スマッシュブラザーズというゲームなんですが、インターンの集合時間前やお昼休みの時間で空いてるモニターをお借りしてみんなでスマブラできたのがとても良かったです。
心が広すぎて感涙でした。

## イマイチだった点
### 初日の空調バグ
普段開かれていない土日に開催された影響か、初日は空調がうまく効かずノベルティのうちわが手放せない１日でした。
汗だくになりました。
### 屋上行ってみたかった
本来であれば屋上でお昼を食べたりもできるらしいんですが、土日は開放されていないということで入ることが出来ませんでした。
悔しい。

## 終わりに
社内がドタバタしている中インターンとしてとても充実した内容の講義をしていただけてとても貴重な経験をさせていただけたと思います。
クックパッドの皆さん本当にありがとうございました！

クックパッドのTech Workshop Courseに参加してきました 

今回ゆめみのフロントエンドの通期インターンに参加させていただいたので、体験記を書いていこうと思います。

::: message
この記事は僕の主観・記憶の中での記事であり、ゆめみの客観的な情報を必ずしも提供するものではないことにご注意ください
:::

## はじめに

メンターのお２人を始めとして、今回受け入れて下さったフロントエンドチームの皆さんに大変感謝申し上げます...!

本当に貴重な経験をさせていただきました！

## 選考の流れ
まずどのようなステップで選考を行ったかを紹介していきます。
### カジュアル面談

#### カジュアル面談をするきっかけ
僕は最初、仲介サービスに紹介してもらう形でゆめみという存在を知りました。
正直IT業界に明るくない僕はゆめみのことも大変失礼ながら存じ上げていなかったのですが、
>折角紹介してもらったし一旦面談だけでもしてみるかぁ

という気持ちで本当にカジュアルにカジュアル面談に臨みました。

#### 当日

２月の終わりに面談させていただきました。
曖昧な記憶ですが、新卒１年目の方と中途５年目くらいの方だった気がします。
選考に関係なく聞きたいことをバンバン聞いていったのですが、お二人とも丁寧に答えて下さってとても良い印象でした。

その中でも特に良いと感じたところが何点かあったので紹介します。
- 給与を自分で決められるところ
- 自分で手を挙げてプロジェクトに参加するため部署ガチャが存在しないところ
-  勉強し放題で教材などの費用を負担していただけること

全体的にとても良い印象でしたし、是非インターンにも挑戦してみたいということで応募することになりました。

### 技術課題
選考のステップは２つに分かれており、１つ目が技術課題でした。

#### 概要

本当に意味が分からないのですが、この技術課題は一般公開されています(?)
https://notion.yumemi.co.jp/%E6%8E%A1%E7%94%A8%E9%96%A2%E9%80%A3%E8%B3%87%E6%96%99%E5%85%AC%E9%96%8B/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%83%89%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E8%A9%A6%E9%A8%93

気になる方は是非見てみて下さい。面白いです。
概要としてはAPIを使って人口統計サイトを制作するというもの。
期限は１週間でしたが、開始のタイミングは柔軟に対応してもらえました。僕の場合、申し込んだ３月が個人開発で忙しかったため４月に開始という形に設定してもらいました。
::: message
実は３月の半ばに期限が２週間に伸びたんですが、僕は１週間のまま継続させられました
:::

#### 実装の流れ
VueかReactを使えという指示だったんですが、実際にインターンではReactを使うとのことでReactを使うことにしました。

正直今までReactをほとんど使ったことがなかったので、技術力という面では絶対に使い慣れたVueを選ぶべきだったんですが、結果的に合格したので良かったです。

実際に始めてみると思ったより時間がなくて焦りました。
「４月なら時間に余裕あるやろ！」と３月の僕は高を括っていたのですが、よく考えたらサークルの新歓や新学期でかなり忙しいことを忘れていました...

そんなこんなで実質３日間くらいで死ぬほど焦りながら、初めて触るReactで技術課題を完成させることができませんでした。はい。
普通に要件漏れしました。
やっぱ慣れないことはするもんじゃないですね。

具体的にはテストを書いていなかったりします。
::: message
本来であれば要件を満たすことは必須事項だと思います。決して真似しないでください。
:::

提出最終日の日が変わるギリギリ(というのは嘘で早朝まで作業してました)まで作業をしたんですが間に合わず、「あー終わった。絶対に無理や。」と絶望しながら提出したことを覚えています。

カジュアル面談の際に、
> インターンのボーダーは厳しく設定している。本選考の上位10%くらい(うろ覚えです)

みたいなお話を聞いたせいで、絶望感はより強まりました。

#### その後
エージェントさんを通して何故か面接の案内が来ました。きっと奇跡が起こったのでしょう。それに加えてびっくりするくらい丁寧なレビューを頂きました。

具体的な内容を載せるのはあまり宜しくない気がしますし、何より僕のカスコードが露呈するのが耐えられないので詳細は省かせて頂きますが、
```md
## Goodチェック
- 〇〇ができている
- ▲▲になっている
以下10項目

## Nextチェック
- □□ができていない
- ✖︎✖︎になっていない
以下10項目

## 総合評価
[とっても丁寧なコメントが続く]

```
といった感じでインターンの課題でここまで丁寧なレビューがもらえるのかと心底感激しました。



### 面接

奇跡的に面接に進むことができたので、技術課題のカスコードを読み返しつつ当日に臨みました。

#### 内容

エンジニアの方２人との面接で、この一回で合否が決まるとのことでした。

どうやら技術面は技術課題の方で十分だったらしく、基本的に人間性重視の面接だった気がします。

過去の開発経験についても深掘りはされましたが、それよりも圧倒的にこれまでの人生経験や考え方などについて詳しく質問されました。

もしこれからゆめみの面接に挑戦する方がいたら自分の過去や自分の内面をひたすら掘り下げておくとかなり対策になると思います。

個人的に印象に残ったのは、「自分はどんな人間か」というテーマの質問でした。
インターンの面接をいくつか受ける中で類似の質問はされるんですが、「じゃあこの場合はどう？」「それって本質的な理由はなんだと思う？」などの深すぎる質問で今まで考えたことが無かった部分を刺激されたのが新鮮でした。

その後の逆質問の時間で
> ゆめみのインターンに参加するためには、僕の技術力はあと何ステップくらい足りないと思いますか？

と率直に質問させていただいたところ、
> うーん... 直感だけど２ステップくらいかなぁ

と言われて絶望したことをおまけでお伝えしておきます。(その後にちゃんと「技術力だけで取るわけでは無い」とのフォローは頂きました。)

#### 結果
体験記なので分かりきってるとは思うんですが、合格をいただくことができました。

同時にまたもやスーパー丁寧なレビューもあり、面接官お二人から良かった点と悪かった点を挙げて下さいました。

それだけに留まらず、面接の時に話していたことに関するおすすめの本まで紹介して下さったことが印象的です。

↓これです。今ちょうど読んでいるんですがめちゃくちゃ面白いです。
https://www.amazon.co.jp/%E3%80%8C%E3%82%84%E3%81%95%E3%81%97%E3%81%95%E3%80%8D%E3%81%A8%E3%81%84%E3%81%86%E6%8A%80%E8%A1%93%E2%80%95%E2%80%95%E8%B3%A2%E3%81%84%E5%88%A9%E5%B7%B1%E4%B8%BB%E7%BE%A9%E8%80%85%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE7%E8%AC%9B-%E3%82%B9%E3%83%86%E3%83%95%E3%82%A1%E3%83%B3%E3%83%BB%E3%82%A2%E3%82%A4%E3%83%B3%E3%83%9B%E3%83%AB%E3%83%B3-ebook/dp/B01BDFHKTE/ref=sr_1_2?adgrpid=53683090739&hvadid=611408448188&hvdev=c&hvlocphy=1009339&hvnetw=g&hvqmt=e&hvrand=15995901889106968913&hvtargid=kwd-334459546553&hydadcr=27485_14587142&jp-ad-ap=0&keywords=%E3%82%84%E3%81%95%E3%81%97%E3%81%95+%E3%81%A8%E3%81%84%E3%81%86%E6%8A%80%E8%A1%93&qid=1686978502&sr=8-2

技術力の点で本当に受かる訳ないと思っていたんですが面接の手応えはかなりあったので、そこで巻き返せたのかなと僕の中で考えています。

## インターン内容

僕が応募したのは３日間のインターンでした。
授業の都合もあり6/12, 6/15, 6/16という飛び飛びだったにも関わらず了承して頂きその３日間で参加させて頂きます。

### 課題
インターンの内容としては、用意されているリポジトリをforkして開発を進めていくという流れになります。

用意と言っても事前にほとんど出来上がっているという訳ではなく、最低限の設定やコンポーネントがある状態から自分でどこを作っていくかを決めていく形でした。
Figmaにデザインカンプはあるので、それを見ながら３日間の過ごし方をメンターと相談しつつ決めていきます。

課題のテーマは「商品を売買するECサイト」だったので、今回の僕の目標は「商品詳細画面を実装すること」に決めました。
「コンポーネントの切り分けや実装全体の流れを学びたい」という思いがあったので、できるだけ要素が多い画面を選びました。

### 進め方
まずページに必要なコンポーネントを作成してからそれらを組み込みつつページ全体を完成させていくことにしたので、１日目・２日目はコンポーネント作成に使い、３日目にページ全体の統合を行いました。

１日目は自分だけでコードを書いてPRをレビューしてもらい修正することを繰り返していましたが、２日目と３日目はほとんどの時間ペアプロでコードを書いていました。

今までペアプロなるものをしたことが無かったので、かなり新鮮な体験だったなと思っています。

メンターの方が僕にめちゃくちゃ時間を使ってくれたおかげでかなり濃い時間になりました。
### その他イベント

インターンではゆめみの方々の交流する機会も多く設けて頂きました。事前のアンケートで「できるだけ交流したい」と書いておいたのが功を奏したのか、昼会(チームごとの定例会のようなもの)とランチ会(ただみんなでお昼を食べる会)に参加させて頂きました。

複数のチームにお邪魔して普段の様子を見たり、エンジニアの皆さんに質問しまくり皆さんが普段どう思われているのかなど聞いてよりゆめみについて深く知ることができました。

ゆめみならではの体験ができて良い機会でした。

## 良かったこと
ここからはゆめみのインターンで良かったことを紹介します。
頑張って書いて採用担当に良い印象を与えようと思います。(嘘です。半分。)
### レビューが圧倒的に丁寧
技術課題や面接の時からずーっと感じていたことではあるんですが、本当にレビューを丁寧にして下さいます。
それはインターン中も変わらず、PRに対するレビューも本当に色々書いて下さいました。

これがPRの一例なんですが、マジで丁寧です。ありがたすぎます。
https://github.com/arfes0e2b3c/yumeshop-frontend/pull/1

### ペアプロを通してリアルタイムで学べる
２日目と３日目はほとんどペアプロでコードを書いていたんですが、PRにレビューをもらうのとはまた違った良さがありました。

それが「リアルタイム性」です。
自分がコードを書いている様を直で見てもらえるので気になったところがあった瞬間に言ってもらえますし、気になることがあればすぐ聞くことができる。
「現状自分の中ではこれが正しいと思うんですけど、いつもどうされてますか？」みたいに文面だけだと伝わりにくいニュアンスの部分も擦り合わせながらコーディングできるので本当に貴重な経験だったと思います。

案件でかなり忙しいはずなのにこんなに時間を使ってもらえるのは、本当にありがたかったなとしみじみ感じます。

仲間内でも是非ペアプロしてみたいです。教えてもらう側だけではなく、教える側にも良い気がしています。

### 内部情報見放題

インターン参加中はゆめみのslackとnotionに招待されます。
元からゆめみは情報の透明性を掲げているのでかなりの情報が一般公開されているんですが、さらに色々な情報見ることができます。もちろん限度はありますが、「インターン生がこれ見ていいの...?」っていう情報がそこらに散らばっていました。

具体的には以下の様なものが見れました
- 取引先一覧(非公開のものも含む)
- みなさんの給与情報(ゆめみは自分の給料を自分で設定するので、その履歴を見ることができます。)
- 過去のインターン生一覧
- 採用の内部情報

僕はNDAを結んでいるのでこれらの内１つでも外部に漏らすと爆散してしまうんですが、自分の将来のキャリアを考える上でとても参考になる情報ばかりで有意義な情報ばかりでした。

中に潜り込まないと見られない情報を見るのもインターンの醍醐味ですね。
見れすぎてる気もしますが。

## いまいちだったこと
ここからはインターンに参加していまいちだなと感じたことを書いていきます。
怒られないようにしたいです。
### US配列があまりにも使いにくい
先ほども書いた通り、今回のインターンではMacbook proを貸与してもらえました。
事前確認で「US配列とJIS配列ではどちらがよろしいですか？」とメールをいただいたので、普段からJIS配列を使用している僕は迷わず「US配列でお願いします」と返信してしまいました。完全にミスでした。
「なんとなくキーボードがすっきりしていてカッコいいな」とUS配列を選んだんですが以下の点で僕には全くと言って良いほど向いていませんでした。
 1. 日本語入力と英字入力の変換が単一ボタンなせいで今どちらの状態かを気にする必要がある
 2. `option + space`で入力を変更するが、`space`を先に押すと空白が入力されてしまう
 3. アルファベット以外の配列が全然違って訳が分からない
 4. Enterが小さくてShiftを永遠に押し続けてしまう

次からは調子に乗らずJIS配列のものを貸与してもらうことにしようと固く誓いました。


### 昼会とランチ会を混同する
インターンの中で昼会に２回、ランチ会に１回参加させていただいたんですが、毎回どっちがどっちか分からなくなって混乱しました。
社員の皆さんは間違えないんでしょうか。

あと関係ないんですが、ランチ会に参加すると社員の皆さんはお昼代が支給されるようで、400円の昼ごはんを食べている僕は悲しくなりました。
### 草が生えない
インターン中の開発はゆめみのリポジトリをforkすると紹介したと思うんですが、どうやらforkしたリポジトリにコミットしたとしてもコミットが正しく反映されない仕様だそうです。

具体的には
> 1commit ≠ 1contribution, 1PR = 1contribution

という仕様になっているらしくPRの数がcontributionの数として数えられる様でした。今回の開発で61回コミットしたんですが、実際に反映されたのは9のみです。

草が生えなくて草も生えませんでした。
### 梱包が難しすぎる
３日間のインターンが終わり、全てのハードルを乗り越えた気でいた僕に最後の試練が降り掛かりました。

そう。貸与PCの梱包です。
これが今回貸与していただいたケーブルなんですが、このケースに再び収納するのが至難の業でした
![macbook proのケーブル画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/61212e4acdad4b5d8039ffcda03af72b/yumemi_pc-cable.JPG)

- 上下のツメを引っ掛ける部分が永遠にハマらない
- 紙製なせいで少し加減を間違えると破壊しそう
- お世話になったのに恩を仇で返すわけにはいかない

という３点で苦しみに苦しんだ結果、これだけで30分くらいかかりました。
ですがご覧ください、この素晴らしい結果を！
![macbook proのケーブル画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/10e07cf250a940679344b35af26f5256/yumemi_pc-cable-after.JPG)

なんとか破壊することもなく無事に梱包することができました。
あー怖かった。



## 最後に
本当に学びのある楽しい３日間でした。これから色々なインターンに参加すると思うんですが、その良いスタートダッシュを切れたと思います。
改めて、ゆめみの皆さん本当にありがとうございました。

### おまけ
募集ページを見ていたら、僕が参加したものの募集は停止していたんですがサマーインターンシップの募集が始まっていました。
絶対に成長できる環境があると思うので、もし良かったら応募してみてはいかがでしょうか。

https://hrmos.co/pages/yumemi/jobs/1791024548071079942

今回ゆめみのフロントエンドの通期インターンに参加させていただいたので、体験記を書いていこうと思います。

::: message
この記事は僕の主観・記憶の中での記事であり、ゆめみの客観的な情報を必ずしも提供するものではないことにご注意ください
:::

## はじめに

メンターのお２人を始めとして、今回受け入れて下さったフロントエンドチームの皆さんに大変感謝申し上げます...!

本当に貴重な経験をさせていただきました！

## 選考の流れ
まずどのようなステップで選考を行ったかを紹介していきます。
### カジュアル面談

#### カジュアル面談をするきっかけ
僕は最初、仲介サービスに紹介してもらう形でゆめみという存在を知りました。
正直IT業界に明るくない僕はゆめみのことも大変失礼ながら存じ上げていなかったのですが、
>折角紹介してもらったし一旦面談だけでもしてみるかぁ

という気持ちで本当にカジュアルにカジュアル面談に臨みました。

#### 当日

２月の終わりに面談させていただきました。
曖昧な記憶ですが、新卒１年目の方と中途５年目くらいの方だった気がします。
選考に関係なく聞きたいことをバンバン聞いていったのですが、お二人とも丁寧に答えて下さってとても良い印象でした。

その中でも特に良いと感じたところが何点かあったので紹介します。
- 給与を自分で決められるところ
- 自分で手を挙げてプロジェクトに参加するため部署ガチャが存在しないところ
-  勉強し放題で教材などの費用を負担していただけること

全体的にとても良い印象でしたし、是非インターンにも挑戦してみたいということで応募することになりました。

### 技術課題
選考のステップは２つに分かれており、１つ目が技術課題でした。

#### 概要

本当に意味が分からないのですが、この技術課題は一般公開されています(?)
https://notion.yumemi.co.jp/%E6%8E%A1%E7%94%A8%E9%96%A2%E9%80%A3%E8%B3%87%E6%96%99%E5%85%AC%E9%96%8B/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%83%89%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E8%A9%A6%E9%A8%93

気になる方は是非見てみて下さい。面白いです。
概要としてはAPIを使って人口統計サイトを制作するというもの。
期限は１週間でしたが、開始のタイミングは柔軟に対応してもらえました。僕の場合、申し込んだ３月が個人開発で忙しかったため４月に開始という形に設定してもらいました。
::: message
実は３月の半ばに期限が２週間に伸びたんですが、僕は１週間のまま継続させられました
:::

#### 実装の流れ
VueかReactを使えという指示だったんですが、実際にインターンではReactを使うとのことでReactを使うことにしました。

正直今までReactをほとんど使ったことがなかったので、技術力という面では絶対に使い慣れたVueを選ぶべきだったんですが、結果的に合格したので良かったです。

実際に始めてみると思ったより時間がなくて焦りました。
「４月なら時間に余裕あるやろ！」と３月の僕は高を括っていたのですが、よく考えたらサークルの新歓や新学期でかなり忙しいことを忘れていました...

そんなこんなで実質３日間くらいで死ぬほど焦りながら、初めて触るReactで技術課題を完成させることができませんでした。はい。
普通に要件漏れしました。
やっぱ慣れないことはするもんじゃないですね。

具体的にはテストを書いていなかったりします。
::: message
本来であれば要件を満たすことは必須事項だと思います。決して真似しないでください。
:::

提出最終日の日が変わるギリギリ(というのは嘘で早朝まで作業してました)まで作業をしたんですが間に合わず、「あー終わった。絶対に無理や。」と絶望しながら提出したことを覚えています。

カジュアル面談の際に、
> インターンのボーダーは厳しく設定している。本選考の上位10%くらい(うろ覚えです)

みたいなお話を聞いたせいで、絶望感はより強まりました。

#### その後
エージェントさんを通して何故か面接の案内が来ました。きっと奇跡が起こったのでしょう。それに加えてびっくりするくらい丁寧なレビューを頂きました。

具体的な内容を載せるのはあまり宜しくない気がしますし、何より僕のカスコードが露呈するのが耐えられないので詳細は省かせて頂きますが、
```md
## Goodチェック
- 〇〇ができている
- ▲▲になっている
以下10項目

## Nextチェック
- □□ができていない
- ✖︎✖︎になっていない
以下10項目

## 総合評価
[とっても丁寧なコメントが続く]

```
といった感じでインターンの課題でここまで丁寧なレビューがもらえるのかと心底感激しました。



### 面接

奇跡的に面接に進むことができたので、技術課題のカスコードを読み返しつつ当日に臨みました。

#### 内容

エンジニアの方２人との面接で、この一回で合否が決まるとのことでした。

どうやら技術面は技術課題の方で十分だったらしく、基本的に人間性重視の面接だった気がします。

過去の開発経験についても深掘りはされましたが、それよりも圧倒的にこれまでの人生経験や考え方などについて詳しく質問されました。

もしこれからゆめみの面接に挑戦する方がいたら自分の過去や自分の内面をひたすら掘り下げておくとかなり対策になると思います。

個人的に印象に残ったのは、「自分はどんな人間か」というテーマの質問でした。
インターンの面接をいくつか受ける中で類似の質問はされるんですが、「じゃあこの場合はどう？」「それって本質的な理由はなんだと思う？」などの深すぎる質問で今まで考えたことが無かった部分を刺激されたのが新鮮でした。

その後の逆質問の時間で
> ゆめみのインターンに参加するためには、僕の技術力はあと何ステップくらい足りないと思いますか？

と率直に質問させていただいたところ、
> うーん... 直感だけど２ステップくらいかなぁ

と言われて絶望したことをおまけでお伝えしておきます。(その後にちゃんと「技術力だけで取るわけでは無い」とのフォローは頂きました。)

#### 結果
体験記なので分かりきってるとは思うんですが、合格をいただくことができました。

同時にまたもやスーパー丁寧なレビューもあり、面接官お二人から良かった点と悪かった点を挙げて下さいました。

それだけに留まらず、面接の時に話していたことに関するおすすめの本まで紹介して下さったことが印象的です。

↓これです。今ちょうど読んでいるんですがめちゃくちゃ面白いです。
https://www.amazon.co.jp/%E3%80%8C%E3%82%84%E3%81%95%E3%81%97%E3%81%95%E3%80%8D%E3%81%A8%E3%81%84%E3%81%86%E6%8A%80%E8%A1%93%E2%80%95%E2%80%95%E8%B3%A2%E3%81%84%E5%88%A9%E5%B7%B1%E4%B8%BB%E7%BE%A9%E8%80%85%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE7%E8%AC%9B-%E3%82%B9%E3%83%86%E3%83%95%E3%82%A1%E3%83%B3%E3%83%BB%E3%82%A2%E3%82%A4%E3%83%B3%E3%83%9B%E3%83%AB%E3%83%B3-ebook/dp/B01BDFHKTE/ref=sr_1_2?adgrpid=53683090739&hvadid=611408448188&hvdev=c&hvlocphy=1009339&hvnetw=g&hvqmt=e&hvrand=15995901889106968913&hvtargid=kwd-334459546553&hydadcr=27485_14587142&jp-ad-ap=0&keywords=%E3%82%84%E3%81%95%E3%81%97%E3%81%95+%E3%81%A8%E3%81%84%E3%81%86%E6%8A%80%E8%A1%93&qid=1686978502&sr=8-2

技術力の点で本当に受かる訳ないと思っていたんですが面接の手応えはかなりあったので、そこで巻き返せたのかなと僕の中で考えています。

## インターン内容

僕が応募したのは３日間のインターンでした。
授業の都合もあり6/12, 6/15, 6/16という飛び飛びだったにも関わらず了承して頂きその３日間で参加させて頂きます。

### 課題
インターンの内容としては、用意されているリポジトリをforkして開発を進めていくという流れになります。

用意と言っても事前にほとんど出来上がっているという訳ではなく、最低限の設定やコンポーネントがある状態から自分でどこを作っていくかを決めていく形でした。
Figmaにデザインカンプはあるので、それを見ながら３日間の過ごし方をメンターと相談しつつ決めていきます。

課題のテーマは「商品を売買するECサイト」だったので、今回の僕の目標は「商品詳細画面を実装すること」に決めました。
「コンポーネントの切り分けや実装全体の流れを学びたい」という思いがあったので、できるだけ要素が多い画面を選びました。

### 進め方
まずページに必要なコンポーネントを作成してからそれらを組み込みつつページ全体を完成させていくことにしたので、１日目・２日目はコンポーネント作成に使い、３日目にページ全体の統合を行いました。

１日目は自分だけでコードを書いてPRをレビューしてもらい修正することを繰り返していましたが、２日目と３日目はほとんどの時間ペアプロでコードを書いていました。

今までペアプロなるものをしたことが無かったので、かなり新鮮な体験だったなと思っています。

メンターの方が僕にめちゃくちゃ時間を使ってくれたおかげでかなり濃い時間になりました。
### その他イベント

インターンではゆめみの方々の交流する機会も多く設けて頂きました。事前のアンケートで「できるだけ交流したい」と書いておいたのが功を奏したのか、昼会(チームごとの定例会のようなもの)とランチ会(ただみんなでお昼を食べる会)に参加させて頂きました。

複数のチームにお邪魔して普段の様子を見たり、エンジニアの皆さんに質問しまくり皆さんが普段どう思われているのかなど聞いてよりゆめみについて深く知ることができました。

ゆめみならではの体験ができて良い機会でした。

ランチ会の際にZoomで使えるバーチャル背景を頂きました。
これで経歴詐称もお手のものです。

![ゆめみのバーチャル背景](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/82dbcd7d35a94218996b6c5f7568f38d/yumemi-zoom-background.PNG)

## 良かったこと
ここからはゆめみのインターンで良かったことを紹介します。
頑張って書いて採用担当に良い印象を与えようと思います。(嘘です。半分。)
### レビューが圧倒的に丁寧
技術課題や面接の時からずーっと感じていたことではあるんですが、本当にレビューを丁寧にして下さいます。
それはインターン中も変わらず、PRに対するレビューも本当に色々書いて下さいました。

これがPRの一例なんですが、マジで丁寧です。ありがたすぎます。
https://github.com/arfes0e2b3c/yumeshop-frontend/pull/1

### ペアプロを通してリアルタイムで学べる
２日目と３日目はほとんどペアプロでコードを書いていたんですが、PRにレビューをもらうのとはまた違った良さがありました。

それが「リアルタイム性」です。
自分がコードを書いている様を直で見てもらえるので気になったところがあった瞬間に言ってもらえますし、気になることがあればすぐ聞くことができる。
「現状自分の中ではこれが正しいと思うんですけど、いつもどうされてますか？」みたいに文面だけだと伝わりにくいニュアンスの部分も擦り合わせながらコーディングできるので本当に貴重な経験だったと思います。

案件でかなり忙しいはずなのにこんなに時間を使ってもらえるのは、本当にありがたかったなとしみじみ感じます。

仲間内でも是非ペアプロしてみたいです。教えてもらう側だけではなく、教える側にも良い気がしています。

### 内部情報見放題

インターン参加中はゆめみのslackとnotionに招待されます。
元からゆめみは情報の透明性を掲げているのでかなりの情報が一般公開されているんですが、さらに色々な情報見ることができます。もちろん限度はありますが、「インターン生がこれ見ていいの...?」っていう情報がそこらに散らばっていました。

具体的には以下の様なものが見れました
- 取引先一覧(非公開のものも含む)
- みなさんの給与情報(ゆめみは自分の給料を自分で設定するので、その履歴を見ることができます。)
- 過去のインターン生一覧
- 採用の内部情報

僕はNDAを結んでいるのでこれらの内１つでも外部に漏らすと爆散してしまうんですが、自分の将来のキャリアを考える上でとても参考になる情報ばかりで有意義な情報ばかりでした。

中に潜り込まないと見られない情報を見るのもインターンの醍醐味ですね。
見れすぎてる気もしますが。

## いまいちだったこと
ここからはインターンに参加していまいちだなと感じたことを書いていきます。
怒られないようにしたいです。
### US配列があまりにも使いにくい
先ほども書いた通り、今回のインターンではMacbook proを貸与してもらえました。
事前確認で「US配列とJIS配列ではどちらがよろしいですか？」とメールをいただいたので、普段からJIS配列を使用している僕は迷わず「US配列でお願いします」と返信してしまいました。完全にミスでした。
「なんとなくキーボードがすっきりしていてカッコいいな」とUS配列を選んだんですが以下の点で僕には全くと言って良いほど向いていませんでした。
 1. 日本語入力と英字入力の変換が単一ボタンなせいで今どちらの状態かを気にする必要がある
 2. `option + space`で入力を変更するが、`space`を先に押すと空白が入力されてしまう
 3. アルファベット以外の配列が全然違って訳が分からない
 4. Enterが小さくてShiftを永遠に押し続けてしまう

次からは調子に乗らずJIS配列のものを貸与してもらうことにしようと固く誓いました。


### 昼会とランチ会を混同する
インターンの中で昼会に２回、ランチ会に１回参加させていただいたんですが、毎回どっちがどっちか分からなくなって混乱しました。
社員の皆さんは間違えないんでしょうか。

あと関係ないんですが、ランチ会に参加すると社員の皆さんはお昼代が支給されるようで、400円の昼ごはんを食べている僕は悲しくなりました。
### 草が生えない
インターン中の開発はゆめみのリポジトリをforkすると紹介したと思うんですが、どうやらforkしたリポジトリにコミットしたとしてもコミットが正しく反映されない仕様だそうです。

具体的には
> 1commit ≠ 1contribution, 1PR = 1contribution

という仕様になっているらしくPRの数がcontributionの数として数えられる様でした。今回の開発で61回コミットしたんですが、実際に反映されたのは9のみです。

草が生えなくて草も生えませんでした。
### 梱包が難しすぎる
３日間のインターンが終わり、全てのハードルを乗り越えた気でいた僕に最後の試練が降り掛かりました。

そう。貸与PCの梱包です。
これが今回貸与していただいたケーブルなんですが、このケースに再び収納するのが至難の業でした
![macbook proのケーブル画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/61212e4acdad4b5d8039ffcda03af72b/yumemi_pc-cable.JPG)

- 上下のツメを引っ掛ける部分が永遠にハマらない
- 紙製なせいで少し加減を間違えると破壊しそう
- お世話になったのに恩を仇で返すわけにはいかない

という３点で苦しみに苦しんだ結果、これだけで30分くらいかかりました。
ですがご覧ください、この素晴らしい結果を！
![macbook proのケーブル画像](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/10e07cf250a940679344b35af26f5256/yumemi_pc-cable-after.JPG)

なんとか破壊することもなく無事に梱包することができました。
あー怖かった。



## 最後に
本当に学びのある楽しい３日間でした。これから色々なインターンに参加すると思うんですが、その良いスタートダッシュを切れたと思います。
改めて、ゆめみの皆さん本当にありがとうございました。

### おまけ
募集ページを見ていたら、僕が参加したものの募集は停止していたんですがサマーインターンシップの募集が始まっていました。
絶対に成長できる環境があると思うので、もし良かったら応募してみてはいかがでしょうか。

https://hrmos.co/pages/yumemi/jobs/1791024548071079942

ゆめみのフロントエンドインターンに参加してきました

はじめまして。
今回こちらのブログを制作したので、紹介させていただきます。

## 経緯
現時点での自分の技術力をしっかりと反映させたプロダクトを作りたいという気持ちと、自分の学んだことを発信できる環境が欲しいと思ったため制作に至りました。

## 使用技術

### Next.js
https://nextjs.org/
TypeScriptとの親和性や周辺環境の充実度、ゼロコンフィグでスピーディーに開発をすることができるという点から採用しました。
レンダリングは基本的に静的に行っています。動的なデータを使用している箇所はgetStaticPropsを使用してSSGもしくは更新頻度が高い記事に関する箇所に関してはISRで対応しています。初期読み込みは時間がかかりますが、読み込み後のシームレスな体験が個人的に良いと感じたのでこのような構成にしています。

### TypeScript
https://www.typescriptlang.org/
型安全に開発することができるので選択しました。高度な型を使用することはまだまだできていないように思えますが、型注釈をするだけでも開発に関してかなり恩恵があるのかなと思っています。

### vanilla-extract
https://vanilla-extract.style/
css-in-jsについてはいくつか候補(styled-components, tailwind)はありましたが、HTML部分の可読性や型安全性や定義参照などのDXの点で優れていると感じたため選択しました。
実際使用してみて、別ファイルに定義しても定義参照ができるため可読性を高めつつシームレスに開発することができていたと思います。
globalStyleに関しては少し問題がある様に思われた(折角責任範囲を絞っているのにglobalにしてしまうから)のですが変数を正しく使えば責務範囲を正しく区切ることができると思うので使い方次第なのかなと思っています。

### Jest/React-Testing-Library
特に他に候補がない様に思われたので特に選択理由はありません。

### Vercel
Nextとの親和性や自動デプロイが魅力的だと感じたので選択しました。マージの前に自動でエラーを確認してくれるところがとても魅力的

### github
選択理由は特にありません。機能ごとにブランチを切ってmainブランチにマージするという流れで開発を行いました。

### react-query
https://tanstack.com/query/v3/#using-hydration
データフェッチやグローバルな状態管理で利用しています。キャッシュで動作を高速化できたりswrと違いisLoadingで読み込みを管理できる点が魅力的だと思っています。
swrと迷ったんですが、swrが少しシンプルすぎるような気がしたので、ある程度機能があらかじめ用意されているこちらの方が楽に開発ができるのではないかと思い採用することにしました。

## デザインパターン

### TreeDesign
componentsディレクトリ化に全てのコードをDOMに即した形で実装するデザインパターンです。
https://zenn.dev/mutex_inc/articles/beca85dd7fdcae
最初はatomic designが候補にありましたが、
:::message
- 今回の規模の開発でmoleclesやorganismを分けられる自信がなく、また分ける必要性を感じなかったこと
- DOMに即したディレクトリ構成にすることでより直感と合った開発をすることができる、
:::
の２点からTreeDesignを採用しています。

実際に使用してみての感想ですが、子コンポーネントや親コンポーネントなどの親子関係を辿るのは非常にやりやすいため選んで良かったと思いました。
他にもHTMLとCSS,ロジックが近い位置に纏まっているためVueを元々使っていた自分にとって理解のしやすさが段違いだったり、pagesディレクトリ直下のファイルとcomponentsディレクトリ直下のフォルダが一対一の関係になっているのでcomponentsディレクトリだけ見ればアプリの全体像を把握できる点が良いと思いました。

逆にイマイチだった点に関してはディレクトリのネストが深くなりすぎる点が気になりました。DOMとディレクトリを一致させるというコンセプトなので仕方ない部分ではあるんですが、ファイル間の移動の際に気になった点です。

具体例としては以下のような状態です。
![TreeDesign説明用画像](https://images.microcms-assets.io/assets/ca0c41f03efd472a910782fea07dff31/d7e3067ad15d47bdaa84d1a61c428871/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-05-24%2018.33.57.png)
一段階のネストなのにも関わらず、AdminList - elements - ArticleCard - index.tsx という風に４階層もあります。正直めちゃくちゃめんどくさいのでelementsディレクトリ無しで直に子コンポーネントを親直下に書く形でもいいのかな〜と開発していて感じたのでこれから先修正していくかもしれません。

## コンセプト、工夫した点
今回のテーマとしては「DX(開発者体験)を意識した技術選定」というものを設定していました。
インターン先でAtomic Designを使用していたんですが、正直めちゃくちゃ書きづらかったので「Reactを使うのであればもっと書きやすいものにしよう」と考えてそれを突き詰めた技術選定を行いました。
Tree Designを始めとして、TypeScriptやvanilla-extract、vercelなどストレスフリーに開発できる技術選定ができていたのではないかと思っています。

https://github.com/arfes0e2b3c/portfolio-blog


ARFES

Menu

PROFILE

Yuki Yata

RECENT POST

SKILLS

Languages

Libraries

Tools

PRODUCTS