Joshua Kerievskyとモダンアジャイル
2016年にJoshua Kerievskyが提唱したモダンアジャイルでは、モダンアジャイルへ向かうための4つの原則*1を柱としています。なお2017年には来日してアジャイルジャパン2017の基調講演で、日本のアジャイル界隈にモダンアジャイルを紹介しました。
- 人々を最高に輝かせる
- 安全を必須条件にする
- 高速に実験&学習する
- 継続的に価値を届ける
この中の「安全を必須条件にする」には心理的安全性が含まれます。同時にモダンアジャイルでは、心理的以外の安全性についても重要性を説いています。Joshua Kerievskyは以前からAnzeneeringという考え方を提唱しています。この言葉は日本語の安全(Anzen)と英語のengineeringを組み合わせた、Joshuaの造語です。彼はIndustrial Logic (Joshuaの会社)のページで、以下のようにAnzeneeringを紹介しています。
- Anzeneerは様々な要素から人びとを守る
- 様々な要素とは、たとえば人間関係、作業環境、プロセス、プロダクトなど
- 人びととは、利用する人、作る人、マネージャ、買う人、利害関係者など
- 安全はすべてのリーンやアジャイルの共通項である
Joshua自身も、エイミー・エドモンドソンやGoogleの研究に触れて心理的安全性を紹介したりしているので、Anzeneeringやモダンアジャイルと心理的安全性は直接関係していると思われます。
いっぽうでJoshuaは心理的以外の要素も大事だとしています。ソフトウェア利用者をソフトウェアの問題から守る、開発者を質の悪い危険なコードから守る、マネージャが進捗を把握できるよう守る、などです。「高速に実験&学習」するには、実験や学習の中で失敗したり問題が起きても、それが人びとの安全をおびやかさないような環境が前提となります。
思うに、心理的安全性が対人リスクを減らし学びと効果を生み出すという現象が、とりわけソフトウェアの領域では人間関係に限定されず幅広いリスクについて言えるのではないでしょうか。たとえば、間違ったことを言っても怒られない、指摘を受けて訂正すればいいという状況は、アジャイルなソフトウェア開発においては、間違った機能を作っても、ユーザーの指摘を受けてすぐ直せばいいという状況に似ているように思われます。モダンアジャイルが言及するのはソフトウェアに限りません。人間が中心となって価値を産み出すという幅広い領域において、アジャイルが有効だというメッセージです。そうした中で心理的安全性は、仕事の多くの側面で有効であり、大事にすべきなのではないでしょうか。
GoogleのProject Aristotle
心理的安全性が特にIT業界で注目されるようになったきっかけの一つが、Googleが社内でおこなった調査プロジェクトです。社内の様々なチームを調べ、効果的なチームの条件は、そのメンバーの能力ではなくチームの働き方にあると発見し、5つの要素を挙げます。中でも最も重要とされたのが、心理的安全性でした。なおチームの効果性(effectiveness)は、この研究の中で独自に定義しており、エグゼクティブの評価、チームリーダーの評価、チームメンバーの評価、四半期のセールス成績の4つの観点から評価しています。
以下の図では、重要な5つの要素として心理的安全性に続き、人を信頼できること、構造と明快さ、個人にとって仕事が有意義であること、チームの成果がインパクトを持つことを示しています。
Googleの研究を紹介するThe New York Times Magazineの記事にはこう書かれています。
…Googleでは誰も「仕事の顔」を着けて職場に来たいとは思っていません。誰も、個性や人生の一部を家に置いて来たいとは思っていないのです。仕事に100%集中するために、心理的安全性を感じるためには、人を脅かしたり驚かしたりしかねないような話であっても、非難を恐れず自由に発言できるのだと意識している必要があるのです。…効率だけを考えていてはいけません。…仕事とは単なる労働以上のものだと考えたいのです。
エイミー・エドモンドソン
エイミー・C・エドモンドソンは90年代から心理的安全性についての研究をしています。書籍『チームが機能するとはどういうことか』(2014年)では、心理的安全性について以下のように書いています。
「「心理的安全」とは、関連のある考えや感情について人びとが気兼ねなく発言できる雰囲気をさす。」
1999年の論文では「チームの心理的安全とは、対人のリスクを取っても安全であるという、チーム全員の信念である」としています。このように、心理的安全性とは人間どうしの関係、主にコミュニケーションに関する状態を指す概念です。
心理的安全があるチームでは、以下のような状況が作られます。
- 心配や懸念がオープンになる
- 失敗しても支えてもらえる
- 全力を出せる、新たな挑戦ができる
- 成功と失敗の両方から全員が学ぶ
2014年の論文(Edmondson and Lei)では、心理的安全性についての研究をふりかえり、多数の研究結果をまとめています。心理的安全性は1960年代から研究が始まっていて、90年代以降急速に注目されるようになりました。60本以上の研究を調べた結果として、現時点(2014年時点)では以下のような考察がされています。
- 個人レベル、組織レベル、チームレベルそれぞれの研究があり、いずれのレベルでも心理的安全性は生産性などによい影響を与える
- 心理的安全性がより強い影響を与えるのは、仕事に不確実性がある場合かつ、人どうしの協調が必要な場合である
- 心理的安全性によって組織やチームでの生産性がもたらされるのは、組織やチームでの学習が促進されるためである
- 組織の学習はもっぱら、独立した個人どうしが関わり合う中で生まれ、そこでは対人リスクがない状態が望ましい
- 心理的安全性がある職場では、人が "Speak Up" する ―― 声を上げたり異を唱えたり、新しいアイデアを出したりするようになる
グループ(チーム)レベルにおいて心理的安全性を取り巻く要素が、次の図のように整理されています。(Google Draw) 心理的安全性の前提となる要素(リーダーシップや信頼など)と、心理的安全性がもたらす影響(学習やパフォーマンス)や、心理的安全性が効果を出すときに求められる要素(不確実性とリソース不足など)の関係を示しています。
心理的安全性について (RSGTアドベントカレンダー2018)
RSGTアドベントカレンダー2018のエントリです。昨日はJean-Baptiste Vasseurさんの「RSGT2019 スポンサーブースでスカベンジャーゲームをやる!」でした。明日はTakao Oyobeさんの「私がアウトプットする理由」 です。
ファン・ダン・ラーン(FDL)ふりかえりボード
ふりかえりで使える手法としてKPTやYWTなどがありますが、新しくファン・ダン・ラーン(Fun/Done/Learn)というアプローチを作ったので紹介します。チームがやったことを、Fun、Done(またはDeliver)、Learnという3つの軸とその重複で見直します。上の図のように、Fun、Done(Deliver)、Learnのを重ね合わせた図をボード上に書いて、そこに分類していきます。
この図を見れば、経験のあるファシリテーターやスクラムマスターなら自分なりのやり方が思いつくのではないでしょうか。ぜひ自由に使ってみてください。以下では、私たちが実際に試してみた方法を紹介します。
- まずホワイトボードや模造紙に、上のFun/Done/Learnの図を描く。重なり合う領域が狭くなりすぎないよう気をつけること
- メンバー1人ひとりで、やったことを付箋に書き出す
- 付箋の内容を共有して会話しながら、図上の当てはまる領域に付箋を貼っていく。
- 付箋を書いた人ではなく、他のメンバーが貼り付ける領域を選ぶようにすると面白いです
- 例: 「みんなでゲームで遊んだ」→ 楽しかったのでFunの円の上半分(他と重ならない部分)に貼る
- 例: 「モブプロでスキルを共有したが進みは遅かった」 → モブプロでモチベーションが上がったのでFun、スキル共有したのでLearn、Doneにはつながらなかったので、FunとLearnの重なる右中央の領域に貼る
- 例: 「新たにVue.jsで機能を実現できた」→ やって楽しかったし、Vue.jsを学べたし、機能をリリース(提供)できたので、Fun/Deliver/Learnの重なる中央部分に貼る
- 次にスプリントやプロジェクト全体としてどうだったか、当てはまると思う領域に1人ずつ選ぶ(シールを貼ったり、ペンで印をつけたりするとよい)。スプリントならスプリント全体、プロジェクトならプロジェクト全体についての評価をする
- ボードを眺めながら、次のスプリントやプロジェクトではどの領域を狙いたいか話をする
進める中で、LearnやDeliverとはどういう意味なのか、疑問が出てきたり、人によって捉え方が違っていたりするかもしれません。チームとして議論して認識をそろえていくよいタイミングになります。逆に、それぞれの意味をあまり細かく定義したり、一方的に説明しない方が、ふりかえりとしての効果が高まるようです。
FDLはScrum Coaches Retreat in Okinawa でのアウトプットとなります。一緒に開発したチームA(Team Almost Done)のみなさん、ありがとうございました!他の参加者のみなさんも(特に実験台になってくれたチームB)、ありがとうございます。
Team Almost Done(順不同)
- HIDE
- indare
- JB
- Tee
- yattom
- YesNo
■
ある現場のチームで「チームのコアタイム」について質問を受けたので、簡単に紹介したいと思います。
『スクラム現場ガイド』で、チームのコアタイムを紹介しています。チームメンバーが全員そろっている時間を、ルール(ワーキングアグリーメントの一部)として決めるというものです。フレックスタイムのコアタイムにも似ています。
コアタイムがあると、コミュニケーションが確実にできる時間がわかります。ミーティングの予定を立てるときとか、誰かに相談したいというときに、コアタイム内に設定すれば基本的には全員そろうので、個別の調整をしなくてすみます。特にチームが離れた場所で作業しているときに、時間が節約できるようになります。(リモートはもちろん、同じビルだけどフロアが違う場合など)
さて、このコアタイムは、単にルールとして設定すべきというものではありません。コアタイムを設定するには、なんらかの動機があるはずです。外のミーティングが多いとか、個人や家庭の事情で朝遅い・夜早い人がいるとか、時差があるとか(中国チームがいるなど)。時間とコミュニケーションに関してチームが問題を感じたときに、使えるソリューション(のひとつ)がチームのコアタイムです。
スクラムチームが用いる“ルール”はいずれも、なにかしらの問題に対する解決策として採用するものです。ルールがあるほうがいいから……というだけでは、ルールを導入する十分な理由にはなりません。問題に対する解決策である以上、結果も求められます。問題が解決しないなら、そのルールはやめて他の方法を考えたほうがいい。
コアタイムを設定するときには、全員が無理なくいられる時間の共通部分を取ります。子供のお迎えの日は17時までという人がいるなら、コアタイムは17時までです。朝が弱い人がいるなら、その人が確実に来られる時間がコアタイムの開始です。時間を問わず打ち合わせが急に入る人がいたら、おそらくコアタイムは解決策にならないでしょう。
チームとプロダクトの状況はどうか(透明性、見える化)、なにが問題なのか(検査)、どんな解決策をとるか(適応)、解決策は効き目があるか(次のループ)。ルールや施策を考えるときは、この全体の流れを常に視野に入れておきましょう。