ページナビゲーションエージェントを作りながら、エージェントの為の手間の少ないデータ追従を考える

「何者でもない新卒」を抜け出すための挑戦で見えてきたもの

:::message
読書感想文を書いてみました。夏だし。
:::
私は、「エンジニアリングマネージャーお悩み相談室」という本を読みました。

この本は、悩みを抱えるエンジニアリングマネージャーからお便りが寄せられてくるという形式で、17個の悩みとそれに対するアクションやアドバイスについて書かれています。

目標の立て方や自律的なチームの作り方といったチーム内部のことから、そのチームの成果を周囲に認めてもらえるような働きかけといったチーム外部との関わり方。また自身のキャリアの進め方に至るまで、EMとして働いていく上での幅広い悩み事について書かれており、将来的にEMとしてのキャリアを目指している自分にとってとても参考になる内容でした。

私はこの本を読んで、EMに求められている要素の１つは「GraphQLになること」なのではないかと感じました。
そう思った要素は２つあるのですが、１つ目は「様々な人の間に入るインターフェースになる必要がある」ということです。

この本ではピープルマネジメントに関連する内容として「翻訳」という単語が何度か登場します。それは一般的な「他の自然言語へ言い換える」という意味ではなく、「異なる立場の人間が理解し合うためにお互いが分かる言葉に変換する」といった意味です。

異なる立場と一口に言っても、「チーム内のエンジニア同士」であったり、「開発と営業」であったり、「上司と部下」であったりと非常に様々です。
そしてそれぞれの立場や視点が異なることによって、思わぬ不和ややすれ違いが発生し組織のパフォーマンスが無駄に低下しまう事があります。

「双方に悪意が無かったとしても、コミュニケーション不足によってお互いを『悪意のある人間』と評してしまう」「チームの成果を上手く他チームや上司に理解してもらえない」

こういったコミュニケーションが原因となって発生する組織の問題を解消するために、EMが間に入り、お互いが理解できる言葉に翻訳し、組織が円滑に回る様に動くのが責務の一つであると理解しました。

例えば、営業側にリファクタリングの重要性を伝えるために工数とリターンを見積もって定量的に伝えてみたり、チームの成果を周囲に認めてもらうために日々のメンバーの活動を定期的に外部にも発信していくなどの行動を取って相互理解を深めていくことが重要だと感じました。

EMに求められている要素の１つが「GraphQLになること」だと思った２つ目の理由は「スキーマを公開するかの様に、自分にできることを周囲に示す必要がある」と感じたからです。

今回この本を読んで一番印象的だったのですが、「EMとしての自分には何ができて何ができないのか」を示すことというのは、考えている以上に大事な要素なんだと気付かされました。

当たり前ですが、それぞれのメンバーの出来ることには限りがあります。知っている知識、積んできた経験、現在のタスク量は短期間で変えることができませんし、それによって出来ることの多さや幅は無限ではありません。

その限界を越えることは非常に困難ですし、時間や労力を多大に消費する可能性が高いです。

しかしそこで自分の外部からその足りない何かを補える要素を取得することができれば、より困難なタスクに対処できる様になるかもしれません。その様な意味でEMはできる事、出来ないことを周囲に示すことが求められていると思いました。

例えば、「この技術に関しては困っていたらヘルプに入ることができる」「自分には出来ないけれどそれに詳しい人を紹介したりできる」などと言った項目(=エンドポイント)をGraphQLスキーマの様に周囲に示しておけば、EMを通して組織の能力を拡張することができます。

これは単にチームのステータスが上がるというだけに留まらず、周囲の組織に対する安心感を向上させることもできるのではないかと思います。
「この人に頼ればこれに関しては何とかなる」と思えていればストレッチなタスクにも挑戦しやすくなりますし、「チームのためにこれをやりたいけど、自分1人ではやり切れない」と思っているメンバーのアクションの後押しにもなるため、組織にとって非常に重要な行動だと感じました。

この様に誰かと誰かを繋ぎ、自身にできることを周囲に発信することで、組織の成果を少しずつ大きくしていけるのではないかと思いました。

また読みたいです。

---

https://www.shoeisha.co.jp/book/detail/9784798189840

https://note.com/ar_tama/n/n4cbfc63bc3b8

著者の[あらたまさん](https://x.com/ar_tama)

【読書感想文】「エンジニアリングマネージャーお悩み相談室」を読んで

先日の6/26にISUCON研修おかわり会という25卒イベントを開催しました。
技術イベントを主催するのが初めてだったので、反省なども含めて記事にまとめます！

# 3行サマリ
- 25卒の繋がりを作るためにISUCONをテーマにしたイベントを開いたよ
- 反省点もあったけど何とかいい感じになったよ
- これからも25卒エンジニア向けイベントやるから来てね

# きっかけ
5,6月にCTO協会が主催する、新卒エンジニア合同研修というものに参加していました。

これは
>「エンジニア育成ワーキンググループ」を主軸として、新卒エンジニアの育成コストを抑えつつ、業界全体・企業横断で育てる試み

としてCTO協会の方々に主催していただいているもので、主にスタートアップの新卒が集まって毎週様々なテーマについての研修を受けることができました。

https://cto-a.org/news/20250408_release

その中のある回では「ISUCON研修」と銘打ち、３人1組のチームになってISUCONのサンプル問題(private-isu)を丸一日かけて解くという研修がありました。

僕はその研修に向けてISUCON本でみっちり練習してから臨んだので、それを活かして基本的な事はできて、チューニングの楽しさを感じることができました。

ただ研修の参加者は開発経験に関しても幅広い層が参加しており、ISUCONの魅力を感じきれないまま終わってしまう方も居た印象があって、個人的にISUCONが楽しかった身としては「もったいないなぁ...」と感じていたため、研修中に仲良くなった[kazu-gor](https://x.com/kazu_gor2)と一緒にリベンジイベントを開催することにしました。

パフォーマンスチューニングが何も分からないという人向けには改善活動の楽しさを、基礎的な内容に留まらずより発展的な内容を知りたいという人向けには更に深い内容を伝えられる会にしようと決め準備に取り掛かります。

その際、去年の合同研修をきっかけにスタートした24卒コミュニティを運営されている[yuhi](https://x.com/yuhi_junior)さんにも相談に乗っていただき、イベント開催の大きな助けになっていただけました。

https://zenn.dev/24th_dev/articles/ed424c70e55193

# 内容
先述の通り、研修参加者の開発経験やISUCON経験にはかなり幅があったので、当日は初級と中級以降に分けて開催することにしました。

初級は０からパフォーマンスチューニングの基礎をハンズオン形式で学んでいく講義、中級以降は基礎的にパフォーマンスチューニングができている前提のグループワーク形式です。

初級では「自力で改善活動を一つやってみる」というのを目標として、パフォーマンスチューニングの第一歩を助けられる様な内容にできたら嬉しいと思っていました。

# 準備
当日までに準備したものは以下の通りです。

### 講義資料
初級向けにパフォーマンスチューニングの基礎的な講義資料を作成しました。
ISUCONの基礎中の基礎は勉強できる内容なんじゃないかと思います。


@[speakerdeck](38df968c54a94dceb335675f0c364546)

### ISUCON環境
当日0からprivate-isuの環境構築をしたりログの設定をするのは平日夜の２時間では不可能だと思ったので、事前にすぐに開発を始められるような環境を用意しました。

初級者用にはログの設定を済ませ、Makefileに一通りのコマンドをmakeコマンドで叩ける様にした環境を、中級者以降にはサーバーを３台構成にして基本的なチューニング(インデックス、N+1、静的ファイル、テンプレートの事前生成、DBのコネクション etc...)を終わらせた環境を用意しました。

環境はprivate-isuに上記の内容を追加したAMIを用意してcloud formationで一発で用意できる様にしました。

また講義中にコマンドを全て手打ちする訳にも行かなかったのでMakefileに全てのコマンドを用意し、各講義part用に叩く必要があるコマンドを全てまとめたcommand.mdを準備しました。

https://github.com/arfes0e2b3c/private-isu-okawari/blob/master/Makefile

https://github.com/arfes0e2b3c/private-isu-okawari/blob/master/lecture/part1/command.md

それらは全てこちらのprivate-isuフォークリポジトリに格納されているのでもし良ければご覧ください。
https://github.com/arfes0e2b3c/private-isu-okawari


### その他の諸々
- 参加者集め：これがないと始まらない。研修後の懇親会でいろんな人に声かけました。
- 会場設営：会場自体は弊社オフィスを借りたので問題なかったですが、一応録画をしたりなんだりと環境が必要だったのでちょい時間がかかった
- 軽食：終業後に行うので食べるものが必要だとなり、作業しながら食べられる銀座のサンドイッチを用意しました。めちゃくちゃおすすめです

https://tabelog.com/tokyo/A1301/A130101/13231045/

# 結果
当日は20人弱の25卒が集まって楽しくイベントを開催することができました！
開催後アンケートでも4.5以上の評価をしてもらったので開催する意味があったかなと思っています。

当日もワイワイと楽しく話しながら講義を進めて行けたのでいい会になったのではないかなと思います！

![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/a1df759c037048fc86e959e001283a67/isucon-okawari-gather.jpg)
*タイミングが遅くなって全員で撮れなかった...*

# 反省
### ハンズオン形式が難しすぎた
全員の環境をその場で構築してハンズオンを行うというのは相当難しいんだなと今回のイベントを開催して感じました。参加者による変数をできるだけ排除しようとcloud formationやMakefileなどを準備しましたが、それでもOSや様々な環境の違いでスムーズに進めるのが難しかったです...
スムーズにできなかった事は申し訳なかったなぁと思います。

### Makefileでコマンドの隠蔽してしまった
これは当日のオペレーションを考えると仕方ないことではあるのですが、Makeコマンドでほとんどのコマンドを隠蔽したせいで実際のコマンドやオプションの詳細に触れることができなかったのも学習体験として良くなかったなと思います。

実際のISUCONでは元のコマンドを使うなり自分でMakefileを用意する必要がある訳で、それに触れる機会を作れなかったのが微妙でした。

### 中級者側の準備が疎かになった
初級者用の講義資料や環境を用意することに忙殺されて中級者用にちゃんと学習環境を用意しきれなかったのが申し訳なかったです。

当日はISUCONに詳しい同期がいい感じに周りを巻き込んで教えてくれていたおかげで学びのある時間になっていそうでしたが、本来はそれは主催の僕たち２人が用意しておくべきものだったと思います。ボトムアップを意識しすぎて全体の満足度を上げきれなかったのが悔しかったです。

### 生活リズムが終了した
直前１週間は、仕事が終わった後に準備をずっとして、休日は丸一日準備をしてといった感じだったので結構大変でした。

kazu-gorと限界の中頑張って何とか形にはなりましたが、もう少しやるやらを厳しく見たり、時間の捻出や同期的な作業の時間を作れたら変わった部分もあったのかなと後から思いました。

# まとめ
反省点もあるイベントではありましたが、25卒イベント開いて無事終了できた事は素直に楽しかったですし達成感がありました。

合同研修でできたこの繋がりをこれからも継続できるように25卒向けイベントをこれからも続けて行けたらいいなと思っています！


# 次もやるよ
という事で次もやります！！
7/25(金)の19-21時で株式会社エブリーのオフィスでやります！

次は入社して４ヶ月の25卒としての働き方を社外の人と話して交流を深める会を開催します！

この４ヶ月間でうまく行った事、行かなかった事、悔しかった事や、できる様になった事。それぞれの会社のそれぞれの環境でどの様に同期が頑張っているのか苦しんでいるのかを共有できる場にできたらいいなと思っているので25卒エンジニアの方ぜひ参加をお待ちしています！！

申し込みはこちらから↓
https://forms.gle/Eo9uKzAfaTMkzJzt8

【25卒イベント】ISUCON研修おかわり会を開催しました



TypeScriptで、UIや挙動を切り替える時に使うキーを複数の値を一つにまとめたい事ってそこそこあると思うんですが、何で定義するのがいいんでしょうか？

パッと思い付くのはenum, ユニオン型, as constオブジェクトの３つですが、正直それぞれを明確な意思を持って選べていなかったので今回比較してみることにしました。

# 結論

楽したいならユニオン型、幅広いケースに対応したいならas constオブジェクトを使うのが良さそう

# 前提
今回は全てのTypeScriptの記法でこれらを使うべき/べきでないを論じるつもりはありません。あくまで複数の数値や文字列をひとまとまりとして表したい場合にどれを選ぶべきかを検討するという前提で考えます。

# enum
```ts
enum Song {
  AMY
  ELMA
}
```

正直これが一番無いだろうなと思います。

ご存知の通りTypeScriptのenum(列挙型)には問題があります。ここで詳しく解説するつもりはありませんが、公称型であることや型安全性に多少の不安があることから積極的に選ぶことはないと思います。

https://typescriptbook.jp/reference/values-types-variables/enum/enum-problems-and-alternatives-to-enums

個人的には[TypeScriptのトップページ](https://www.typescriptlang.org/)にも書いてあるとおり「TypeScript is JavaScript with syntax for types.」であり続けて欲しいので、なるべく使いたくないです。

即時実行関数にトランスパイルされるってなんやねんという気持ちになりますね。

ただ逆に言えば絶対に選んではいけないほどのクリティカルな理由がないとも言えます。enumを選んだからといってメジャーなユースケースで困るようなことはそこまで無さそうです。

## 補足：いつかJSにenumが来るかも
先日TSKaigiに参加した際にtc39のenumに関するproposalが動いているという話を聞きました。
[リポジトリ](https://github.com/tc39/proposal-enum)を見ると７年前から存在していますし、現状でもstage1らしいので実装はまだ先だと思いますが、将来型安全で標準実装のenumを堂々と使える日が来るかもしれません。

↓最近公開されていたTSKaigiのLT動画
https://www.youtube.com/watch?v=eZV4LXRXP64

<br/>
<br/>


正直ここからが本番です。今回の主な比較対象はenumを除いた二つでずっと考えていました。

それぞれのメリットデメリットを比較して考えていこうと思います。

# ユニオン型
```ts
type Song = "AMY" | "ELMA"
```

TypeScriptのド定番な書き方ですね。

## メリット
- 記述量が少ない：1行書くだけで簡単
- トランスパイルすると消える：跡形も無くなるからバンドルサイズが軽くなる

## デメリット
- 柔軟な操作は難しい：キーを配列で取ったりする様なのは難しい
- どの型か分かりにくい：実装の中で使われている文字列リテラルだけを見て、それがどの型の値なのかを識別するのが難しい

# as constオブジェクト
```ts
const Song = {
  Amy: "AMY",
  Elma: "ELMA"
} as const 

type Song = (typeof Song)[keyof typeof Song]
```

こちらはas constでアサーションをするパターンです。オブジェクトを定義するだけだと不便なのでその値を元に別途型をユニオン型を作成しています。

## メリット
- 柔軟に使える：Object.keysなどで色々できる
- 型の判別がしやすい：実装中の値を見てすぐにどの型のものかが分かる
- 一括変換で便利：エディタの機能を使って値を一括で変換できる
- 定義ジャンプできる：使用箇所から定義元に飛ベて嬉しい

## デメリット
- 冗長：シンプルに行数も多いし、同じような値を毎回２回書かなきゃいけないのが面倒。型も別で定義する必要がある。
- バンドルサイズが大きくなる：トランスパイルしてもオブジェクト自体は残ってしまう

# 結局どれがいいのか
色々調べたり検証したりした結果、**楽したいならユニオン型、幅広いケースに対応したいならas constオブジェクトを使うべき**という結論に至りました。


:::details 幅広いパターンの例
- as constオブジェクトのメリットで挙げた要素が欲しい
- キーを配列で取得してそれら全てに対して処理を行いたい
:::

最初は結構as constオブジェクト寄りの考えを持っていたのですが、調べていく内に「あれ、これ別にユニオン型でもそんなに困らないぞ？」となる場面が本当に多かったです。

型補完や変更容易性に関してもユニオン型でかなりカバーできました。正直最初の方は「ハードコーディングなんかしないに越したことないからなぁ〜！」という安直な考えだったので今回ちゃんと考えてみてよかったです。

ただ、今でもas const派閥ではあります。というのも、やはり定義ジャンプできたりどの型の内容なのかが一目で分かったり一括変換ができるというのは認知負荷も下がりますしストレスも減ります。

その一方で、最初の定義が結構面倒だという意見も分かります。ユニオン型なら1行で済むものを何行にも分けて書くのはコストだなぁとは思うので。

僕が感じているそれらの恩恵が定義のコストに見合っているかは正直微妙なところで、実際のユースケースや個々人のお気持ちによるところが大きいというのが正直なところだと感じました。

例えばgraphql-codegenの自動生成ファイルの様に、開発者のコスト０でas constオブジェクトが使用できる場合は積極的に使っていくのが良さそうですが、通常の利用方法の場合は皆さんの好きな方を使えばいいと思います！

# 宣伝
これを考えるきっかけになったLTを7/28のお昼にやるので見てね！

@[tweet](https://twitter.com/LayerX_tech/status/1940996887185969393)


【TypeScript】enum, union, as constって意思を持って使い分けてる？

今回の卒業記念記事は２つあります。
①切り口無しのひたすら時系列を追ったver
②切り口あり(これ)

もし興味と暇があれば是非①も読んでみてもらえると嬉しいです

↓①の記事こちらです
https://www.arfes.jp/article/zmlf28yzkzvp

# はじめに

エンジニアという意味で、大学生活をまとめると「劣等感を克服し、受容できた４年間」だったなと思います。

毎年様々なイベントがあり、紆余曲折を経て今の自分に至っています。

そんな自分の大学生活を振り返れたらと思います。

# 劣等感

僕の劣等感の正体は努力というものに起因していると思います。

始まりは大学受験でした。

推薦入試の面接対策で将来像を聞かれた時、本当に何も思い付かず、自己分析なるものをやってみても何も出ず、自分の原体験の少なさに絶望しました。

原体験がなければ将来像に対して明確な回答が出せる訳もなく、その推薦入試はそのまま不合格でした(その後一般で合格して同じところに入ります)

では原体験がなぜ無いのかと問われたら、困難を乗り越えるような努力をしてきていないからだという結論になり、大学生活ではその劣等感を抱えながら、それを乗り越えるために過ごそうと決意を固めます。

余談ですが僕は『努力』が好きです。

それは自分が努力をすることが好きな訳ではなく、努力そのものが好きです。

何かに対して直向きに努力するというものは、今までの自分には成し得なかったことであり自分にとって手が届かないものなので、結果がどうであれ努力をするという姿勢が美しいなと思います。

劣等感の裏返しではありますが、自分に無いものだからこそ素晴らしいものだなと常々感じています。

# 克服

ではそんな劣等感を克服するにはどうしたらいいのでしょうか？

大学一年の時の僕は「とにかく何かを頑張るしかない」と確信していました。

というのも、時間や労力もろくにかけない状態で自分の中から勝手にやりたいことなんて見つからないし、そこでもし見つかったとしてもハリボテでしかないだろうと推薦の対策をしているときに考えていたからです。

現状やりたいことが特にない自分にとって、とにかく何かをやってみることが求められていることだと思い、そこまで崇高な目標があった訳でもなく高校生から始めていたプログラミングに取り組みます。

１年生の頃はほぼ全ての授業がオンラインで暇を持て余していたので、家で一人で黙々と勉強をしていた気がします。当時勉強していたことは、本当の本当に初歩の初歩だったけど、それが今の自分に繋がってはいると思います。

でもそれが楽しかったかというと全くそんなことはなくて、劣等感や将来に対する焦りがメインだったと思います。

多少ものづくりが楽しいという思いはあったのでそれらを含めて何とか続けることができたと思います。

そこから個人開発を始めて、ベンチャーで長期インターンを始めて、サマーインターンでも様々な企業に参加させてもらって、自分の技術力を少しずつ高めることができました。

最終的に、学生としてはまずまずな実力にはなれたかなと思います。

非エンジニアのコミュニティではエンジニアであることを自信を持ってアイデンティティとして捉えることができていますし、自分なりにスキルを持っていると自覚できる機会も増えてきました。

そのような意味でプログラミングというものは僕に劣等感を克服するきっかけをくれたものでした。

じゃあちゃんと努力をできたのか？という話なのですが、「最終的にできたと思えるようになった」というのが正直なところです。

３年生までは過去を振り返っても努力している感覚が正直ありませんでした。

これは「努力を努力だと思わずできる凄いやつ」みたいな意味ではなく、「たくさん時間をかけているから努力風になっているけど、実際これを努力と呼ぶのは烏滸がましいよなぁ」と過去の自分に対してずっと思っていました。

ただ４年生に入り内定者インターンとして様々なタスクをこなす中で、自分にとっても非常に難易度が高いタスクに対してどうにか取り組まなければなりませんでした。

そのタスクに立ち向かうために時間と労力を沢山かけながら頭を使って頑張ることができたなぁという実感があったので、大学生活で唯一「努力」したと自信を持って言える時間でした。

:::message
 僕は成長のための努力パートがごっそりカットされてるタイプの物語を見る度に「そこが一番大事やろ！」と思っていたのですが、自分で書いてみると「面白みもなくて尺も長いものを書いてもつまらんな」と思ったので、これからはそのような物語を見た時に「視聴者体験を考えていて素晴らしいな！」と思うことにします。
:::

# 受容

そうやって曲がりなりにも頑張ってきたから劣等感を完全に克服できたのか？

そんな事はなく、むしろ深まった部分もありました。

自分の実力が少し付いてきたからこそ本当に実力のある人との差が分かるようになったり、熱量の違いをよりハッキリと実感できるようになったからです。

サマーインターンで有名な企業のインターンに参加すると、同年代の本当に優秀な人が集まっていて驚きます。

自分なりに実力を少しずつ付けてきたと思っていたのに全く歯が立たなかったり、会話についていけずに分かったふりをしたりといったこともありました。

その人達からは「君も優秀だから」みたいな事を言ってくれたりすることもあるのですが、どこを見たらそう言えるんだろうと思うような人達ばかりでとっても”刺激的”でした。

ただ、その差を明確に実感したものの、その現実を受け入れられるようにもなりました。

当たり前のことなんですが、何事にも上には上がいて、見上げればキリがありません。

しかし、その上の人たちとの差があることを理解して、その上で自分なりにできることを淡々と進めていこうという気持ちを持つことができています。

この気持ちは今の自分にとってとても大事なことだと思っていて、この気持ちを持つことで、腐ったり絶望したりせずに居られています。

決してこれはマイナスではありませんし、むしろプラスな要素だと思います。

受容は決して諦めではないし、前を向いて歩いて行くために必要なことです。

何者でも無い自分を受け入れてそれでも前に進める姿こそが、僕の好きで僕が目指す「努力」の形かもしれません。

# おわりに

今回はエンジニアという切り口で書きましたが、学生生活全体で言えばとっても充実した４年間でした。

周りには「学生のままでいたい」「社会人になりたくない」と言っている人もいますが、少なくとも今の僕は社会人というものに対してポジティブな気持ちを持っていますし、頑張りたいなという気持ちが強いです。

それもこれも、本当に４年間色々な事をやり切れたからに他なりません。

本当に周りの人に恵まれた最高の大学生活でした。

後からこの記事を読んだ時に、かつての眩しさに目を焼かれないために、これからも永遠に輝き続けられるよう「努力」していきたいと思います。

:::message
僕の下の名前は悠輝というんですが、「悠久の時が経っても輝き続けられますように」という思いが込められているものだと思い込んでとっても気に入っていたところ、親に聞いたら全然違う意味でした。ダブルミーニングって事にします。
:::

【祝大学卒業！】劣等感、克服、受容

【祝卒業】今日までのエンジニア人生を振り返る

2025/2/27に行われたEMConf JPの参加記です。
印象に残ったセッションや参加して感じたことをまとめます。

# 参加するきっかけ
昨年インターンしていた際のメンターが今回のEMConf JPに大きく貢献されている[@ar_tama](https://x.com/ar_tama)さんで、1on1の時に「マネジメントとか興味あるんすよね〜」とイキっていたところ、「こんなイベント今度やるんだけど来てみない？」と紹介していただきました。

新卒として社会人生活を始めるにあたって自分のキャリアをどう進めていくかは重要なテーマだったので、お仕事見学のような気持ちで参加することに決めました。
# 印象に残ったセッション
## Potential EM制度を始めた理由、そして２年後にやめた理由
@[speakerdeck](886fe07b3fd844c295cc1cbc3c0e9838)
こちらはタイトルの通り、estieさんでのPotential EM制度の採用と廃止に関する発表でした。

「いきなりEMになるのは不安だし怖い」という気持ちを汲み取った素晴らしい施策だなぁと話を聞いていたのですが、後半で登場した『「信じて任せる、ができていないマネージャー側の問題では？」という言葉にハッとした』という内容に僕もハッとさせられました。

一見するとメンバーとしてのエンジニアとEMの間を繋ぐ良い施策である一方で、中間択を取ることによる中途半端さのデメリットという側面があったこともまた事実で、いつでもどこでも振りかざすことができる銀の弾丸ではないのだなと理解しました。

ただ、だからと言ってアンチパターンかと言うと一概にそうと言うわけではなく、当時のestieさんのエンジニア組織にとっては良い選択だったんだろうなと言うのは本人談でもそうですし、僕もそう感じました。

「時と場合による」と言ってしまえば月並みですが、組織の状態によっては非常に効果的な施策であり、慎重に運用されるべきものであるという理解は刻んでおきたいなと感じました。

## n=1の経験が紡ぐエンジニアリングマネジメントの可能性
@[speakerdeck](7a1a376900894d18b4f152dd319aedb6)
こちらは今回のエンディング keynoteで、岩瀬さんのこれまでの経験と生成AIを踏まえたこれからのマネジメントについてのお話でした。

内容もさることながらプレゼンが上手すぎて40分の内容にも関わらず１秒も飽きることなく聞くことができました。こんな風にプレゼンできる様になりたいです。

内容に関しては、他の方の発表やお話とも共通する部分が印象に残ったのですが、「時と場合による」「銀の弾丸は無い」「EMの仕事は不確実性に満ちている」と言うのがEMの方全員に刻まれているんだなと言うことを強く感じました。

その様な難しい環境の中で働かれているEMの方々を尊敬して止みません...
# 得たもの(物理)
めちゃくちゃノベルティなどを沢山頂いたのですが、その中でも嬉しかったものをピックアップします。
## アメジスト(!?)
Buysell Technologyさんのブースではリユースお宝ガチャというものを引くことができたのですが、引いてみたところガチのアメジストがもらえました。なんで？
まさか技術イベントでガチ宝石を貰えると思っていなかったので驚きましたが嬉しかったです。

![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/577ac92413654c3bac51dd1bd4a3fa52/IMG_2116.jpg)

## AirTag(!?)
サポーターズさんは就活の際にめちゃくちゃお世話になったのですが、ガチャの一等のAirTagを当ててしまい頭が上がらなくなってしまいました(?)

ちょうど３日前に財布を無くして絶望したばかり(昨日見つかりました)だったので一生無くさないように財布に入れました。ちなみにAirTagの名前は「もう絶対無くさない」です。
![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/13a49c00788044938ea3335c3457c447/IMG_2113.jpg)

## 著者の方々のサイン
後述しますが、今回のEMConfに向けて本を２冊読んできたのですが、そのどちらの著者/訳者も参加されていたので是非！と思ってサインを頂きました。
こんなにカジュアルにお礼を言うことができるのも技術イベントならではですね。
「エンジニアのためのマネジメント入門」の著者の佐藤大典さんが、僕が付箋付きで読んでいた事にめちゃくちゃ感激してくれて、「読んでよかったなぁ」としみじみ思ったのですが、よく考えたら佐藤さん側が「書いてよかったなぁ」と思うのが正しい反応だと気づいたので無かったことにしました。
![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/f48c77b8de144e15a2ba484257a1d030/IMG_2117.jpg)
![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/e04b00d4543544408e1d891c43ed04b2/IMG_2118.jpg)

(本当は写真撮って頂いたのですが恥ずかしいので載せません。)

# 参加するにあたって
今回のemconfに参加するに当たって本を２冊ほど読んでみました。
http://gihyo.jp/book/2023/978-4-297-13334-4
https://pub.jmam.co.jp/book/b646574.html

と言うのも、せっかく現職のEMの方々とお話しできる機会なのに「あの〜...EMってどんなお仕事なんですか...?」の様な初歩的な質問をするのはあまりにもったいないと思ったからです。

せっかく生の声を聞けるのであれば、より深い話を聞きたいですし、EMの方々の目線に立つと「折角EMの濃い話を議論できると思ってたのに、無知な若造のせいでレベルの低い話で時間浪費したわ〜」となりそう(ならない)だったので、できるだけその場の濃度を下げないように最低限のインプットをして臨みました。

結果としてこれは大成功で、事前に「EMとは何か」をある程度理解できたのでセッションではより深く理解できましたし、懇親会では具体的な相談や質問を沢山させていただくことができました。

これも一種の締切駆動勉強だなと思ったので、知らない技術に関するイベントにも積極的に顔を出してインプットのきっかけにしていきたいと感じました。

# 考えたこと
２冊本を読んで、またEMConf JPに参加してとても感じたことが１つあります。
それは「新卒(メンバー)もマネジメントについて勉強した方が良いのではないか？」ということです。

というのも、過去のインターン経験を振り返ってみると、EMの方々にしていただいていたメンタリングを十分に活かせていなかったという実感があったからです。

EMがどんな目線で働いているのか、1on1での意義や求められる役割は何なのか、EMからされる問いかけにはどんな意図があるのか。

何となく頭では分かっていても腑に落ちていなかったせいで、EMからの働きかけを100%活かすことができていませんでした。

しかし今回EM、特にピープルマネジメントについての理解を深めることで、メンバーとして求められる立ち回り(所謂フォロワーシップ)をはっきりと認識できる様になりました。

ピープルマネジメントは一方的なものではなく双方の共同作業なのかもしれないと感じたので、新卒全員に上記のマネジメントの本を読んで欲しいなと強く思いました。

(抽象化すると「相手の立場に立って考えよう」なので、当たり前のことを当たり前にやる難しさを感じたりもしました。)

また今まで「視座を上げる」という言葉があんまり真に理解できている実感がなかったのですが、EMという一つ上のレイヤーの視点を持てた事によって「視座ってこういうことか」と腹落ちした感覚があって嬉しかったです。
やっぱ視座っすよね。視座。

# アンカンファレンスなるものに出てみた
僕は今回初めて知ったのですが、アンカンファレンスなるものがこの世にはあるらしいのです。
意味を調べてみると
> 従来の会議の様なトップダウン企業、スポンサー出資、講演者報酬等の要素を除外し、幅広い参加者たちが会議を行う形式の事である。(by wikipedia)

と出てきます。
要するに「ゆるくお話ししたり発表したりしていいよの場」ってことですね。

10分区切りで誰でも枠使っていいよ〜とのことだったので、「せっかく来たし、学生の自分にしか出せないバリューがある気がするぞ！」と思って先ほどの考えたことに書いた様な内容を話しました。

↓即席で作った資料
@[speakerdeck](4ab859062c824b15a9d1abbfbf06ec4d)

こんなカジュアルな発表をガチEMの皆さんに聞いていただけてとってもありがたかったですし、褒めていただけて素直に嬉しかったです。

# 終わりに(ポエム)
本編とは関係ないのですが、最後に個人的な内省をポエって終わろうと思います。

今回のEMConfに限らず、今年度はいろんなカンファレンスに参加しました(TSKaigi2024、フロントエンドカンファレンス北海道、JSConf2024)

そこで度々こんなことを言って頂きました。

> まだ学生なのにすごいね〜！

褒めて頂いてとても嬉しかったのですが、その一方で「これって大学生だから褒めてもらっているだけだよなぁ...」とも思うことも多かったです。

自分としてはあくまで「若さ、大学生ブランド」にかこつけているだけで、自分の本質的な価値を認めてもらえている訳ではないと考えてしまいました。

僕は１ヶ月後から大学生ではなくなり、社会に出て、皆さんと同じ土俵で戦うことになります。

そこでも「新卒１年目」と言うエクスキューズを背負って生きていくのはブランディングや引きを作ると言う点では良いものの、「甘え」という側面も捨てきれないとも思います。

いつか「学生なのに」「若いのに」というprefix抜きで褒めてもらえる様にこれからの社会人生活を生きていこうと思います。

:::message
一応なのですが、上記の様に褒めて頂いた方々に悪意や裏の意図が無いことは十二分に理解していますし、それに対してマイナスの感情は一切持っていません。
純粋に褒めていただけて嬉しいです！
:::

【EMConf JP 2025参加記】新卒こそマネジメントを学べ！

12/8に行われたYAC(横浜アプリコンテスト)という学内のアプリコンテストに出場しました。
マジで悔しかったので記録に残しておきます。

# 経緯
最初はそんなに出るつもりがなかったんですが、半年後から社会人になりサービスを完全に一人で立ち上げることが難しくなるのではないかと思っていたので、「これも学生の今しかできないことか」と思って出場することにしました。
あと優勝賞金の30万円を引越し費用にしたかったです。

# 作ったアプリ
今回のコンテストのテーマが「心を揺さぶるアプリ」というものだったので、感情に着目したrene(リネ)というアプリを作りました。
iOSのみなんですが外部テスト中(2024/12/13時点)なのでもし良かったら以下のリンクから試してみてもらえると嬉しいです。内省的な人には割と刺さるかなぁと思ってます。
https://testflight.apple.com/join/mmVssZnj
アプリ概要に関しては以下の発表スライドを見ていただければと思います(見なくても記事の内容は分かるので飛ばしていただいて大丈夫です。あと有料フォントを使っていたのでデザインが崩れています。)

@[speakerdeck](d8af4a3fa8d1466a968a323ee7aa855d)
# 開発中のあれこれ
## 無限開発
10月中旬くらいからアプリの構想を考え始めて10月末から開発を始めました。

せっかく出るなら優勝を狙いたいということで本気開発をすることにしました。
本番までの１ヶ月強はYACのためだけに生きていたと言っても過言ではないです。

ほとんど家からも出ず(11月はまともに家から出たのは6,7回くらい)、卒論も書かずひたすらコードと向き合って永遠に開発していました。冗談抜きで合計400時間くらいは通算で時間を使っていたんじゃないかなと思います。

バックエンドを０から作ることは初めてでしたし、モバイル開発は本当の本当に初めてだったので分からないことばかりで手探りでしたが、やるしかないので無限に時間を投下することで解決しました。

起きる、プログラミングサークルのボイチャに入って作業する、息抜きにスマブラをする、寝るというサイクルをひたすら繰り返す生活はある意味最高でした。

業務以外の開発でここまで没頭できたのは久しぶりで本当にしんどかったんですが今思えば悪くなかったなと思います。

ただ途中２週間目くらいで限界が来て、一人でカップルひしめく江ノ島を観光した後に友達と油そばをたらふく食べてたくさん散歩したりもしました。改めてフルリモートにとことん向いていないなと思いました。

## Honoが最高だった
バックエンドはHonoを採用したんですが、シンプルで薄いことが本当に僕にとってありがたく、開発効率を最大化するのにとても良かったです。時間がない中での開発はHono以外じゃ不可能だったなと思います。
他にもdrizzle、OpenAPIなどを使用した開発体験がとっても良かったです。

余談ですがこの前のJSConfで[sugar-cat](https://x.com/sugar235711)さんにお会いしてHonoの丁寧な記事を書いてくださったことに対する感謝を述べさせていただきました。本当にありがとうございます...!

## なぜかフルマラソン
コンテスト１週間前になぜかフルマラソンに出場しました。
４月から申し込んでいた＆16000円くらいしたので出ない訳にもいかず、あまり練習できないまま臨んだら案の定死亡しました。
最初の30kmは３時間ピッタリくらいだったんですが最後の12kmは歩いた方が速いくらいのペースでしか足が動かなくて地獄でした。ただ「歩いたら負け、歩いたら負け」と永遠に心の中で唱えることによってなんとか走り続けました。結果としては歩くことなく完走でき、プライドを守れて良かったです(?)

# 当日の発表
そして待ちに待った当日になりました。
抽選で決まった発表順は一番手でした。
「俺がアプリコンテスト界の令和ロマンになるんや」という気持ちで臨みました。

発表自体は(体感)めちゃくちゃ上手くいって、伝えたいことをしっかりと出せた悔いのないプレゼンだったなと思います(TODO: 発表の動画が配信されたらここに貼ります)

質疑応答に関してもそこまで悪くなかった気がするのでいい感じに終わることができました。

そこからは他チームの発表を聞くターンになったのですが、学内のアプリコンテストにも関わらずめちゃくちゃレベルが高くて特色のあるアプリばかりでした。

当日まで周りがどんなアプリを作っているのか分からなかったんですが非常に魅力的なアプリをどのチームも作っていていい大会だなぁと思いました。

# 結果
イノベーション賞という企業賞をいただきました。
とても素晴らしい賞を頂けたことは嬉しい一方で、優勝できないのはとても悔しかったです。必死に隠そうとしても表情に出てしまうくらい悔しかったです。

優勝したのは「[QCoder](https://www.qcoder.jp/ja)」という量子プログラミングコンテストサービスでした。

正直に言うと、今回優勝したアプリに勝つのは僕一人がこの１ヶ月どれだけ頑張ったとしても無理だったんじゃないかなと思います。

技術力ももちろん非常に高かったですし、独創性や社会的意義、かけた時間労力全てにおいてハイレベルだったため納得の優勝です。

でも悔しいです。そして嬉しいです。
こんな素晴らしいアプリが優勝したことに対して「悔しい」と言う感情を抱けている自分が居たことが嬉しかったです。
悔しいと思える舞台に自分が立てたと思えていることが嬉しいです。

優勝はできなかったですがこの１ヶ月間頑張って良かったなと思いました。

ただこの感想は「綺麗事」を多分に含んでいます。もちろん嘘ではないですが。
メインは圧倒的に「悔しい」の一点に尽きます。

このコンテストを通して、技術力やドメインに対するコミットの足りなさを痛感しました。
優勝するとはどう言うことなのかを学ぶことができました。

これからもサービスを作って評価される機会を作りたいなと思いました。

やはり感情こそが人生ですね。

# 後日談
後日審査員の方からの評価が返ってきたんですが、割とプレゼンが好評で嬉しかったです。ただ一方で「発想や着眼点はいいけど結果として凡庸なアプリになっている気がする」的なフィードバックもいただいたので、今後アプリを改善していきたいなぁと思います。

【悔しい】本気でアプリコンテストに出てみたらマジで悔しかった

このブログは基本自作しているんですが、最近機能の物足りなさを感じています。
記事に対するコメント機能もないですし、管理画面で言えばサムネイルをブログ上からアップロードできる機能もありません。

しかし現状これらは実現できない事情があります。
その事情とは「バックエンド側をすべてmicroCMSに頼っている」ことです。

https://www.arfes.jp/article/astz6mijti

ブログを作った当初はバックエンドに関する知識が全くと言っていいほどなかったのでめちゃくちゃありがたいサービスとしてmicroCMSを使用させていただいていたんですが、最近になってお困りが発生する様になりました。

それが先ほど挙げた２点です。
より正確に言えば以下の通りです。
- カスタムAPIが３つまでしか生やせない
- 画像のアップロードAPIが使えない

これらはmicroCMSの機能としては存在しているのですが無料で使用できるHobbyプランでは使用することができません。

流石にただの個人ブログに有料プランとして登録するほどのモチベーションは無いため今回バックエンドのスクラッチで自作することにしました。

# 技術構成
- Hono
- Drizzle ORM
- postgreSQL
- Docker
- OpenAPI

Honoが熱いらしいので使ってみました。TSで書けるのがいい感じで、薄いので描き心地も違和感なかったです。

# 本題：後から層を分割してみた
今回はバックエンド開発の練習という目的もあったので、最初は最小限で作ってみて、そこから必要に応じて層を足していこうかな〜という気持ちで開発を始めました。

ここからはその変遷の過程と共にどんなことを学んだのかを書いていこうと思います。

## １段階目：何も分割しない期
最初は層の分割すらせずに、ひたすらcontroller層(層を分けてないので不適切な気もしますがこう呼ぶことにします)にベタ書きする構成でした。
![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/f727c64e7d7d4c65937b419ba046d3f8/%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%202024-10-16%209.57.44.png)

src/api配下のファイルにそのままORMのコードを書いて直接DBにアクセスする方法だったのでとっても単純に書けますね。正直ごく小規模なものを作るんだったらこれで全然いいなって思いました。

```ts
app.openapi(fetchArticleListRoute, async (c) => {
	const allArticles = await db
		.select()
		.from(articlesTable)
		.where(sql`${articlesTable.deletedAt} IS NULL`);
	return c.json({ contents: allArticles });
});
```

## ２段階目：Repository層とDomain層の分割
本当に最小限のものを作るのであれば１段階目で十分だったんですが、これだとエラーハンドリングをする時に困りました。

例えばブログの記事を投稿する時に重複したタイトルがあると困るので、それを確認して重複してたらエラーを出したいとなることがあると思います。

それは「記事を投稿する」という本質的な処理とは異なりますが、ドメインに紐づいているものなのでdomain層に分割したくなります。

しかしここでdomain層にも記事の取得処理を書いてしまうとcontroller層と全く同じコードを書くことになりあまりに冗長なので、共通化したいなぁという気持ちになりました。
そこでrepository層を追加してdomain層とcontroller層で共通のDBアクセスを行うORMのコードを共通化することにしました。
これによって冗長性が解消してハッピーな気持ちになりました。

::: message
よく考えたら現状でdomainとcontrollerから共通して呼び出しているrepositoryの関数はありませんでした...
将来的に増えると思うのでよしとさせて下さい
:::

```ts
// controller(エラーハンドリングの部分は本質では無いので省略している)
app.openapi(postArticleRoute, async (c) => {
	const body = c.req.valid("json");
	await checkDuplicateTitle(body.title);
	const res = await createArticle(body);
	return c.json(res);
});

// domain
export const checkDuplicateTitle = async (title: string) => {
	const existingArticle = await findArticleByTitle(title);
	if (existingArticle.length > 0) {
		throw new HTTPException(400, {
			message: "An article with the same title already exists",
		});
	}
};

// repository
export const findArticleByTitle = async (title: string) => {
	return await db
		.select()
		.from(articlesTable)
		.where(eq(articlesTable.title, title));
};
```

一応の補足でrepositoryを実装する際には抽象クラスを定義してそれを継承した具象クラスを定義するのがセオリーだと思うのですが今回はそれを行いませんでした。

このような抽象クラスを定義するやり方を取るメリットは
- DBアクセスのORMなどが変更する際に結合度を減らすことによって変更コストが小さい
- 先に抽象クラスを定義しておくことで具象クラスが定義される前により高レイヤーの層の実装を並行で進められる

の様なものがあると理解しているんですが、今回の実装では「必要になったら実装する」がポリシーなので現状必要ないこれら抽象クラスは実装しませんでした。

## ３段階目：Service層の分割
次の段階として、テストを書きたくなりました。
repositoryをテストする分には現状のディレクトリ構成でも問題なかったのですが、よりAPI全体の動作をテストしたいとなった時に現状のcontrollerだと難しい点がありました。

というのも、テストは関数単位でしかできないにも関わらず、controllerの内容は関数として定義されているのではなく登録しているだけなのでテストのしようがありません。

```ts
// 関数として定義されていないので呼び出し不可能でテストもできない
app.openapi(postArticleRoute, async (c) => {
	const body = c.req.valid("json");
	await checkDuplicateTitle(body.title);
	const res = await createArticle(body);
	return c.json(res);
});
```


ということでService層にAPIの本質的な処理の部分を移してテスト可能な形に変更しました。

```ts
// controller
app.openapi(postArticleRoute, async (c) => {
	return handleErrors(async (ctx) => {
		const body = ctx.req.valid('json')
		const res = await svc.article.create(body)
		return ctx.json(res)
	}, c)
})

// service
async create(body: ArticleInputSchema) {
	await domain.article.isUniqueTitle(body.title)
	await domain.article.exists(body.category)
	return await repo.article.create(body)
}

// domain
async isUniqueTitle(title: string) {
	const existingArticle = await repo.article.findByTitle(title)
	if (existingArticle.length > 0) {
		throw new HTTPException(400, {
			message: 'An article with the same title already exists',
		})
	}
}

async exists(articleId: string) {
	const existingArticle = await repo.article.findById(articleId)
	if (existingArticle.length === 0) {
		throw new HTTPException(400, {
			message: 'The specified article does not exist',
		})
	}
}

// repository
async create(body: ArticleInputSchema) {
	const res = await db
		.insert(articlesTable)
		.values(body)
		.returning({ id: articlesTable.id })
	return res[0]
}
```

これでよくあるリポジトリパターンのディレクトリ構成になったんじゃ無いかと思います。

# おわりに
初めてまともにバックエンドを構築してみたんですが、自分で実際に作ってみることで層の分割の重要性に気づくことができてとても良かったです。

ここから基本以上のコードを書ける様により学習を進めていけたらと思います。

このブログは基本自作しているんですが、最近機能の物足りなさを感じています。
記事に対するコメント機能もないですし、管理画面で言えばサムネイルをブログ上からアップロードできる機能もありません。

しかし現状これらは実現できない事情があります。
その事情とは「バックエンド側をすべてmicroCMSに頼っている」ことです。

https://www.arfes.jp

ブログを作った当初はバックエンドに関する知識が全くと言っていいほどなかったのでめちゃくちゃありがたいサービスとしてmicroCMSを使用させていただいていたんですが、最近になってお困りが発生する様になりました。

それが先ほど挙げた２点です。
より正確に言えば以下の通りです。
- カスタムAPIが３つまでしか生やせない
- 画像のアップロードAPIが使えない

これらはmicroCMSの機能としては存在しているのですが無料で使用できるHobbyプランでは使用することができません。

流石にただの個人ブログに有料プランとして登録するほどのモチベーションは無いため今回バックエンドのスクラッチで自作することにしました。

# 技術構成
- Hono
- Drizzle ORM
- postgreSQL
- Docker
- OpenAPI

Honoが熱いらしいので使ってみました。TSで書けるのがいい感じで、薄いので描き心地も違和感なかったです。

# 本題：後から層を分割してみた
今回はバックエンド開発の練習という目的もあったので、最初は最小限で作ってみて、そこから必要に応じて層を足していこうかな〜という気持ちで開発を始めました。

ここからはその変遷の過程と共にどんなことを学んだのかを書いていこうと思います。

## １段階目：何も分割しない期
最初は層の分割すらせずに、ひたすらcontroller層(層を分けてないので不適切な気もしますがこう呼ぶことにします)にベタ書きする構成でした。
![image](https://images.microcms-assets.io/assets/ff031b7059e24bf49ba18a06ed82cf72/f727c64e7d7d4c65937b419ba046d3f8/%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%202024-10-16%209.57.44.png)

src/api配下のファイルにそのままORMのコードを書いて直接DBにアクセスする方法だったのでとっても単純に書けますね。正直ごく小規模なものを作るんだったらこれで全然いいなって思いました。

```ts
app.openapi(fetchArticleListRoute, async (c) => {
	const allArticles = await db
		.select()
		.from(articlesTable)
		.where(sql`${articlesTable.deletedAt} IS NULL`);
	return c.json({ contents: allArticles });
});
```

## ２段階目：Repository層とDomain層の分割
本当に最小限のものを作るのであれば１段階目で十分だったんですが、これだとエラーハンドリングをする時に困りました。

例えばブログの記事を投稿する時に重複したタイトルがあると困るので、それを確認して重複してたらエラーを出したいとなることがあると思います。

それは「記事を投稿する」という本質的な処理とは異なりますが、ドメインに紐づいているものなのでdomain層に分割したくなります。

しかしここでdomain層にも記事の取得処理を書いてしまうとcontroller層と全く同じコードを書くことになりあまりに冗長なので、共通化したいなぁという気持ちになりました。
そこでrepository層を追加してdomain層とcontroller層で共通のDBアクセスを行うORMのコードを共通化することにしました。
これによって冗長性が解消してハッピーな気持ちになりました。

::: message
よく考えたら現状でdomainとcontrollerから共通して呼び出しているrepositoryの関数はありませんでした...
将来的に増えると思うのでよしとさせて下さい
:::

```ts
// controller(エラーハンドリングの部分は本質では無いので省略している)
app.openapi(postArticleRoute, async (c) => {
	const body = c.req.valid("json");
	await checkDuplicateTitle(body.title);
	const res = await createArticle(body);
	return c.json(res);
});

// domain
export const checkDuplicateTitle = async (title: string) => {
	const existingArticle = await findArticleByTitle(title);
	if (existingArticle.length > 0) {
		throw new HTTPException(400, {
			message: "An article with the same title already exists",
		});
	}
};

// repository
export const findArticleByTitle = async (title: string) => {
	return await db
		.select()
		.from(articlesTable)
		.where(eq(articlesTable.title, title));
};
```

一応の補足でrepositoryを実装する際には抽象クラスを定義してそれを継承した具象クラスを定義するのがセオリーだと思うのですが今回はそれを行いませんでした。

このような抽象クラスを定義するやり方を取るメリットは
- DBアクセスのORMなどが変更する際に結合度を減らすことによって変更コストが小さい
- 先に抽象クラスを定義しておくことで具象クラスが定義される前により高レイヤーの層の実装を並行で進められる

の様なものがあると理解しているんですが、今回の実装では「必要になったら実装する」がポリシーなので現状必要ないこれら抽象クラスは実装しませんでした。

## ３段階目：Service層の分割
次の段階として、テストを書きたくなりました。
repositoryをテストする分には現状のディレクトリ構成でも問題なかったのですが、よりAPI全体の動作をテストしたいとなった時に現状のcontrollerだと難しい点がありました。

というのも、テストは関数単位でしかできないにも関わらず、controllerの内容は関数として定義されているのではなく登録しているだけなのでテストのしようがありません。

```ts
// 関数として定義されていないので呼び出し不可能でテストもできない
app.openapi(postArticleRoute, async (c) => {
	const body = c.req.valid("json");
	await checkDuplicateTitle(body.title);
	const res = await createArticle(body);
	return c.json(res);
});
```


ということでService層にAPIの本質的な処理の部分を移してテスト可能な形に変更しました。

```ts
// controller
app.openapi(postArticleRoute, async (c) => {
	return handleErrors(async (ctx) => {
		const body = ctx.req.valid('json')
		const res = await svc.article.create(body)
		return ctx.json(res)
	}, c)
})

// service
async create(body: ArticleInputSchema) {
	await domain.article.isUniqueTitle(body.title)
	await domain.article.exists(body.category)
	return await repo.article.create(body)
}

// domain
async isUniqueTitle(title: string) {
	const existingArticle = await repo.article.findByTitle(title)
	if (existingArticle.length > 0) {
		throw new HTTPException(400, {
			message: 'An article with the same title already exists',
		})
	}
}

async exists(articleId: string) {
	const existingArticle = await repo.article.findById(articleId)
	if (existingArticle.length === 0) {
		throw new HTTPException(400, {
			message: 'The specified article does not exist',
		})
	}
}

// repository
async create(body: ArticleInputSchema) {
	const res = await db
		.insert(articlesTable)
		.values(body)
		.returning({ id: articlesTable.id })
	return res[0]
}
```

これでよくあるリポジトリパターンのディレクトリ構成になったんじゃ無いかと思います。

# おわりに
初めてまともにバックエンドを構築してみたんですが、自分で実際に作ってみることで層の分割の重要性に気づくことができてとても良かったです。

ここから基本以上のコードを書ける様により学習を進めていけたらと思います。

【バックエンド】必要になってから層を分割してみたらアーキテクチャの重要性を実感した

「あー、ハンバーグ食べてぇなぁ...」

大学に入った頃からずっと存在は知っていたけど、いかんせん値段が高くて足を運べていなかったハンバーグ屋さんに遂に行くことにしたんだ。

いざ行ってみたら店員さんがテーブルで切ってくれるタイプの店で、テンション上がったよね。

目の前でジュージュー言いながら食べごろを迎えたハンバーグをハフハフ言いながら食べてたんだけどさ、その時ふと通路挟んで向かいに座ってる夫婦が目に入ったのよ。

推定55歳くらいの夫婦で僕より少しだけ後に入店してきてた夫婦。
僕がラストオーダーギリギリに店に入ったからお店の人に申し訳ないなぁとか思ってたけど、その夫婦が後から入ってきてくれたおかげでちょっと安心したよね。
結局僕の後に合計３組くらいきたんだけどさ。

最初はそれくらいでしか夫婦のことは認識してなくて、「ただ視界に入っているだけの人達」だったんだけど、一度気になり始めると急に色々気になり始めちゃうことって無い？

旦那さんはスーツ着てるけど奥さんは私服着てるなぁとか、旦那さんめっちゃ冷静で寡黙な感じ(細身で眼鏡かけてて、多分会社では経理の偉い人とかやってそう)なのに奥さんとめっちゃ楽しそうに笑いながら話してるなぁとか。

そんなことに気付き出した途端に、その夫婦の妄想的なことが次々と頭に浮かんできて止まらなくなってさ。
五条悟の無量空処くらったみたいに脳に流れてきた情報で頭フリーズしたよね。

「平日の夜に旦那さんと晩御飯食べるっていう用事なのに奥さんがイヤリングとかネックレスしてるってことは旦那さんとハンバーグ食べいくのが相当楽しみだったのかなぁ」とか。

「ちょっと前までは家に娘さんが居て"パパ"と"ママ"だったけど、就職のタイミングで娘さんが独り立ちして家を出ていったから改めて"旦那"と"妻"っていう関係性を思い出して二人でご飯食べ行ったりとかし始めたのかなぁ」とか。

「でもその夫婦としての関係性を自覚し始めたきっかけは今まで10年以上祝ってなかった結婚記念日を旦那さんから切り出してちょっといいディナーとかいったからなのかなぁ」とか。

「でもやっぱり高級なディナーとかよりもちょっと贅沢なご飯をこの人と一緒に食べられることが幸せなんだなとか気づいて今日ハンバーグ食べにきたのかなぁ」とか。

「最近またお互いを名前で呼ぶ様になったりしたのかなぁ」とか。

「仕事帰りの旦那さんの車の助手席で奥さんは昔のデートの時の思い出とか思い出すのかなぁ」とか。

「ママ友的な人達とお茶しに行って、今までは一緒になって言っていた旦那の愚痴をあんまり言いたくないなとか思ってから改めて旦那さんの事好きだと思い出したりしたのかなぁ」とか。

そういう「長年連れ添った夫婦」性を感じるようなエピソード(というか妄想)が脳裏に次々よぎって、あまりに尊すぎて他に何も考えられなくて、なんだか泣きそうになって、ひたすらゆっくりハンバーグを味わう事しかできなかったんだ。

数十年一緒に居て、何回も辛いことがあって、喧嘩することもあって、仲直りもして、また喧嘩して。
そういうことを繰り返しても、好きな人となんでもない平日の夜に二人で出掛けて、ちょっといいハンバーグを笑い合いながら食べるっていう尊さは何にも変え難いと思うよ。

「あー、ハンバーグ食べてぇなぁ...」

【戯言】「長年連れ添った夫婦」性で泣きそうになった

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

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

:::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が配列で返ってくる理由に気づいたかもしれない

インターンによるTSKaigi 2024参加レポート！

こんにちは。やたです。
就活が一段落し自分の進路が決まりました。
今回は、そもそもどこに行くのか、なぜそこにしたのか、そこでどんなことをしていきたいのかなどを忘れない内に纏めておこうと思いこれを書くことしました。
あまり誰かの役に立つためになどは考えていないのですが、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

TALK & EVENT

PRODUCTS