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
心理的安全性を0から80ぐらいに上げた話
Search
Yusuke Hisatsu
July 27, 2022
Business
0
520
心理的安全性を0から80ぐらいに上げた話
2018/10/24 Roppongi Product Manager Meetup #6での登壇資料です。
Yusuke Hisatsu
July 27, 2022
Tweet
Share
More Decks by Yusuke Hisatsu
See All by Yusuke Hisatsu
アンラーニングし続けるプロダクトマネジメント
yusukehisatsu
2
830
チームで盛り上げる ファシリテーション
yusukehisatsu
19
13k
新卒者向け資料_タスクマネジメント・ドキュメンテーション
yusukehisatsu
0
410
プロダクトのための地味な動き - 地味PM meetup
yusukehisatsu
7
8.7k
システム思考とプロダクトマネジメント
yusukehisatsu
20
16k
JobsToBeDone/ジョブ理論をまとめてみた
yusukehisatsu
6
6.3k
幅広い経験を活かして PdMになった話@Kiitok meetup
yusukehisatsu
0
240
エンジニアチームビルディングジャーニー
yusukehisatsu
0
340
心理的安全性の高いチームを作ってみた
yusukehisatsu
1
520
Other Decks in Business
See All in Business
成功をつなげる プロジェクトマネジメントの探求 / Exploring Project Management to Continuous Success
tunepolo
0
170
仮説のマップ・ループ・リープ
tumada
PRO
11
4k
LayerX AI・LLM Division Deck
layerx
PRO
0
1k
無自覚にメンバーの心理的安全性を奪っていた経験から得た学び
lighttiger2505
142
190k
【エンジニア採用】BuySell Technologies会社説明資料
buyselltechnologies
2
55k
CData 製品を使って不動産API を可視化!実際に注文住宅を買ってみるまでの話
cdataj
2
150
pmconf2024 意思決定の質とスピードを上げるドキュメントの極意
issei123
1
6.6k
FinOps入門×三大クラウドコスト削減術_Azureコスト削減ポイント紹介
katsura127
0
140
ストーリーテリングでチームに”熱"を伝える🔥
inagakikay
1
10k
行動なしに良い仮説思考はできない
tumada
PRO
6
880
Theoria technologies:About Us
theoriatec2024
1
5k
署内デジタルインフォボードの開発
tokyo_metropolitan_gov_digital_hr
0
330
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
44
13k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Designing for humans not robots
tammielis
250
25k
RailsConf 2023
tenderlove
29
940
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Building Applications with DynamoDB
mza
91
6.1k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Docker and Python
trallard
42
3.1k
Transcript
⼼理的安全性を 0から80ぐらいに上げた話 2018/10/24 Roppongi Product Manager Meetup #6 久津 佑介
話したいこと ⼼理的安全性が0の組織を 試⾏錯誤して80ぐらいに上げた話
Google “Project Aristotle” 「効果的なチームの条件は何か」 引⽤元:re:Work - ガイド: 「効果的なチームとは何か」を知る https://rework.withgoogle.com/jp/guides/understanding-team- effectiveness/steps/identify-dynamics-of-effective-teams/
1年前 この機能を◦⽉まで に作れ!クライアン トが⾔ってるんだ! 偉い⼈ 事業担当者 開発チーム 関連部署 はい・・・ (スケジュールがタイト
だなあ) はい・・・ (何のためにやるのかわ らないけど) はい・・・ (そんなクソ機能いら ねぇよ) PM
⼼理的安全性がほぼゼロ ただ「明るく話す」とか「雑談する」と⾔ったレベルの 改善では何も変わらない 根本から⽴て直すための挑戦
3つのポイントと⽬指す姿 ü1on1 ü⼩改⾰ ü⼤改⾰ ヒーローになる
1on1 ⾃分が⾔っても意味ないので… 全体像を把握しておらず、 何を⾔っていいのかわかりません どうせ⾔っても決まっちゃったこと なので無駄です PM üとにかく多くの⼈から情報を得る ü最初はなかなか問題の核⼼に迫れない
⼩改⾰ 全体像を把握しておらず、 何を⾔っていいのかわかりません PM ü⼩さいことから解決していく 毎週⽉曜のミーティングで全体像と状 況を説明するので、参加してください どうせ⾔っても決まっちゃったこと なので無駄です PM
決まっていること・決まっていないこ との可視化をしておきます
ひたすら繰り返す 1on1 ⼩改⾰ ü「解決してくれる⼈」というイメージが⽣まれる ü⾔われる不満や悩みの量が増える ü問題の本質が⾒える
⼤改⾰のヒント どこで何が決まってるか わからないんです ⼈によって⾔っていることが 違うんです いつも話をひっくり返してしまって 申し訳ないです… ü多くの不満や悩みに共通する根本原因が⾒えてくる 「知らない」こと による不安
意思決定プロセス に問題が?
⼤改⾰ 意思決定プロセスの変更と可視化を 実施する! ü根本原因をできるだけ仰々しく解決しにいく ᎄͦͷҰ ҙࢥܾఆऀΛ̍ਓ͚ͩʹ͢Δ ᎄͦͷೋ ҙࢥܾఆΛߦ͏ΛఆΊΔ ᎄͦͷࡾ ҙࢥܾఆͷഎܠɾ༰Λશެ։͢Δ
PM
ヒーローになる ü再び不安になっても解決してくれると思われる存在 ü本⾳を受け⼊れてくれる存在 ⼼理的安全性の象徴
なう 偉い⼈ 事業担当者 開発チーム 関連部署 PM この機能を◦⽉まで に作れ!クライアン トが⾔ってるんだ! やりましょう!
ただしタイトすぎる ので期⽇は伸ばしま しょう これちょっとリス クありません?確 認しておきます こういう機能の⽅ が効果出るよ!
3つのポイントと⽬指す姿 ü1on1 ü⼩改⾰ ü⼤改⾰ ヒーローになる
おまけ 開発チームの ⼼理的安全性を上げるために ⾏ったこと
1.メンバーに期待する、信頼する ü⼼からメンバーを信頼しないとバレる。どんなに信頼し ているふりをしてもバレる。 üもちろん苦⼿分野もある。だったらそれに合わせたレベ ルの「期待」「信頼」をしてあげれば良い。 ü「◦◦さんはドキュメント作成は苦⼿だから期待しない けど、コーディングは信頼している」みたいな。(⾃尊 ⼼を傷つけない範囲で)
2.ビジョンを語りまくる ü組織が⽬指すビジョンを⾃分事として語りまくる。 ü「俺はこうしたいんだ、だから協⼒してくれ」というス タンスを、これでもかってほど伝えまくる。 ü「求められている感」を出していくことがモチベーショ ンの維持、上昇に繋がる。
3.メンバーの仕事に極⼒⼝を出さない ü⽬指すのは「メンバーが⾃分の仕事に責任を持つ」とい う状態。なのでその責任範囲の仕事には⼝を出さない。 ü不安事には相談に乗ってあげるが、いちいち細かく チェックしない。⼩⾔とか⾔わない。 ü最初はいろいろ問題も起こる。時間と我慢と勇気が必要。
4.会議・ミーティングでは 明るく話し、しっかり聞く üどんなに忙しくても、ミーティングでは明るく振舞う。 ü冒頭にアイスブレイクとして⼩話でも⼊れたり、メン バーに話してもらったりする。ただし無茶振りは厳禁。 üメンバーの発⾔はしっかり聞く。キーボード打ちながら 聞くのはダメ。⼿を⽌めて話している⼈の⽅を⾒てちゃ んと聞く。
5.問題をみんなで解決する場を作る üミーティングは各メンバーの抱えている問題を⾔っても らい、何かしらの解決⽅法を提⽰してあげる。 ü最後に「もしこれでも解決しなかったら◦◦さんに声か けて」「◦◦さんはその時こう助けてあげて」と、さら にその次の解決⽅法まで提⽰してあげる。 ü「悩みを⾔えばチームが助けてくれる」と認識してもら う。
6.メールやチャットでは即レス ü「⾃分の意⾒や質問はよくほっとかれているから、発信 しても意味がない」と思われるのは最悪。なので即レス。 üもし本当に忙しくて質問を受ける余裕がない場合でも、 その状態を正直に⾔うだけで良い。 ü「ごめん、今余裕がないから回答に時間がかかるかも」。
7.メンバーの意⾒を⼤切にする ü頻繁に「何か意⾒やアイディアがあれば⾔って」と⾔う。 ü出てきた意⾒はしっかり拾って、必ず何かしらの答え (採⽤するか⾒送るか)とその理由を伝える。 ü絶対に放っておかない!
8.ライトな1on1をする ü⽬的はメンバーからの不満やチームの隠れた問題点、⼤ 事にしている価値観などを早い段階で⾒つけること。 ü⼤々的に「不満を⾔え」とすると、他のメンバーがどう いう不満を⾔ったのかも気になってしまうので、こっそ り聞くのが良い。 ü他のメンバーに⾒られていないところで「最近どう?な んか問題ある?なければいいよ」ぐらいのかるーい感じ。
落とし⽳
落とし⽳ üスキルの⾼いメンバーの独裁が始まる üチームの⼼理的安全性が⾼くなってくると、意⾒交換や 質疑が活発になる。そこに⼀⼈スキルの⾼いメンバーが いると、その⼈の意⾒が採⽤されることが多くなる。 üその状態が続くとそれ以外のメンバーは「どうせあの⼈ の意⾒が採⽤されるから⾃分が⾔っても仕⽅ない」とい う⼼理状態になり、再び⼼理的安全性が低くなる。
落とし⽳にハマったら… üスキルの⾼いメンバーの視座をあげる。つまりチームの ために動いてもらう。 üチームを分ける。スキルの⾼いメンバーに頼れない状況 を作る。 üスキルの⾼いメンバーを外す。