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
最近試してみた議論のやり方
Search
とぴ
August 30, 2025
0
77
最近試してみた議論のやり方
社内で行われたプロジェクトマネジメント同好会で発表した内容を外部公開用に整えたものです。
とぴ
August 30, 2025
Tweet
Share
More Decks by とぴ
See All by とぴ
エタらないアプリ開発
topi0247
0
210
今からできる簡単アイディア出し
topi0247
0
350
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
500
Navigating Team Friction
lara
189
15k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
A better future with KSS
kneath
239
17k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Become a Pro
speakerdeck
PRO
29
5.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
284
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Transcript
最近試してみた議論のやり方 2025年8月27日 とぴ
自己紹介 とぴ プロフィール バックエンドエンジニア Go Rails React
名古屋本社のヘルステック系スタートアップ企業勤務 フルリモート 長野県出身・在住 最近Nagano.dev立ち上げました プロジェクトマネージャーは今回が初めて 上長や先輩の手を借りつつ試行錯誤中
経緯 ※驚かせる=ステークホルダーが知らない情報を大々的に披露する 書籍で上記を読んで下記のメリットがありそう 「そんなの聞いてない」を防げる 事前にある程度把握していただいておくことで、発表時の認識すり合わせの時間が減りそう
発表前に良い点・懸念点を把握できそう 発表に限らず、議論のミーティングでも同じことができないか? 議論したい内容を事前に共有と軽い認識すり合わせをすることで、ミーティングでは議論に集中できるのではないか 「大きな」ミーティングでシニアステークホルダーに何か伝える場合は、絶対に驚かせないことです。 理由はたくさんありますが、新しいアイディアをグループの場で発表する前に、シニアステークホルダーに対して個別に説明す るのが良いでしょう。 引用:プロダクトマネージャーのしごと 第2版
やってみた 前提 担当プロジェクトの画面デザインについてのミーティング 最終目標:「画面デザインのfix」 「デザインに基づく仕様の確定」 ステークホルダー:社内運用部門(該当プロダクトを使用している部署) シニアステークホルダーに対して個別に説明する フルリモ環境だと「ちょっと聞いてよ」が難しい
ステークホルダー個別にmeetsやハドルをするのは時間がちょっとかかりそう
流れ 共有・説明自体は全体で行う ただし、内容は一度持ち帰って個々あるいは部門内で確認して、あらかじめ議論したい内容をまとめておいていただく。 対応範囲全てを一気にデザイン化せず、大きな機能別に画面デザインを分けて作成・共有 機能別設計 1回目ミーティング
(認識合わせ) 2回目ミーティング (議論) 1機能のサイクルを上記2回のミーティングに分けるイメージ 1回目のミーティング 最長30分程度の共有・説明と軽い認識すり合わせ この時点で気になることがあれば話していただき、時間がかかりそうであれば持ち帰る 1 2回目のミーティング 1時間の議論 必要に応じて「持ち帰る」 次回ミーティングまでに持ち帰った内容を検討・反映 2
狙い・やってみたメリット 狙い その場では出なかったがあとで出てきた疑問や懸念を次のミーティングで議題にできる 前回のミーティングから日が空いてしまっているので、そもそのこのPJなんだっけ?の再確認の時間を作れる 議論したい項目を時間内になるべく多く議論したい - 1つの項目に時間がかかりすぎる課題があったため
やってみたメリット 認識すり合わせと議論が分かれたことで、議論パートの時間の確保ができた すり合わせで時間が終わるということがなかった すり合わせ自体すぐに終わったのと、要件確定してから日が空いてしまっていたのでPJ自体の再確認ができた(はず) 1 適宜「持ち帰り」を行なったことで一つの議題が終わるまで話す、ということがなく1時間内で取り上げられる議題が増え た 2
反省 共有時点でPJの開発部担当者(主に私)から確認したい内容を伝え切れなかった 議論するミーティングより前にNotionで共有はしたが、それなりに量があったので確認し切れなかったと思う どうしたか? 議論し切れなかった項目を、次のミーティングまでに確認 して気になることなど記載しておいてほしいと依頼 事前に開発部担当者も把握できるので、議論内容が
「どうしましょうか」からではなく「いただいたこの 意見についてですが」から始められる 今後どうするか? 具体的な日にちを決めて、その日までに確認していた だく 課題 事前に共有したとして、運用部門の忙しさが掴み切れてい ないのでそもそも確認する時間があるのか不明 議論ミーティング時に「先に確認したいことあります か?」と聞いたら「特にない」と言われてしまったた め 実際、こちらから議題をあげたらご意見いっぱい出て きたため(Notion共有が直前過ぎたのもあるかもしれ ない)
感想 ミーティングの仕方やPJの進め方を今後も色々試していきたいと思いました。 そのためにもミーティング後の個人反省会や、書籍によるインプットを継続していきたいです。
ご清聴ありがとうございました とぴ