こんにちは！クラッソーネでアプリケーションエンジニアをしている町田です。 
今回は、これまでに試してきた様々な振り返り手法について総評をお伝えします。振り返りの進め方に悩んでいる方や、新しい手法を取り入れてみたい方の参考になれば幸いです。
<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__815331d0e737" src="https://embed.zenn.studio/card#zenn-embedded__815331d0e737" 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__c5d6c6ea5004d" src="https://embed.zenn.studio/card#zenn-embedded__c5d6c6ea5004d" 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__db8e7594044e6" src="https://embed.zenn.studio/card#zenn-embedded__db8e7594044e6" 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__eafa86c41d4a" src="https://embed.zenn.studio/card#zenn-embedded__eafa86c41d4a" 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__aecde080628fc" src="https://embed.zenn.studio/card#zenn-embedded__aecde080628fc" 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/


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

町田連が執筆した記事

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

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

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

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

GitHubのScheduled remindersが便利だった話

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

町田 連が執筆した記事

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

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

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

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

GitHubのScheduled remindersが便利だった話

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

町田連が執筆した記事