プロダクトエンジニアに必要な “いい感じ”に作る能力 たくさん作れる時代に、どこまで作るかの決め方 Dress Code 株式会社 / 西銘 承太郎 1 

自己紹介 ● 経歴 ○ 2013.04 〜 新卒旅行会社で総合職(営業など) ○ 2016.10 〜 SESの会社でエンジニア ○ 2019.10 〜 事業会社でエンジニア(SREもちょっと) ○ 2025.08 〜 Dress Code株式会社でエンジニア(PdE🙌) ● やっていること ○ 主に「デバイス管理」ドメインの開発 ● 趣味 ○ 休日は主に2歳の息子とじゃれてます 西銘 承太郎 （にしめ） © Dress Code Inc . 2 

No content

では、本題へ © Dress Code Inc . 4 

“いい感じに作って” と言われたこと、ありませんか？ © Dress Code Inc . 5 

“いい感じに作る”とは © Dress Code Inc . 6 

“いい感じに作る”とは プロダクト・顧客・組織を見て “今どうするか”を決めること © Dress Code Inc . 7 

アジェンダ 1. プロダクト・顧客・組織を見るとは 2. 実例紹介 3. 実例を再現する考え方 4. まとめ © Dress Code Inc . 8 

1. プロダクト・顧客・組織を 見るとは © Dress Code Inc . 9 

プロダクトの「過去」と「未来」 過去 未来 なくしたいもの 寄せたい方針 例： 依存が重い、構造が過剰に複雑など、 今後消したいDBテーブルやモジュール 例： 古参やテックリードの頭の中の構想 参考にしたい類似機能の実装 「過去」と「未来」で「作り方」を今どうするかがわかる © Dress Code Inc . 10 

顧客の「温度感」と「利用タイミング」 温度感 利用タイミング どれくらい重要な機能か？ 実際にいつから使い始めるか？（ ≠ リリース日） 利用頻度が高い 影響が大きい あったら便利な機能(+α) 温度感が高い (詳細も要検討) 温度感が低い (段階的に拡張可能) 同じ「欲しい」でも重さは違う 変えられない リリース日 顧客が使い 始める時期 リリース日時点では 誰も気にしない仕様もある 「温度感」と「利用タイミング」で「作る範囲」を今どうするかが見える © Dress Code Inc . 11 

組織の「意向」と「状況」 意向 意向 プラットフォームチーム 「共通基盤に寄せたい」 →作ると車輪の再発明？ だれがいつ 作るか？ 隣のプロダクトチーム 「このテーブルは使わないで...」 →使うと別チームの負債？ 自チーム 状況 状況 CS 「繁忙期で手一杯」 →リリースは延期？ リリースは どう進めるか？ セールス 「既存実装で商談予定」 →段階リリースが必要？ 「意向」と「状況」で「進め方」を今どうするかが変わる © Dress Code Inc . 12 

組織の「意向」と「状況」 意向 意向 プラットフォームチーム 「共通基盤に寄せたい」 →作ると車輪の再発明？ 隣のプロダクトチーム 「このテーブルは使わないで...」 →使うと別チームの負債になる？ プロダクト・顧客・組織を見て 自チーム 作り方・作る範囲・進め方の 状況 CS 「繁忙期で手一杯」 →リリースは延期？ 状況 「今どうするか」を決める セールス 「既存実装で商談予定」 →段階リリース必要？ 「意向」と「状況」で「進め方を今どうするか」が変わる © Dress Code Inc . 13 

2. 実例紹介 © Dress Code Inc . 14 

例：デバイスのアラート画面の新規追加 PdMの企画デザイン 「メンバー名で検索」 ＝ 人の検索機能の仕様がある デバイスの割当ルールを満たしていない人を、一覧画面に表示する機能 © Dress Code Inc . 15 

実装を進めると、3つの情報が見えてきた プロダクトの「過去」 顧客の「利用タイミング」 人名参照するビューテーブルは 更新エラーが頻発 名前照合をこれに頼りたくない 利用までに各種設定が必要な 今までの運用に＋αな機能 リリース後すぐには使われない 組織の「意向」 別チームが人に関する情報の 検索基盤を構築中 待てば、相乗り出来るかも あれ、人名検索は今作らない方がよくね？ © Dress Code Inc . 16 

気づいたことは、関係者にすぐ頭出し 別チーム 「人名検索の実装で、このテーブルとモジュール今使って大丈夫ですか？」 エンジニア （自分） PdM 「人名検索って、初期スコープとして必須ですか？」 「触って気づいたのですが、もっと手軽にアラート対象外にするUI/UX欲しく ないですか？」 大げさな会議までにせず、雑談レベルの相談でサクッと聞く © Dress Code Inc . 17 

結果 × 見送り ○ 追加 「人名検索」ボックス 基盤ができたら乗る 「対象外リストに追加」 UX改善を浮いた工数で実装 「作らない」選択をし、代わりに「UX改善」を増やす意思決定 © Dress Code Inc . 18 

3. 実例を再現する考え方 © Dress Code Inc . 19 

背景にある2つの思想 ● ご近所さんを探せ ○ 書籍「アジャイルサムライ」の「ご近所さんを探せ」という考え方 ○ プロジェクトに影響する人たちを最初に見つけて、味方になってもらう ● アジャイルテスティング ○ 書籍「Agile Testing Condensed」の「アジャイルテスティング」の考え方 ○ テスト工程だけでなく、設計や実装などすべてのフェーズでテスト(検証)する © Dress Code Inc . 20 

各フェーズで、ご近所さんと相談(検証)する フェーズ 相談する相手 聞くこと（例） 基本設計 PdM・QA 「実装後のイメージ、自分はこう考えてますが認識合ってますか？」 詳細設計 参考機能を実装した エンジニア 「当時の課題感は？真似しない方が良いことはありますか？」 影響するデータ・実装の オーナーチーム 「これ、この用途で使って良かったですかね？」 CS・Sales 「こんな感じでリリース予定です。気になるところありますか？」 実装 リリース リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 21 

各フェーズで、ご近所さんに相談する フェーズ 相談する相手 聞くこと（例） 基本設計 PdM・QA 「実装後のイメージ、自分はこう考えてますが認識合ってますか？」 詳細設計 プラットフォームチーム 類似実装をした人 たった5分の軽い相談で、 「当時の課題感は？真似しない方が良いことはありますか？」 「想定と違った」「聞いてない」「使わないでほしかった」 データ・モジュールの 実装 リリース オーナーチーム CS 「これ、この用途で使って良いですよね？」 の事故が大幅に減る！ 「こんな感じでリリース予定です。気になるところありますか？」 リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 22 

4. まとめ © Dress Code Inc . 23 

3つを見て、3つを決めよう ● プロダクトの「過去」と「未来」を見る ○ → 「作り方」を今どうするか決める ● 顧客の「温度感」と「利用タイミング」を見る ○ → 「作る範囲」を今どうするか決める ● 組織の「意向」と「状況」を見る ○ → 「進め方」を今どうするか決める やること：リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 24 

個人の頑張りだけではない ● Dress Codeには、やりやすい仕組みがある ○ プロダクト ・・・意思決定をADRに残す文化 ○ 顧客 ・・・温度感など顧客期待値をチケットに記載 ○ 組織 ・・・週次のBiz/Devチーム横断MTG ADR ● 詳しくは、ブースでお話ししましょう！ 意思決定を全部残す 「ADR(Any Decision Record)」 という文化 zenn.dev/dress_code © Dress Code Inc . 25 

おわりに © Dress Code Inc . 26 

PdMの仕事っぽい話と思いました？ © Dress Code Inc . 27 

主体的に情報を集めて、 “今どうするか”を決めるのは プロダクトエンジニアの仕事！ © Dress Code Inc . 28 

もし、Dress Codeの働き方に 興味持った方は・・・ © Dress Code Inc . 29 

No content

No content

ご清聴ありがとうございました！！！ ブースや懇親会等でもお話ししましょう！ © Dress Code Inc . 32