Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PdMとエンジニアのより良いコミュニケーションに向けて / Improve communic...
Search
Yuichiro SAITO
PRO
November 25, 2021
Technology
1
630
PdMとエンジニアの より良いコミュニケーションに向けて / Improve communication between Product Manager and Software Engineer
2021/11/25
ポップインサイト UXリサーチ共有会 11月
https://popinsight.jp/seminar/?p=23431
Yuichiro SAITO
PRO
November 25, 2021
Tweet
Share
More Decks by Yuichiro SAITO
See All by Yuichiro SAITO
FinTech スタートアップのセキュリティチェックシートとの向き合い方 / AWS FinTech Bootcamp! Compliance
koemu
PRO
0
660
クラウドを積極活用したサービスの開発のために / AWS FinTech Bootcamp! Basic
koemu
PRO
0
290
ワークショップFinTech アーキテクチャ / AWS FinTech Bootcamp! Workshop
koemu
PRO
0
260
正しい理解で作る安心安全な FinTech の IT インフラ / tech play aws 2022 2
koemu
PRO
1
330
AWSの「今」 -PHPのコードを素早く動かすためのサービスのご紹介 / PHPCon2022 AWS Japan Session
koemu
PRO
2
2.1k
フェイズ別・スタートアップ企業への技術選定 シード編 #AWS #AWSStartup / Startup Tech 101 for Seed
koemu
PRO
0
510
AWSを使って送金機能を実装してみよう - 「sunabar-GMOあおぞらネット銀行API実験場-」コミュニティイベント第6弾
koemu
PRO
0
1.1k
Hardening II SU Softening Day - Team カムイ Presentation
koemu
PRO
0
3.9k
Software Development at Mercari #ioi2018
koemu
PRO
0
1.2k
Other Decks in Technology
See All in Technology
[mercari GEARS 2025] Keynote
mercari
PRO
0
170
Data & AIの未来とLakeHouse
ishikawa_satoru
0
720
Design and implementation of "Markdown to Google Slides" / phpconfuk 2025
k1low
1
390
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
1.3k
Lazy Constant - finalフィールドの遅延初期化
skrb
0
130
從裝潢設計圖到 Home Assistant:打造智慧家庭的實戰與踩坑筆記
kewang
0
160
LINE公式アカウントの技術スタックと開発の裏側
lycorptech_jp
PRO
0
350
CDKの魔法を少し解いてみる ― synth・build・diffで覗くIaCの裏側 ―
takahumi27
1
140
なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える
mizzy
43
12k
嗚呼、当時の本番環境の状態で AI Agentを再評価したいなぁ...
po3rin
0
400
エンジニアにとってコードと並んで重要な「データ」のお話 - データが動くとコードが見える:関数型=データフロー入門
ismk
0
470
Flutterコントリビューションのススメ
d_r_1009
1
350
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
Navigating Team Friction
lara
190
15k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
4 Signs Your Business is Dying
shpigford
186
22k
Speed Design
sergeychernyshev
32
1.2k
Facilitating Awesome Meetings
lara
57
6.6k
Context Engineering - Making Every Token Count
addyosmani
9
380
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.8k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Transcript
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. PdMとエンジニアの より良いコミュニケーションに向けて 2021/11/25 アマゾン ウェブ サービス ジャパン 合同会社 スタートアップソリューションアーキテクト 齋藤 祐⼀郎
齋藤 祐⼀郎 (@koemu) アマゾン ウェブ サービス ジャパン合同会社 スタートアップ ソリューションアーキテクト 創業まもないスタートアップ企業、およびFinTech企業
の技術⽀援を担当。 数々のスタートアップ企業での開 発業務を経験。直近では、株式会社メルカリでフリー マーケット及び決済サービス(メルペイ)の開発を担 当、急成⻑に貢献しIPOを経験。筑波⼤学 ⼤学院 ビジ ネス科学研究科 経営システム科学専攻 博⼠前期課程修 了 (経営システム科学)。
1. UXリサーチはプロダクトマネージャーとソフトウェアエンジニア の気持ちを結ぶ良い⽅法の⼀つ 2. ソフトウェアエンジニアの気質を知る 3. サービスは「新しく作る」「拡張する」そして「外部のサービス を活⽤する」ことができる (以後、プロダクトマネージャーをPdM、ソフトウェアエンジニアは エンジニアと省略します)
今⽇の話のあらすじ
• 作る話が主体になりがちになりませんか︖ • 仕様 • スケジュール • こんなことを思いませんか︖ • もうちょっとサービスに対して「愛」って育めないかな…
• サービスへのオーナーシップを発揮してもらいたいな… PdMの⽅がエンジニアと接するとき…
• PdMの⽅が発した「希望」は、エンジニアは… • 「〇〇(e.g. スケジュール)は守るもの」 • 「⽭盾」「曖昧」「抜け漏れ」がないかを確かめたり • という「基準」として捉えられがちです。 なので、厳しく聞いたり、予防線を張られがちになります。
情報の捉え⽅が違う この⽇までに仕上げる 必要があるのか… この⽇までに仕上げて もらえると嬉しいな… PdM エンジニア
• ⽬線がソフトウェアの品質に注⼒されているからです。 • 「プログラマの三⼤美徳(出典: Programming Perl)」で説明できます。 • 怠惰: 省⼒化につながる仕組み化・⽂書化を⾏う •
短気: ニーズに対応するばかりでなく問題が起きる前に⼿を打つ • 傲慢: 他⼈に批判をされない⾼い品質を出す • 結果として次のものにつながります • より良い設計 / より正確な実装 /より新しい技術 / より⾼速な処 理 / より効率的な開発 / より障害に強く拡張性のある基盤 / etc. どうして︖
• それはお客様︕ • UXリサーチを通じてPdMとエンジニアの距離を縮める。 • チーム全員がお客様への価値提供に「関⼼」を統⼀できます。 • エンジニアは相対的にお客様からの距離が遠くなりがちです。 実際に使ってもらっている状況を⾒て、改めて⾃分たちのサービ スは「⼈」が使っていることを知り、良い点・改善点を直接伺う
ことで、誰のためにサービス開発をしているのを知ります。 誰のためにサービスを開発しているのか
• お客様に提供したい「価値」を再確認して、互いに交渉します。 • そうすると、本当に守る必要があるものが何で、あとはどれを取捨選択し ていくか、前向きな議論に向かっていくことができます。 そしてどうコミュニケーションしていくのか 引⽤元: ⽥辺めぐみ (「プロダクトづくりで ユーザー視点を取り⼊れる」より)
この辺りに 効きやすいです
• PdMとしては、エンジニアが次のカードを持っているか知ってお くとよいです。 • 既存機能の改修で進められるか。 • 外部のサービスを活⽤できるか。 • 新規開発が必要か。 •
下に向かうほど開発のコスト(特に⼯数)が⽐較的⾼くなります。 実際に開発になったとき
サービスと統合して活⽤できる外部のサービス(SaaS) Zendesk: カスタマーサポート管理 Stripe: 決済 Salesforce: CRM (顧客管理) Datadog: システム監視
• AWSは、ITインフラ基盤を提供しているばかりではありません。 • サービスに求められる機能を⾃分たちで作り込まずとも提供する ための基盤(マネージドサービス)もあります。 AWSにもあるんです サービスに統合できる機能 【マーケティングコミュニケーション】 Amazon Pinpoint
【機械学習】 Amazon Personalize / Amazon Rekognition 【BI(分析)】 Amazon QuickSight 【動画配信】 Amazon Elemental MediaLive (以上は⼀例です)
• 「⾞輪の再発明」 「Undifferentiated Heavy Lifting」をしない • 既にある汎⽤的な技術を、わざわざ⾃分で作って運⽤するコ ストを払うのはもったいないです(e.g. プッシュ通知基盤)。 •
クラウド事業者が、サービスとして既にITインフラを構築し ており、運⽤も任せることができるケースがあります。 • ⼯数ではなくお⾦の投資で解決できる問題があります。 • 聞けるところ(⼈・窓⼝)があります。 SaaSなどのマネージドサービスを使う意義
• UXリサーチは、エンジニアの「品質」とPdMの「希望」を同じ 「関⼼」のベクトルに向けるための良い⽅法の⼀つです。 • お客様に提供したい「価値」が明確になると、交渉して取捨選択 も捗りやすいです。 • サービスを作る⽅法は3つあり、特にPdMの⽅には外部のサービ スの活⽤があることもぜひ知ってください︕ まとめ
Q&A
Thank you © 2021, Amazon Web Services, Inc. or its
affiliates. All rights reserved.