こんにちは！クラッソーネでエンジニアをしている町田です。
私事ですが、実は今年（2025年）の4月から、<a href="https://zen.ac.jp" target="_blank" rel="nofollow noopener noreferrer">ZEN大学</a>という通信制の大学に入学し、社会人大学生になりました。 
今回は、「なぜ社会人になってから通信制大学に通い始めたのか」、そして「実際に数ヶ月通ってみてどうだったのか」という、個人的な学び直しの話を書いてみたいと思います。
<h2 id="%E3%81%AA%E3%81%9C%E9%80%9A%E4%BF%A1%E5%88%B6%E5%A4%A7%E5%AD%A6%E3%81%AB%E9%80%9A%E3%81%8A%E3%81%86%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%8B%EF%BC%9F"><a class="header-anchor-link" href="#%E3%81%AA%E3%81%9C%E9%80%9A%E4%BF%A1%E5%88%B6%E5%A4%A7%E5%AD%A6%E3%81%AB%E9%80%9A%E3%81%8A%E3%81%86%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%8B%EF%BC%9F" aria-hidden="true"></a> なぜ通信制大学に通おうと思ったのか？</h2>
これまで、エンジニアとして数年働いてきた中で、「理論的な知識が足りないな」と感じる場面が少しずつ増えてきました。 
特に、理系の大学に通っていたり、基礎からしっかり学んできた人と話すと、自分の理解が表面的だったり、うまく言語化できないことに気づかされる瞬間がありました。
また、業務経験を通じて一定のスキルは身についたと感じるものの、理論的な背景や体系的な知識に触れる機会は限られていました。 
議論やレビューの場で、自分の考えを明確に言語化できずに詰まることがあり、それが理解の浅さに起因していると実感するようになりました。
今後のキャリアを見据えたとき、理系の基礎知識を体系的に学び直すことで、より自信を持ってプロダクトや技術と向き合えるようになると考え、通信制大学への入学を決めました。
<h2 id="zen%E5%A4%A7%E5%AD%A6%E3%81%AB%E6%B1%BA%E3%82%81%E3%81%9F%E7%90%86%E7%94%B1"><a class="header-anchor-link" href="#zen%E5%A4%A7%E5%AD%A6%E3%81%AB%E6%B1%BA%E3%82%81%E3%81%9F%E7%90%86%E7%94%B1" aria-hidden="true"></a> ZEN大学に決めた理由</h2>
いくつか通信制大学を比較検討した中で、最終的に選んだのがZEN大学でした。
<ul>
<li>学費が高すぎず、自分でも手が届く範囲だったこと</li>
<li>フルオンライン対応で、働きながらでも無理なく続けられそうだったこと</li>
<li>理系科目にも力を入れていそうだったこと</li>
</ul>
また、私は第1期生として入学したのですが、まだ新しい大学ということで、これからどう発展していくのかを初期フェーズから体験できるという点にも魅力を感じ、入学を決意しました。
幅広い分野の中から、自分の興味に応じて科目を選べる自由度も魅力でした。 
実際に履修してみても、分野横断的に構成されている印象があり、ひとつの領域に偏らずに学べる設計になっていると感じました。 
実際にZEN大学の<a href="https://syllabus.zen.ac.jp/search/result" target="_blank" rel="nofollow noopener noreferrer">シラバス</a>を見ると、250以上の科目が用意されており、単に選択肢が多いだけでなく、それらをどう組み合わせて履修するかを自分で設計できる点が特徴的です。 
興味や課題に応じて、自分なりの学びの軸をつくれる構成になっているため、社会人が限られた時間の中でも効率よく、必要な知識を整理・習得していける仕組みだと感じました。
授業は基本的にオンデマンド形式で、自分の生活リズムに合わせて受けられるので、働きながら学ぶ社会人にとってはかなり現実的なスタイルだと思います。 
また、カリキュラムも完全に固定されているわけではなく、自分の関心や将来の方向性に応じてある程度自由に組み立てられるのも特徴的で魅力に感じました。
<h2 id="%E5%85%A5%E5%AD%A6%E3%81%8B%E3%82%893%E3%83%B6%E6%9C%88%E7%B5%8C%E3%81%A3%E3%81%A6"><a class="header-anchor-link" href="#%E5%85%A5%E5%AD%A6%E3%81%8B%E3%82%893%E3%83%B6%E6%9C%88%E7%B5%8C%E3%81%A3%E3%81%A6" aria-hidden="true"></a> 入学から3ヶ月経って</h2>
入学してから3ヶ月が経ち、少しずつ大学での学び方やペースにも慣れてきました。 
ここでは、実際に通ってみて感じたことや気づいたことをいくつか紹介してみたいと思います。
<h3 id="%E8%87%AA%E5%88%86%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B9%E3%81%A7%E5%AD%A6%E3%81%B9%E3%82%8B"><a class="header-anchor-link" href="#%E8%87%AA%E5%88%86%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B9%E3%81%A7%E5%AD%A6%E3%81%B9%E3%82%8B" aria-hidden="true"></a> 自分のペースで学べる</h3>
ZEN大学はすべての授業がオンラインなので、時間や場所にしばられず、自分のペースで学べるのがとても助かっています。 
経済・経営・情報・データサイエンス・国際教養など、いろんな分野を横断的に学べるつくりになっていて、「この科目だけ取ってみようかな」とか「ちょっと今は手を広げすぎないでおこう」といった柔軟な動き方ができるのも魅力です。
仕事をしながら学ぶ身としては、この自由度はかなり大きいです。
<h3 id="%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%A7%E3%82%82%E6%84%8F%E5%A4%96%E3%81%A8%E3%80%8C%E5%A4%A7%E5%AD%A6%E3%82%89%E3%81%97%E3%81%95%E3%80%8D%E3%81%AF%E3%81%82%E3%82%8B"><a class="header-anchor-link" href="#%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%A7%E3%82%82%E6%84%8F%E5%A4%96%E3%81%A8%E3%80%8C%E5%A4%A7%E5%AD%A6%E3%82%89%E3%81%97%E3%81%95%E3%80%8D%E3%81%AF%E3%81%82%E3%82%8B" aria-hidden="true"></a> オンラインでも意外と「大学らしさ」はある</h3>
ZEN大学はオンライン完結型の大学ですが、「大学っぽさがない」というわけではありません。 
Slack上ではサークル活動が活発に行われており、学生同士が趣味や興味をベースにつながる場もあります。 
また、文化祭にあたる「磁石祭」はオフラインで開催されており、実際に学生が対面で交流できる貴重な機会にもなっています。
とはいえ、「毎日キャンパスに通って友人と過ごす」ような従来型の大学生活を求めている人にとっては、やや物足りなさを感じるかもしれません。
<h3 id="%E8%87%AA%E5%B7%B1%E7%AE%A1%E7%90%86%E3%81%AE%E9%9B%A3%E3%81%97%E3%81%95"><a class="header-anchor-link" href="#%E8%87%AA%E5%B7%B1%E7%AE%A1%E7%90%86%E3%81%AE%E9%9B%A3%E3%81%97%E3%81%95" aria-hidden="true"></a> 自己管理の難しさ</h3>
一方で、時間割が固定されていない分、学習ペースの管理は完全に自分次第です。 
仕事と並行して学んでいると、「気づいたら期限ギリギリ」「ここ数日まったく進めていない」といったこともたくさんありました。
とくに気をつけたいのが、履修登録の時点でどれだけ見通しを立てておくかということです。 
ZEN大学の授業はオンデマンド形式で、1回あたり「10分×6本の映像授業」を順に視聴して進めていきます。 
そして、それぞれの動画のあとには四択式または完全一致形式の小テストが用意されており、動画とテストを交互にこなしながら理解を深めていきます。 
6本すべての動画と小テストを終えたら、最後に記述式の確認レポートを提出して1回分の授業が完了します。
この流れを15回分こなして1科目の単位取得を目指す形なので、気軽に複数科目を履修すると、レポート提出が後半に集中してかなりしんどくなってきます。
私自身、仕事や家事に追われながら提出に間に合わせようとして、内容をじっくり理解する余裕がなくなってしまったことがありました。 
「学ぶために動画を見てレポートを書く」というより、「とりあえずレポートを仕上げるために動画を消化する」ような形になってしまい、結果的にあまり身についた感じがしないまま、単位取得の最終テストを迎える…ということもありました。
自由度の高さはありがたい反面、それをどうコントロールするかで学びの質が大きく変わると感じています。 
ZEN大学は、まさに自主性が試される大学だなと、実感しています。
<h3 id="%E7%8F%BE%E6%99%82%E7%82%B9%E3%81%A7%E3%81%AF%E8%AA%B2%E9%A1%8C%E3%82%82%E3%81%82%E3%82%8B"><a class="header-anchor-link" href="#%E7%8F%BE%E6%99%82%E7%82%B9%E3%81%A7%E3%81%AF%E8%AA%B2%E9%A1%8C%E3%82%82%E3%81%82%E3%82%8B" aria-hidden="true"></a> 現時点では課題もある</h3>
ZEN大学はまだ開学して間もないということもあり、学習環境まわりには少し不安定さを感じる場面もあります。
たとえば、学習教材に誤りがあり、あとから修正が入ることが何度かありました。 
また、使用している学習システムに関しても、いくつか不具合や細かな不備を感じる場面はありました。
ただ、こうした不具合には比較的早く対応されることが多く、数日以内に修正されていたケースもありました。 
ポジティブに捉えると、私自身エンジニアということもあって、新しいシステムや仕組みが安定するまでには時間がかかるものだというのは理解していますし、むしろ、柔軟に対応し改善を重ねている姿勢には安心感もあります。
まだ新しい大学だからこそ、こうした試行錯誤も含めてこれからの成長に期待できる部分だと思っています。
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
仕事と学業の両立は決して簡単ではありませんが、少しずつ手応えも感じ始めています。 
ZEN大学はまだ発展途上な部分もありますが、自由度の高いスタイルや横断的なカリキュラムは、社会人にとって現実的な学びの選択肢です。
「基礎から整理し直したい」「学び直したい」と思ったときに、こうした場があるのは心強いと感じています。
たとえば、仕事でふと疑問に思ったことを学びの中で体系的に理解できたり、実務経験があるからこそ「この知識は実際に役立つ」と確信を持って学べたりする。そういった瞬間に、社会人だからこそ見える学びの価値を実感することが増えてきました。
同じように迷っている方の参考になればうれしいです。


こんにちは！クラッソーネでエンジニアをしている町田です。

私事ですが、実は今年（2025年）の4月から、ZEN大学という通信制の大学に入学し、社会人大学生になりました。
今回は、「なぜ社会人になってから通信制大学に通い始めたのか」、そして「実際に数ヶ月通ってみてどうだったのか」という、個人的な学び直しの話を書いてみたいと思います。

なぜ通信制大学に通おうと思ったのか？

これまで、エンジニアとして数年働いてきた中で、「理論的な知識が足りないな」と感じる場面が少しずつ増えてきました。
特に、理系の大学に通っていたり、基礎からしっかり学んできた人と話すと、自分の理解が表面的だったり、うまく言語化できないことに気づかされる瞬間がありました。

また、業務経験を通じて一定のスキルは身についたと感じるものの、理論的な背景や体系的な知識に触れる機会は限られていました。
議論やレビューの場で、自分の考えを明確に言語化できずに詰まることがあり、それが理解の浅さに起因していると実感するようになりました。

今後のキャリアを見据えたとき、理系の基礎知識を体系的に学び直すことで、より自信を持ってプロダクトや技術と向き合えるようになると考え、通信制大学への入学を決めました。

ZEN大学に決めた理由

いくつか通信制大学を比較検討した中で、最終的に選んだのがZEN大学でした。

学費が高すぎず、自分でも手が届く範囲だったこと
フルオンライン対応で、働きながらでも無理なく続けられそうだったこと
理系科目にも力を入れていそうだったこと

また、私は第1期生として入学したのですが、まだ新しい大学ということで、これからどう発展していくのかを初期フェーズから体験できるという点にも魅力を感じ、入学を決意しました。

幅広い分野の中から、自分の興味に応じて科目を選べる自由度も魅力でした。
実際に履修してみても、分野横断的に構成されている印象があり、ひとつの領域に偏らずに学べる設計になっていると感じました。
実際にZEN大学のシラバスを見ると、250以上の科目が用意されており、単に選択肢が多いだけでなく、それらをどう組み合わせて履修するかを自分で設計できる点が特徴的です。
興味や課題に応じて、自分なりの学びの軸をつくれる構成になっているため、社会人が限られた時間の中でも効率よく、必要な知識を整理・習得していける仕組みだと感じました。

授業は基本的にオンデマンド形式で、自分の生活リズムに合わせて受けられるので、働きながら学ぶ社会人にとってはかなり現実的なスタイルだと思います。
また、カリキュラムも完全に固定されているわけではなく、自分の関心や将来の方向性に応じてある程度自由に組み立てられるのも特徴的で魅力に感じました。

入学から3ヶ月経って

入学してから3ヶ月が経ち、少しずつ大学での学び方やペースにも慣れてきました。
ここでは、実際に通ってみて感じたことや気づいたことをいくつか紹介してみたいと思います。

自分のペースで学べる

ZEN大学はすべての授業がオンラインなので、時間や場所にしばられず、自分のペースで学べるのがとても助かっています。
経済・経営・情報・データサイエンス・国際教養など、いろんな分野を横断的に学べるつくりになっていて、「この科目だけ取ってみようかな」とか「ちょっと今は手を広げすぎないでおこう」といった柔軟な動き方ができるのも魅力です。

仕事をしながら学ぶ身としては、この自由度はかなり大きいです。

オンラインでも意外と「大学らしさ」はある

ZEN大学はオンライン完結型の大学ですが、「大学っぽさがない」というわけではありません。
Slack上ではサークル活動が活発に行われており、学生同士が趣味や興味をベースにつながる場もあります。
また、文化祭にあたる「磁石祭」はオフラインで開催されており、実際に学生が対面で交流できる貴重な機会にもなっています。

とはいえ、「毎日キャンパスに通って友人と過ごす」ような従来型の大学生活を求めている人にとっては、やや物足りなさを感じるかもしれません。

自己管理の難しさ

一方で、時間割が固定されていない分、学習ペースの管理は完全に自分次第です。
仕事と並行して学んでいると、「気づいたら期限ギリギリ」「ここ数日まったく進めていない」といったこともたくさんありました。

とくに気をつけたいのが、履修登録の時点でどれだけ見通しを立てておくかということです。
ZEN大学の授業はオンデマンド形式で、1回あたり「10分×6本の映像授業」を順に視聴して進めていきます。
そして、それぞれの動画のあとには四択式または完全一致形式の小テストが用意されており、動画とテストを交互にこなしながら理解を深めていきます。
6本すべての動画と小テストを終えたら、最後に記述式の確認レポートを提出して1回分の授業が完了します。

この流れを15回分こなして1科目の単位取得を目指す形なので、気軽に複数科目を履修すると、レポート提出が後半に集中してかなりしんどくなってきます。

私自身、仕事や家事に追われながら提出に間に合わせようとして、内容をじっくり理解する余裕がなくなってしまったことがありました。
「学ぶために動画を見てレポートを書く」というより、「とりあえずレポートを仕上げるために動画を消化する」ような形になってしまい、結果的にあまり身についた感じがしないまま、単位取得の最終テストを迎える…ということもありました。

自由度の高さはありがたい反面、それをどうコントロールするかで学びの質が大きく変わると感じています。
ZEN大学は、まさに自主性が試される大学だなと、実感しています。

現時点では課題もある

ZEN大学はまだ開学して間もないということもあり、学習環境まわりには少し不安定さを感じる場面もあります。

たとえば、学習教材に誤りがあり、あとから修正が入ることが何度かありました。
また、使用している学習システムに関しても、いくつか不具合や細かな不備を感じる場面はありました。

ただ、こうした不具合には比較的早く対応されることが多く、数日以内に修正されていたケースもありました。
ポジティブに捉えると、私自身エンジニアということもあって、新しいシステムや仕組みが安定するまでには時間がかかるものだというのは理解していますし、むしろ、柔軟に対応し改善を重ねている姿勢には安心感もあります。

まだ新しい大学だからこそ、こうした試行錯誤も含めてこれからの成長に期待できる部分だと思っています。

まとめ

仕事と学業の両立は決して簡単ではありませんが、少しずつ手応えも感じ始めています。
ZEN大学はまだ発展途上な部分もありますが、自由度の高いスタイルや横断的なカリキュラムは、社会人にとって現実的な学びの選択肢です。

「基礎から整理し直したい」「学び直したい」と思ったときに、こうした場があるのは心強いと感じています。

たとえば、仕事でふと疑問に思ったことを学びの中で体系的に理解できたり、実務経験があるからこそ「この知識は実際に役立つ」と確信を持って学べたりする。そういった瞬間に、社会人だからこそ見える学びの価値を実感することが増えてきました。

同じように迷っている方の参考になればうれしいです。


ZEN大学に入学し、社会人をしながら大学生になった理由と3ヶ月経っての感想

こんにちは！クラッソーネでアプリケーションエンジニアをしている町田です。 
今回は、これまでに試してきた様々な振り返り手法について総評をお伝えします。振り返りの進め方に悩んでいる方や、新しい手法を取り入れてみたい方の参考になれば幸いです。
<h2 id="%E5%89%8D%E7%BD%AE%E3%81%8D"><a class="header-anchor-link" href="#%E5%89%8D%E7%BD%AE%E3%81%8D" aria-hidden="true"></a> 前置き</h2>
筆者はこれまで、KPTという手法を用いて振り返りを行ってきました。 
ですが、最近の振り返り会では、新しい視点を取り入れるために象、死んだ魚、嘔吐とWWWという2つの手法を試してみました。 
新しい手法を試した理由は以下の通りです。
<ul>
<li>振り返りのマンネリ化や形骸化を防ぐため</li>
<li>KPT以外の手法を通じて、新たな学びや効果を得たかったため</li>
</ul>
今回はそれぞれの手法の概要や使ってみた感想を中心にお伝えするため、具体的な進め方は省略しています。 
興味があればぜひ調べてみてください！
<h2 id="%E3%80%8Ckpt%EF%BC%88keep-problem-try%EF%BC%89%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F"><a class="header-anchor-link" href="#%E3%80%8Ckpt%EF%BC%88keep-problem-try%EF%BC%89%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> 「KPT（Keep Problem Try）」とは？</h2>
「KPT（Keep, Problem, Try）」は、振り返り手法の中でも広く使われているものです。 
うまくいったこと（Keep）を評価し、問題点（Problem）を洗い出し、次のアクションプラン（Try）を考えるために活用されます。 
こちらは一般的に広く使われている手法なので、詳細の説明は省きます。
<h2 id="%E3%80%8C%E8%B1%A1%E3%80%81%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A%E3%80%81%E5%98%94%E5%90%90%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F"><a class="header-anchor-link" href="#%E3%80%8C%E8%B1%A1%E3%80%81%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A%E3%80%81%E5%98%94%E5%90%90%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> 「象、死んだ魚、嘔吐」とは？</h2>
「象、死んだ魚、嘔吐」は、チームの振り返りやレビューで使われる少しユニークな手法です。 
チーム内に隠れている問題や感情を表面化し、解決や整理に役立てることが目的です。 
それぞれの要素には次のような意味があります。
<h3 id="%E8%B1%A1"><a class="header-anchor-link" href="#%E8%B1%A1" aria-hidden="true"></a> 象</h3>
「象」は、チーム全員が感じているものの、あえて触れられていない課題を指します。 
皆が気づいているのに見て見ぬふりをしてきた問題に光を当て、正直な議論をしましょう。
<h3 id="%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A"><a class="header-anchor-link" href="#%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A" aria-hidden="true"></a> 死んだ魚</h3>
「死んだ魚」は、放置していると後々困る問題を意味します。 
過去のトラブルや放置されている問題を再確認し、必要な解決策を見つけていきましょう。
<h3 id="%E5%98%94%E5%90%90"><a class="header-anchor-link" href="#%E5%98%94%E5%90%90" aria-hidden="true"></a> 嘔吐</h3>
「嘔吐」は、心の中に溜まっていたぶっちゃけた思いを表します。 
感情的なストレスや不満を吐き出し、感情面からもチームの健全さを保つようにしていきましょう。
<h2 id="%E3%80%8Cwww%EF%BC%88what-went-well%EF%BC%89%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F"><a class="header-anchor-link" href="#%E3%80%8Cwww%EF%BC%88what-went-well%EF%BC%89%E3%80%8D%E3%81%A8%E3%81%AF%EF%BC%9F" aria-hidden="true"></a> 「WWW（What Went Well）」とは？</h2>
「WWW（What Went Well）」は、チームの成功体験やポジティブな成果に焦点を当て、良かった点を再確認し、今後に活かすことを目的とする手法です。 
それぞれの要素について説明します。
<h3 id="went-well"><a class="header-anchor-link" href="#went-well" aria-hidden="true"></a> Went Well</h3>
「Went Well」では、うまくいったことを振り返ります。 
チームや個々のメンバーが達成した成果を再確認することで、チーム全体の士気を高め、次のプロジェクトに活かせる成功のポイントを共有します。
<h3 id="to-improve"><a class="header-anchor-link" href="#to-improve" aria-hidden="true"></a> To Improve</h3>
「To Improve」では、カイゼンが必要な点や問題を洗い出します。 
過去に起きた問題や、さらに良くできる部分を見つけて、次に同じことが起こらないように対策を考えます。
<h3 id="action-items"><a class="header-anchor-link" href="#action-items" aria-hidden="true"></a> Action Items</h3>
「Action Items」では、次にやってみることを具体的に挙げていきます。 
「Went Well」と「To Improve」で出てきた内容を踏まえ、次のプロジェクトやスプリントでのアクションプランを作成します。
<h2 id="%E7%B7%8F%E8%A9%95"><a class="header-anchor-link" href="#%E7%B7%8F%E8%A9%95" aria-hidden="true"></a> 総評</h2>
それぞれの振り返り手法の概要を説明してきました。 
これらの手法を試した結果、チームの状況や目指す目的によって有効な手法が変わってくると感じました。 
以下に、各手法のメリットや感じたことをまとめてみます。
<h3 id="kpt%EF%BC%88keep-problem-try%EF%BC%89"><a class="header-anchor-link" href="#kpt%EF%BC%88keep-problem-try%EF%BC%89" aria-hidden="true"></a> KPT（Keep Problem Try）</h3>
KPTは、ポジティブな意見とネガティブな意見をバランスよく引き出せる手法で、幅広く認知されています。 
そのため、初めて振り返りを行うチームでもスムーズに意見が集まりやすい印象です。 
特に、Keep（うまくいったこと）を最初に振り返ることで、ポジティブな雰囲気を作りやすく、その後のProblem（課題）の指摘も自然な流れで行えます。 
参加者から「こうしたらもっと良くなる」というTry（次にやってみること）の提案も出やすく、具体的なアクションプランを作りやすいのが魅力です。 
振り返り後には得られるものが多く、定期的に使いたい手法です。
<h3 id="%E8%B1%A1%E3%80%81%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A%E3%80%81%E5%98%94%E5%90%90"><a class="header-anchor-link" href="#%E8%B1%A1%E3%80%81%E6%AD%BB%E3%82%93%E3%81%A0%E9%AD%9A%E3%80%81%E5%98%94%E5%90%90" aria-hidden="true"></a> 象、死んだ魚、嘔吐</h3>
この手法は、普段は表に出にくい感情や潜在的な課題を洗い出すための、少しユニークな振り返り方法です。 
象、死んだ魚、嘔吐というインパクトのある名前からして、チームメンバーの気持ちを解放しやすく、心に溜めていたものを出すきっかけを作ってくれます。 
課題や感情をチーム全体で共有し、向き合うことができるため、チームの結束力を高める効果もあると感じました。特に、感情面での不安や不満がチームに存在する場合に非常に有効です。 
また、象（チームで見て見ぬふりをしてきた問題）や嘔吐（溜まっていた本音）の要素があることで、他の振り返り手法では出てこない深い課題に気づくこともありました。 
ただし、この手法を効果的に使うためには、チーム内に安心して意見を言える雰囲気が必要だと感じました。 
そういった基盤がチームで整っている場合にのみ、非常に有用な振り返り手法だと思います。
<h3 id="www%EF%BC%88what-went-well%EF%BC%89"><a class="header-anchor-link" href="#www%EF%BC%88what-went-well%EF%BC%89" aria-hidden="true"></a> WWW（What Went Well）</h3>
ポジティブな意見が出やすいテーマを軸にしているため、さまざまなバックグラウンドを持つメンバーがいるチームでも使いやすい手法です。 
成功体験に焦点を当てることで、振り返り後にはチーム全体の士気が上がり、次の業務に前向きに取り組める雰囲気になるのがこの手法の大きな魅力です。 
特に、Action Itemsを出す際、前向きなものばかりがリストアップされるので、実際に取り掛かるときに手が進みやすいです。 
また、振り返りが初めてのメンバーや、振り返りに慣れていないチームにも導入しやすいという点も評価のひとつです。 
ポジティブな雰囲気を保ちながら改善を進めたい場合には、とてもおすすめの手法だと思いました。
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
振り返りにはいろいろな手法がありますが、どの手法がベストかはチームの状況や目的次第だと改めて思いました。 
今回紹介した手法はそれぞれに特徴があり、チームのフェーズや抱えている課題に合わせて選ぶと、効果的な振り返りができると思います。 
ぜひ皆さんも、自分たちのチームに合った手法を探してみてください。


こんにちは！クラッソーネでアプリケーションエンジニアをしている町田です。
今回は、これまでに試してきた様々な振り返り手法について総評をお伝えします。振り返りの進め方に悩んでいる方や、新しい手法を取り入れてみたい方の参考になれば幸いです。

前置き
筆者はこれまで、KPTという手法を用いて振り返りを行ってきました。
ですが、最近の振り返り会では、新しい視点を取り入れるために象、死んだ魚、嘔吐とWWWという2つの手法を試してみました。
新しい手法を試した理由は以下の通りです。
振り返りのマンネリ化や形骸化を防ぐため
KPT以外の手法を通じて、新たな学びや効果を得たかったため

今回はそれぞれの手法の概要や使ってみた感想を中心にお伝えするため、具体的な進め方は省略しています。
興味があればぜひ調べてみてください！

「KPT（Keep Problem Try）」とは？
「KPT（Keep, Problem, Try）」は、振り返り手法の中でも広く使われているものです。
うまくいったこと（Keep）を評価し、問題点（Problem）を洗い出し、次のアクションプラン（Try）を考えるために活用されます。
こちらは一般的に広く使われている手法なので、詳細の説明は省きます。

「象、死んだ魚、嘔吐」とは？
「象、死んだ魚、嘔吐」は、チームの振り返りやレビューで使われる少しユニークな手法です。
チーム内に隠れている問題や感情を表面化し、解決や整理に役立てることが目的です。
それぞれの要素には次のような意味があります。

象
「象」は、チーム全員が感じているものの、あえて触れられていない課題を指します。
皆が気づいているのに見て見ぬふりをしてきた問題に光を当て、正直な議論をしましょう。

死んだ魚
「死んだ魚」は、放置していると後々困る問題を意味します。
過去のトラブルや放置されている問題を再確認し、必要な解決策を見つけていきましょう。

嘔吐
「嘔吐」は、心の中に溜まっていたぶっちゃけた思いを表します。
感情的なストレスや不満を吐き出し、感情面からもチームの健全さを保つようにしていきましょう。

「WWW（What Went Well）」とは？
「WWW（What Went Well）」は、チームの成功体験やポジティブな成果に焦点を当て、良かった点を再確認し、今後に活かすことを目的とする手法です。
それぞれの要素について説明します。

Went Well
「Went Well」では、うまくいったことを振り返ります。
チームや個々のメンバーが達成した成果を再確認することで、チーム全体の士気を高め、次のプロジェクトに活かせる成功のポイントを共有します。

To Improve
「To Improve」では、カイゼンが必要な点や問題を洗い出します。
過去に起きた問題や、さらに良くできる部分を見つけて、次に同じことが起こらないように対策を考えます。

Action Items
「Action Items」では、次にやってみることを具体的に挙げていきます。
「Went Well」と「To Improve」で出てきた内容を踏まえ、次のプロジェクトやスプリントでのアクションプランを作成します。

総評
それぞれの振り返り手法の概要を説明してきました。
これらの手法を試した結果、チームの状況や目指す目的によって有効な手法が変わってくると感じました。
以下に、各手法のメリットや感じたことをまとめてみます。

KPT（Keep Problem Try）
KPTは、ポジティブな意見とネガティブな意見をバランスよく引き出せる手法で、幅広く認知されています。
そのため、初めて振り返りを行うチームでもスムーズに意見が集まりやすい印象です。
特に、Keep（うまくいったこと）を最初に振り返ることで、ポジティブな雰囲気を作りやすく、その後のProblem（課題）の指摘も自然な流れで行えます。
参加者から「こうしたらもっと良くなる」というTry（次にやってみること）の提案も出やすく、具体的なアクションプランを作りやすいのが魅力です。
振り返り後には得られるものが多く、定期的に使いたい手法です。

象、死んだ魚、嘔吐
この手法は、普段は表に出にくい感情や潜在的な課題を洗い出すための、少しユニークな振り返り方法です。
象、死んだ魚、嘔吐というインパクトのある名前からして、チームメンバーの気持ちを解放しやすく、心に溜めていたものを出すきっかけを作ってくれます。
課題や感情をチーム全体で共有し、向き合うことができるため、チームの結束力を高める効果もあると感じました。特に、感情面での不安や不満がチームに存在する場合に非常に有効です。
また、象（チームで見て見ぬふりをしてきた問題）や嘔吐（溜まっていた本音）の要素があることで、他の振り返り手法では出てこない深い課題に気づくこともありました。
ただし、この手法を効果的に使うためには、チーム内に安心して意見を言える雰囲気が必要だと感じました。
そういった基盤がチームで整っている場合にのみ、非常に有用な振り返り手法だと思います。

WWW（What Went Well）
ポジティブな意見が出やすいテーマを軸にしているため、さまざまなバックグラウンドを持つメンバーがいるチームでも使いやすい手法です。
成功体験に焦点を当てることで、振り返り後にはチーム全体の士気が上がり、次の業務に前向きに取り組める雰囲気になるのがこの手法の大きな魅力です。
特に、Action Itemsを出す際、前向きなものばかりがリストアップされるので、実際に取り掛かるときに手が進みやすいです。
また、振り返りが初めてのメンバーや、振り返りに慣れていないチームにも導入しやすいという点も評価のひとつです。
ポジティブな雰囲気を保ちながら改善を進めたい場合には、とてもおすすめの手法だと思いました。

まとめ
振り返りにはいろいろな手法がありますが、どの手法がベストかはチームの状況や目的次第だと改めて思いました。
今回紹介した手法はそれぞれに特徴があり、チームのフェーズや抱えている課題に合わせて選ぶと、効果的な振り返りができると思います。
ぜひ皆さんも、自分たちのチームに合った手法を探してみてください。


様々な振り返りの手法を試してみた


こんにちは！最近は韓国語の勉強をしている町田です。
次回のブログ執筆までには単純な文の読み書きができているといいな〜と思っているこの頃です。
korean-language-books

さて、今回のテックブログでは、RemixとLucia Auth(v3)とCloudflare D1でGoogleログインを実装するプロセスについて紹介します。

Remixでの認証はremix-authを使う実装をよく見かけますが、Lucia Authを使った実装方法を紹介する記事はあまり見かけません。
そこで、自身で実装してみたので、今後RemixとLucia Authで認証を実装したい方の参考になれば幸いです。
(執筆時点ではLucia Authのv3での実装例が少ないため、その点も含めて参考になることを願っています。)

※ Remix、Lucia Auth、およびCloudflare D1についての詳細な説明はこの記事では行いませんので、公式ドキュメントや他の参考記事をご参照ください。
※ Cloudflareのアカウントは既に作成済みの前提で進めます。

1. プロジェクトのセットアップ
まずは、Cloudflareで動かすRemixの新しいプロジェクトを作成します。
npm create cloudflare@latest my-remix-app -- --framework=remix
cd my-remix-app

次に、Lucia Authとその依存関係をインストールします。
今回はCloudflare D1をデータベースとして使うので、sqlite用のアダプターもインストールします。
また、Google認証の実装にarcticを使うので、合わせてインストールします。
npm install lucia @lucia-auth/adapter-sqlite arctic

Cloudflare D1に接続するためにdrizzleを使用するので、こちらもインストールします。
npm install drizzle-orm
npm install -D drizzle-kit
※ drizzle-ormがインストールできない場合は、reactとreact-domをv18.3.0以上にしてから再度インストールを試してください。

2. Cloudflare D1を作成
以下のコマンドを実行して、Cloudflare D1を作成します。
npx wrangler d1 create my-remix-app-d1

[[d1_databases]]の部分をwrangler.tomlに貼り付けます。

✅ Successfully created DB 'my-remix-app-d1' in region APAC
Created your new D1 database.

[[d1_databases]]
binding = "DB" # i.e. available in your Worker on env.DB
database_name = "my-remix-app-d1"
database_id = "your-database-id"

3. Cloudflare D1のスキーマを定義
luciaはセッションを発行するためのテーブルと、セッションに紐づくユーザテーブルが必要なので定義します。
app/schema.tsにスキーマファイルを作成します。
import { sql } from 'drizzle-orm';
import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core';

export const users = sqliteTable('users', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  email: text('email').notNull(),
  googleProfileId: text('googleprofileid').notNull().unique(),
  iconUrl: text('icon_url'),
  displayName: text('display_name').notNull(),
  createdAt: integer('created_at', { mode: 'timestamp' }).default(sql(unixepoch())),
  updatedAt: integer('updated_at', { mode: 'timestamp' }).default(sql(unixepoch())),
});

export const sessions = sqliteTable('sessions', {
  id: integer('id').primaryKey().notNull(),
  expiresAt: integer('expires_at', { mode: 'timestamp' }).notNull(),
  userId: text('user_id').references(() => users.id),
});

4. Cloudflare D1にマイグレーションを適用
ディレクトリのトップにdrizzle.config.tsを作成します。
Cloudflare D1にマイグレーションを適用するための設定をします。
import type { Config } from "drizzle-kit";

export default {
  dialect: 'sqlite',
  schema: "./app/schema.ts",
  out: "./migrations",
  driver: "d1",
  dbCredentials: {
    wranglerConfigPath: "wrangler.toml",
    dbName: 'my-remix-app-d1',
  },
} satisfies Config;

マイグレーションファイルを生成します。
npx drizzle-kit generate

以下のようなログが出ていると成功です。
No config path provided, using default 'drizzle.config.ts'
Reading config file '/Users/hoge/my-remix-app/drizzle.config.ts'
2 tables
sessions 3 columns 0 indexes 1 fks
users 7 columns 1 indexes 0 fks

[✓] Your SQL migration file ➜ migrations/0000naiveturbo.sql 🚀

ローカルで動作するCloudflare D1に、マイグレーションを適用します。
npx wrangler d1 migrations apply my-remix-app-d1 --local

マイグレーションの適用に成功すると、以下のようなログが出ます。

Migrations to be applied:
┌──────────────────────┐
│ name                 │
├──────────────────────┤
│ 0000naiveturbo.sql │
└──────────────────────┘
✔ About to apply 1 migration(s)
Your database may not be available to serve requests during the migration, continue? … yes
🌀 Executing on local database my-remix-app-d1 (your-database-id) from .wrangler/state/v3/d1:
🌀 To execute on your remote database, add a --remote flag to your wrangler command.
┌──────────────────────┬────────┐
│ name                 │ status │
├──────────────────────┼────────┤
│ 0000naiveturbo.sql │ ✅       │
└──────────────────────┴────────┘

5. Google OAuth クレデンシャルの取得
Google Cloud Consoleにアクセスし、新しいプロジェクトを作成してOAuth 2.0クライアントIDを設定します。
リダイレクトURIを設定し、クライアントIDとクライアントシークレットを取得します。
以下のリンクを参考にしてください。
参考：https://developers.google.com/identity/protocols/oauth2/web-server#creatingcred

承認済みのJavaScript生成元：http://localhost:5173
承認済みのリダイレクトURI：http://localhost:5173/google/callback

※ 承認済みのリダイレクトURIは後ほど実装する認証処理でのコールバックを受け取ります。

6. 環境変数の設定
.dev.varsファイルを作成し、以下を追加します。
OAuthクライアント作成時に発行されたIDとSECRETは各自で貼り付けてください。
NODE_ENV="development"
GOOGLEAUTHCLIENT_ID="your-google-client-id"
GOOGLEAUTHCLIENT_SECRET="your-google-client-secret"
GOOGLEAUTHCALLBACK_URL="http://localhost:5173/auth/google/callback"
SESSION_SECRET="se3cret"

この時点で、バインディングで環境変数やCloudflare D1を扱えるように以下のコマンドを実行してください。
npx wrangler types

7. LuciaAuthの設定
app/lucia.tsというファイルを作成し、Lucia Authの設定を記述します。
Lucia Authで扱うセッションやクッキーの設定は、以下のリンクを参考に各自で設定してください。
参考：https://lucia-auth.com/basics/configuration
import { Lucia, TimeSpan } from "lucia";
import { D1Adapter } from "@lucia-auth/adapter-sqlite";
import { AppLoadContext } from "@remix-run/cloudflare";

let lucia: Lucia | null = null;
export function initializeLucia(context: AppLoadContext) {
  if (lucia) {
    return lucia;
  };
  const { DB, NODE_ENV } = context.cloudflare.env;
	const adapter = new D1Adapter(DB, {
    // ユーザーを保存するテーブル名を指定
		user: "users",
    // セッションを保存するテーブル名を指定
		session: "sessions"
	});
  lucia = new Lucia(adapter, {
    // セッションの有効期限
    sessionExpiresIn: new TimeSpan(2, "w"),
    // クッキーの設定
    sessionCookie: {
      name: "session",
      attributes: {
        secure: NODE_ENV === "production",
        sameSite: "lax",
      }
    },
  });
	return lucia;
};

declare module "lucia" {
	interface Register {
		Auth: ReturnType;
	}
};

8. 認証ルートの作成
app/auth/google.tsファイルを作成し、Googleログインを実装するためにarcticから提供されるGoogleクラスを初期化します。
import { AppLoadContext } from "@remix-run/server-runtime";
import { Google } from "arctic";

export interface Profile {
  sub: string;
  email: string;
  email_verified: boolean;
  name: string;
  picture: string;
  given_name: string;
  locale: string;
}

let google: Google | null = null;
export const initializeArcticGoogle = (context: AppLoadContext) => {
  if (google) {
    return google;
  }
  const {
    GOOGLEAUTHCLIENT_ID: clientId,
    GOOGLEAUTHCLIENT_SECRET: clientSecret,
    GOOGLEAUTHCALLBACK_URL: redirectURI,
  } = context.cloudflare.env;
  google = new Google(clientId, clientSecret, redirectURI);
  return google;
};

次に、app/routes/auth.google.tsxを作成し、Googleログインのエンドポイントを設定します。
import { ActionFunctionArgs } from '@remix-run/cloudflare';
import { generateCodeVerifier, generateState } from "arctic";
import { serializeCookie } from "oslo/cookie";
import { initializeArcticGoogle } from '~/auth/google';

export const action = async ({ context }: ActionFunctionArgs) => {
  const state = generateState();
  const codeVerifier = generateCodeVerifier();
  const google = initializeArcticGoogle(context);

  const url: URL = await google.createAuthorizationURL(state, codeVerifier, {
    scopes: ["profile", "email"]
  });

  return redirect(url.toString(), {
		headers: [
      [
        'Set-Cookie',
        serializeCookie("state", state, {
          httpOnly: true,
          secure: context.cloudflare.env.NODE_ENV === "production",
          maxAge: 60 * 10,
          path: "/"
        })
      ],
      [
        'Set-Cookie',
        serializeCookie("code_verifier", codeVerifier, {
          httpOnly: true,
          secure: context.cloudflare.env.NODE_ENV === "production",
          maxAge: 60 * 10,
          path: "/"
        })
      ]
    ]
	});
};

export default function Empty() {
  return null;
};

9. 認証コールバックの作成
app/routes/auth.google.callback.tsxを作成し、認証コールバック時の処理を書きます。
ログインに成功したら、セッションとクッキーを発行し、トップページにリダイレクトするようにします。
import { LoaderFunctionArgs, redirect } from '@remix-run/cloudflare';
import { OAuth2RequestError } from 'arctic';
import { eq } from 'drizzle-orm';
import { drizzle } from 'drizzle-orm/d1';
import { parseCookies } from "oslo/cookie";
import { Profile, initializeArcticGoogle } from '~/auth/google';
import { initializeLucia } from '~/auth/lucia';
import { users } from '~/schema';

export const loader = async ({ request, context }: LoaderFunctionArgs) => {
  const cookies = parseCookies(request.headers.get("Cookie") ?? "");
	const storedState = cookies.get("state") ?? null;
  const storedCodeVerifier = cookies.get("code_verifier") ?? null;

	const url = new URL(request.url);
  const code = url.searchParams.get("code");
	const state = url.searchParams.get("state");

	if (!code || !storedState || !storedCodeVerifier || state !== storedState) {
		return new Response(null, {
			status: 400
		});
	};

	try {
    const google = initializeArcticGoogle(context);
		const tokens = await google.validateAuthorizationCode(code, storedCodeVerifier);
		const response = await fetch("https://openidconnect.googleapis.com/v1/userinfo", {
      headers: {
        Authorization: Bearer ${tokens.accessToken}
      }
    });
    const profile = await response.json() as Profile;
    const lucia = initializeLucia(context);
    const db = context.cloudflare.env.DB;
    const existsUser = await drizzle(db).select().from(users).where(eq(users.googleProfileId, profile.sub)).get();

    if (existsUser) {
      const session = await lucia.createSession(existsUser.id.toString(), {});
      const sessionCookie = lucia.createSessionCookie(session.id);
      return redirect('/', {
        headers: [
          ["Set-Cookie", sessionCookie.serialize()]
        ],
      });
    };

    const [user] = await drizzle(db).insert(users).values({
      email: profile.email,
      googleProfileId: profile.sub,
      iconUrl: profile.picture,
      displayName: profile.name
    }).returning();

		const session = await lucia.createSession(user.id.toString(), {});
		const sessionCookie = lucia.createSessionCookie(session.id);
    return redirect('/', {
      headers: [
        ["Set-Cookie", sessionCookie.serialize()]
      ],
    });
	} catch (e) {
		console.error(e);
		if (e instanceof OAuth2RequestError) {
			return redirect('/login');
		}
		return redirect('/login');
	};
};

export default function Empty() {
  return null;
};

10. ログイン画面の作成
app/routes/login.tsファイルを作成し、ボタンのみの簡易的なログイン画面を作成します。
ログインページに遷移する際に、既にログインしている状態であればトップページにリダイレクトするようにします。
import { LoaderFunctionArgs, redirect } from "@remix-run/cloudflare";
import { Form } from "@remix-run/react";
import { initializeLucia } from "~/auth/lucia";

export const loader = async ({ context, request }: LoaderFunctionArgs) => {
  const lucia = initializeLucia(context);
  const cookie = request.headers.get("Cookie");
  if (!cookie) {
    return { user: null, session: null };
  }
  const sessionId = lucia.readSessionCookie(cookie);
  if (!sessionId) {
    return { user: null, session: null };
  };

  const { user, session } = await lucia.validateSession(sessionId);
  if (user) {
    return redirect("/");
  };

  return { user, session };
};

export default function Login() {
  return (

        Login with Google

  )
};

これで、ユーザーがGoogleログインボタンをクリックすることで認証フローを開始できるようにしました。
実際にログインが成功すると、トップページにリダイレクトされます。
また、/loginのページに遷移してもトップページにリダイレクトされることを確認してください。

まとめ
Remix-authよりも柔軟に認証・認可の開発を進めたい場合は、Luciaに加えて、osloやarcticなどのOAuth2.0ライブラリや認証周りのユーティリティを合わせて実装するのがおすすめです。

これらのプロセスを通して、RemixとLucia Authを組み合わせてGoogleログインを実装する方法を解説しました。この記事が、今後RemixとLucia Authで認証を実装したい方の参考になれば幸いです。


Remix、Lucia Auth(v3)、Cloudflare D1を使ってGoogleログインを実装してみた

こんにちは！クラッソーネでエンジニアをしている町田です。
前回のテックブログ投稿（<a href="https://tech.crassone.jp/posts/useful-pathpida" target="_blank" rel="nofollow noopener noreferrer">pathpidaをSapper(Svelte)で使ってみた</a>）から2年と数ヶ月ほど経っており、かなり長い間投稿できずにいたのですが、久しぶりに記事を執筆したいと思います。
今回のテックブログでは、Railsのフロントエンド開発で使用している<a href="https://stimulus.hotwired.dev/" target="_blank" rel="nofollow noopener noreferrer">Stimulus</a>を<a href="https://vitest.dev/" target="_blank" rel="nofollow noopener noreferrer">Vitest</a>でテストする方法について書いてみました。
Stimulusを選んだ理由は、HTMLに再利用可能なロジックを小さく追加でき、シームレスにHTMLとJavaScriptを繋げられる点と、RailsでJavaScriptを扱う際のデファクトスタンダードになりつつあるためです。一方、Vitestは実行速度が高速で、Stimulusと同様に現代のテストフレームワークのデファクトスタンダードになっているため、採用しました。
今後Stimulusを使っていきたい方や、Stimulusのテストコードを書きたい方の参考になれば幸いです。
※ VitestやStimulusについての詳細な説明はこの記事では行いませんので、公式ドキュメントや他の参考記事を参照してください。
<h2 id="%E7%92%B0%E5%A2%83"><a class="header-anchor-link" href="#%E7%92%B0%E5%A2%83" aria-hidden="true"></a> 環境</h2>
使用しているライブラリについては以下のバージョンを利用しています。
<ul>
<li><code>@hotwired/stimulus: v3.2.2</code></li>
<li><code>vitest: v1.6.0</code></li>
<li><code>jsdom: v24.0.0</code></li>
</ul>
必要なライブラリをインストールします。パッケージマネージャはお好みのものに適宜書き換えてください。
<div class="code-block-container"><pre class="language-shell"><code class="language-shell">npm install @hotwired/stimulus
</code></pre></div><div class="code-block-container"><pre class="language-shell"><code class="language-shell">npm install --save-dev vitest jsdom
</code></pre></div><h2 id="stimulus%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%AE%E8%BF%BD%E5%8A%A0"><a class="header-anchor-link" href="#stimulus%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%AE%E8%BF%BD%E5%8A%A0" aria-hidden="true"></a> Stimulusコントローラの追加</h2>
以下にサンプルとなるStimulusコントローラを追加します。以下のコードはStimulusのドキュメントから引用しています。 
引用：<a href="https://stimulus.hotwired.dev/handbook/hello-stimulus" target="_blank" rel="nofollow noopener noreferrer">https://stimulus.hotwired.dev/handbook/hello-stimulus</a>
<div class="code-block-container"><pre class="language-ts"><code class="language-ts">// hello_controller.ts
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
 greet() {
 console.log("Hello, Stimulus!", this.element);
 };
};
</code></pre></div><h2 id="vitest%E3%81%AE%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97"><a class="header-anchor-link" href="#vitest%E3%81%AE%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97" aria-hidden="true"></a> Vitestのセットアップ</h2>
<code>vitest.config.ts</code>をプロジェクトディレクトリのトップに作成します。
<div class="code-block-container"><pre class="language-ts"><code class="language-ts">import { defineConfig } from 'vitest/config';

export default defineConfig({
 test: {
 // StimulusはDOMを操作するため、jsdom環境を設定します。
 environment: 'jsdom',
 // テスト対象のファイルパターンを指定します。
 include: ['src/**/*.{test,spec}.{js,ts}']
 },
});
</code></pre></div><h2 id="%E3%83%86%E3%82%B9%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E8%BF%BD%E5%8A%A0"><a class="header-anchor-link" href="#%E3%83%86%E3%82%B9%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E8%BF%BD%E5%8A%A0" aria-hidden="true"></a> テストコードの追加</h2>
次に、Stimulusコントローラのテストコードを追加します。今回は<code>HelloController</code>の<code>greet</code>メソッドが呼ばれることを確認します。
※ 以下は例としてのテストコードですので、実際のテストコードはテストしたいロジックに合わせて適宜書き換えてください。
<div class="code-block-container"><pre class="language-ts"><code class="language-ts">// hello_controller.test.ts
import { vi, describe, beforeEach, afterEach, test, expect } from 'vitest';
import { Application } from "@hotwired/stimulus";
import HelloController from './hello_controller';

describe('HelloController', () =&gt; {
 let application: Application;

 beforeEach(() =&gt; {
 document.body.innerHTML = `
 &lt;div data-controller="hello"&gt;
 &lt;input type="text"&gt;
 &lt;button id="button" data-action="click-&gt;hello#greet"&gt;Greet&lt;/button&gt;
 &lt;/div&gt;
 `;
 application = Application.start();
 application.register("hello", HelloController);
 });

 afterEach(() =&gt; {
 application.stop();
 });

 describe('#greet', () =&gt; {
 test('greetメソッドが呼ばれること', () =&gt; {
 const helloController = application.getControllerForElementAndIdentifier(document.querySelector('[data-controller="hello"]'), 'hello') as HelloController;
 const spy = vi.spyOn(helloController, 'greet');
 const buttonElement = document.getElementById('button') as HTMLButtonElement;
 buttonElement.click();

 expect(spy).toHaveBeenCalled();
 });
 });
});
</code></pre></div><h2 id="%E3%83%86%E3%82%B9%E3%83%88%E7%B5%90%E6%9E%9C"><a class="header-anchor-link" href="#%E3%83%86%E3%82%B9%E3%83%88%E7%B5%90%E6%9E%9C" aria-hidden="true"></a> テスト結果</h2>
テストがパスし、<code>HelloController#greet</code>が呼ばれていることが確認できました。
<img src="/images/posts/stimulus-testing-by-vitest/testing_result.png" alt="testing_result" />
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
今回の記事では、StimulusとVitestを使用してフロントエンドのロジックをテストするためのシンプルな環境を構築し、実際にテストコードを書くプロセスを解説しました。
Rspecに慣れている方はSystem Specでテストしてもいいですが、小さく早くテストを回したい方にはVitestでのテストコード作成をおすすめします。
Stimulusのテスト環境を構築したい方や、既存のプロジェクトに効率的なテストを導入したい方に、少しでも役立つ情報が提供できたなら幸いです。


こんにちは！クラッソーネでエンジニアをしている町田です。

前回のテックブログ投稿（pathpidaをSapper(Svelte)で使ってみた）から2年と数ヶ月ほど経っており、かなり長い間投稿できずにいたのですが、久しぶりに記事を執筆したいと思います。

今回のテックブログでは、Railsのフロントエンド開発で使用しているStimulusをVitestでテストする方法について書いてみました。

Stimulusを選んだ理由は、HTMLに再利用可能なロジックを小さく追加でき、シームレスにHTMLとJavaScriptを繋げられる点と、RailsでJavaScriptを扱う際のデファクトスタンダードになりつつあるためです。一方、Vitestは実行速度が高速で、Stimulusと同様に現代のテストフレームワークのデファクトスタンダードになっているため、採用しました。

今後Stimulusを使っていきたい方や、Stimulusのテストコードを書きたい方の参考になれば幸いです。

※ VitestやStimulusについての詳細な説明はこの記事では行いませんので、公式ドキュメントや他の参考記事を参照してください。

環境
使用しているライブラリについては以下のバージョンを利用しています。
@hotwired/stimulus: v3.2.2
vitest: v1.6.0
jsdom: v24.0.0

必要なライブラリをインストールします。パッケージマネージャはお好みのものに適宜書き換えてください。
npm install @hotwired/stimulus

npm install --save-dev vitest jsdom

Stimulusコントローラの追加
以下にサンプルとなるStimulusコントローラを追加します。以下のコードはStimulusのドキュメントから引用しています。
引用：https://stimulus.hotwired.dev/handbook/hello-stimulus

// hello_controller.ts
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  greet() {
    console.log("Hello, Stimulus!", this.element);
  };
};

Vitestのセットアップ
vitest.config.tsをプロジェクトディレクトリのトップに作成します。

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // StimulusはDOMを操作するため、jsdom環境を設定します。
    environment: 'jsdom',
    // テスト対象のファイルパターンを指定します。
    include: ['src/*/.{test,spec}.{js,ts}']
  },
});

テストコードの追加
次に、Stimulusコントローラのテストコードを追加します。今回はHelloControllerのgreetメソッドが呼ばれることを確認します。

※ 以下は例としてのテストコードですので、実際のテストコードはテストしたいロジックに合わせて適宜書き換えてください。

// hello_controller.test.ts
import { vi, describe, beforeEach, afterEach, test, expect } from 'vitest';
import { Application } from "@hotwired/stimulus";
import HelloController from './hello_controller';

describe('HelloController', () => {
  let application: Application;

  beforeEach(() => {
    document.body.innerHTML = `

        hello#greet">Greet

    `;
    application = Application.start();
    application.register("hello", HelloController);
  });

  afterEach(() => {
    application.stop();
  });

  describe('#greet', () => {
    test('greetメソッドが呼ばれること', () => {
      const helloController = application.getControllerForElementAndIdentifier(document.querySelector('[data-controller="hello"]'), 'hello') as HelloController;
      const spy = vi.spyOn(helloController, 'greet');
      const buttonElement = document.getElementById('button') as HTMLButtonElement;
      buttonElement.click();

      expect(spy).toHaveBeenCalled();
    });
  });
});

テスト結果
テストがパスし、HelloController#greetが呼ばれていることが確認できました。

testing_result

まとめ
今回の記事では、StimulusとVitestを使用してフロントエンドのロジックをテストするためのシンプルな環境を構築し、実際にテストコードを書くプロセスを解説しました。

Rspecに慣れている方はSystem Specでテストしてもいいですが、小さく早くテストを回したい方にはVitestでのテストコード作成をおすすめします。

Stimulusのテスト環境を構築したい方や、既存のプロジェクトに効率的なテストを導入したい方に、少しでも役立つ情報が提供できたなら幸いです。


Hotwire StimulusのテストをVitestで書いてみた


こんにちは！プロダクト開発部の町田です！

私事ですが、沖縄から東京への引っ越しが完了してやっと一息つきました。
デスク周りを整理するいい機会なので、新居では FlexiSpot のスタンディングデスクを新調し、4K の縦画面モニターも新しく配置しました。

ほんの少しでも開発がしやすくなるといいな〜と思ってる今日この頃です。

foreword

今回の記事ですが、フロントエンドフレームワークの Sapper(Svelte)で pathpida を使ってみた話をしていきたいと思います。

pathpida とは

pathpida は Next.js や Nuxt.js や Sapper の内部リンクを取得するためのライブラリです。

概要

各フレームワークのディレクトリによるルーティング規約に最適化されており、型安全に内部リンクを取得することができます。

pathpida を Sapper で使ってみる

前述にもある通り、今回は Sapper(Svelte)で pathpida を使っていきたいと思います。
Sapper(Svelte)は既にインストール済みの前提で進めます。

下記が、執筆時点でのバージョンです。

svelte: 0.28.0
pathpida: 0.17.0

インストール

npm-run-all もインストールします。
npm-run-all を導入することで、シンプルな記述で npm-scripts を順次・並列実行できます。
特に依存してるわけではないのですが、入れておくと便利です。

npm

npm install pathpida npm-run-all --save-dev

yarn

yarn add pathpida npm-run-all --dev

開発時に pathpida が動くように設定します

{
  "scripts": {
    "dev": "run-p dev:*",
    "dev:sapper": "sapper dev",
    "dev:path": "pathpida --ignorePath .gitignore --watch",
    "build": "pathpida --ignorePath .gitignore && sapper build --legacy",
    "export": "pathpida --ignorePath .gitignore && sapper export --legacy"
    // ...other
  }
}

以上です。
pathpida は設定なしに動作します。

あとは開発サーバーを立ち上げるだけで内部リンク取得に必要なオブジェクトが生成されます。
特に複雑な設定など要らず簡単に設定できました。

型安全に内部リンクの取得

以下のように/posts/1に遷移するリンクがあります。

  import { pagesPath } from "$path"

記事1

上の例だと、url の/posts/1が内部リンクとして適してるかどうかは型安全に判定できません。
もしroutes/posts/[id]/index.svelteというファイルが存在しなければページの遷移に失敗してしまいます。

このような内部リンクを型安全に取得し、利用できるようにしてくれるのが pathpida です。

routes が以下のようなディレクトリの場合

routes/index.svelte
routes/about.svelte
routes/posts/index.svelte
routes/posts/[id]/index.svelte

以下の TypeScript のファイルが生成されます

/* eslint-disable */

// prettier-ignore
export const pagesPath = {
  about: {
    $url: (url?: { hash?: string }) => /about${url?.hash ? #${url.hash} : ''}
  },
  posts: {
    _id: (id: string | number) => ({
      $url: (url?: { hash?: string }) => /posts/${id}${url?.hash ? #${url.hash} : ''}
    }),
    $url: (url?: { hash?: string }) => /posts${url?.hash ? #${url.hash} : ''}
  },
  $url: (url?: { hash?: string }) => /${url?.hash ? #${url.hash} : ''}
}

// prettier-ignore
export type PagesPath = typeof pagesPath

svelte で使うイメージはこういう感じです

  import { pagesPath } from "$path"

記事1

型安全に取得したオブジェクトでページ遷移ができました。

型安全なので、オブジェクトから取得できないリンクはエラーが出て気づけたり、型推論によってリンクの候補が出てくるので、候補から取得したいリンクを選択するだけでよい点も便利ですね。

オブジェクトから取得できないリンクを指定した場合
vscode_01

型推論でリンク候補の表示
vscode_02

静的ファイルのパスを型安全に利用する

--enableStaticオプションを追加してください。

{
  "scripts": {
    "dev": "run-p dev:*",
    "dev:sapper": "sapper dev",
    "dev:path": "pathpida --ignorePath .gitignore --enableStatic --watch",
    "build": "pathpida --ignorePath .gitignore --enableStatic && sapper build --legacy",
    "export": "pathpida --ignorePath .gitignore --enableStatic && sapper export --legacy"
    // ...other
  }
}

static ディレクトリが以下のような場合

static/favicon.png
static/manifest.json
static/posts/post_1.json
static/posts/post_2.json

$path.ts に以下の オブジェクトが生成されます

// prettier-ignore
export const staticPath = {
  favicon_png: '/favicon.png',
  manifest_json: '/manifest.json',
  posts: {
    post1json: '/posts/post_1.json',
    post2json: '/posts/post_2.json'
  }
} as const

// prettier-ignore
export type StaticPath = typeof staticPath

pagesPath の時と同様に自動生成されたstaticPathを利用して静的ファイルのパスを型安全に取得できます。

クエリパラメータを指定する

pathpida が生成する URL にクエリパラメータを含めたい場合は svelte コンポーネントからQueryorOptionalQuery を export すると、あとは pathpida がよしなに組み込んでくれます。

クエリパラメータが必須なページの場合はQuery、必須でない場合はOptionalQueryで使い分けます
以下がpostsページにクエリパラメータを指定する場合の例です。
Query Type を export してpostsのリンクを pathpida で取得する際にクエリパラメータの指定を行います。

  import { pagesPath } from "$path"

  export type Query = {
    page: number;
    limit: number;
  }

svelte で使うイメージはこういう感じです

	import { pagesPath } from "$path"

記事一覧

また、ドキュメントにもありますが、reference types をクエリパラメータの型に含める際は、絶対パスを利用した dynamic import を利用してください。

TypeScript の制限により、.svelte ファイルから export された型は import できないからです。

https://github.com/aspida/pathpida#warning-in-the-case-of-svelte-file-queryoptionalquery-type-must-not-contain-any-reference-types

公式にある方法とは異なりますが、私は tsconfig.json の設定を変更して path のエイリアスを登録して使う方が好みです

{
  "extends": "@tsconfig/svelte/tsconfig.json",
  "compilerOptions": {
    "lib": ["DOM", "ES2017", "WebWorker"],
    "types": ["svelte", "node"],
    "baseUrl": "./",
    "paths": { "@routes/": ["src/routes/"] }
  },
  "include": ["src//", "src/node_modules//"],
  "exclude": ["nodemodules/*", "sapper_/", "static/"]
}

export type Page = number;
export type Limit = number;

  import { pagesPath } from "$path"

  export type Query = {
    page: import('@routes/posts').Page;
    limit: import('@routes/posts').Limit
  }

ここらは各々の気に入った方法でコーディングするといいと思います。

まとめ

pathpida を使うことで静的ファイルのパスや内部リンクを型安全に取得し、ページ遷移のリンクに利用することができました！

個人的にはうっかりしたリンクのタイプミスをなくせるのがすごく助かってます。
プロジェクト内には、文字列で書かれたページ遷移のリンクがまだ複数あるので、少しずつ pathpida で取得したリンクに置き換えていこうと思います。

皆さんも是非携わっているプロジェクトに pathpida を導入してみてください！

おわりに

クラッソーネでは一緒に働くクルーを大募集してます！
プロダクトをより良いものにしたいきたいエンジニア、常に改善を続けていきたいエンジニアの皆さんからのご連絡をお待ちしております。

少しでも興味を持っていただけた方、ぜひ一度カジュアルにお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


pathpidaをSapper(Svelte)で使ってみた

こんにちは！プロダクト開発部の町田です！
つい最近 34 インチのモニターや、初のメカニカルキーボードを導入したのですが、快適にレビューやコーディングができており、とても良い買い物をしたと感じてます。
<h2 id="%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E3%81%AE%E9%81%8B%E7%94%A8%E4%B8%8A%E3%81%AE%E8%AA%B2%E9%A1%8C"><a class="header-anchor-link" href="#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E3%81%AE%E9%81%8B%E7%94%A8%E4%B8%8A%E3%81%AE%E8%AA%B2%E9%A1%8C" aria-hidden="true"></a> コードレビューにおいての運用上の課題</h2>
突然ですが皆さんはどのようなルールでコードレビューしていますか？ 
また、コードレビューでなにか課題を抱えていますか？
私が現在携わってるプロダクトでは２名以上のレビュワーから承認をもらえるとマージできるというルールにしております。
私も同僚のコードをレビューしたり、自分が書いたコードをレビューしてもらうことがありますが、レビュー依頼などコードレビューに関連する通知を稀に見落としてしまうことがありました。
GitHub のデフォルトの通知であるメールの通知だと気づけずに、確認や返信が遅れて次のアクションに移るまでのタイムロスがあり、小さいですが課題を感じていました。
クラッソーネでは、チャットの連携は主に Slack を利用しています。 
なので今回は、プルリクエスト関連のイベントがある際に Slack に通知することができる Scheduled reminders を利用してみることにしました。
<h2 id="scheduled-reminders-%E3%81%A8%E3%81%AF"><a class="header-anchor-link" href="#scheduled-reminders-%E3%81%A8%E3%81%AF" aria-hidden="true"></a> Scheduled reminders とは</h2>
Scheduled reminders は設定次第でプルリクエストに関する様々な通知をしてくれる機能です。
リアルタイムでの通知に合わせて、プルリクエストのリマインドを複数の時間を指定して設定することができます。
<h2 id="scheduled-reminders-%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9"><a class="header-anchor-link" href="#scheduled-reminders-%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9" aria-hidden="true"></a> Scheduled reminders の使い方</h2>
では実際に設定してみましょう。
Scheduled reminders には２つの使い方があります。 
それぞれ公式が丁寧なドキュメントを用意しているので参考にしてください。
<ol>
<li>Slack のチャンネルに通知をする</li>
</ol>
<iframe id="zenn-embedded__52206acd33f14" src="https://embed.zenn.studio/card#zenn-embedded__52206acd33f14" data-content="https%3A%2F%2Fdocs.github.com%2Fja%2Forganizations%2Fmanaging-organization-settings%2Fmanaging-scheduled-reminders-for-your-organization" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://docs.github.com/ja/organizations/managing-organization-settings/managing-scheduled-reminders-for-your-organization" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://docs.github.com/ja/organizations/managing-organization-settings/managing-scheduled-reminders-for-your-organization</a>
<ol start="2">
<li>Slack の DM に通知をする</li>
</ol>
<iframe id="zenn-embedded__084580f861ac7" src="https://embed.zenn.studio/card#zenn-embedded__084580f861ac7" data-content="https%3A%2F%2Fdocs.github.com%2Fja%2Faccount-and-profile%2Fsetting-up-and-managing-your-github-user-account%2Fmanaging-your-membership-in-organizations%2Fmanaging-your-scheduled-reminders" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/managing-your-scheduled-reminders" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/managing-your-scheduled-reminders</a>
<h2 id="%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F"><a class="header-anchor-link" href="#%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F" aria-hidden="true"></a> 設定してみた</h2>
Slack の DM に通知がくるように設定してみました。
現在はリマインダーを 10 時と 14 時に設定しており、滞留してるレビューはリマインダーが通知してくれるため、滞りなくレビューを進めることができそうです。
リアルタイムの通知については、レビュー依頼、レビューの承認、コードの変更依頼、コメントがあった際に Slack の DM に通知がくるようになっています。
<img src="/images/posts/github-scheduled-reminders/scheduled-reminders%E2%88%9202.png" alt="notification" />
設定するとこのような通知がきます。 
GitHub の Notifications や GitHub のスマホアプリを開いて通知を確認しなくても良いのでとても楽です！
<img src="/images/posts/github-scheduled-reminders/scheduled-reminders%E2%88%9201.png" alt="notification" />
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
今回、Slack の個人の DM に通知するリマインダーを設定して利用してみました。レビュー依頼があるとリアルタイムで通知をしてくれるため、コードレビューの依頼が見逃すことが殆どなくなりました！ 
プルリクエストのコメントも即レスできるようになり、スムーズなコミュニケーションができてると実感しています。
また、気のせいかもしれませんが、Scheduled reminders を利用してからはレビュー依頼が多くなってきている気がしています。(レビューまでの着手が早いことやスムーズなコミュニケーションができてるおかげ？)
これを機にチームの Slack チャンネルへの通知も検討して、開発フローのさらなる改善していければと思います！ 
この小さい改善の積み重ねが大きい結果を生むことを期待しています。
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB"><a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
クラッソーネでは一緒に働くクルーを大募集してます！ 
プロダクトをより良いものにしたいきたいエンジニア、常に改善を続けていきたいエンジニアの皆さんからのご連絡をお待ちしております。
少しでも興味を持っていただけた方、ぜひ一度カジュアルにお話ししましょう！
<iframe id="zenn-embedded__2fc898eb5abfd" src="https://embed.zenn.studio/card#zenn-embedded__2fc898eb5abfd" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>


こんにちは！プロダクト開発部の町田です！

つい最近 34 インチのモニターや、初のメカニカルキーボードを導入したのですが、快適にレビューやコーディングができており、とても良い買い物をしたと感じてます。

コードレビューにおいての運用上の課題

突然ですが皆さんはどのようなルールでコードレビューしていますか？
また、コードレビューでなにか課題を抱えていますか？

私が現在携わってるプロダクトでは２名以上のレビュワーから承認をもらえるとマージできるというルールにしております。

私も同僚のコードをレビューしたり、自分が書いたコードをレビューしてもらうことがありますが、レビュー依頼などコードレビューに関連する通知を稀に見落としてしまうことがありました。

GitHub のデフォルトの通知であるメールの通知だと気づけずに、確認や返信が遅れて次のアクションに移るまでのタイムロスがあり、小さいですが課題を感じていました。

クラッソーネでは、チャットの連携は主に Slack を利用しています。
なので今回は、プルリクエスト関連のイベントがある際に Slack に通知することができる Scheduled reminders を利用してみることにしました。

Scheduled reminders とは

Scheduled reminders は設定次第でプルリクエストに関する様々な通知をしてくれる機能です。

リアルタイムでの通知に合わせて、プルリクエストのリマインドを複数の時間を指定して設定することができます。

Scheduled reminders の使い方

では実際に設定してみましょう。

Scheduled reminders には２つの使い方があります。
それぞれ公式が丁寧なドキュメントを用意しているので参考にしてください。

Slack のチャンネルに通知をする

https://docs.github.com/ja/organizations/managing-organization-settings/managing-scheduled-reminders-for-your-organization

Slack の DM に通知をする

https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-github-user-account/managing-your-membership-in-organizations/managing-your-scheduled-reminders

設定してみた

Slack の DM に通知がくるように設定してみました。

現在はリマインダーを 10 時と 14 時に設定しており、滞留してるレビューはリマインダーが通知してくれるため、滞りなくレビューを進めることができそうです。

リアルタイムの通知については、レビュー依頼、レビューの承認、コードの変更依頼、コメントがあった際に Slack の DM に通知がくるようになっています。

notification

設定するとこのような通知がきます。
GitHub の Notifications や GitHub のスマホアプリを開いて通知を確認しなくても良いのでとても楽です！

notification

まとめ

今回、Slack の個人の DM に通知するリマインダーを設定して利用してみました。レビュー依頼があるとリアルタイムで通知をしてくれるため、コードレビューの依頼が見逃すことが殆どなくなりました！
プルリクエストのコメントも即レスできるようになり、スムーズなコミュニケーションができてると実感しています。

また、気のせいかもしれませんが、Scheduled reminders を利用してからはレビュー依頼が多くなってきている気がしています。(レビューまでの着手が早いことやスムーズなコミュニケーションができてるおかげ？)

これを機にチームの Slack チャンネルへの通知も検討して、開発フローのさらなる改善していければと思います！
この小さい改善の積み重ねが大きい結果を生むことを期待しています。

おわりに

クラッソーネでは一緒に働くクルーを大募集してます！
プロダクトをより良いものにしたいきたいエンジニア、常に改善を続けていきたいエンジニアの皆さんからのご連絡をお待ちしております。

少しでも興味を持っていただけた方、ぜひ一度カジュアルにお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


GitHubのScheduled remindersが便利だった話

こんにちは！ 
はじめまして、プロダクト開発部の町田です！
前書きですが、そろそろ秋・冬に向けて衣替えの季節かと思います。 
沖縄在住の私は日々の気温が未だ 30 度を超えるので衣替えするのはまだまだ先になりそうです(早く冬服着たいな...)
さて、今回は私がクラッソーネに入社に至るまでと、クラッソーネに入社して何をしているのかについて書いていきたいと思います！
<h2 id="%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B"><a class="header-anchor-link" href="#%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B" aria-hidden="true"></a> 自己紹介</h2>
まずは私のことを知ってもらいたいので、簡単に自己紹介をします
<blockquote>
<ul>
<li>1999 年 9 月 13 日生まれ</li>
<li>中学を卒業後に建築業界で働いた後、エンジニアにキャリアチェンジ</li>
<li>受託会社を経てクラッソーネに入社</li>
</ul>
</blockquote>
クラッソーネに入社する前までは主に<code>TypeScript</code>を使って Web アプリケーション開発をしてました。 
少数精鋭で開発をしており、バックエンドからフロントエンド、インフラなど色々な経験をさせていただきました。
中卒で建築業界に入り、 IT 業界へキャリアチェンジしたことについては、我ながら珍しい経歴だと思い、面接ではあえて強みとして話題にしてました！
<h2 id="%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AB%E3%81%AA%E3%82%8B%E5%89%8D%E3%81%AF%E4%BD%95%E3%82%92%E3%81%97%E3%81%A6%E3%81%84%E3%81%9F%E3%81%8B"><a class="header-anchor-link" href="#%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AB%E3%81%AA%E3%82%8B%E5%89%8D%E3%81%AF%E4%BD%95%E3%82%92%E3%81%97%E3%81%A6%E3%81%84%E3%81%9F%E3%81%8B" aria-hidden="true"></a> エンジニアになる前は何をしていたか</h2>
エンジニアとしての道をスタートする前は、建設現場で働いておりました。
毎日朝 5 時に起きて現場に出発し、現場からの帰りは 21 時以降になることが多く、毎日汗水をたらして働いていたのを今でも鮮明に覚えています。
4 年と半年ほど建設現場で働いており、現場での職長も務めるようになった頃に、エンジニアになるきっかけが訪れました。
中卒、高卒向けのエンジニアインターンの存在を知人を通して知り、ハードなものづくりから、ソフトなものづくりへの興味が湧いてきたのがちょうどこのタイミングでした。 
このインターンへの参加が自分の人生の大きなターニングポイントなると感じました。
悩んだ結果、建設業の仕事を辞めてインターンに参加すると決意しました。 
参加資格を得るために現場終わりに日々勉強していたのがとても懐かしく感じます。
努力が実ったのか、インターンの参加枠に無事選んでいただき、私のエンジニア人生がスタートしました！
<h2 id="%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AB%E5%85%A5%E7%A4%BE%E3%82%92%E6%B1%BA%E3%82%81%E3%81%9F%E3%81%8D%E3%81%A3%E3%81%8B%E3%81%91"><a class="header-anchor-link" href="#%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AB%E5%85%A5%E7%A4%BE%E3%82%92%E6%B1%BA%E3%82%81%E3%81%9F%E3%81%8D%E3%81%A3%E3%81%8B%E3%81%91" aria-hidden="true"></a> クラッソーネに入社を決めたきっかけ</h2>
入社を決めたきっかけには、大きく３つの理由がありました。
<h4 id="%EF%BC%91%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E8%87%AA%E8%BA%AB%E3%81%AE%E5%BB%BA%E7%AF%89%E6%A5%AD%E7%95%8C%E3%81%A7%E3%81%AE%E7%9F%A5%E8%A6%8B%E3%81%8C%E6%A5%AD%E5%8B%99%E3%81%AE%E4%B8%AD%E3%81%A7%E6%B4%BB%E3%81%8B%E3%81%9B%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%8B%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8"><a class="header-anchor-link" href="#%EF%BC%91%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E8%87%AA%E8%BA%AB%E3%81%AE%E5%BB%BA%E7%AF%89%E6%A5%AD%E7%95%8C%E3%81%A7%E3%81%AE%E7%9F%A5%E8%A6%8B%E3%81%8C%E6%A5%AD%E5%8B%99%E3%81%AE%E4%B8%AD%E3%81%A7%E6%B4%BB%E3%81%8B%E3%81%9B%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%8B%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8" aria-hidden="true"></a> １つ目は、自身の建築業界での知見が業務の中で活かせるのではないかと思ったこと</h4>
解体業界といえど、工事現場で働く環境は変わりません。 
自身の建築業界での経験と得られた知見から、サービスの機能開発や方針などの意思決定に関わりたいと強く思っていました。
<h4 id="%EF%BC%92%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%92%E9%80%9A%E3%81%97%E3%81%A6%E8%A7%A3%E4%BD%93%E5%B7%A5%E4%BA%8B%E7%8F%BE%E5%A0%B4%E3%81%AE-dx-%E5%8C%96%E3%81%8C%E8%A1%8C%E3%82%8F%E3%82%8C%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%80%81%E5%BB%BA%E7%AF%89%E6%A5%AD%E7%95%8C%E3%81%AB%E6%A7%98%E3%80%85%E3%81%AA%E5%BD%B1%E9%9F%BF%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B%E3%81%93%E3%81%A8%E3%82%92%E6%9C%9F%E5%BE%85%E3%81%97%E3%81%9F%E3%81%93%E3%81%A8"><a class="header-anchor-link" href="#%EF%BC%92%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%99%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%92%E9%80%9A%E3%81%97%E3%81%A6%E8%A7%A3%E4%BD%93%E5%B7%A5%E4%BA%8B%E7%8F%BE%E5%A0%B4%E3%81%AE-dx-%E5%8C%96%E3%81%8C%E8%A1%8C%E3%82%8F%E3%82%8C%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%80%81%E5%BB%BA%E7%AF%89%E6%A5%AD%E7%95%8C%E3%81%AB%E6%A7%98%E3%80%85%E3%81%AA%E5%BD%B1%E9%9F%BF%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B%E3%81%93%E3%81%A8%E3%82%92%E6%9C%9F%E5%BE%85%E3%81%97%E3%81%9F%E3%81%93%E3%81%A8" aria-hidden="true"></a> ２つ目は、クラッソーネが提供するサービスを通して解体工事現場の DX 化が行われることで、建築業界に様々な影響を与えることを期待したこと</h4>
<ul>
<li>解体工事が促進することで建設工事の仕事が増加し、建築人材の需要の増加が見込める</li>
<li>近年の IT 人材の需要の増加みたいに、建築人材の需要が高まり、建築人材の 3K(きつい、汚い、危険)などのイメージが払拭される</li>
</ul>
まだまだあると思いますが、私は建築業界にとても愛着があるため、業界人の地位向上や、楽しく安全に働ける現場作りなどには積極的に貢献していきたいと思っております。
<h4 id="%EF%BC%93%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AE%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AB%E3%82%B8%E3%83%A7%E3%82%A4%E3%83%B3%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%80%81%E8%87%AA%E8%BA%AB%E3%81%AE%E8%89%B2%E3%82%93%E3%81%AA%E5%81%B4%E9%9D%A2%E3%81%A7%E3%81%AE%E6%88%90%E9%95%B7%E3%81%8C%E8%A6%8B%E8%BE%BC%E3%82%81%E3%82%8B%E3%81%A8%E6%84%9F%E3%81%98%E3%81%9F%E3%81%93%E3%81%A8"><a class="header-anchor-link" href="#%EF%BC%93%E3%81%A4%E7%9B%AE%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AE%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AB%E3%82%B8%E3%83%A7%E3%82%A4%E3%83%B3%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%80%81%E8%87%AA%E8%BA%AB%E3%81%AE%E8%89%B2%E3%82%93%E3%81%AA%E5%81%B4%E9%9D%A2%E3%81%A7%E3%81%AE%E6%88%90%E9%95%B7%E3%81%8C%E8%A6%8B%E8%BE%BC%E3%82%81%E3%82%8B%E3%81%A8%E6%84%9F%E3%81%98%E3%81%9F%E3%81%93%E3%81%A8" aria-hidden="true"></a> ３つ目は、クラッソーネの開発チームにジョインすることで、自身の色んな側面での成長が見込めると感じたこと</h4>
クラッソーネに入社する前の選考フローにて、開発メンバーと何度か面談させていただきました。 
その中で感じた開発メンバーのプロダクトに対する熱意、チームの雰囲気の良さなどに惹かれました。 
開発メンバーは様々な業界を経験しており、色んな知見が集まった上で開発に臨めることから、「技術的にも人間的にも成長するならクラッソーネだ！」と強く思い、「一緒に働きたい」と切に思いました。
以上の事からクラッソーネへの入社を決めました。
<h2 id="%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B"><a class="header-anchor-link" href="#%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B" aria-hidden="true"></a> どんなことをしているのか</h2>
現在私がいるチームでは、解体工事会社向けに業務支援を行うためのサービスを開発しています。
バックエンドはRuby on Rails、フロントエンドはNext.js, TypeScriptで開発しています。 
Web API には GraphQLを採用しており、エコシステムも充実してきた事から、快適に開発することができています。(とはいえ課題も山積みですが...)
<iframe id="zenn-embedded__e984a962c287" src="https://embed.zenn.studio/card#zenn-embedded__e984a962c287" data-content="https%3A%2F%2Ftech.crassone.jp%2Fposts%2Ftypesafe-graphql-with-typescript-and-codegen" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://tech.crassone.jp/posts/typesafe-graphql-with-typescript-and-codegen" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://tech.crassone.jp/posts/typesafe-graphql-with-typescript-and-codegen</a>
また、技術やその基盤に関する提案・改善もチーム全体を通して頻繁に行われており、プロダクトをより良くしていこうといるメンバーが集まっております。 
頭ごなしに意見や提案が否定されることはなく、とても心理的安全性の高い環境だと感じています。
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB"><a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
クラッソーネでは一緒に働くクルーを大募集してます！
少しでも興味を持っていただけた方、ぜひ一度カジュアルにお話ししましょう！
<iframe id="zenn-embedded__7c5bf1f99b003" src="https://embed.zenn.studio/card#zenn-embedded__7c5bf1f99b003" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>


こんにちは！
はじめまして、プロダクト開発部の町田です！

前書きですが、そろそろ秋・冬に向けて衣替えの季節かと思います。
沖縄在住の私は日々の気温が未だ 30 度を超えるので衣替えするのはまだまだ先になりそうです(早く冬服着たいな...)

さて、今回は私がクラッソーネに入社に至るまでと、クラッソーネに入社して何をしているのかについて書いていきたいと思います！

自己紹介

まずは私のことを知ってもらいたいので、簡単に自己紹介をします

> - 1999 年 9 月 13 日生まれ
> - 中学を卒業後に建築業界で働いた後、エンジニアにキャリアチェンジ
> - 受託会社を経てクラッソーネに入社

クラッソーネに入社する前までは主にTypeScriptを使って Web アプリケーション開発をしてました。
少数精鋭で開発をしており、バックエンドからフロントエンド、インフラなど色々な経験をさせていただきました。

中卒で建築業界に入り、 IT 業界へキャリアチェンジしたことについては、我ながら珍しい経歴だと思い、面接ではあえて強みとして話題にしてました！

エンジニアになる前は何をしていたか

エンジニアとしての道をスタートする前は、建設現場で働いておりました。

毎日朝 5 時に起きて現場に出発し、現場からの帰りは 21 時以降になることが多く、毎日汗水をたらして働いていたのを今でも鮮明に覚えています。

4 年と半年ほど建設現場で働いており、現場での職長も務めるようになった頃に、エンジニアになるきっかけが訪れました。

中卒、高卒向けのエンジニアインターンの存在を知人を通して知り、ハードなものづくりから、ソフトなものづくりへの興味が湧いてきたのがちょうどこのタイミングでした。
このインターンへの参加が自分の人生の大きなターニングポイントなると感じました。

悩んだ結果、建設業の仕事を辞めてインターンに参加すると決意しました。
参加資格を得るために現場終わりに日々勉強していたのがとても懐かしく感じます。

努力が実ったのか、インターンの参加枠に無事選んでいただき、私のエンジニア人生がスタートしました！

クラッソーネに入社を決めたきっかけ

入社を決めたきっかけには、大きく３つの理由がありました。

１つ目は、自身の建築業界での知見が業務の中で活かせるのではないかと思ったこと

解体業界といえど、工事現場で働く環境は変わりません。
自身の建築業界での経験と得られた知見から、サービスの機能開発や方針などの意思決定に関わりたいと強く思っていました。

２つ目は、クラッソーネが提供するサービスを通して解体工事現場の DX 化が行われることで、建築業界に様々な影響を与えることを期待したこと

解体工事が促進することで建設工事の仕事が増加し、建築人材の需要の増加が見込める
近年の IT 人材の需要の増加みたいに、建築人材の需要が高まり、建築人材の 3K(きつい、汚い、危険)などのイメージが払拭される

まだまだあると思いますが、私は建築業界にとても愛着があるため、業界人の地位向上や、楽しく安全に働ける現場作りなどには積極的に貢献していきたいと思っております。

３つ目は、クラッソーネの開発チームにジョインすることで、自身の色んな側面での成長が見込めると感じたこと

クラッソーネに入社する前の選考フローにて、開発メンバーと何度か面談させていただきました。
その中で感じた開発メンバーのプロダクトに対する熱意、チームの雰囲気の良さなどに惹かれました。
開発メンバーは様々な業界を経験しており、色んな知見が集まった上で開発に臨めることから、「技術的にも人間的にも成長するならクラッソーネだ！」と強く思い、「一緒に働きたい」と切に思いました。

以上の事からクラッソーネへの入社を決めました。

どんなことをしているのか

現在私がいるチームでは、解体工事会社向けに業務支援を行うためのサービスを開発しています。

バックエンドはRuby on Rails、フロントエンドはNext.js, TypeScriptで開発しています。
Web API には GraphQLを採用しており、エコシステムも充実してきた事から、快適に開発することができています。(とはいえ課題も山積みですが...)

https://tech.crassone.jp/posts/typesafe-graphql-with-typescript-and-codegen

また、技術やその基盤に関する提案・改善もチーム全体を通して頻繁に行われており、プロダクトをより良くしていこうといるメンバーが集まっております。
頭ごなしに意見や提案が否定されることはなく、とても心理的安全性の高い環境だと感じています。

おわりに

クラッソーネでは一緒に働くクルーを大募集してます！

少しでも興味を持っていただけた方、ぜひ一度カジュアルにお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


クラッソーネ開発者ブログ

町田連が執筆した記事

ZEN大学に入学し、社会人をしながら大学生になった理由と3ヶ月経っての感想

様々な振り返りの手法を試してみた

Remix、Lucia Auth(v3)、Cloudflare D1を使ってGoogleログインを実装してみた

Hotwire StimulusのテストをVitestで書いてみた

pathpidaをSapper(Svelte)で使ってみた

GitHubのScheduled remindersが便利だった話

クラッソーネに入社しました！

町田 連が執筆した記事

ZEN大学に入学し、社会人をしながら大学生になった理由と3ヶ月経っての感想

様々な振り返りの手法を試してみた

Remix、Lucia Auth(v3)、Cloudflare D1を使ってGoogleログインを実装してみた

Hotwire StimulusのテストをVitestで書いてみた

pathpidaをSapper(Svelte)で使ってみた

GitHubのScheduled remindersが便利だった話

クラッソーネに入社しました！

町田連が執筆した記事