自社ブログから技術を勉強 - 2025-12-15 - 2025-12-21

1週間の記事を読んだ感想

Dress Code アドカレ2025の感想を1週間単位で書いていく。

先週分の記事

12月15日(日)から21日(土)の１週間、公開されたブログをおさらいする。

2025-12-15 : 「状態」ではなく「変化（イベント）」を保存したい｜かわうそ

• 履歴データを扱う際の設計について、テンポラルデータモデルとEvent Sourcingの2つのアプローチを比較し、「状態」ではなく「変化（イベント）」を中心に据える考え方を整理している。
• 一般的なRDBっぽく設計すると履歴要件が入ったときに破綻しやすい点を指摘し、Bi-temporalデータモデルの複雑さと実装コストについても言及している。
• Event Sourcingは銀の弾丸ではなく、最新状態の取得が遅くなる・有効期間の表現・イベントスキーマのVersioning・取り消し/訂正の設計など、採用時の注意点を多面的に整理している。

2025-12-16 : そのRequest Scope、Async Local Storageでいいんじゃない？｜anizozina

• NestJSのRequest Scopeはbubble upするため、依存関係の終端でRequest Scopeを使うと全てのクラスがRequest Scopeになってしまい、リクエストごとに大量のインスタンス化が発生してパフォーマンスが悪化する課題を整理している。
• リクエスト単位で独立する情報（テナントID・ユーザーIDなど）を格納するだけならAsync Local Storage（nestjs-cls）を使うことで、Singletonと同等のパフォーマンスを維持できることを定量比較で示している（Request Scopeは約20%のRPS低下）。
• 一方で、テナントごとにDB接続情報を変えたりIAM Roleをassumeするようなケースではライフサイクルをリクエストごとに完結させる必要があり、Request Scopeが適切な場面もある点を注意している。

2025-12-17 : 「DevicePeople」か「PeopleDevice」かで悩んだ話。そして、中間テーブルの「解」を求めた話。｜ぽんこつエンジニア

• 「デバイスに使用者を設定する」という要件を字面通りに実装したが、入社時に複数デバイスを貸与するシナリオを考えると「メンバーがデバイスを持てる」の方が自然だった、という振り返りが正直で共感できる。
• 最終的に「デバイス貸与」という独立した集約を切り出すことで、どちらの視点からも自然に扱える構造にたどり着いている。中間テーブルをエンティティとして昇格させる設計判断が学びになる。
• コンパウンドプロダクト（HR Force / IT Force）の境界を意識した設計が必要で、主語が入れ替わっても成り立つ設計を心がける重要性を示している。

2025-12-18 : 繰り返される問題を3ステップで根絶する氷山モデル｜ないとー

• 目に見える問題は「氷山の一角」で、水面下に「パターン→構造→メンタルモデル」の層が隠れているというシステム思考のフレームワーク「氷山モデル」を紹介している。
• AIは「どう直す？」は教えてくれるが「なぜ起こる？」「なぜ繰り返される？」は教えてくれない。問題が繰り返されるのは表面だけを直して構造に手をつけていないから、という指摘が刺さる。
• 本番障害を例に4層を具体的に掘り下げ、「繰り返される問題を選ぶ→4層で整理→層3(構造)から介入」という実践的な3ステップを示している。構造が行動を変え、行動が認識を変えるという考え方が良い。

2025-12-19 : 画面が増え続けるプロダクトの Server-Driven UI という選択｜ないとー

• コンパウンドプロダクトでは「詳細画面」が大量に必要になるが、よく見ると「セクションの中に属性が並ぶ」という共通構造を持っている点に着目し、Server-Driven UIの採用判断を解説している。
• バックエンドからセクション・属性の構造をJSONで返し、フロントエンドはvalueTypeに応じて適切なコンポーネントを描画するだけにすることで、画面追加時の工数削減と実装者による構造の揺れを防止している。
• さらに、sectionKey/attributeKeyがGraph（SSOT）と一致しているため、権限制御もGraph中心で一元管理できる。昨日の氷山モデルと関連づけて「層3(構造)への介入」として位置づけているのが面白い。

2025-12-20 : 元フロントエンドエンジニアがプロダクトエンジニアとして強制成長している話｜もず

• フロントエンド専門からプロダクトエンジニアへ転身し、バックエンド（NestJS/Prisma/DDD）やインフラ（AWS/CDK/GitHub Actions）など、領域を広げながら成長している過程を率直に共有している。
• 「本質的な価値は顧客課題を解決すること」であり、技術はその手段。専門性を深めつつも越境していく姿勢が、スタートアップのスピード感と合っている。
• CI/CDの改善、E2Eテストのメンテナンス改善、分析用SQLの作成など、具体的なタスクを通じて「苦手だった領域が楽しくなってきた」という変化が、プロダクトエンジニアとしてのマインドセットを示している。

2025-12-21 : 【PdM/デザイナー】デスクリサーチにおける「自問自答」を言語化してみる｜つーじー

• 「調べればわかる」ことに誠実でありたいという姿勢を起点に、デスクリサーチの段階で50点の景色を見るか、120点に到達するための論点まで見越せるかで天と地ほどの差が生まれることを指摘している。
• マーケット観点・ユーザー観点・設計観点・法的観点の4軸で「自問自答」の質問リストを言語化し、競合の設計思想やAPIの仕様、特許情報まで調査対象として挙げている網羅性が参考になる。
• Dress Codeが「最後発として一番優れたプロダクトを届ける」という立場から、先行他社の優れた設計は参考にしつつ、同じ設計ミスは踏まず、最初から横断的な設計をするという方針が伝わってくる。

総括

今週もどの記事も本当に良い！特に氷山モデルとServer-Driven UIの連続した記事は、問題の構造を捉えて介入するという一貫したメッセージが印象的。最終日のデスクリサーチの記事は、PdM/デザイナー視点での「調べる力」の重要性を改めて認識させてくれた。自社アドカレの企画は本当に助かる！！