justInCase Technologies

作ったもの自分がメンテナンスしているjackson-module-kotlinと、その実験機能を試験するためのプロジェクトであるjackson-module-kogeraのベンチマークプロジェクト…

GitHub Actions + Googleスプレッドシートでベンチマークを管理する

やりたいことビルド時にgradleから値を埋め込んだKotlinファイルを生成し、それをソースとして扱います。実際に生成したかったのは、以下のようなファイルです。文字列で設定されている"2.1…

【Gradle】gradleから値を埋め込んだファイルを生成し、ソースとして扱う【Kotlin】

やることGitHub Actionsで、qaブランチに変更が有った時に、developブランチへの同期PRを発行します。この記事で紹介する方法ではbaseブランチが新しく作成されるため、主要なブ…

【GitHub Actions】ブランチ間に差分が有った時に同期pull requestを発行する（baseブランチは新しく作成する）

やること「$n$人のメンバー表から順番に今日の当番を割り当てる（ただし休日はスキップする）」ようなシートを作成します。サンプルは以下にアップロードしてあります。ローカルにコピーし、メンバー部分…

【GAS無し】Googleスプレッドシートで毎日の担当者を自動で割り当てるシートを作成する

この記事はSpring Advent Calendar 2022の20日目の記事になりました。qiita.com前書きこんにちは、justInCaseTechnorogiesでバックエンドエンジニアをしている宮田です。Spring WebFlux(Kotlin Coroutines) x R2DBCのマルチモジュールプロジェクトで、Row Level Securityを有効にし、かつ効率的に開発を行うための基盤を作成しました。技術スタックPostgreSQL 13SpringBoot 2.7.3Kotlin 1.7.10Row Level Securityについて本題に入る前に、Row Level Security（以降RLSと記載）について軽く解説します。RLSは、簡単に言うと、識別子が一致しない行へのアクセスをDB側で禁止する機能です（DB側の機能であるため、この機能を提供していないDBでは利用できません）。これは、例えばSQLに渡す条件を取り違えたり、where句を付け忘れてしまった場合などに役立ちます。fun findFooBy(fooId: Int): Foo { /* 何らかのクエリ処理 */ }fun processFoo(fooId: Int, barId: Int) {    val foo = findFooBy(barId) // 渡すIDを間違えた！！    /* 取得できてしまうと処理は継続される... */}このような場合に、間違えた条件の先にデータが存在していると、そのデータが破壊されたり、不正なデータが画面に表示されたりといった事象が起きます。一方、RLSを適用していれば、A社のデータはB社から取得できないため、このようなバグを作り込んでしまった場合にも問題の影響範囲を限定することができます。アプリケーション側の実装についてここからは、クライアントからのリクエストを処理する一連の流れを紹介します。説明内では、RLS用の識別子を単にIdentifierと表現します。基本方針シンプルな対応方針としては、以下のように、Identifierを引数として引き回し、クエリ発行時にそれぞれ設定する形も考えられます。import io.r2dbc.spi.ConnectionFactoryimport kotlinx.coroutines.reactive.awaitSingleimport org.springframework.r2dbc.connection.ConnectionFactoryUtilsimport org.springframework.stereotype.Repositoryimport reactor.core.publisher.Monoimport reactor.kotlin.core.publisher.toMono@Repositoryclass Repository(private val cfi: ConnectionFactory) {    // コネクション発行 -> クエリ処理    suspend fun query(identifier: String) {        ConnectionFactoryUtils.getConnection(cfi)            .flatMap { connection ->                connection.createStatement("SET app.current_identifier = $1")                    .bind(0, identifier)                    .execute()                    .toMono()                    .thenReturn(connection)            }            .map { /* identifier設定後のコネクションを利用したクエリ処理 */ }            .awaitSingle()    }}一方、このやり方には以下のような欠点があり、何千と機能を作っていく上では良いやり方とは言えません。処理が非効率になる特にORMを利用する場合、発行したコネクションから一々初期化処理を行わなければならないTransaction中など、1度発行したコネクションを使い回す場合には、Identifierに関するクエリを何度も発行することになり非効率全体的な記述が冗長になる全クエリ処理にIdentifierの設定処理を書く必要が出る全関数に引数としてIdentifierを設定するのは大変Identifierが処理に必須とは限らないため、RLSのために全体で引き回すことには違和感が有るそこで、基本方針としてはRLSが設定されていない場合と同じ見た目になる（= 日常的なコーディングを行う上での労力が最低限になる）形を目指しました。基本的な処理の流れ基本的な処理の流れは以下のようになります。これらの基盤を実装することで、日常的に触れるコードではRLSが設定されていない場合と同じ見た目を実現できます。スコープ内で利用するIdentifierをReactor Contextにセットする1でセットしたIdentifierをReactor Contextから読み出す2で取得したIdentifierをコネクションにセットするモジュール配置としては、2と3は共通モジュールに、1はモジュール毎に個別の内容を配置する形になります。以下、基本的な処理の流れに沿ってそれぞれの部分を紹介していきます。1. スコープ内で利用するIdentifierをReactor Contextにセットするスコープ内で利用するIdentifierをReactor Contextにセットする際には、WebFilterを利用します。Identifierを読み取り、Reactor Contextにセットするコードは以下のようになります。import org.springframework.core.Orderedimport org.springframework.core.annotation.Orderimport org.springframework.stereotype.Componentimport org.springframework.web.server.ServerWebExchangeimport org.springframework.web.server.WebFilterimport org.springframework.web.server.WebFilterChainimport reactor.core.publisher.Monoconst val IDENTIFIER_KEY: String = /* Identifierを管理するためのキー、 */@Component@Order(Ordered.LOWEST_PRECEDENCE) // 認証周りより後に実行するため、順序は最低にするclass SetIdentifierFilter : WebFilter {    // リクエストのヘッダーからIdentifierを抽出する関数    private fun ServerWebExchange.getIdentifierFromHeader(): String =        request.headers.getFirst(IDENTIFIER_KEY)!!    override fun filter(exchange: ServerWebExchange, chain: WebFilterChain): Mono<Void> {        val identifierMono: Mono<String> = Mono.just(exchange.getIdentifierFromHeader())        return chain.filter(exchange).contextWrite { it.put(IDENTIFIER_KEY, identifierMono) }    }}filter関数をJWT認証のトークンから読み出す形に修正した場合は以下のようになります。import org.springframework.security.core.context.ReactiveSecurityContextHolderimport org.springframework.security.oauth2.server.resource.authentication.JwtAuthenticationToken    /* class SetIdentifierFilter...は省略 */    override fun filter(exchange: ServerWebExchange, chain: WebFilterChain): Mono<Void> {        return chain.filter(exchange).contextWrite { context ->            // ReactiveSecurityContextHolderはchainに連なる処理内でなければ正常に値を読み出せない            val identifierMono: Mono<String> = ReactiveSecurityContextHolder.getContext().map {                (it.authentication as JwtAuthenticationToken)                    .token                    .getClaimAsString(IDENTIFIER_KEY)            }            context.put(IDENTIFIER_KEY, identifierMono)        }    }以下、これらのサンプルコードに関して解説していきます。セットする内容についてサンプルコードではMono<String>をセットする形に統一しています。ReactiveSecurityContextHolder.getContextに連なる処理で得たMono<String>をStringにアンラップしてセットする方法が思いつかなかったためです。これについては多くの部分で問題になりませんが、どちらかと言えばStringをセットできた方が嬉しい部分がありますので、分かる方がいらっしゃいましたらコメント頂けると助かります。Reactor Contextへのアクセスに関する注意点Reactor Contextは非リアクティブプログラミングにおけるThreadLocalのようなもので、リクエスト単位で固有の値を設定・読み出すことができます。projectreactor.ioただし、WebFilter内でReactor Contextにセットされた値を読み出す機能を利用する場合は、必ずchainに連なる処理の中で呼び出す必要があります。contextWrite内で呼び出しているReactiveSecurityContextHolder.getContextがそれです。これは、WebFilterのReactor Contextとchain内のReactor Contextが異なるために必要な対応です。Reactor Contextにセットされた値を読み出したい場合は、chainに連なる処理の中で呼び出す必要があります。認証等の情報から読み出す場合の注意点他のWebFilterによってセットされる値（特に認証周りなど）からIdentifierを参照したい場合が有ります。SetIdentifierFilterは他のWebFilterが設定された後に実行される必要があります。OrderアノテーションでSetIdentifierFilterの実行が最後になるよう制御しています。2. 1でセットしたIdentifierをReactor Contextから読み出す1でセットしたIdentifierをReactor Contextから読み出すコードは以下のようになります。import kotlinx.coroutines.reactive.awaitSingleimport org.springframework.stereotype.Componentimport reactor.core.publisher.Mono@Componentclass IdentifierGetter {    // Identifier取得の共通関数    // 有効なスコープ内で実行すればIdentifierが取得できる（コンポーネント内に配置しているのはモックの都合）    fun getIdentifierMono(): Mono<String> = Mono.deferContextual {        it.get<Mono<String>>(IDENTIFIER_KEY)            .onErrorMap { e -> RuntimeException("コンテキストからIdentifierが取得できませんでした", e) }    }    suspend fun getIdentifier(): String = getIdentifierMono().awaitSingle()}コメントの通り、Component化している理由はモックを容易にするためで、基本的にはトップレベルにも配置できる内容です。Coroutineで書かれている場合にも、これらのコードは機能します。読み出し処理に関する注意点この読み出し処理はReactor Contextに対して行われるため、Reactor Contextが異なっていたり、Reactor Contextにアクセスできない場所から呼び出すと正常に機能しません。前者は、例えば共通処理を別Coroutine Scopeで実行したような場合に問題となります。Reactor Contextの値を引き継ぐことで対処できます。qiita.com後者はReactorを利用していない・Reactive Streamsのみ利用している外部ライブラリに連なる処理で実行されたような場合に問題となります。jOOQがこれに当たります。qiita.com3. 2で取得したIdentifierをコネクションにセットするIdentifierをコネクションにセットする際は、ConnectionPoolのpostAllocateを利用するのが楽だと思います。R2dbcConfigurationは以下のようになります。import io.r2dbc.pool.ConnectionPoolimport io.r2dbc.pool.ConnectionPoolConfigurationimport io.r2dbc.spi.ConnectionFactoriesimport io.r2dbc.spi.ConnectionFactoryimport org.springframework.boot.autoconfigure.r2dbc.R2dbcPropertiesimport org.springframework.boot.context.properties.ConfigurationPropertiesimport org.springframework.context.annotation.Beanimport org.springframework.context.annotation.Configurationimport org.springframework.data.r2dbc.config.AbstractR2dbcConfigurationimport reactor.kotlin.core.publisher.toMono@Configurationclass R2dbcConfiguration(private val identifierGetter: IdentifierGetter) : AbstractR2dbcConfiguration() {    @ConfigurationProperties("spring.r2dbc")    @Bean    fun r2dbcProperties(): R2dbcProperties = R2dbcProperties()    @Bean    override fun connectionFactory(): ConnectionFactory {        // URL にユーザー名とパスワードが含まれてないと接続ができない        val defaultConnectionFactory = ConnectionFactories.get(r2dbcProperties().url)        val config = ConnectionPoolConfiguration.builder(defaultConnectionFactory)            .postAllocate { connection ->                identifierGetter.getIdentifierMono()                    .flatMap {                        connection.createStatement("SET app.current_identifier = $1")                            .bind(0, it)                            .execute()                            .toMono()                    }                    .then()            }            .build()        return ConnectionPool(config)    }}application.propertiesのspring.r2dbcの下にはurlプロパティのみ設定している想定です。spring.r2dbc.url=r2dbc:postgresql://${ユーザー名}:${パスワード}@localhost/${DB名}この設定を行なったConnectionPool（ConnectionFactory）から発行されるConnectionは、アプリケーション内では常に適切なIdentifierが設定された状態になります。終わりにこの記事では、Spring WebFlux x R2DBCのマルチモジュールプロジェクトでのRLS基盤作成についてまとめました。弊チームが開発を行なっていた時点では、Spring WebFlux x R2DBCでRow Level Securityを有効にする例は世界的に見ても少なく、実装時点ではサンプルコードも中々見つけられない状況でした。jOOQ固有の問題でハマったりと、多くの苦労が有りました。同じような構成での開発を行う方へ、この記事が何かのお役に立てば幸いです。justInCaseでは、さまざまな職種を採用中です。Spring WebFluxを用いたバックエンド開発をやってみたい方大歓迎です！justincase.jp

Spring WebFlux・R2DBCのマルチモジュールプロジェクトでRow Level Security基盤を構築した話

こんにちは。justInCaseTechnologies の web frontend engineer の kondei です。当社は今 "joinsure" という SaaS 型保険システムを開発中です。チームは Systems of Record, Systems of Engagement という区分を参考にして大きく "record" と "engagement" に区分しています。そのうちの契約管理などの部分を担当する record チームの最近の開発体制についてご紹介します。アジャイル × スクラム開発導入まで導入にあたって実践してみての工夫効果DDDドメインコンテキストマップドメインモデル図アクティビティ図状態遷移図bitemporal data model参考文献OpenAPI, スキーマ駆動の API 開発参考文献ADR(Architecture Decision Record)参考文献デザイン開発における Figma の活用デザイン開発におけるコンポーネント指向開発チームのエンジニア全員でエンジニア採用に関わる状態終わりにアジャイル × スクラム開発導入までjoinsure 以前の開発はハッキリ言って「なんちゃってアジャイル」な部分があり、明確なフレームワークに沿っていませんでした。それによってミーティングが少なかったり機動力があったりするというメリットはありましたが、感じていたデメリットとしては、以下のようなものがあります。タスクを頼んだと思っていた人と、頼まれたと思っていない人の認識の齟齬があることがあるしばらく経つと、誰がボールを持っているのか、何によって待ち状態になっているのか分からないことがある期間も進捗も分からないことがあるゴールが明確でないときがあるjoinsure プロジェクトが明確に立ち上がるとき、開発体制をどうするかコアメンバーで議論しました。そのとき草案としては既存のオリジナル体制の発展型が提案されており、ウォーターフォール型となんちゃってアジャイルの混ざりあったような状態が想定に入っていましたが、 「既知のプラクティスであるアジャイル × スクラム開発手法に従った方が良い」という議論の結果、導入が決定されました。他の手法ではなくこれを選んだ理由としては、以下の通りです。教科書や実践記事が豊富である他のどの手法と比べても劣らないくらいメジャーであるはずウォーターフォール開発は評判が悪い上に、米軍においても失敗とみなされてアジャイルが義務化されたとのこと導入にあたって導入にあたっては、まずアジャイルソフトウェア開発宣言アジャイル宣言の背後にある原則スクラムガイドをチームメンバー全員で読むことでマインドセットと方法の認識合わせをしました。ツールは BizDev, PdM, designer, engineer全員で YouTrack を使用しています。また、アジャイルの流儀の 1 つである、インセプションデッキを作成しました。最近では「何を諦めるのかはっきりさせる」ページの優先度調整が現実に合わせて更新されたりして、全員の方向合わせに有効活用されています。インセプションデッキ実践してみての工夫プロジェクト状況に応じて適宜イベントのタイムボックスを調整しています（スプリント期間を 2 週間 → 1 週間 → 2 週間で調整したり、内容が減ってきたらミーティングを短くしたり）スプリントレトロスペクティブは KPT 法で実施しており、なるべく改善案・next action を決めるようにしています社内ドキュメントに「スクラムを始めるときに読んでおくと良いもの」というページを作って、参考文献をまとめていますSlack にアジャイルスクラムの話をするためのチャンネルを作っています効果導入によって、以下の効果があったと感じています。スプリントの導入によってゴールが明確に共有されるようになった誰が何をしているのかわかるようになった短い締切の繰り返しが生まれることによって、意欲が向上したデイリーやスプリントプランニングによって、計画の見直しがしやすくなったengagement チームの開発にも導入されて、会社全体として IT 開発の素地が整った良い開発体制を持ったことで、採用上も訴求力が上がった各チームを超えた会社全体の体制として「大規模スクラム(LeSS )」を見据えることができるようになったDDDドメインコンテキストマップドメインコンテキストマップ幅広い保険業務を扱う SaaS の開発のために、BizDev がドメインコンテキストマップを作成して、大まかな区分けと依存関係を認識共有しています。また、個人的に良いと思うところは、このマップに対し、バックエンドのサービス区分・フロントエンドの機能区分をほぼ一致させることができていることです。ドメインモデル図ドメインモデル図ドメインモデル図をクラス図の形式で書き、ドメイン知識のメモ書きを付記して、PdM とエンジニアで共同管理しています。目的としては、全員のビジネスの想定を揃えることと、バックエンドのドメイン層実装のために使います。変更があるときは随時議論したり、スプリントレビューで全員に共有されています。アクティビティ図アクティビティ図同様にPdMがアクティビティ図を使ってシステム間に跨ったビジネスのフローを定義・管理しています。状態遷移図状態遷移図「契約」「請求」など、状態がある概念に対しては状態遷移図を作って状態とイベントを定義しています。これは以下の役に立っています。PdM とエンジニアで明確に認識を合わせることバックエンドもフロントエンドも状態変更操作や用語を正確に図に従って実装すること状態遷移に伴う UX や用語の改善議論また、これを作る文化が根づいたことで、メンバーが仕様定義の時点で「これは状態遷移がある概念かどうか。状態とイベントを定義した方が要件定義しやすいかどうか」という判断ができるようになったと感じています。bitemporal data model保険の業務では契約やお金の絡むイベントを厳密に扱う必要があったり、特定の日時のデータを出力する必要があったりします。つまり「データによっては任意時点のイベント・状態を後から復元できる必要がある。どう保持するか？」という課題があります。それに対して、チームメンバー主導で bitemporal data (model)というデータモデルの導入が提案され、ハンズオンが開催されてチームで勉強して、バックエンドのデータモデルに導入されました。参考文献https://en.wikipedia.org/wiki/Temporal_databasehttps://martinfowler.com/articles/bitemporal-history.htmlhttps://speakerdeck.com/f440/implementing-command-history-and-temporal-accesshttps://speakerdeck.com/wata727/after-the-practice-of-bitemporal-data-model-in-smarthrSQL:2011 https://www.dummies.com/category/articles/sql-33608/https://qiita.com/masakinihirota/items/c232832bd72ae11905e7OpenAPI, スキーマ駆動の API 開発APIスキーマから自動生成したドキュメントjoinsure 以前の API 開発と利用では以下のペインがありました。API 定義が手動生成になっており、ドキュメントの更新漏れ等が発生するAPI ドキュメントと実装の差分がわからない、検知できないクライアント側の API モデル（型）とコードが手動生成になっていて乖離やコーディングコストで開発効率が悪いので、自動生成したいAPI 定義がサーバーサイド主導になっており、クライアントサイドが API に対する議論への参画がしづらいことを、スキーマファーストで解決したいそれに対して OpenAPI のスキーマ駆動開発と、コードとドキュメントの自動生成を導入し、ペインがほぼ解消できました。参考文献https://logmi.jp/tech/articles/324190ADR(Architecture Decision Record)技術選定の議論と理由を残すため、バックエンド・webフロントエンド共に技術選定ドキュメントに ADR が導入されています。ADRをレビューフローに乗せることで合意を得る意思決定プロセスが明確になり、リポジトリに残ることで新入社員も経緯を追いやすくなります。参考文献https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.mdhttps://github.com/joelparkerhenderson/architecture-decision-record#suggestions-for-writing-good-adrsデザイン開発における Figma の活用デザイン面の開発は Figma を活用し、以下の流れとなっています。BizDev, PdM がワイヤーフレームを作成し、デザイナーとブラッシュアップ（場合によってはエンジニアとも議論）デザイナーがワイヤーフレームから実装用デザインを作成し、BizDev, PdM, フロントエンドエンジニアとブラッシュアップフロントエンドエンジニアが実装ワイヤーフレーム実装用デザインこれによって以下の効果がありました。PdMの意図するUXから乖離しにくいUX改善や変更の議論が活発になったデザイン開発におけるコンポーネント指向開発これまでの課題として、複数のプロダクトで同じようなデザイン定義とその実装が再作成されている状態がありました。それを解決する手法として、デザインの時点でコンポーネント指向で定義し、実装もコンポーネント単位で再利用できるものを作っています。コンポーネント指向デザインまた、最近では Chromatic というサービスを導入してコンポーネントのVisual Regression Testで差分の検知をできるようにして、品質を高めています。チームのエンジニア全員でエンジニア採用に関わる状態エンジニア採用において、人事メンバー主導で数ヶ月前に「スクラム採用」という手法が導入されました。エンジニア採用のために「採用 weekly」や「転職ドラフトもくもく会」などの定期イベントが設定され、基本的にエンジニアメンバー全員が候補者を探して判断するようになり、開発上求める人員の話・採用活動上の課題・面談や面接やツール利用方法の改善点などが議論されるようになりました。これによって採用という業務が「人事や一部の人だけが関わるもの、通常メンバーにとって新入社員はいつの間にか降ってくるもの」というような状況から、「チームで一緒に働きたい人を主体的に見つけて判断し、やり方自体を改善していく」という状況に変わりました。開発体制がスクラム化したこともあり、人事面もスクラム要素が取り入れられたのは相性がよい体制と感じています。終わりにjustInCaseTechnologiesでは常に現状の改善を進めており、新たな開発メンバーも募集しています。この記事で少しでも働くイメージが湧いたら嬉しいです！ご応募お待ちしています。

joinsure recordチームの開発体制

こんにちは、justInCaseTechnorogiesでバックエンドエンジニアをしている宮田です。Server-Side Kotlin Meetup vol.2へ「jackson-module-kotlinを読もう!」というタイトルで登壇してきました。 speakerdeck.comServer-Side Kotlin MeetupについてServer-Side Kotlin Meetupはsmartroundとマネーフォワード、及びjustInCaseが中心となって開催している、サーバーサイドKotlinに特化した勉強会です。OSSコントリビュータも登壇する勉強会となっています。第3回は6月16日開催予定で、弊社からは吉本が登壇予定です。Kotlinの導入話まで幅広い発表が聞ける勉強会となっておりますので是非ご参加ください！server-side-kotlin-meetup.connpass.com二部として登壇者や参加者とコミュニケーションの取れる懇親会も有りますのでそちらも是非！！

Server-Side Kotlin Meetup vol.2へ登壇しました

こんばんは、justInCaseTechnologies CTO の大畑ですTech Team Journal にて、株式会社デジタルハーツ CTO 城倉氏との対談記事を掲載いただきました。ttj.paiza.jp色々と書いていただきましたが、当社の魅力としては以下な感じです ✨レガシーなイメージの保険業界だが、モダンな技術・手法を積極的に取り入れている優秀なメンバーが集っており、チーム主体で提案・意思決定している事業と開発が一体となったスクラムで、プロダクトを作っている当社にご興味を持っていただけた方は、まずはお話できると嬉しいです 😄Twitter や Meety でも、お気軽にご連絡ください！もちろん、転職意欲がなくても大丈夫ですjustincase.jp

Tech Team Journalにて、対談記事を掲載いただきました

こんにちは。justInCaseTechnologiesのwebフロントエンドエンジニアのkondeiですこの度、当社は Vercel Pro から Enterpriseプランへと変更しました差分は Pricing – Vercel の表にある通りですこれから検討している方に参考になりそうな情報としては、契約締結に向けたメールのやり取りについて、こちらからは日本語で書いて送信できた日本語ができる方によるサポートを受けれているOnboarding Support (Training sessions and shared Slack channel with a dedicated Customer Success Manager.) とあるように、slackによるサポートがあるただし詳細は契約内容によるがありますまた、メンバーのohataさんと協力して作った導入申請書の一部を公開します（サービス比較など、不完全な部分も多いですが）要点としては、メンバーを増やせるということ、SLAがあるということがポイントでしたこういう作業で個人的に印象が深かったのは、非エンジニアに対して必要性が分かりやすい稟議を出すために、工数をどれくらい削減するか見積もるという視点が得られたことでした導入したいサービス・ツール概要現状、Webフロントエンド ホスティングサービスとして、Vercelを利用している。現状のProプランは、10人までしか使えない。Webフロントエンドエンジニアの増強に伴い、Enterpriseプラン変更をしたい。導入の目的・解決したい課題Webフロントエンド エンジニアの生産性の向上AWSエンジニアに頼らず自律して開発を進められる or （AWS特有の）インフラ管理・キャッチアップの工数を減らすPreview を提供するための、デプロイ管理する工数を削減できる各案件・商品に対して、Preview を迅速・並行して提供することで、社内外の確認を円滑に実施できるNext.js の開発元として安定している、管理・構築が不要Webフロントエンドエンジニアが使いやすい、ドメイン管理機能がある商品ごとにLPのサブドメインを分けるなど、自律して対応できるWebフロントエンドエンジニアが使いやすい、アクセス保護機能があるAWSLambdaなどで、Basic認証の実装・連携が不要EnterpriseだとSSO Protectionも選べて、チームの大規模化に伴うパスワード共有の煩雑さを解消しやすいWebフロントエンドエンジニアが使いやすい、サーバーレスファンクション機能があるAWS Lambda のキャッチアップ、構築・運用、管理工数が不要ちょっとしたAPIを実装できる横断的に挟みたい処理を実装できるnext.jsのmiddlewareがvercelだとサーバーレスファンクションに乗るので楽に利用できるweb frontendフレームワーク最大シェアのNext.jsの開発元としてその機能を完璧にサポートし、継続的により良い機能を取り入れられる分離されたインフラでさらなるビルド速度、実行キュー待ちの削減Vercelで、Webフロントエンドエンジニア or SRE の工数を、6時間/人月 以上 は 削減している※ 削減できる工数に加え、そこから生み出すクリエイティブに、より価値がある現状のプランのままだと、10人までしか使えない。現状10人利用しており、更にWebフロントエンジニアが数人入社する（やりくりが限界）コミットのAuthorが Vercelのmemberである必要があるデプロイ時の担当者がボトルネックor切り替え工数がかかる当社は自律したプロダクトチームを推進、MoveForwardでフルスタックな関わりを推奨しているVercel 以外のものに移行するにも工数はかかるので、Vercelのプランを変更するのが良い。事業継続・事故防止・損失回避SLA 99.99% を保証する （ 現状のプランのままだと、SLAがない ）各チームの然るべきメンバーが常に利用できる状態にしておくことで、万が一の対応にも備える。導入にかかるコスト費用契約に関わるので秘匿工数・スケジュール感導入そのものにコストは掛からない（プラン変更のみ）Enterprise契約の締結なので、段取りに1-2ヶ月かかる英文契約書のレビュー・締結などWebフロントエンドエンジニアがジョインする時期までにはプラン変更をしたい検討した選択肢要件・比較ポイントNext.js 機能のサポートサイトパフォーマンスの上げやすさ管理工数（CI/CD連携、ビルド など構築、そのキャッチアップ）その他、生産性に寄与する機能VercelProsnext.js機能のサポート ◎ （開発元）サイトパフォーマンスの上げやすさ ◎CDN edgeに配置されるhttps://speakerdeck.com/takefumiyoshii/nextjs-make-the-web-faster のように次世代のreactパフォーマンスについて設計されている管理工数 ◎その他、生産性に寄与する機能  ◎Consコスト ○コストパフォーマンスは有るAmplify並の細かい設定はない複数環境ビルドには若干準備が必要参考各種フレームワークのサポートにより、next.js以外もデプロイしやすいhttps://vercel.com/docs/concepts/deployments/build-step#framework-preset実際、rinseではnext.js非採用で使っているSWCやmonorepoのビルドツールであるturborepoを取り込んでいるなど、生産性改善への取り組みが進んでいるhttps://vercel.com/blog/vercel-acquires-turborepoSWCなど重要なOSSの作者を雇用しているのでエコシステムの先行きが明るいhttps://nextjs.org/blog/next-11-1#adopting-rust-based-swchttps://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelteserverless-nextjs を使ってAWSによしなに配置Prosnext.js機能のサポート ○サイトパフォーマンスの上げやすさ ○Lambda@Edgeに配置されるので良いと思われるが、AWSの使い方によるCons管理工数  ×githubと連携してpreviewする方法などは不明なんやかやで勉強と手間がかかることは間違いないその他、生産性に寄与する機能  ×参考https://www.serverless.com/blog/serverless-nextjs/https://qiita.com/fumiki/items/5f4408ce844520a922c2AmplifyとかS3とかに配置ProsコストConsnext.js機能のサポート ×dynamic routingやSSRのような、staticで済まない機能が必要になった場合に対応できないサイトパフォーマンスの上げやすさ△AWSの使い方による管理工数 ×Amplifyはビルドが保留のまま止まることがそこそこ多く不安定で支障が出ることがあるキャッチアップが難しいその他、生産性に寄与する機能 ×AWSとしてはある、キャッチアップなどが必要参考EC2にnode serverとして配置ProsNext.js 機能のサポート ○SSR, ISRなどの基本機能は使えるがvercel + nextで楽に使えることが前提の機能は厳しいと思われるCons管理工数（CI/CD連携、ビルド など） ×仮想サーバー管理コストがかかるし、CI/CD を自前で頑張ることになるその他、生産性に寄与する機能 ×参考netlifyProsNext.js 機能のサポート ○管理工数（CI/CD連携、ビルド など） ○その他、生産性に寄与する機能 ○Cons参考https://www.netlify.com/blog/2020/05/04/building-a-markdown-blog-with-next-9.4-and-netlify/できるけどあえてnext.jsを開発してるところと違う会社のjamstackにする必要がないセキュリティ・リスク都合上内容は割愛その他、リスク・注意事項都合上内容は割愛

Vercel Enterprise 導入しました

justInCaseTechnologies、ソフトウェアエンジニアの小笠原です。2022年1月7日に、社内で「GraphQLハッカソン」を開催しました。会社初の試みであり、準備期間も短かったのですが、概ね好評のうちに1日を終えることができました。チームが成長し続けるための一つのアイデアとして、ここに共有させていただきます。ハッカソン集合写真背景justInCaseTechnologiesでは現在、保険業界特化SaaS「joinsure」の様々な機能を開発しています。そうした中で適切な技術選定のためのインプットとすべく、チームでGraphQLについて学ぶ機会がほしい、という声がきっかけでした。イベント内容開催までハッカソンを開こうというアイデア自体は2021年の9月ごろからありました。社内でGraphQLハッカソンを開くことについて、Slackの投稿話が本格化したのは年末になってからです。私達はスクラムで開発を進めているのですが、年末年始にスプリント外の期間を設け、そこでハッカソンを開いてはどうか、というアイデアが生まれました。そこからは急展開で、ハッカソンの形式・内定者への招待・社内での告知などが全て1〜2週間の内に行われました。イベント当日ハッカソンには、joinsure Engagementチームの1名を除く全員と、joinsure Recordチームの1名、さらに内定者が1名の合計6名が参加しました。個人とチームどちらの参加にするか悩みましたが、2名1チームとして合計3チームを完全にランダムに作りました。これはコミュニケーション促進の面でも、審査時間の短縮の面でも良かったと思います。朝9時に集合し、自己紹介とチーム分けのあとは17時までひたすら開発タイムでした。ちなみに、ミーティングやお客様対応がある人は途中で出たり入ったりが可能になっています。開発形式はどのチームもペアプログラミングで、コミュニケーション手段は内定者がいることもありGoogle MeetのBreakout Roomを活用して行われました。審査17時の開発終了後、CTOやPdMも集まっての発表・審査タイムがありました。面白かったのは、3チーム中2チームがTwitterライクなWebアプリを作ったことです。TwitterライクなWebアプリTwitterライクなWebアプリ2いずれもツイートやリプライ、ライクができる、1日で作ったとは思えないクオリティでした。実はある意味合っていて、参加者の何名かは事前にボイラープレートを作っていました。勉強も目的なので、当然アリです！ちなみにボイラープレートはこちらです。github.comgithub.com発表後は審査タイムがありました。ちなみに、審査基準は以下のとおりです。発見があったことGraphQLのドキュメントを深く読み、みんなが気づかなかった仕様を知っていることエコシステムをよく調査し、便利なライブラリを見つけたことEngagementでの使用を見据えて、いい感じのユースケースを思いついていることetc...サービスがイケてること実際に動くこと審査の結果、フルスタックのボイラープレートを自作して参戦したやる気モリモリのメンバーと3月入社の内定者のチームが優勝しました！作成したのはTwitterのクローンで、リプライやライクができるなど、本物そっくりでした。1日で作成したとは思えないクオリティでした👏ふりかえりハッカソンの後はふりかえりを行いました。1日を振り返って思いついたことを、FUN, DONE, LEARNのベン図に分類して記述していきました。FUN DONE LEARN普段の開発とは違った環境で、集中できた＆学びになった、という意見が多く寄せられました。実際に発表中は驚きの声やツールの紹介などの知見共有も多くあり、開発工数の1日を使ってイベントを開いた意味が十分あったと考えています。まとめチームで勉強する時間がほしい！という意見から始まり、この度業務時間を使ったハッカソンを開くことができました。チームが成長するためには、先を見据えた勉強が絶対に必要です。忙しい開発と勉強とを両立するための手札の一つとして、ハッカソンを加えることができました。最後にjustInCaseでは、保険SaaS「joinsure」を一緒に開発するメンバーを募集しています！このブログの投稿を見て、良い組織だな、と思った方、まずはお話してみませんか？こちらからご連絡お待ちしております🙏justincase.jp

【開催報告】justInCase社内でGraphQLハッカソンを開催しました

ソフトウェアエンジニアの @xhiroga です。2021年9月39日、AWSの数多のカンファレンスで最も開発者に特化した AWS Dev Day Online Japanに登壇してきました。[AWS CDK] 1,000+のCloudWatch Alarmsを自動生成する技術TL;DR応援してくださった皆様に感謝登壇をネタに様々な人と繋がれたこれまでのAWS CDKに関するLTの集大成Twitterの反響・よいアンケート結果応援してくださった皆様に感謝AWS Dev Day Online JapanはCFP制で、一般人気の高いセッションが採用される仕組みでした。Twitterのお知り合いの皆様やそうでない方にも「見たい！」との反応をいただけたのが、今回の機会につながったと考えています。ありがとうございました！良いものをお届けできたでしょうか？登壇をネタに様々な人と繋がれたAWS CDKに関する登壇であったことから、周囲の知見のある方にレビューや練習を申し込ませていただきました。また、資料レビューにはAWS CDKユーザーとして大先輩（とこれまで勝手に尊敬していた）のtmkさんにもご協力いただきました。本当にありがとうございました！これまでのAWS CDKに関するLTの集大成実は今回初出のネタは多くなく、私のCDKに関するLTの集大成だったりします。Twitterの反響・よいアンケート結果登壇中・登壇後にTwitterで知らない方（でもCDK Loverの方）と繋がれるのが登壇の魅力だな、と思っています。登壇後しばらくして事務局からアンケートもいただき、詳細は共有できないものの（私だけで）累計数百人のオーディエンスがいたとのことでした。初めての数でびっくりしています。（Startup Architecture of the Year 2019も 50~200人くらいだった気がするので（目測）、それよりも多い人数でした）まとめいろんな方の応援のおかげで、得難い経験をさせてもらいました。面白いSREの仕事をしたい！という方はこちらからご応募お願いします🙏

AWS DevDay Online 2021登壇のご報告

ソフトウェアエンジニアの @xhiroga です。保険SaaS joinsureのプロダクトを新規開発するにあたって、チケット管理ツールを再選定したので記録に残します。網羅的とは言い難いですが、多少なりともお役に立てば幸いです。結論YouTrack, ClickUpともにプロダクト開発に十分利用できるYouTrackはデータ構造が、ClickUpはWebベースのUXが勝る複数人・複数チームでの開発ではYouTrackが、小規模開発ではClickUpが向いていると判断した前提joinsureの開発はスクラムで行っています。さらに言えば、バックオフィスではAsanaを使っており、これを統一したい思いもありました。また、justInCaseは（主にWeb版のUXの悪さを理由として）過去にJiraからYouTrackに移ってきた経緯がありました。したがって、メンバーがストレスなく使えることは強く意識していました。比較YouTrackとClickUpを、それぞれ1年/半年利用して感じたPros/Consです。YouTrackProsデータ構造が優れている。具体的には、プロジェクトとボードの関係性が1:1ではなく、1:Nである。Jiraなどではどんなボードを見たいかを考えてからプロジェクトの単位を考える必要がありましたが、YouTrackではボードに表示するチケットが所属するプロジェクトをクエリで指定できます。プロジェクト設定で余計に悩むことが減り、ありがたいです。全体的に柔軟なカスタマイズが可能。プロジェクトに任意の型の属性を追加したり、ダッシュボードやレポートを作成したり、スプリントの期間を自由に指定できたり、等々。JavaScriptライクな記述ができる、柔軟なワークフローCons設定が柔軟すぎて、初心者がプロジェクトを設定すると何かしら間違いが起きる。例えば、権限の設定ミスでボードが見えなくなる事故が年に3回くらい起きる。ちょっとしたサービス間連携にもスクリプトを書かされる。いまどきSlack通知やGitHub連携はWeb画面からポチッと設定できて当然だが、(一部例外はあるが)JavaScriptを書かないといけない。ネイティブアプリがありえないくらい使いづらい。もっさりしている上に必要なボタンが探しづらいUI/UX。ClickUpPros開発者向けツールと一般的なタスク管理ツールのいいとこ取りといった印象Web画面のUI/UXがよい。チケットの編集ひとつとっても、YouTrackに比べて表示が大きく、操作がしやすい。繰り返しタスクも作れるので、営業やバックオフィスの人にも使ってもらえるかも。2017年の創業だけあり、Webサービス間連携はコンソールからポチで可能。SlackやGitHubを始め、グローバルなWebサービスなら一通り揃っている印象。ゲストを招待できる。例えば特定のボードに対して、社外の人に参照権限を渡すことが出来る。比較サイトでのレビューが圧倒的に良いG2 Crowdでレビュー数が約100倍あり、レートもYouTrackに勝っている。単なる人気ではなく、開発者以外でも使える間口の広さが反映されていることは考慮すべき。Consプロジェクトとボードが紐ついており、例えばチケットをスプリントに移動すると、元々どのプロジェクトに紐ついていたかわからなくなってしまうこれにより、プロジェクトをエピックやユーザーストーリーに見立てる運用ができなくて辛い。2021年現在、同時編集にバグがある。正確なことは不明だが、複数人で編集していると操作（チケットを完了にする、スプリントを閉じる、など）が何度やっても反映されないことがあるこれがスクラムイベント中に多発するので本当に困るチケット番号が数字ではないため、GitHubの機能でチケット番号をリンク化することができない。評価両方ともいいところと悪いところがハッキリしており、（いいとこ取りのツール出てこないかな...）と本当に思いました。笑結論justInCaseでは久しぶり(1年ぶりは当社では久しぶりです)のチケット管理ツールの見直しでしたが、YouTrackを続投する、という結論にいたり、そのようにチームメンバー・他チームの皆さんにも共有した次第です。一方、チケット管理ツールのような激戦区のSaaSでもこれだけ改善できるポイントがあるのだな、と、今回比較して少し意外な気持ちになりました。保険業界のSaaSともなれば、改善すべきことは山積していますね！justInCaseではツールへのこだわりのある素敵なメンバーを大募集しています。なにかのご縁ですので、ぜひ一度お話できれば幸いです🙏

チケット管理ツール再考察 YouTrack vs ClickUP

バックエンドエンジニアのOsanoです。5月18日にCoral Capital様主催のスタートアップ開発しくじり先生LTに登壇しました。関連リンク登壇資料主催のCoral Capital様の記事LogmiTech様に掲載された記事

スタートアップ開発しくじり先生LTに登壇しました

justInCaseTechnologies (以下、JICT) のエンジニアの kondei です当社のテックブログを設立したので、その目的と、廃墟にならず運営するためにはどうすればよさそうか考察したので記事にしてみます現状エンジニアの採用に苦労しているそもそも応募者が少ない気がしている社員のイベント登壇や社員が書いた記事などの情報が集約されておらず、散逸していて探せない状況になっている社員のツイートなどはあるが流れていってログとしての機能が弱い採用上の問題の仮説JICTのエンジニアが何をやっているかわかりづらいし、技術力やメンバーのブランド力による訴求力が弱いので応募に至らない潜在的候補者がいるのではないかJICTのコーポレートサイト が必要最低限で、情報がないし正直技術力も感じさせないので応募に至らない潜在的候補者がいるのではないかJICTが保険システムを提供している少額短期保険会社であるJICのコーポレートサイト は内容が充実しているが、 justInCaseTechnologies で検索すると上のが最上位にヒットするので、応募を考えた方はそちらを見ることも多いはずJICのコーポレートサイト のデザインに合わせることができていない（2021年9月時点）ので困惑を生んでいる可能性があったまた、コロナ前は在職者が候補者と一緒に飲みに行って親密度を高めることがあったけど、今はご時世的に無いので、上記のようなオンライン情報の重要度が少し上がってるのではないか残念ながらこれらを直接検証する方法はないものの、議論の中で「採用候補者の方にアンケートして、どの情報が良かった・もっと欲しい情報が何か　などの情報を集める」ことはできるという話が上がったため、余談ですが それも派生して行うことになりました対策として考えたことJICTエンジニアに関する集約された情報がないことへの対策何らかのサービスを用いてテックブログを作る（低〜中コスト）コーポレートサイトにテックブログの仕組みを実装する（高コスト）結論として、低コストな外部サービスでテックブログを試しに作ってみることにしました後述するかなりの懸念はありましたが、対策は講じる上で、廃墟になったら閉じるということも視野に入れて、試すことを優先しましたJICT側のコーポレートサイトがイケてないことへの対策コーポレートサイトを作り直す（中〜高コスト）いっそコーポレートサイトを消す（低コスト）場合によってはテックブログに会社情報を移転？結論として、JIC側と違ってJICT側のサイトはまだレガシーなコードベースになっているので、組織だって対策することは一旦保留になりましたしかし当社の Otani がデザインを一致させる改修をしたことで、混乱を生むデザインの違いは解消されました足りない部分があれば改修を続けるようにはしたいと思いますテックブログをどうすれば続くのかについて考察以下、テックブログに関してのみ記述しますテックブログを廃墟にせず運用することを考えるにあたって、次の記事は大いに参考になりましたnote.com共感した部分を引用すると採用担当1人ではできず、協力を仰いだ数名でも続かない。全社的に巻き込まないと達成されないや「会社を盛り上げるために協力してくれ」で始まったブログは多く見ましたが、概ね最初の一ヶ月盛り上がって終わります。私が観察した範囲では、下記の要素のうち2項目くらい揃ったら直ちに危篤状態になります。・編集長が居ない／転職する・誰がいつ投稿するか決めない、スケジュールがない、締切がない・濃密すぎる文章チェック・法務チェック・（上記とは逆に）チェックが皆無で内容がしょぼく、社内外にディスブランディングとなって「投稿したら負け」という雰囲気になる・（ヘッドハンティング対策で）完全匿名にする・業務時間外に書かせる・PV、LGTM、応募者などKPIを設ける・社内に称える文化がない・他職種から遊びに見えるような立て付けがありますそれに対する対策を考えたものが以下になります低コストなものをなるべく書くイベント登壇ログを簡単な文章で投稿「○○が○○に登壇しました 」発表資料も置いときたいQiitaとかZennに書いた技術記事（not 義務）があれば、リンクを簡単に投稿「○○が技術記事を投稿しました https://~~ 」ADR書いたら投稿社内向けに作ったのを転記するだけなら低コストのはず高コストなものは義務化しないよくある（会社の名を背負っての）気合の入った技術記事当然運用上は歓迎だが、義務にはしないいつ、誰がやるか明瞭にする最初は定期ブログ会（月1,2回で、1回15分とか）でネタを話して執筆担当者を決める事を考えましたしかし全員を巻き込みたいのに全員の入ったミーティングを作ることは無理というジレンマから、以下のようなSlackメンションを2週間に1回飛ばすことでスレッドで話す運用にしました@エンジニア全員へのメンションテックブログのネタ出しのリマインドです書きたい/書きます/自分のコレどう？/他人のアレどう？　というネタがあればスレッドに記載・相談してください例）• 技術記事• Qiitaなど外部に書いた記事へのリンク• 登壇・発表の記録、発表資料• ADR• 開発環境やツールなどエンジニア的ネタ記事は随時基本的に自由に書いていいので、書いた記事の事後報告も歓迎ですその他特定の誰か（テックブログ発足を推進した自分とか、CTOとか、テックリード達とか）の意欲や頑張りに依存しない体制にする業務であるという意識を共有する書くことにインセンティブが生じるようにする技術記事であれば、筆者名（ハンドル名）を明示することで個人の技術的経歴が増えるようにする発信したら評価になるようにするコーポレートサイトからリンクするまた、当社の Ogasawara から寄せられた面白い案としては以下のものがありました個人が書いたものに、当社の求人を載せるというのはどうか？逆に言えば、求人を貼るのであれば休日や朝晩に書いた記事であっても稼働を請求して良いものとする。会社がなくなった時に記事がなくなるリスクもなくせる。終わりに当社ではエンジニアが個人的に記事を書いたり発表したりすることは既に行われていますしかしそれを集約した場が無いと、発見されず勿体ないという思いが僕にはあります運用は変わっていくかも知れませんが、テックブログによって当社のエンジニア組織や技術力の魅力がより多く伝わるようになれば良いなと思いますまた潜在的な候補者だけでなく、営業の際の技術上の訴求力向上にも繋がると良いなと思います