最近試してみた議論のやり方 2025年8月27日 とぴ 

 自己紹介 とぴ プロフィール  バックエンドエンジニア Go Rails React  名古屋本社のヘルステック系スタートアップ企業勤務 フルリモート  長野県出身・在住 最近Nagano.dev立ち上げました  プロジェクトマネージャーは今回が初めて 上長や先輩の手を借りつつ試行錯誤中 

 経緯  ※驚かせる＝ステークホルダーが知らない情報を大々的に披露する  書籍で上記を読んで下記のメリットがありそう  「そんなの聞いてない」を防げる  事前にある程度把握していただいておくことで、発表時の認識すり合わせの時間が減りそう  発表前に良い点・懸念点を把握できそう 発表に限らず、議論のミーティングでも同じことができないか？  議論したい内容を事前に共有と軽い認識すり合わせをすることで、ミーティングでは議論に集中できるのではないか 「大きな」ミーティングでシニアステークホルダーに何か伝える場合は、絶対に驚かせないことです。 理由はたくさんありますが、新しいアイディアをグループの場で発表する前に、シニアステークホルダーに対して個別に説明す るのが良いでしょう。 引用：プロダクトマネージャーのしごと 第2版  

やってみた 前提  担当プロジェクトの画面デザインについてのミーティング 最終目標：「画面デザインのfix」 「デザインに基づく仕様の確定」 ステークホルダー：社内運用部門（該当プロダクトを使用している部署） シニアステークホルダーに対して個別に説明する  フルリモ環境だと「ちょっと聞いてよ」が難しい  ステークホルダー個別にmeetsやハドルをするのは時間がちょっとかかりそう 

流れ  共有・説明自体は全体で行う ただし、内容は一度持ち帰って個々あるいは部門内で確認して、あらかじめ議論したい内容をまとめておいていただく。 対応範囲全てを一気にデザイン化せず、大きな機能別に画面デザインを分けて作成・共有  機能別設計   1回目ミーティング （認識合わせ）   2回目ミーティング （議論）  １機能のサイクルを上記2回のミーティングに分けるイメージ 1回目のミーティング  最長30分程度の共有・説明と軽い認識すり合わせ  この時点で気になることがあれば話していただき、時間がかかりそうであれば持ち帰る 1 2回目のミーティング  1時間の議論  必要に応じて「持ち帰る」  次回ミーティングまでに持ち帰った内容を検討・反映 2 

狙い・やってみたメリット 狙い  その場では出なかったがあとで出てきた疑問や懸念を次のミーティングで議題にできる  前回のミーティングから日が空いてしまっているので、そもそのこのPJなんだっけ？の再確認の時間を作れる  議論したい項目を時間内になるべく多く議論したい - 1つの項目に時間がかかりすぎる課題があったため やってみたメリット 認識すり合わせと議論が分かれたことで、議論パートの時間の確保ができた すり合わせで時間が終わるということがなかった すり合わせ自体すぐに終わったのと、要件確定してから日が空いてしまっていたのでPJ自体の再確認ができた（はず） 1 適宜「持ち帰り」を行なったことで一つの議題が終わるまで話す、ということがなく1時間内で取り上げられる議題が増え た 2 

反省  共有時点でPJの開発部担当者（主に私）から確認したい内容を伝え切れなかった 議論するミーティングより前にNotionで共有はしたが、それなりに量があったので確認し切れなかったと思う  どうしたか？ 議論し切れなかった項目を、次のミーティングまでに確認 して気になることなど記載しておいてほしいと依頼  事前に開発部担当者も把握できるので、議論内容が 「どうしましょうか」からではなく「いただいたこの 意見についてですが」から始められる  今後どうするか？  具体的な日にちを決めて、その日までに確認していた だく  課題 事前に共有したとして、運用部門の忙しさが掴み切れてい ないのでそもそも確認する時間があるのか不明  議論ミーティング時に「先に確認したいことあります か？」と聞いたら「特にない」と言われてしまったた め  実際、こちらから議題をあげたらご意見いっぱい出て きたため（Notion共有が直前過ぎたのもあるかもしれ ない） 

 感想  ミーティングの仕方やPJの進め方を今後も色々試していきたいと思いました。  そのためにもミーティング後の個人反省会や、書籍によるインプットを継続していきたいです。 

ご清聴ありがとうございました とぴ