イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです。ITトレンド・List Finderの開発をベースに、業務外での技術研究などもブログとして発信していってます!


このエントリーをはてなブックマークに追加

開発組織こそ心理的安全性が肝になるのではと思っている話

こんにちは。ozasaです。
最近はコードに触れる機会が多かった反面、
組織のことを考える時間が取れなかったので、
自分の頭を整理する意味でも改めて組織の話に向き合ってみました。

昨今「生産性向上」や「イノベーション」をキーワードに
労働環境を見直す動きが盛んであると思います。

また、同じような文脈でリモートワークを禁止とする企業も出てきており、
コミュニケーションやそれによるコラボレーションの改善などが
謳われるようになってきてます。

そんな社会背景があり、「心理的安全性」というキーワードが注目されてきています。

心理的安全性とは

元はハーバードビジネススクールの教授である エドモンドソン氏 による 『Psychological safety and learning behavior in work teams』(1999)が初出の言葉になりますが、 Googleが2015年に 『re:Work』 で取り上げたことで注目を浴びています。

Googleは心理的安全性について

Psychological safety was far and away the most important of the five dynamics we found — it’s the underpinning of the other four.

とし、Psychological safety、Dependability、Structure & clarity、Meaning of work、Impact of workという 組織が成功する鍵の中でもっとも重要であると言っています。

また、その効果について

Individuals on teams with higher psychological safety are less likely to leave Google, they’re more likely to harness the power of diverse ideas from their teammates, they bring in more revenue, and they’re rated as effective twice as often by executives.

とし、生産性だけでなく離職率の低下についても効果があると触れています。

ここで紹介した以外にも様々な効果が報告されている心理的安全性ですが、 最近流行りだしたからなのかあまり日本語の"論文"は出てきていないようです。 ※CiNiiで「心理的安全性」と検索した結果です

開発組織にこそ必要だと思う理由

当然ですが、エンジニアリング行為のほとんどは自分だけでは完結しないものが多いです。
プロダクトバックログによるコミュニケーション、
スプリントプランニングやスプリントレトロスペクティブもありますし、
設計やコードレビューも他者とのコミュニケーションが必須です。

チームで開発を進める上で心理的安全性の有無はどのような差を生むことになるのか、 考察してみました。

以下はスクラム開発において、 上記の条件を想像して書いてみたものになります。 あくまで個人的な意見ですが参考になれば幸いです。

スクラムイベント 心理的安全性あり 心理的安全性なし

プロダクトバックログリファインメント

バックログで理解できていない部分に関して質問をすることができ要件のすり合わせができる

理解力がないと思われることを恐れ、理解しないまま実装に入る

デイリースクラム

進捗を明確にした上で自分の作業の阻害になっていることを報告できる

できないと思われることを恐れ、進捗を曖昧に表現してしまう。阻害の報告もしない

スプリントプランニング(キックオフ)

プランニングポーカーで見積もりが合わない時妥協せず話し合う

できないと思われることを恐れ、他の人の出方を伺いプランニングする。

スプリントレトロスペクティブ

課題を様々上げることができ、なおかつそれを解決するための議論ができる

衝突することを恐れ課題をあげない。または自分に関わる課題のみをあげる。

コードレビュー

疑問/質問をぶつけたり、書き方の修正を依頼できる。

特に意見せずレビューを終える。その後気になる部分は自分で修正してしまう。

極端な例にはなってしまいますが、恐れや遠慮はチームの能力に影響があるように思えます。

心理的安全性を高めるには

心理的安全性という言葉が使われている訳ではありませんが、 チームの信頼醸成として『あなたのチームは、機能してますか(2003.パトリック・レンシーオ著.伊豆原弓編.株式会社翔泳社発行)』の中では

長期間にわたって経験を共有し、なんども約束を守って信用を高め、ここのメンバーの特徴を十分に理解する必要がある

とされています。

チームで働くからこそお互いを知ることはまず第一に必須ということですね。 お互いの価値観や考えを肯定し合う必要は決してありませんが、 少なくともその違いを知り、認め合うことは必要なのではないでしょうか。

終わりに

いかがでしょうか?

難しいのは心理的安全性を担保しつつも、 様々なことにコミットメントをしていくこと(ある種の厳しさ)、そのバランスを取るだと思います。

それすらもチームの中で解が出せるとするならば、きっと良いチームなのでしょう。
色々書きましたが、良いプロダクトを作っていくためにも良いチームを作っていくことが重要だと考えます。

良いエンジニアライフを!

余談

コードレビューにおいて typoを指摘したつもりで 「typpですかね?」とコメントしたことがあり、 逆にそれを指摘された恥ずかしい思い出が蘇ったのでここで晒しておきます。