はてなブックマーク

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

執筆プラットフォーム: Zenn 19本 / note 6本 2024年9月に設立し、2025年4月に正式創業したDress Code。創業初月アドベントカレンダー（21本）に続く、2度目の挑戦でした。創業1年目にして25日間を完走できたのは、チームの発信力と技術への情熱があってこそです。 2025年のカレンダーの見どころ 創業1年目のリアル 組織づくり、採用、オンボーディングなど「人」にまつわる記事が7本。入社1週間から2ヶ月半、1年と、様々なフェーズのメンバーがそれぞれの視点でDress Codeを語っています。 アーキテクチャへのこだわり 認証基盤、データモデリング、設計パターンなど「構造」に関する記事が最多の8本。「なぜこの設計にしたのか」「どんな選択肢を検討したのか」という思考プロセスが見えるのが特徴です。 ライフスタイルへの拡張 技術だけでなく「家を建てる」「壁をDIYする」と

はじめに こんにちは。ぷーじ（@yug1224）です。 Dress Code Advent Calendar 2025 25日目の記事です🎄 この記事では、業務でのプロダクト開発のことではなく、プライベートでAIを活用して子ども部屋の間仕切り壁をDIYした話をお届けします。 「DIYやりたいけど、設計とか材料選びとか難しそう…」と感じている方に、AIと一緒なら意外とできるよ！とお伝えできれば幸いです。 なぜ子ども部屋に間仕切りが必要になったか 我が家には子どもが3人いるのですが、子どもたちも成長してきて「自分だけのスペースが欲しい」という声が上がるようになりました。 とはいえ、壁に穴を開けたり大がかりなリフォームをするのは大変です。そこで思いついたのが、LABRICO（ラブリコ）を使った間仕切り壁のDIYです。 ラブリコなら突っ張り式で天井と床を傷つけずに柱を立てられるので、手軽に設置で

※ 2025年7月1日〜12月時点のデータ（GitHub MCPツールにて集計） 弊社チームメンバーが書いた記事によると、Dress Codeでは1年間でリポジトリ規模が合計約130万行に成長し、年間3,900件以上のPRがマージされているそうです。 この圧倒的なスピード感の中で振り落とされず、ついていけるようになったのは大きな成長でした。 やりきったと感じた瞬間 フロントエンドからバックエンドまで一気通貫でプロダクトリリースをやりきった時、ようやく「人並みに成果を出せるようになった」と感じました。 具体的には、2025年10月にリリースした「ネットワーク管理/Networks」のプロダクト開発を担当しました。 今見ると改善したいところがたくさんありますが、リリースまで持っていけたこと、チームのスピードに追いつけたこと、他のメンバーのフォローなく完遂できたことが自信につながりました。 アン

はじめに こんにちは。ぷーじ（@yug1224）です。 Dress Code Advent Calendar 2025 24日目の記事です🎄 フロントエンド・バックエンド開発において、リンター、フォーマッター、型チェッカーはコード品質を担保する上で欠かせないツールですよね。しかし、プロジェクトの規模が大きくなるにつれ、これらのツールの実行時間がCI/CDのボトルネックになることがあります。 私たちのプロジェクトはTypeScriptファイルだけで1万ファイル以上という規模であり、まさにこの問題に直面していました。 今回、Rust製の高速ツールチェーンであるoxc（Oxidation Compiler） と、TypeScript公式のTypeScript Native Preview（tsgo） を導入することで、CI時間を大幅に削減しました！ この記事では、導入の背景、実際の改善結果、そ

TL;DR はじめに こんにちは、プロダクトエンジニアをしているもず（@mozu1206）です。 本記事は、Dress Code Advent Calendar 2025 の 20 日目の記事です。 10 月に Dress Code に入社し、約 3 ヶ月が経ちました。 以前記事に書いた通り、毎日新しい学びがあり非常に刺激的な日々を過ごしております。 フロントエンド専任から、プロダクトエンジニアになったことで、インフラとバックエンドも業務の中で触る機会が増えました。 これまでのキャリアの大半がフロントエンドをメインとしており、インフラやバックエンドは業務としてガッツリ触れる機会が多くなかったため、急速な知識のインプットとアップデートが求められています。 以前かわうそさんの記事でも触れられていましたが、まさに 「強制成長」 させてもらっています笑 そのおかげもありこの 3 ヶ月で下記のような

TL;DR はじめに この記事は Dress Code Advent Calendar 2025 の 19 日目の記事です。 こんにちは、Dress Code でプロダクトエンジニアをしている ないとー です！私は DRESS CODE という、人事、情報システム、総務、採用、コーポレートなど、複数の部門を横断する業務 OS として機能するコンパウンドプロダクトを開発しています。 このようなプロダクトを開発していると、「詳細画面」を作る機会がやたらと多いことに気づきます。従業員のプロフィール、勤務地となる拠点の情報、導入している備品の管理情報など、扱うドメインが広いからこそ詳細画面の数も自然と増えていきます。これは DRESS CODE に限った話ではなく、EC サイトなら商品詳細・注文詳細・顧客詳細、CRM なら取引先・案件・担当者、プロジェクト管理ツールならプロジェクト・タスク・メンバ

Dress Code Advent Calendar 2025 の 13 日目の記事です。 遅刻です。 TL;DR はじめに：この記事で伝えたいこと この記事では、O11y / SREの一般論や文化論はあんまりしません。 「実務で障害調査が進まない理由」と「どう計装設計に落とすか」 を、デバイス棚卸しレポートのドメインイベントを題材に、具体的な設計・実装パターンとして書きます。 なお、内容は試行錯誤中のものとなっています。 この記事のゴール 「計装を始める上で最初に整理するべきもの」と「実装パターン」など具体的な話で盛り上がりたい 前提：プラットフォームとドメインの二層構造 本記事で扱うシステムは、以下のような構造を持っています： プラットフォーム層：ワークフロー実行、タスク管理、状態遷移を司る共通基盤 ドメイン層：デバイス棚卸し、入社手続きなど、業務固有のロジック この二層構造が、後述す

はじめに Dress Code Advent Calendar 2025 の 15 日目の記事です。 Dress Code 株式会社で、プロダクト開発しながらアーキテクト、組織設計、採用、技術広報などなど担当しているかわうそです。 今日は「履歴」というデータを取り扱うことために考えていること・戦い方について整理してみたので、その内容を共有したいと思います。 履歴のデータはとても重要になる場合があり、履歴管理や監査証跡、時点復元、法令対応などで「過去の状態を正確に残したい」という要件が発生することがあります。 概要 「状態（Current State）」の保存は一見シンプルだけど、履歴要件が入ると破綻しやすい Bi-temporal は強力な設計手法だが、クエリ・運用の複雑さが課題になりやすい Event Sourcing は「変化（イベント）」を中心に据えることで、履歴が自然に残すことがで

はじめに Dress Code Advent Calendar 2025 の10日目の記事です。 GitHub Actionsは非常に便利なCI/CDツールですが、プロジェクトが成長するにつれて、GitHub-hosted runnersだけでは対応しきれない課題に直面することがあります。 本記事では、AWS上にSelf-Hosted Runnerを構築し、CI/CDパイプラインの高速化とコスト最適化を実現した取り組みについて紹介します。同様の課題を抱えている方の参考になれば幸いです。 背景・課題 私たちのプロジェクトでは、GitHub-hosted runnersを使用する中でいくつかの課題が顕在化していました。 リソース不足 プロジェクトの規模が大きくなるにつれ、ビルドやテストに必要なCPUとメモリが増加しました。特にNode.jsアプリケーションの大規模なビルドでは、GitHub-h

はじめに Dress Code Advent Calendar 2025の8日目の記事です。 こんにちは！ 最近、ビジネスネームを持った方が続々入社されて、自分も何か欲しいなぁと思う今日この頃です。 この記事では、 Microsoft Graph API を活用した新機能を実装する際に調査・検討した3つの認証方式について解説します。 Microsoft 365 / Microsoft Entra ID と連携する機能を開発する際、「どの認証方式を選べばいいんだろう？」と悩んだ経験はありませんか？ 実は認証方式によって、実装の複雑さ、セキュリティ、運用コスト、スケーラビリティが大きく変わってきます。 この記事では、それぞれの認証方式の特徴、適したユースケース、そして実装のポイントを詳しく解説します。 公式ドキュメントも充実してる Microsoft Graph API ですが、解釈に自信を持

Dress Code Advent Calendar 2025、2日目の記事です🎉 私がgit worktreeを使うに至るまでの話と、worktreeを使う際のおすすめのツールを紹介します。AI系の話はしません。 よろしくお願いします！ はじめに。 「タイトル盛りすぎだろw」と思われそうですが、DRESS CODE（弊社が展開しているSaaSの名称）の直近1ヶ月のPR数を確認したところ、なんと350件以上がマージされていました。 現在は2チーム体制で開発を行なっており、コードレビューはチーム内でクロスレビューで行なっています。そのため、自分の実装タスクを進めながらも、並行して大量のPRのレビューリクエストが飛んできます。 検証や提案のためにローカルでブランチをチェックアウトし、また自分の作業ブランチに戻りと繰り返し、気がつけばローカルにはアクティブなブランチが5個も10個も溜まっている

TL;DR 約600ファイル、5,000箇所への中国語追加を「工程分割 + AST 解析」により計6時間（実装4時間、実行2時間）で完了 AI にファイル単位で処理させると無駄な再計算が発生して非効率だったため、「抽出」「翻訳」「適用」の3工程に分割し AST 解析で効率化を実現 この手法の鍵は「コンテキストの制御」で、適切な粒度で問題を分割し AI に必要最小限の情報だけを渡すことで処理速度と精度を最大化できる はじめに こんにちは、DressCode でプロダクトエンジニアをしているないとーです。 この記事では、AI だけでは解決できなかった大規模コード変更を、AST（抽象構文木）解析によって効率化した実践例を紹介します。同じような課題に直面しているエンジニアの方々の参考になれば幸いです👋 背景 私たちは DRESS CODE という、Workforce Management 領域の

こんにちは、Dress Code でプロダクト開発に奮闘中のかわうそです。 今回は、DDD（ドメイン駆動設計）や Event Sourcing における集約について整理してみます。 Dress Code でも DDD や Event Sourcing を採用しているのですが、日頃の会話で”集約”というワードを使いながらも適切に使えているのか怪しいときがあるなぁと思い始めたので、整理がてら記事にしてみます。 DDD における集約ってなんだ？ AI の回答 ドメイン内のエンティティ（Entity）と値オブジェクト（Value Object）のクラスター（グループ）で、ビジネスルールに基づいて一貫性を保つための単位です。これにより、ドメインの整合性を守りながら、システムの複雑さを管理します。 トランザクションの境界を定義し、外部からのアクセスを制限することで、データの不整合を防ぎます。集約は「原

はじめに こんにちは。ぷーじ（@yug1224）です。 最近、Dress Code株式会社に転職し、5年ぶりにEM（Engineering Manager）からIC（Individual Contributor）、つまり1人のプロダクトエンジニアに戻ったので、その決断の背景と現在の状況を共有します！ ちなみに転職活動の話はこちらのPodcastでもしているので、良かったら聞いてみてください！ なぜEMからICへ戻ろうと思ったのか？ これまで経験してきた会社は規模の大きい会社も多く、もともといつかはアーリーのスタートアップに挑戦したいと思っていました。しかし、実際に自分で手を動かす開発の現場からはしばらく遠ざかっていたため、その夢は諦めかけていました。 そんな中、AIの登場とVibe Codingの流行があり、AIの伴走があればブランクがある自分でもまたICに戻れるのではと考えたのがきっかけ

「mise」ってすごい使いやすいんですよ。 miseとは GitHubリポジトリの説明書きに 「dev tools, env vars, task runner」 と書かれているrust製のcliツールです。 この記事ではmiseヘビーユーザーの私が推したい生産性の上がる機能を紹介するので、miseを初めて知った人も、知ってるけど使ってないって人も、ぜひ一読してみてください。 ちなみに最近話題になりやすいAIツールのcliパッケージなどもmiseで管理できたりします。 推したい機能はこれです！ ① タスクランナー（私が推したい機能No.1） 私はmiseにおいてはタスクランナーが一番便利な機能だと思っているので最初に紹介します。 タスクランナーはmise.tomlによく使うスクリプトをタスクとして定義しておいて、mise runコマンドで実行する機能です。 ※設定ファイルはグローバルで有効

はじめに こんにちは、ふるしょうです。 DRESS CODEは画面数が既に200を超えており、新規機能開発や既存機能の拡張が目まぐるしく進んでいます。 デザイントークンやタイポグラフィをデザインシステムとして運用していますが、画面内のレイアウトや複合コンポーネント、共通UIコンポーネントがFigmaのデザインデータと微妙に「ズレ」ていることが課題になってきています。(絶賛解消に向けて試行錯誤中🔥) 今回は、デザインデータとUIのズレを解消する手段として、2025年6月4日にベータリリースされたFigmaのDev Mode MCPサーバーとCursorを活用して既存画面のUIメンテナンスに取り組んだ事例について紹介します。 TL;DR Dev Mode MCPサーバーと Cursor を連携し、デザインデータと実装 UI のズレを爆速で修正 17ファイルをCursorとペアプロしながら約3

はじめに Dress Code株式会社で直近HR Forceの開発をしている、ふるしょうです。 HR領域のSaaSは、複雑なフォームの機能要件が伴うことが少なくありません。 例えば、入社手続きにおける家族情報の登録など、動的フィールドの表示/非表示や編集制御、複雑な依存関係を持つ計算フィールド、再起的な階層構造、同一ページ内に複数の独立したフォームインスタンスが存在する場合の適切な状態管理が必要になります。 弊社では、このような複雑なフォーム要件に対応するため、Zustand と React Context を組み合わせたアーキテクチャパターンを採用し、開発を進めています。 本記事では、この組み合わせを前提に、DRESS CODEで取り入れているデザインパターンの具体例と設計内容について紹介します。 TL;DR Zustand + React Context パターンにより、コンポーネント

はじめに CursorのようなAIのコードエディタがめちゃくちゃ進化してきている、こんな時代だからこそ静的型付け言語、特に厳格な静的型付け言語であるRustとの相性が良いのでは？という話をポエム的に書いてみます。 この記事ではあえてRustに特化して比較や検討をしているのは、個人的な好みの問題です笑 今の現場では静的型付け言語であるTypeScriptを使っているけど、厳格な静的型付け言語ではないし、実装されているコードも現場や人によって異なることが多くて、AIと共創していくことを考えたときにベターな言語があるんじゃないかって思ってつらつら書いてみます。 （TypeScriptって本当に十人十色なコードができてしまうから悩ましいw） 一方で、TypeScriptは型安全じゃないからすばらしいという意見もあるので、あくまでポエム的な内容であるということはご理解ください。 TypeScript

tl;dr 7ヶ月で3シリーズ8プロダクトの設計をした1人目デザイナーの奮闘 設計の速度って重要？　どう上げるのか 設計のスピードを出す方法その1：内圧を高めること 設計のスピードを出す方法その2：ドメイン知識の習得速度を上げること 設計のスピードを出す方法その3：ガードレールを敷いて道を舗装すること 7ヶ月で3シリーズ8プロダクトの設計をした1人目デザイナーの奮闘 Dress Code社では、2024年9月の設立からわずか7ヶ月で、国内外あわせて130社を超える企業に導入されています（プレスリリース）。その価値を生み出しているのは、3シリーズ8プロダクトに及ぶコンパウンドプロダクトです。ラスト1ヶ月は、2人目のデザイナーが加わりましたが、それまでは、優秀な開発チームに支えられながら、デザイナーという職種としては1人でプロダクトデザイン担当していました。 この記事では、人事、情報システム、

はじめに 4月で正式創業を迎えたDress Code株式会社で働いているかわうそです。 今回は正式創業を迎えるにあたり、コーポレートサイトを公開したのですが、 コーポレートサイトをCursorのAgent Modeを活用して、どこまで乗り切れるのか試しみました。 ということで、どんな風にトライしたのかについて簡単にご紹介します。 （ついでに、Figma MCP × Cursor Agent Modeだけでは無理でしたw多少、実装してますw） 前提 デザイン Figma フレームワーク NextJS Tailwind CSS ... ※ 開発環境構築については割愛させていただきます（環境構築もAgentでいけた説） セットアップ Project Rule ある程度のディレクトリ構成や実装方針を簡単に決めて決めておきたかったので、 まずはProject Ruleを先に作成しておきました。 Pr

はじめに この前久しぶりにSRE系のイベントに参加して、SREの匂いを懐かしんできました。 というわけでSREっぽいアウトプットしようかと。 弊社ではまだ正式ローンチ前の段階ですが、初期の段階からObservability（011y）を高める取り組みをしていて その初手として 監視ツールの導入 構造化ログ APMの導入 の３つを進めています。 ローンチ前にO11y、いる？ 初期の段階でObservabilityが必要かどうかは意見が分かれるかもしれませんが 弊社では正式ローンチ前から推し進める決定をしています。 スタートアップのプロダクトで必要なことは、なるべく早くユーザーに価値を届けることです。 価値を届ける上でプロダクトで一番重要なことは「動くこと」です。 早さを優先しすぎた結果、価値をデリバリーできないことは 作りたてのサービスを利用してくれているユーザーを裏切ってしまうことになりか