📝

自社ブログから技術を勉強 - 2025-12-08 - 2025-12-14

に公開
2025/12/16
topics
idea

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

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

先週分の記事

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

2025-12-08 : Microsoft Graph API の認証方式を整理｜SaaS開発で検討した3つのアプローチ｜jnishime

  • 認証方式を「ユーザー委任 / 顧客側アプリ / SaaS側マルチテナント+Admin Consent」の3択で整理してくれて、迷子になりやすい論点が一気に見える。
  • 「アプリ登録をどこで持つか（顧客テナント or SaaS側）」が、導入の手間・運用コスト・スケーラビリティ・顧客の安心感に直結する、という腹落ちが得られる。
  • 最後の比較表と選択ポイントが実務向けで、個人データ操作/バッチ同期/高セキュリティ要件など、ユースケースで判断しやすい。

2025-12-09 : Dress Code QAチーム立ち上げの軌跡(2025年振り返り)｜うさぴょん

  • スタートアップのスピード前提で、全部やるより「今回絶対に守るライン（価値/シナリオ）」を定義してテスト設計する話がリアル。
  • Playwright MCP（自然言語でのUIテスト）と runn（YAMLでAPI E2Eを量産）を組み合わせて、泥臭い物量戦を回す設計が参考になる。
  • QA指摘をラベル設計で可視化し、Critical/Major/進捗%などの「Go/No Go」基準まで落とすことで、QAの価値を「品質の可視化と判断材料」として示している。

2025-12-10 : Self-Hosted Runnerで GitHub Actions のCI/CDを高速化・コスト最適化した｜cottpan

  • GitHub-hosted runnerの「スペック不足・並列上限によるキュー待ち・課金増」を課題として整理し、Self-Hosted Runner導入の意思決定が納得できる。
  • TypeScriptビルドはシングルスレッド性能とメモリが効く、Warm Poolで起動待ちを潰す、Ephemeral Runner＋SSMでセキュリティも担保、など選定軸が実践的。
  • terraform-aws-github-runner をベースに、Spot（capacity-optimized）＋PackerでカスタムAMI＋業務時間のみWarm Poolなど、性能とコストのバランスを数値で示している。

2025-12-11 : AI時代のプロダクトデザイナーの生存戦略は、「DRESS CODEというプロダクト」を作ること｜KENJI NUMATA

  • AIでUI生成/自動化が進むほど、表層アウトプット（UIを整える）の希少性が下がる、という前提整理がわかりやすい。
  • 一方で「業務・制度・制約・リスク」を統合して成立させる設計（タスクモデル、状態遷移、情報構造など）はまだ人の領域だ、という線引きが刺さる。
  • 「描く人」から「壊れない構造を設計する人」へ、というメッセージと、複雑性を扱うDRESS CODEがその実践の場、という結論が一貫している。

2025-12-12 : 認証基盤をCognitoからOry Kratosへ：B2B SaaSの「当たり前品質」を守るためのリプレイス戦略｜ぽこひで

  • Cognitoの限界を「Lambdaトリガー肥大化で保守/デバッグが辛い」「ステートレス/JWT前提とステート管理要件の衝突」「マルチテナントとの不適合」の3点で整理されているんだけど、前提知識が必要そうでついていけてない僕。
  • 移行戦略をCognito継続／OSS活用／IDaaS（Auth0）で比較し、創業フェーズならではのリスク（将来の技術的負債）を先に潰しにいく意思決定が学びになる。
  • Ory Kratos（Ory Network含む）を選んだ理由が、DAU課金でスパイクに強い・SaaS↔Self-Hostのポータビリティ・Server Driven UI・データホーミング・B2B必須機能（SSO/マルチテナント）と多面的。

2025-12-13 : O11y実践の話で盛り上がりたい｜gamonges

  • 「システムは正常に動いているのに、お客様から『業務が終わらない』と問い合わせが来る」状況を、業務フローのどこで止まっているかを可視化することで解決しようとするアプローチが、情シス・カスタマーサポート視点でも理解しやすい。
  • 「監視ツールは入れたけど、障害調査で結局ログを横断して探し回る」という"あるある"に対して、計装設計の具体的なコード例とチェックリストが示されていて、実務で真似しやすい。
  • プラットフォーム層（operation.*）とドメイン層（domain.*）でタグ設計を分離し、障害調査の初手で「基盤の問題か業務の問題か」を即座に切り分けられる構造が実践的。

2025-12-14 : Dress Codeに来て2ヶ月半が経って｜なたこん

  • 入社後に感じた文化として「価値仮説（誰の/どんな負の状態を/どう変える）を先に言語化する」が具体的で、会話の前提が見える。
  • 「全量想定→ロジカル引き算」をやり切る難しさ（帰納と演繹の切り替え、安心できる設計に逃げたくなる）というつまづきが正直で共感する。
  • toCの探索モードから、B2Bの複雑さを“整理して構造化する”モードへのスタンスチェンジが、エンジニア→PM転身のリアルとして読める。

総括

どの記事も本当に良い！自社の文化や内容が理解できる！自社アドカレの企画は本当に助かる！！

GitHubで編集を提案

Discussion