CLOSE

プロダクトリリースと心理的安全性(全2記事)

時間もお金もない開発状況でも、心理的安全性は作れる イノベーションを起こすチーム作りに必要な、リーダーの心構え

「プロダクト筋トレ」は、「プロダクトづくりに関する知識を広げ、深め、身につける」を目的に活動をしているコミュニティです。プロダクトマネージャーカンファレンス2021の非公式な非採択セッションイベントとして開催された「プロ筋Conf」には、9seconds株式会社(※登壇当時、現在はQuicker)から宇田川嵩史氏が登壇。予算や期日を動かせない状況で、チームの心理的安全性を保つためにやってきたことを発表しました。

「土台を作る」の評価アベレージは4.3

一つひとつ見ていきましょう。1個目の「土台を作る」というところですね。これがベースとなる最初のところなんですが、チームからの評価のアベレージは約4.3でした。

「土台を作る」はどういう項目かというと、仕事の目的の共有だったり、僕たちはなぜこういうことをやっているのかということの共有だったり、その文化ですね、素直さを重視しましょうであったり、失敗しても大丈夫ですよみたいな、文化醸成の項目がどれだけできているかというところです。

最終的には、心理的安全性はけっこうあるんじゃないの? という結果なので、なんか変な話なんですが、土台となる行動はしっかり取れているというのが、個人的に思ったことですね。

評価された行動としては、そもそも開発自体やデザインの難しさが持つ不確実性を僕自身がしっかり理解していて、メンバーに共有してそれをベースに開発しているところはよかった、という話がフィードバックとして返ってきていました。

あとは、顧客の課題や機能の目的が、イシューや主要なところにしっかり書かれていて、それをベースに議論ができるのもすごく良いという話でした。

一方で、失敗なんですけど。これは見積もりとかに関わっているみなさんはご存じだと思いますが、どうしてもやってみないとわからないことだったり、そもそも期限に間に合わないみたいなことが多発していました。そこは伝えてもらわないと困るんですが、伝えた上で企画・仕様側で調整して対応されるのはすごくよかったという話がありました。

「参加を求める」は課題を残す結果

2つ目の「参加を求める」というところですね。これがどういう項目かというと、発言しやすい態度をしているか、発言を促す仕組みができているかの項目です。

僕個人の感想としては、質問自体はあまりできていなかったというか……どうしても僕自身は聞かれる側だったので、アイデアを求めたりとか、そこの質問に関してはやはりぜんぜんできていませんでした。実際、結果も3と3になっているので、ここはもっとやっていかなきゃいけないなと思ったところですね。

もう1つ、アイデアを出したり失敗を共有するというところも、やはりプロセスの確立までは至っていません。個人としては実際の評価を4にしていますが、実際のチーム評価はもう少し低くて、そこのアイデアを出すというところまでの仕組み化があまりできていないと感じました。

評価された行動について。不確定事項というか、あいまいな仕様や機能を一緒に決めていこうというのが感じられたのは、すごくよかったという話です。そこでけっこうしっかり参加できたんだなと感じました。

ほかには、開発チームは週次でチケットの内容をそれぞれでしっかり確認する時間を取っているなど、なにか起きた時にはとりあえずイシュー化しましょうかというかたちで、イシュー化が徹底されているところは、最低限の仕組みとしてはよかったという話が出ていました。

「生産的に反応する」の評価アベレージは4.2

最後ですね。「生産的に反応する」というのが、アベレージ4.2で一応マルにしています。自己評価で1をつけているところもあるので、そこをちょっと共有できればと思います。

この項目が何を指しているかというと、積極性や生産性を上げる行動ができているかです。

感謝や失敗への対応には、個人的にも気をつけていたので、そこに対してはよかったのですが、違反に関しては未策定となっています。

ここは書籍でも書かれているのですが、心理的安全性を守るためには、その心理的安全性を脅かす人に対して制裁措置というか、厳重注意を含めて対応しなければいけません。心理的安全性を自分たちの文化として作っている上で、どういう行動がそこに対するルール違反なのかを決めなければいけない、みたいなところがあります。

正直、そこに関してはまだできる状況ではなく、文化を作っている最中だったので個人評価としても1にしています。チーム評価が3.3になっている理由は、どう点数化していいかわからないのでとりあえず3、みたいなことになった結果、3.3になっています。

一方で、感謝と失敗の項目で評価されたのは、チャットと口頭の両方で、仕事に対して感謝されることが多かったというのがありました。

また、機能開発をしているとどうしても、「この機能やはり要らなかった」とか、あまりいいことではありませんが、「ちょっと大きく注力する機能が変わりました」みたいな方針転換がある時があります。「そういうところに関してしっかり説明と謝罪があった」というのが、フィードバックとして返ってきたのはよかったと思っています。

時間やお金がない厳しい状況でもチームの心理的安全性は作れる

結論ですね。「土台」と「対応」はいいが、「参加」はまだまだでした。土台と対応については、そもそも僕自身も開発していてデザインも開発もある程度わかっているので、そこが共感しやすいというか、大変なことがわかっているというのがまず大きかったと思います。

あとは、後ほど参考のところにも出しますが、HRT(Humility、Respect、Trust)というので、謙虚・尊敬・信頼を大切にしようという話をちょっとしています。そこをベースにしていることが、今回のチームの心理的安全性が高いところにけっこう影響しているのかなと思っています。

ただ、今回の開発にはお金も時間もなく、どうしても意思決定者がほぼ僕になってしまうとか、議論をする時間がないというところで、僕自身が「もっといい方法ないですか?」と、あまり聞けていなかったというのがあります。引き出すコミュニケーションなど、もっとよくする方法ができていなかったのが今回の反省です。

先ほども少し言いましたが、メンバーもまだかなり少ないので、カルチャー違反などの対応はこれからだなと思っています。

最終結論としては、時間がなかったりお金がなかったりという厳しいチーム状況でも、いったん「リーダーのツールキット」の行動が取れていれば心理的安全性は作れるのではないかな、と思っています。

「最後に」というところで。今回は、先にクォーターのふりかえりをして「このチームはけっこう心理的安全性が高いんじゃないか」というところから、何をしていた、できていたから、心理的安全性が高かったのか? というのを見てきました。

『恐れのない組織』という本で、「どういうことをしているべきか」という話もけっこうあるのですが、「どうやったら心理的安全性が損なわれて、その結果どういう災害を引き起こすか」というところまで全部研究されているので、もしよかったら読んでみてください。

先ほどちょっとだけ話していたように、エンジニアの方だと読んでる方がけっこう多かったりするのですが、Googleのエンジニアチームが何を大切にしてチームを作っているかという話が『Team Geek』にも書かれているので、もしよければ読んでみてください。

最後に、「We are hiring!!」と私たちも採用をこれから加速していくということで、エンジニア、デザイナー、プロダクトマネージャーも含めて、今回の発表について気になることとか、雑談ベースでもいいので、もしよかったら応募をしてみてください。ということで、以上です。

チームが拡大した時の変化の有無に注視していきたい

司会者:ありがとうございました。ちょっと私から質問してもいいですか?

宇田川:はい、ありがとうございます。

司会者:すごく雑な質問になっちゃうかもしれないのですが、宇田川さんみたいなCTOとかCPOとかの立場の方から、こういうことで「アンケートを取りたいんだけど」と言われた時に、社員さんは少なからず忖度しなきゃみたいな、そういうメンタルになっちゃうかなという気もしたり、そういうイメージもあるかなって思ったんですけど。

そういうことに対して、今回どういうアンケートの取り方をしたのかも聞いてみてよろしいですか?

宇田川:そうですね。確かにけっこうそれは難しいなと思っているところもあります。一応アンケート自体は匿名にしているのですが、今のこの人数だと、誰がどう回答しているかが全部わかるので、それはちょっとありますよね。

前提として、チームメンバーには「素直に言ってほしい」と伝えたり。そもそも失敗の共有も含めてあのアンケートの結果自体が、心理的安全性が高いチームにできていたりすることだと思うので、今回というより、今後ずっと見ていった時に今のこの結果に変化があるかないかというほうが、個人的には気になっているところです。

今のチームは最初なので、「いい人を採用して、いいチームができていて当然でしょ」みたいにどうしてもなってしまいます。今後メンバーが増えて、「ピザルール」と言われている8人とか、もうちょっとチームが大きくなってきても同じ状況を保てていられるならいいんですが、たぶんそんなことはないと思っているので、そこをもうちょっと見たいなとは思っていますね。

司会者:確かにそうですね。現状を上げていくとか、「今がよかったらよかったね」ではなくて、これを継続して追っていって、事業をグロースしていった中でもきちんとこれが維持できているかを測定していくのが大事ですね。

宇田川:そうですね。

司会者:なるほど。私も理解が深まって助かりました。ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!