DressCodeでプロダクトエンジニアをしている@cottpanです。DressCodeでは、外部 SaaS と連携しながらユーザー・ロール・ライセンス・グループなどの情報を可視化できるソフトウェア管理というプロダクトがあります。このプロダクトでは、外部SaaSの情報を定期的に同期する処理を行っています。私たちはこの同期処理を長く Choreography型の非同期パイプラインで運用してきましたが、連携数の増加とともに限界が見えてきたため、Orchestration型へ作り直しました。本記事の「Choreography Saga / Orchestration Saga」は、制...

はじめにこんにちは。Dress Code 株式会社でプロダクトエンジニアをしている西銘です。DRESS CODEにはデバイス台帳画面があります。数あるプロダクトの中でも初期から作られ、使われてきただけに業務知識は詰まっている一方で、機能を追加するたびに別の潜在不具合が見つかる状態でした。直しても別の場所で似た問題が出るので、開発側も利用側も消耗しやすくなっていました。最初は「使いづらい UI をどう改善するか」という話だと思っていました。ですが掘っていくと、見た目や操作感よりも、現在の状態を直接編集する前提のデータ設計が実際の業務の流れとズレていることが問題でした。この記事...

Dress Code株式会社の蒲生です。DRESS CODEではStorage & Files というプロダクトを開発しています。BoxやGoogle Driveなど企業が利用しているクラウドストレージ 上のフォルダ・共有設定を組織横断で可視化し、リスクのある共有や設定を検知・修正するようなプロダクトです。本記事では、Google Workspace 全社員分の My Drive / Shared Drive を「キーレス + 組織横断」で棚卸しするために、GCP Service Account + Domain-wide Delegation + Workload Id...

はじめにこんにちは、Dress Code株式会社でプロダクトエンジニアをしているもず（@mozu1206）です。データ構造やAPI設計までしっかりやる時間はないけれど、ビジネスサイドと「作成・更新・削除まで動く画面」で会話を進めたい場面、ありませんか？AIで雑にプロトタイプを作る選択肢もありますが、本実装に入るときに全部捨てるのは、正直もったいないですよね。この記事では、フロントのみでプロトタイプを作りつつ、API繋ぎ込み時に捨てるコードを最小限にする設計（-api → -query → コンポーネントの3層構造）を紹介します。 TL;DR-api 層にデータのやりとり...

TL;DRPrismaのRawQuery / QueryBuilderがinfra層の外に漏れ出していたのをQueryService + DTOパターンに移行したQueryBuilderが返したクエリを呼び出し側が $queryRaw で実行する構造だと、意図しない拡張が可能になりinfra変更時の影響範囲も広がるCQRSの観点から参照系はQueryServiceに分離し、呼び出し元はFilterを渡してDocumentを受け取るだけのI/Fに統一した優先度判定（現在 > 未来 > 過去）とページネーションを両立させるにはSQL側で重複排除するしかないという設...

React CompilerをannotationモードとOxlintで漸進的に導入する はじめにこんにちは。ぷーじ（@yug1224）です。約7,500ファイルのTypeScriptプロジェクトにReact Compilerを導入しました。本記事では、annotationモードとOxlintで、all モードの一括適用ではなく、段階的に Compiler を広げた進め方を紹介します。 導入の背景最初は "all" モードをローカルで気軽に試してみたのですが、TanStack Table v8を使ったテーブルが軒並み壊れ、react-hook-formのフォームが無限ルー...

こんにちは。Dress Code株式会社でプロダクトエンジニアをしているぽこひで（@pokohide）です。先日、DRESS CODEのメインDBであるAurora PostgreSQLにBlue/Green Deployments(以下B/G)を採用し、v16.11からv17.9にメジャーアップデートしました。この記事では、アップデートをどのように進めたか、その過程で整えたインフラ周りの設計、そして実際にやってみた際の気付きをご紹介します。 なぜBlue/Green Deploymentsを採用したかAurora PostgreSQLのメジャーバージョンを上げる方法にはIn-...

はじめにこんにちは。Dress Code 株式会社で、プロダクトエンジニアをやっている津田です。弊社では走り始めの当初からバックエンドのORMにPrismaを採用しています。スキーマの宣言だけで型もマイグレーションも出来てしまう楽さと、凝ったことをしなければ大体のことができる表現の豊かさと型の柔軟性が特に気に入っています。つい最近RustエンジンをやめてTSネイティブのアダプタを使うようになりましたが、DBの負荷も減っていい感じです(パラメーターの調整が必要になりましたが…)PrismaとAsync Local Storageを使って、Transactionが成功したときだ...

螺旋階段のように積み上がるキャリア はじめにこんにちは。ぷーじ（@yug1224）です。2026年3月にEMConf JP 2026で、同年4月にITエンジニアの転職物語 〜EMからICへのキャリアチェンジの壁とその超え方で、いずれも同じテーマで登壇しました。資料は次のとおりです。https://speakerdeck.com/yug1224/2026-03-04https://speakerdeck.com/yug1224/2026-04-15本記事は、 主に後者のストーリー（転職物語の資料）を軸 に、登壇内容をブログ向けに再構成したものです。私自身の経験に限りますが、...

TL;DR拡張性は、パターン名より先に「誰が拡張するか（自分 / チーム内 / 第三者）」と「何を変えるか（実装を差し替える / 手順を組み替える / 参加者を足す）」の 2 軸で考えると判断がぶれにくい。実装を差し替える: 役割の interface を固定して中身を入れ替えるなら Strategy、生成判断を呼び出し側から切り離すなら Factory Method / Abstract Factory、処理の骨格を固定して一部のステップだけ差し替えるなら Template Method。手順を組み替える: 同じ interface を保ったまま外側から責務を足すなら De...

はじめにDress Code 株式会社のかわうそです。今回は、フロントエンドとバックエンドの型共有に OpenAPI（コード生成）を使っていた構成から、oRPC を導入した話を紹介します。!この記事は「バックエンドの実装から OpenAPI スキーマを生成し、そこからフロントエンド用の型をコード生成する」という構成が前提です。OpenAPI 自体を否定するものではなく、コントラクトファーストで OpenAPI を正として運用するアプローチなど、OpenAPI の活用方法は他にもあります。 技術スタックこの記事で登場する主な技術スタックです。レイヤー技術...

はじめにこんにちは、Dress Code株式会社でプロダクトエンジニアをしているもず（@mozu1206）です。テーブルの実装って結構面倒なことありませんか？一覧性が高いページなので、後からカラムが増えたりセルの中身が変わったりってしがちですよね。ただこの要望の度に、バックエンドから返すデータを変え、フロントエンドでカラム定義の変更・セルのコンポーネント作って…とするのは地味にしんどいと思います。そこで本記事では、台帳画面（一覧テーブル）を Server-Driven UI（SDUI）に作り変え、バックエンドの変更のみでテーブルのカラム増減や権限による表示制御を可能にした実...

TL;DR はじめにこんにちは、Dress Code でプロダクトエンジニアをしている ないとー です！私たちは DRESS CODE という、人事・情報システム・総務・採用など複数の部門を横断する業務 OS として機能するコンパウンドプロダクトを開発しています。DRESS CODE では、各組織が CSV などのファイルをアップロードすると、バックエンドのバッチ処理基盤が非同期でデータ変換・取り込み処理を行います。この基盤は AWS Batch on Fargate で動いており、S3 へのファイルアップロードをトリガーに EventBridge 経由でジョブが起動する...

こんにちは。Dress Code株式会社でプロダクトエンジニアをしているぽこひで（@pokohide ）です。試写会が当たったので一足先にプラダを着た悪魔2を観に行ってきました 👠 試写会って当たるんですね。Dress Code株式会社は、2024年9月に設立された、人・採用・総務・IT などの領域を統合管理するワークフォースマネジメントプラットフォーム「DRESS CODE」を開発・提供する企業です。マルチテナントSaaSアーキテクチャでは、システムを、テナント向けの機能とビジネスロジックを担う Application Plane と、テナント管理や横断的な運用に使う Contr...

Cursorを使い始めてから、もう「AIなしで開発してた頃どうやって生きてたんだろ」状態になっている。コード補完もリファクタも、もはや当たり前すぎて逆に感謝も忘れてきた。で、そうなると欲が出てくる。「ブラウザ側もAIに任せられんの？」 これ、地味にずっとつらかったやつCursorで書いたコードを検証するとき、毎回こういう作業が発生する。管理画面開いてテストユーザーをポチポチ作るフォーム送信を何パターンも繰り返す「APIのレスポンスがUIに反映されてるか」を目で確認する頭使わない。でも飛ばせない。「Cursorがコード書いてくれてるなら、ブラウザ操作も誰かに投げたい」...

はじめにこんにちは。Dress Code 株式会社で、プロダクトエンジニアをやっている津田です。仕様駆動開発を始めて 4 ヶ月ほど経過したので、改めて振り返ってみるべく記事に残してみています。今回の対象読者は次に列挙するような方々を想定しています。とりあえず試して実感してみたい人プロセスが重そうで踏み出しきれない人現場での工夫・実践知を知りたい人本記事がこれらの方の一助になれば幸いです。正直、仕様駆動開発自体の合う合わないは組織の規模やプロダクトの性質、開発スタイルに強く依存すると考えています。参考程度に弊社の情報を軽くお伝えすると、次のようになっております。...

はじめにDress Code 株式会社のかわうそです。Dress Code には Permission & Roles（権限 & ロール）という、プロダクトを横断した共通基盤の一つとして権限管理機能があります。この機能では、プロダクトごとへのアクセス制御、管理者側と従業員側の権限の分離、Core DB（詳細は割愛）で定義された項目に対する権限設定などができます。この権限管理機能を拡張していく中で、「そもそも初期状態の権限ってどうあるべきなんだっけ？」という悩みがありました。たとえば、新しく 1 つの項目を追加したときに、その項目の閲覧・編集を初期状態から許可し...

はじめに突然ですが、Dress Code 株式会社ではつい先日コードレビューの負荷軽減を目的として Greptile を導入しました。Graphベースでコードのコンテキストを持ってくれているのでそれなりに精度が高く、学習させることで継続的に改善できる点が気に入っています。ただ、一つだけ困った点があって、使用量を制限する仕組みがないんです。Greptileの料金体系はざっくり以下のようになっています。月に1ユーザーあたり 50レビューまでが基本料金に含まれる超過分は 1レビューあたり$1の従量課金つまり、誰かがガンガンPRを出してレビューを回すと、知らないうちにコス...

はじめにDress Code 株式会社のかわうそです。今日はとある記事をきっかけに、AI時代における設計やアーキテクチャで大事なことについて考えてみたので、その内容を共有したいと思います。!破壊性（Destroyability）と回復性（Recoverability）という言葉は僕が勝手に定義した言葉です。他に良いネーミングがあれば、コメントいただけると嬉しいです。 TL;DR 気になったきっかけ最近、とある記事を見かけました。https://aicoding.leaflet.pub/3mbaguyrjek2gこの記事の中で紹介されている"Mutable C...

TL;DR はじめにこんにちは、Dress Code でプロダクトエンジニアをしている ないとー です！私たちは DRESS CODE という、グローバル向けの Workforce Management プロダクトを開発しています。DRESS CODE では、日本、タイ、ベトナム、インドネシア、シンガポールなど各国の拠点から業務データが CSV でアップロードされます。エンコーディングは拠点ごとにバラバラなため、ICU プロジェクトの文字検出アルゴリズムをベースにした node-chardet でエンコーディングを検出し、iconv-lite で UTF-8 に変換する...