プロダクトエンジニアに必要な「いい感じ」に作る能力 〜たくさん作れる時代に、どこまで作るかの決め方〜

こちらはProduct Engineering Conference 2026のスポンサーランチセッションの登壇記事です。

Transcript

1. プロダクトエンジニアに必要な “いい感じ”に作る能力 たくさん作れる時代に、どこまで作るかの決め方 Dress Code 株式会社 / 西銘 承太郎 1
2. 自己紹介 • 経歴 ◦ 2013.04 〜 新卒旅行会社で総合職(営業など) ◦ 2016.10 〜 SESの会社でエンジニア ◦ 2019.10 〜 事業会社でエンジニア(SREもちょっと) ◦ 2025.08 〜 Dress Code株式会社でエンジニア(PdE🙌) • やっていること ◦ 主に「デバイス管理」ドメインの開発 • 趣味 ◦ 休日は主に2歳の息子とじゃれてます 西銘 承太郎 （にしめ） © Dress Code Inc . 2
4. では、本題へ © Dress Code Inc . 4
5. “いい感じに作って” と言われたこと、ありませんか？ © Dress Code Inc . 5
6. “いい感じに作る”とは © Dress Code Inc . 6
7. “いい感じに作る”とは プロダクト・顧客・組織を見て “今どうするか”を決めること © Dress Code Inc . 7
8. アジェンダ 1. プロダクト・顧客・組織を見るとは 2. 実例紹介 3. 実例を再現する考え方 4. まとめ © Dress Code Inc . 8
9. 1. プロダクト・顧客・組織を 見るとは © Dress Code Inc . 9
10. プロダクトの「過去」と「未来」 過去 未来 なくしたいもの 寄せたい方針 例： 依存が重い、構造が過剰に複雑など、 今後消したいDBテーブルやモジュール 例： 古参やテックリードの頭の中の構想 参考にしたい類似機能の実装 「過去」と「未来」で「作り方」を今どうするかがわかる © Dress Code Inc . 10
11. 顧客の「温度感」と「利用タイミング」 温度感 利用タイミング どれくらい重要な機能か？ 実際にいつから使い始めるか？（ ≠ リリース日） 利用頻度が高い 影響が大きい あったら便利な機能(+α) 温度感が高い (詳細も要検討) 温度感が低い (段階的に拡張可能) 同じ「欲しい」でも重さは違う 変えられない リリース日 顧客が使い 始める時期 リリース日時点では 誰も気にしない仕様もある 「温度感」と「利用タイミング」で「作る範囲」を今どうするかが見える © Dress Code Inc . 11
12. 組織の「意向」と「状況」 意向 意向 プラットフォームチーム 「共通基盤に寄せたい」 →作ると車輪の再発明？ だれがいつ 作るか？ 隣のプロダクトチーム 「このテーブルは使わないで...」 →使うと別チームの負債？ 自チーム 状況 状況 CS 「繁忙期で手一杯」 →リリースは延期？ リリースは どう進めるか？ セールス 「既存実装で商談予定」 →段階リリースが必要？ 「意向」と「状況」で「進め方」を今どうするかが変わる © Dress Code Inc . 12
13. 組織の「意向」と「状況」 意向 意向 プラットフォームチーム 「共通基盤に寄せたい」 →作ると車輪の再発明？ 隣のプロダクトチーム 「このテーブルは使わないで...」 →使うと別チームの負債になる？ プロダクト・顧客・組織を見て 自チーム 作り方・作る範囲・進め方の 状況 CS 「繁忙期で手一杯」 →リリースは延期？ 状況 「今どうするか」を決める セールス 「既存実装で商談予定」 →段階リリース必要？ 「意向」と「状況」で「進め方を今どうするか」が変わる © Dress Code Inc . 13
14. 2. 実例紹介 © Dress Code Inc . 14
15. 例：デバイスのアラート画面の新規追加 PdMの企画デザイン 「メンバー名で検索」 ＝ 人の検索機能の仕様がある デバイスの割当ルールを満たしていない人を、一覧画面に表示する機能 © Dress Code Inc . 15
16. 実装を進めると、3つの情報が見えてきた プロダクトの「過去」 顧客の「利用タイミング」 人名参照するビューテーブルは 更新エラーが頻発 名前照合をこれに頼りたくない 利用までに各種設定が必要な 今までの運用に＋αな機能 リリース後すぐには使われない 組織の「意向」 別チームが人に関する情報の 検索基盤を構築中 待てば、相乗り出来るかも あれ、人名検索は今作らない方がよくね？ © Dress Code Inc . 16
17. 気づいたことは、関係者にすぐ頭出し 別チーム 「人名検索の実装で、このテーブルとモジュール今使って大丈夫ですか？」 エンジニア （自分） PdM 「人名検索って、初期スコープとして必須ですか？」 「触って気づいたのですが、もっと手軽にアラート対象外にするUI/UX欲しく ないですか？」 大げさな会議までにせず、雑談レベルの相談でサクッと聞く © Dress Code Inc . 17
18. 結果 × 見送り ◦ 追加 「人名検索」ボックス 基盤ができたら乗る 「対象外リストに追加」 UX改善を浮いた工数で実装 「作らない」選択をし、代わりに「UX改善」を増やす意思決定 © Dress Code Inc . 18
19. 3. 実例を再現する考え方 © Dress Code Inc . 19
20. 背景にある2つの思想 • ご近所さんを探せ ◦ 書籍「アジャイルサムライ」の「ご近所さんを探せ」という考え方 ◦ プロジェクトに影響する人たちを最初に見つけて、味方になってもらう • アジャイルテスティング ◦ 書籍「Agile Testing Condensed」の「アジャイルテスティング」の考え方 ◦ テスト工程だけでなく、設計や実装などすべてのフェーズでテスト(検証)する © Dress Code Inc . 20
21. 各フェーズで、ご近所さんと相談(検証)する フェーズ 相談する相手 聞くこと（例） 基本設計 PdM・QA 「実装後のイメージ、自分はこう考えてますが認識合ってますか？」 詳細設計 参考機能を実装した エンジニア 「当時の課題感は？真似しない方が良いことはありますか？」 影響するデータ・実装の オーナーチーム 「これ、この用途で使って良かったですかね？」 CS・Sales 「こんな感じでリリース予定です。気になるところありますか？」 実装 リリース リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 21
22. 各フェーズで、ご近所さんに相談する フェーズ 相談する相手 聞くこと（例） 基本設計 PdM・QA 「実装後のイメージ、自分はこう考えてますが認識合ってますか？」 詳細設計 プラットフォームチーム 類似実装をした人 たった5分の軽い相談で、 「当時の課題感は？真似しない方が良いことはありますか？」 「想定と違った」「聞いてない」「使わないでほしかった」 データ・モジュールの 実装 リリース オーナーチーム CS 「これ、この用途で使って良いですよね？」 の事故が大幅に減る！ 「こんな感じでリリース予定です。気になるところありますか？」 リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 22
23. 4. まとめ © Dress Code Inc . 23
24. 3つを見て、3つを決めよう • プロダクトの「過去」と「未来」を見る ◦ → 「作り方」を今どうするか決める • 顧客の「温度感」と「利用タイミング」を見る ◦ → 「作る範囲」を今どうするか決める • 組織の「意向」と「状況」を見る ◦ → 「進め方」を今どうするか決める やること：リリースに関係しそうな人を特定して、早めに頭出しする © Dress Code Inc . 24
25. 個人の頑張りだけではない • Dress Codeには、やりやすい仕組みがある ◦ プロダクト ・・・意思決定をADRに残す文化 ◦ 顧客 ・・・温度感など顧客期待値をチケットに記載 ◦ 組織 ・・・週次のBiz/Devチーム横断MTG ADR • 詳しくは、ブースでお話ししましょう！ 意思決定を全部残す 「ADR(Any Decision Record)」 という文化 zenn.dev/dress_code © Dress Code Inc . 25
26. おわりに © Dress Code Inc . 26
27. PdMの仕事っぽい話と思いました？ © Dress Code Inc . 27
28. 主体的に情報を集めて、 “今どうするか”を決めるのは プロダクトエンジニアの仕事！ © Dress Code Inc . 28
29. もし、Dress Codeの働き方に 興味持った方は・・・ © Dress Code Inc . 29
32. ご清聴ありがとうございました！！！ ブースや懇親会等でもお話ししましょう！ © Dress Code Inc . 32