SHARE

目次

目次

SHARE

リーダーシップとチームマネジメント

「質問数イベント史上最多!!心理的安全性Q&A」ZENTech 石井 遼介 × トラーナ めもりー

psychological-safety03-new-img

国内最大級 ITエンジニア向け勉強会プラットフォーム connpass においてグループ人数 No.1 の Forkwell Communityこれまでの開催イベントの中でも 「Forkwell Library #3 心理的安全性のつくりかた」は、当日参加人数が740人を超える大注目イベントになりました。Forkwell イベント史上、最大数となる50件を超える質問数で盛り上がりを見せた視聴者Q&Aから、投票数が多かった質問をピックアップしレポートします

 

Q1:健全な衝突を醸成するためのテクニック・アプローチはありますか?

石井:心理的安全性、仕事の基準がどちらも高い状態を目指すことが理想ですね。「心理的安全性は高いけど、仕事はどっちでもいいよね」だと、馴れ合いのヌルい職場になってしまいます。反対に「仕事の基準はめちゃめちゃ高いけれど、心理的安全性がめちゃめちゃ低い」と、キツい職場になってしまいます。では、仕事の基準はどうやってあげるか?ですが、事例講演のめもりーさんの発表の中でチームのミッションを数ヶ月に1回、考え直す機会を設けているというお話がありました。そこに多くのヒントがあるのではないかと思います。

めもりー:まさか振られるとは(笑)この図のようなアジェンダで、四半期に一度、チームミッションの定義をしています。

心理的安全性のスライド

目指す方向が異なると、チーム開発はうまくいかないので足並みを揃える必要があります。

— 目標の高さとバランスについて、もう少し教えてください。スタートアップって、あり得ないような高い目標を掲げる組織が多いと思います。現場のチームメンバー目線も大切にしつつ、めもりーさんのようなCTO目線での高い欲求を、どう伝えますか?コミュニケーションで気を付ける点は?

めもりー:そうですね。スタートアップらしくないかも知れませんが、このあたりが大事だと思います。

  • 達成できない目標を設定しない
  • その人がどこまでできるかの共通認識を作っていく

例えば、500万しか売れない営業に1000万売れと唐突に言っても、無理ですよね。だからまずは、750万を目指す。次に1,000万。750万と1,000万の間のギャップってなんだろうね?と会話しながら目標設定をしていくイメージです。

仕事の基準を上げる = 目標を高くすることではない

石井:仕事の基準を上げる = 目標を高くすることではないんです。先ほどのめもりーさんの話にあった、ミッションを四半期に一度、きちんと考えるところがポイントです。皆さんも「来期は5000兆円を売りましょう」と言われて「よし!」とはならないじゃないですか。仕事の基準を上げるというのは、それこそミッションやパーパスを言語化することが大事ですよね。

Q2:組織の中でマイノリティー側に属しており、心理的安全性を感じません。何かできることはありますか?

【質問全文】私は女性エンジニアですが職場に男性しかおらず、どうしても居心地が悪く心理的安全性を感じません。こういった状況の場合、本人の立場、もしくは自分がマネジメント側の立場になった時にできることはありますか?

—いわゆる会社の中でマイノリティー側だったり、派閥的な問題もあるかも知れないので「女性」に限定せず広い視野で回答いただきたいです。いかがでしょうか?

石井:自分がマイノリティー側だと感じるとき、心理的安全性が低く感じるのは事実だと思います。

① 自分ができること

なかなか難しいですが、まずは噛み砕いていくのがいいと思います。

  • どの瞬間に居心地の悪さを感じるか
  • 心理的安全性が低いなと感じる瞬間はいつか

言語化することで「こういう時にはこうして欲しい」という具体的な交渉の一歩が踏み出せるのかなと思います。

② マネージャーや管理職の立場でできること

まずはマイノリティーだけでなく、立場の弱い方から意見を聞いていくのは大事な進め方かなと思います。例えば、若手新入社員に「どう思う?」と最初に聞いてみて「なるほど。そう考えるんだね」と受け止めていく感覚ですね。

心理的安全性には 4つの因子に「新奇歓迎」という因子があるとお伝えしました。そのあたりがダイバーシティ、多様な人材を包摂していく感覚だと思うので、そこをどう広げていくかが大事なポイントかなと思います。

—ありがとうございます。めもりーさんはこちらはいかがでしょうか?

めもりー:そうですね。難しい質問だなと実はリハーサル時に話していて(笑)うーん、まずは、相手との相互理解を深めることが大事なんじゃないでしょうか?

  • 相手がどうしてそう思うのか
  • マジョリティー側の考え

このあたりを自分から聞いていく作業がないと、ずっとマイノリティー側に属してしまうのではないかと思います。つまり、マジョリティー側も巻き込んでいくような気持ちでやっていくといいのではないかと思いました。

石井:相互理解から始めると面白いですし、難しいことでも「まずはもうちょっと教えてもらいたいんです」と、聞いて理解を深めていくのは良い1歩かもしれないですね。

—マジョリティー側も、居心地を悪くさせようと思っているわけではなく、単純に知識がないので理解が阻害されているのかもしれないですよね。特にエンジニア業界の女性比率が低いのも、理解が深まらない理由かも知れません。相互理解から始める。良い回答ありがとうございました。

Q3:転職先などで「心理的安全性」が確保されているか事前に確認する方法は?

【質問全文】転職先や新たにジョインしたチームで心理的安全性が確保されているかどうかを確認するために投げかけると良い質問はありますか?

—転職先や新たにジョインしたチーム、これは入ってみないとわからない気がしますが、何かポイントはありますか?

石井:最近たまたまNHKさんから「就活での見分け方」というインタビューを受けまして、似たような回答をしたのですが、1つは「普段どういう言葉を使用しているか?」に注目すると良いと思うんです。

例えば

  • 社内の上下関係をどう表現しているか(上司 / 部下 / 社長 / リーダー / メンバー etc……)
  • 業務委託の方をどう呼んでいるか(パートナーさん / 下請け / 委託先 / あいつら etc……)

結構、普段からどう表現しているか、言葉に会社の特徴が出ますし、面接なんかでもポロっと漏れ聞こえたりしますよね。ちょっと違和感のある表現だと「この会社はマズいかも知れない……」と、仮説が立てられそうですよね。

Q4:チームMTGで積極的に意見を出せる雰囲気つくりの方法とは?

【質問全文】チームリーダーです。チームメンバー各自に、意見を積極的に出してほしいのですが、複数名集まるミーティングでは、あまり出てきません。1対1で話すと結構、意見が出てきます。効率が悪いので、全体の場で意見が出てくる雰囲気を作りたいのですがどうすればいいでしょうか?

石井:単純に人数が増えると話しづらくなりますよね。「本当はその会議に必要ないけど念のためにいてもらう」を削減するだけでも話しやすくなったりします。あとは小手先テクニックですが、それぞれ個人が考える5分ほど確保して、メモしてもらい、終わったらチャットに貼ってもらうとか。それから「誰か意見ないですか?」と聞くのではなく「◯◯さん意見ないですか?」と指名する方法もあります。

めもりー:うちも「あれ〜めちゃくちゃ話したそうな顔してるじゃない」みたいなのを人に振ったりとかはしますね。

その他だと

  • 人数が多いと発言しづらいので出来るだけ削ぐ
  • テキストで完結できる文化の醸成

これらを意識しています。それでも、全員の前で言えない人はDMで吸い取る。そこは効率云々ではなくて、パーソナリティに合わせて運用しています。結局、参加者に「心理的安全性が高くない」と感じられたら、そこでおしまいだなと思っているので、そこは尊重してやっているような状況です。

石井:いいですね。あとは「その意見違うな〜」と思っても、バッサリ切るのではなく、いったん受け止めたうえで進めていくことも大切ですね。

Q5:オンラインで「心理的安全性」をつくる方法とは?

—コロナになり、フルリモートをベースにする企業が増えてきましたが、実際オフライン、オンラインで変わるものなんでしょうか?

石井:そうですね。変わります。まず、オンラインの方が心理的安全性の重要度って高いんですよね。例えばオフラインだと、隣で新人の営業パーソンが電話をしていて「どうもお客さまから、お叱りを受けているようだぞ」と察すれば、すぐに助けに入っていけると思いますが、オンラインだとその状況って見えないですよね。

だからどんな相談や困りごとでも、すぐに報告してもらえる環境・関係をつくることが、オンラインやリモートの状況でこそ大切です。

仕事をしてもらったら「ありがとう」を即レスする

実は我々 ZENTechという会社も、設立当初からほぼオンラインだったんです。オンラインでも良いチームがつくれることは、自信を持ってお伝えできます。

オススメのやりかたは「返事はゆっくり、でも反応は即レス」です。どういうことかというと「企画をつくりました」「これを、ここまでやりました」とか、Slackなりメールなりで報告が来ますよね。そういう業務、特に重い業務をしてもらったら、即レスしましょう。

ちゃんと返事をしようと思うと、文章を読み込んで、コード読んで、理解してと結構時間かかっちゃいますよね。忙しいと、そのような時間を確保するだけでも一苦労です。

でも報告した方はその「返事」を待っている間「せっかく書いたのに何か上司がコードレビューもしないまま放置してる」「なんか怒ってるのかな」とか、いろんな妄想をしてしまいます。だから、まずは「そこまでやってくれてありがとう」ってひと言書くだけ。きちんとした返事が伸びそうなら「週明けまでには見るね」とひと言追加する。10秒で終わります。

簡単な作業ですが、そのひと言があるかだけで報告した側の感触としては違うんですよ。

ちゃんと返事をするのは後回しでいいので、まずは「ありがとう」っていうことを即座に打ち込むっていうのが大事なポイントだと思ってます。

めもりー:私たちの場合はSlackの絵文字を大量に作ってですね、登録しまくるっていう仕事をわざわざ上のポジションについてる方が、あえてやっています。上のポジションに立ってる人も「自分たちはこう会話をする意思があるよ」っていうのを伝えていくのがすごい大事かなっていうふうに思っております。

石井:いいですね。うちも「圧倒的感謝!!」っていうスタンプとかあります(笑)そのうち略されて、ひらがな4文字で「あっかん」っていうのとかもありますね(笑)

めもりー:あっかん(笑)

— 弊社も結構いろんなメンバーの名字に神って付いたスタンプシリーズが結構あってみんな神様になってますね(笑)

石井:神いいですよね。あと「まじ天才」とかっていうスタンプもありますね(笑)

—心理的安全性が高い職場だとスタンプの数が多いみたいな観点は、もしかしたらあるかもしれないですよね(笑)

めもりー:もしかしたらあるかも知れない(笑)

石井:ありそうですね(笑)

Q6:やる気のない人、ルールを守らない人へのフィードバック方法とは?

—指摘すべきことは指摘しつつ、心理的安全性を保つ振る舞いっていうのは、なかなか難しいですよね。要は人間関係がそこで壊れるんじゃないか、とか考えてしまうわけですが、何か心がけた方が良いポイントはありますか?

石井:人格否定をせず、行動だけをフィードバックすることですね。フィードバック後に、きちんと理解し、行動が変わりそうなのであれば、あとはもう引きずらないってことが大事です。

仕事でバチバチにやり合っても、その話が終わったら「このあと寿司食いに行こうか」みたいな。議論は議論、そのあとの人間関係は、きちんと切り替える。

—フィードバックを受け取る側が、行動に対してのフィードバックを勝手に人格に結び付けてしまうことが多いのかなと思うのですが、何か防止策はありますか?

石井:僕はこのあたりに気を付けています。

  • 1回の注意で直ったら掘り返さない
  • 一貫性を持つ
  • 気になったことは、できるだけすぐにその場で指摘する

もし何度も注意して変わらない場合、もう一度フラットに言うっていうのをやり続けることで、何か伝わるものがあるかなっていう感覚ですかね。

めもりー:そうですね。まず、なぜそのルールが存在しているかを論理的に説明します。コードに対する指摘を、なぜか人格否定に受け取ってしまうみたいなことってエンジニア界隈だと、あるあるかも知れません。そのコードのルールは、なぜ存在しているのか?を、話すと良いのかなぁなんて思います。

—ありがとうございました!

動画視聴はこちら

Forkwellキャリア相談

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

取締役

東京大学工学部卒。シンガポール国立大学 経営学修士(MBA)。神戸市出身。研究者、データサイエンティスト、プロジェクトマネジャー。組織・チーム・個人のパフォーマンスを研究し、アカデミアの知見とビジネス現場の橋渡しを行う。心理的安全性の計測尺度・組織診断サーベイを開発すると共に、ビジネス領域、スポーツ領域で成果の出るチーム構築を推進。 2020年9月に上梓した著書『心理的安全性のつくりかた』(日本能率協会マネジメントセンター)は24刷・13万部を超え、読者が選ぶビジネス書グランプリ「マネジメント部門賞」、HRアワード2021 書籍部門 「優秀賞」を受賞。

めもりー
めもりー
「レガシーコードとどう付き合うか」著者

複数のスタートアップを経て,GameWith や BASE といった上場企業でソフトウェアエンジニアとして従事。2020 年に株式会社トラーナに一人目のエンジニアとしてエンジニアリングマネジャー兼テックリードとして入社。2022 年 1 月に執行役員 CTO として就任。2023 年 5 月末に,執行役員 CTO を退任。同年 6 月より暫定無職。PHP 関連のカンファレンスやイベントなどで数多く登壇。拙著に「Swoole で学ぶ PHP 非同期処理」,「レガシーコードとどう付き合うか」,そのほか Software Design などに寄稿。