Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PdMとエンジニアの より良いコミュニケーションに向けて / Improve communication between Product Manager and Software Engineer

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

More Decks by Yuichiro SAITO

Other Decks in Technology

Transcript

  1. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. PdMとエンジニアの より良いコミュニケーションに向けて 2021/11/25 アマゾン ウェブ サービス ジャパン 合同会社 スタートアップソリューションアーキテクト 齋藤 祐⼀郎
  2. 齋藤 祐⼀郎 (@koemu) アマゾン ウェブ サービス ジャパン合同会社 スタートアップ ソリューションアーキテクト 創業まもないスタートアップ企業、およびFinTech企業

    の技術⽀援を担当。 数々のスタートアップ企業での開 発業務を経験。直近では、株式会社メルカリでフリー マーケット及び決済サービス(メルペイ)の開発を担 当、急成⻑に貢献しIPOを経験。筑波⼤学 ⼤学院 ビジ ネス科学研究科 経営システム科学専攻 博⼠前期課程修 了 (経営システム科学)。
  3. 1. UXリサーチはプロダクトマネージャーとソフトウェアエンジニア の気持ちを結ぶ良い⽅法の⼀つ 2. ソフトウェアエンジニアの気質を知る 3. サービスは「新しく作る」「拡張する」そして「外部のサービス を活⽤する」ことができる (以後、プロダクトマネージャーをPdM、ソフトウェアエンジニアは エンジニアと省略します)

    今⽇の話のあらすじ
  4. • 作る話が主体になりがちになりませんか︖ • 仕様 • スケジュール • こんなことを思いませんか︖ • もうちょっとサービスに対して「愛」って育めないかな…

    • サービスへのオーナーシップを発揮してもらいたいな… PdMの⽅がエンジニアと接するとき…
  5. • PdMの⽅が発した「希望」は、エンジニアは… • 「〇〇(e.g. スケジュール)は守るもの」 • 「⽭盾」「曖昧」「抜け漏れ」がないかを確かめたり • という「基準」として捉えられがちです。 なので、厳しく聞いたり、予防線を張られがちになります。

    情報の捉え⽅が違う この⽇までに仕上げる 必要があるのか… この⽇までに仕上げて もらえると嬉しいな… PdM エンジニア
  6. • ⽬線がソフトウェアの品質に注⼒されているからです。 • 「プログラマの三⼤美徳(出典: Programming Perl)」で説明できます。 • 怠惰: 省⼒化につながる仕組み化・⽂書化を⾏う •

    短気: ニーズに対応するばかりでなく問題が起きる前に⼿を打つ • 傲慢: 他⼈に批判をされない⾼い品質を出す • 結果として次のものにつながります • より良い設計 / より正確な実装 /より新しい技術 / より⾼速な処 理 / より効率的な開発 / より障害に強く拡張性のある基盤 / etc. どうして︖
  7. • それはお客様︕ • UXリサーチを通じてPdMとエンジニアの距離を縮める。 • チーム全員がお客様への価値提供に「関⼼」を統⼀できます。 • エンジニアは相対的にお客様からの距離が遠くなりがちです。 実際に使ってもらっている状況を⾒て、改めて⾃分たちのサービ スは「⼈」が使っていることを知り、良い点・改善点を直接伺う

    ことで、誰のためにサービス開発をしているのを知ります。 誰のためにサービスを開発しているのか
  8. • お客様に提供したい「価値」を再確認して、互いに交渉します。 • そうすると、本当に守る必要があるものが何で、あとはどれを取捨選択し ていくか、前向きな議論に向かっていくことができます。 そしてどうコミュニケーションしていくのか 引⽤元: ⽥辺めぐみ (「プロダクトづくりで ユーザー視点を取り⼊れる」より)

    この辺りに 効きやすいです
  9. • PdMとしては、エンジニアが次のカードを持っているか知ってお くとよいです。 • 既存機能の改修で進められるか。 • 外部のサービスを活⽤できるか。 • 新規開発が必要か。 •

    下に向かうほど開発のコスト(特に⼯数)が⽐較的⾼くなります。 実際に開発になったとき
  10. サービスと統合して活⽤できる外部のサービス(SaaS) Zendesk: カスタマーサポート管理 Stripe: 決済 Salesforce: CRM (顧客管理) Datadog: システム監視

  11. • AWSは、ITインフラ基盤を提供しているばかりではありません。 • サービスに求められる機能を⾃分たちで作り込まずとも提供する ための基盤(マネージドサービス)もあります。 AWSにもあるんです サービスに統合できる機能 【マーケティングコミュニケーション】 Amazon Pinpoint

    【機械学習】 Amazon Personalize / Amazon Rekognition 【BI(分析)】 Amazon QuickSight 【動画配信】 Amazon Elemental MediaLive (以上は⼀例です)
  12. • 「⾞輪の再発明」 「Undifferentiated Heavy Lifting」をしない • 既にある汎⽤的な技術を、わざわざ⾃分で作って運⽤するコ ストを払うのはもったいないです(e.g. プッシュ通知基盤)。 •

    クラウド事業者が、サービスとして既にITインフラを構築し ており、運⽤も任せることができるケースがあります。 • ⼯数ではなくお⾦の投資で解決できる問題があります。 • 聞けるところ(⼈・窓⼝)があります。 SaaSなどのマネージドサービスを使う意義
  13. • UXリサーチは、エンジニアの「品質」とPdMの「希望」を同じ 「関⼼」のベクトルに向けるための良い⽅法の⼀つです。 • お客様に提供したい「価値」が明確になると、交渉して取捨選択 も捗りやすいです。 • サービスを作る⽅法は3つあり、特にPdMの⽅には外部のサービ スの活⽤があることもぜひ知ってください︕ まとめ

  14. Q&A

  15. Thank you © 2021, Amazon Web Services, Inc. or its

    affiliates. All rights reserved.