Hatena::ブログ(Diary)

やっとむでぽん

 

2018-12-22

心理的安全性について (RSGTアドベントカレンダー2018)

RSGTアドベントカレンダー2018のエントリです。昨日はJean-Baptiste Vasseurさんの「RSGT2019 スポンサーブースでスカベンジャーゲームをやる!」でした。明日はTakao Oyobeさんの「私がアウトプットする理由」 です。

心理的安全性について

RSGT2019のセッションで、心理的安全性ゲームをやる予定です(一日目1/9(火)15:15〜)。このゲームは、チームにおける心理的安全性を考えるきっかけづくりを狙いにしています。

さて、心理的安全性という言葉は最近あちこちで使われるようになり、優れたチームや組織にとって重要という考え方が広まっています。ここであらためて関連する研究を見直し、心理的安全性について理解を深めたいと思います。

エイミー・エドモンドソン

エイミー・C・エドモンドソンは90年代から心理的安全性についての研究をしています。書籍『チームが機能するとはどういうことか』(2014年)では、心理的安全性について以下のように書いています。

「「心理的安全」とは、関連のある考えや感情について人びとが気兼ねなく発言できる雰囲気をさす。」

1999年の論文では「チームの心理的安全とは、対人のリスクを取っても安全であるという、チーム全員の信念である」としています。このように、心理的安全性とは人間どうしの関係、主にコミュニケーションに関する状態を指す概念です。

心理的安全があるチームでは、以下のような状況が作られます。

  • 心配や懸念がオープンになる
  • 失敗しても支えてもらえる
  • 全力を出せる、新たな挑戦ができる
  • 成功と失敗の両方から全員が学ぶ

2014年の論文(Edmondson and Lei)では、心理的安全性についての研究をふりかえり、多数の研究結果をまとめています。心理的安全性は1960年代から研究が始まっていて、90年代以降急速に注目されるようになりました。60本以上の研究を調べた結果として、現時点(2014年時点)では以下のような考察がされています。

  • 個人レベル、組織レベル、チームレベルそれぞれの研究があり、いずれのレベルでも心理的安全性は生産性などによい影響を与える
  • 心理的安全性がより強い影響を与えるのは、仕事に不確実性がある場合かつ、人どうしの協調が必要な場合である
  • 心理的安全性によって組織やチームでの生産性がもたらされるのは、組織やチームでの学習が促進されるためである
  • 組織の学習はもっぱら、独立した個人どうしが関わり合う中で生まれ、そこでは対人リスクがない状態が望ましい
  • 心理的安全性がある職場では、人が "Speak Up" する ―― 声を上げたり異を唱えたり、新しいアイデアを出したりするようになる

グループ(チーム)レベルにおいて心理的安全性を取り巻く要素が、次の図のように整理されています。(Google Draw) 心理的安全性の前提となる要素(リーダーシップや信頼など)と、心理的安全性がもたらす影響(学習やパフォーマンス)や、心理的安全性が効果を出すときに求められる要素(不確実性とリソース不足など)の関係を示しています。

https://i.gyazo.com/12cad8975bc0eeeb91482b4b17d4e2a7.jpg

GoogleのProject Aristotle

心理的安全性が特にIT業界で注目されるようになったきっかけの一つが、Googleが社内でおこなった調査プロジェクトです。社内の様々なチームを調べ、効果的なチームの条件は、そのメンバーの能力ではなくチームの働き方にあると発見し、5つの要素を挙げます。中でも最も重要とされたのが、心理的安全性でした。なおチームの効果性(effectiveness)は、この研究の中で独自に定義しており、エグゼクティブの評価、チームリーダーの評価、チームメンバーの評価、四半期のセールス成績の4つの観点から評価しています。

以下の図では、重要な5つの要素として心理的安全性に続き、人を信頼できること、構造と明快さ、個人にとって仕事が有意義であること、チームの成果がインパクトを持つことを示しています。

https://i.gyazo.com/6ea4d276a452ed2d25ee2a76d6b2248d.png

Googleの研究を紹介するThe New York Times Magazineの記事にはこう書かれています。

…Googleでは誰も「仕事の顔」を着けて職場に来たいとは思っていません。誰も、個性や人生の一部を家に置いて来たいとは思っていないのです。仕事に100%集中するために、心理的安全性を感じるためには、人を脅かしたり驚かしたりしかねないような話であっても、非難を恐れず自由に発言できるのだと意識している必要があるのです。…効率だけを考えていてはいけません。…仕事とは単なる労働以上のものだと考えたいのです。

Joshua Kerievskyとモダンアジャイル

2016年にJoshua Kerievskyが提唱したモダンアジャイルでは、モダンアジャイルへ向かうための4つの原則*1を柱としています。なお2017年には来日してアジャイルジャパン2017の基調講演で、日本のアジャイル界隈にモダンアジャイルを紹介しました。

  • 人々を最高に輝かせる
  • 安全を必須条件にする
  • 高速に実験&学習する
  • 継続的に価値を届ける

https://anagileway.files.wordpress.com/2016/10/modernagilejp.png

この中の「安全を必須条件にする」には心理的安全性が含まれます。同時にモダンアジャイルでは、心理的以外の安全性についても重要性を説いています。Joshua Kerievskyは以前からAnzeneeringという考え方を提唱しています。この言葉は日本語の安全(Anzen)と英語のengineeringを組み合わせた、Joshuaの造語です。彼はIndustrial Logic (Joshuaの会社)のページで、以下のようにAnzeneeringを紹介しています。

  • Anzeneerは様々な要素から人びとを守る
  • 様々な要素とは、たとえば人間関係、作業環境、プロセス、プロダクトなど
  • 人びととは、利用する人、作る人、マネージャ、買う人、利害関係者など
  • 安全はすべてのリーンやアジャイルの共通項である

Joshua自身も、エイミー・エドモンドソンやGoogleの研究に触れて心理的安全性を紹介したりしているので、Anzeneeringやモダンアジャイルと心理的安全性は直接関係していると思われます。

いっぽうでJoshuaは心理的以外の要素も大事だとしています。ソフトウェア利用者をソフトウェアの問題から守る、開発者を質の悪い危険なコードから守る、マネージャが進捗を把握できるよう守る、などです。「高速に実験&学習」するには、実験や学習の中で失敗したり問題が起きても、それが人びとの安全をおびやかさないような環境が前提となります。

思うに、心理的安全性が対人リスクを減らし学びと効果を生み出すという現象が、とりわけソフトウェアの領域では人間関係に限定されず幅広いリスクについて言えるのではないでしょうか。たとえば、間違ったことを言っても怒られない、指摘を受けて訂正すればいいという状況は、アジャイルなソフトウェア開発においては、間違った機能を作っても、ユーザーの指摘を受けてすぐ直せばいいという状況に似ているように思われます。モダンアジャイルが言及するのはソフトウェアに限りません。人間が中心となって価値を産み出すという幅広い領域において、アジャイルが有効だというメッセージです。そうした中で心理的安全性は、仕事の多くの側面で有効であり、大事にすべきなのではないでしょうか。

その他の参考資料

*1:よくモダンアジャイルの4つの原則や理念と紹介されていますが、原文ではModern agile methods are defined by four guiding principlesとなっており、「モダンアジャイルへ向けてガイドする原則」とするほうが正しそうです。些細な違いかもしれませんが、4つの原則がモダンアジャイルであると理解するのと、4つの原則はモダンアジャイルへ近づくヒントだと理解するのでは、行動と結果が変わってくるように思われます。

2018-10-31

ファン・ダン・ラーン(FDL)ふりかえりボード

https://i.gyazo.com/17f8179eec49ae9d7583b1bf3be08414.jpg

ふりかえりで使える手法としてKPTやYWTなどがありますが、新しくファン・ダン・ラーン(Fun/Done/Learn)というアプローチを作ったので紹介します。チームがやったことを、Fun、Done(またはDeliver)、Learnという3つの軸とその重複で見直します。上の図のように、Fun、Done(Deliver)、Learnのを重ね合わせた図をボード上に書いて、そこに分類していきます。

この図を見れば、経験のあるファシリテータースクラムマスターなら自分なりのやり方が思いつくのではないでしょうか。ぜひ自由に使ってみてください。以下では、私たちが実際に試してみた方法を紹介します。

  1. まずホワイトボードや模造紙に、上のFun/Done/Learnの図を描く。重なり合う領域が狭くなりすぎないよう気をつけること
  2. メンバー1人ひとりで、やったことを付箋に書き出す
  3. 付箋の内容を共有して会話しながら、図上の当てはまる領域に付箋を貼っていく。
    • 付箋を書いた人ではなく、他のメンバーが貼り付ける領域を選ぶようにすると面白いです
    • 例: 「みんなでゲームで遊んだ」→ 楽しかったのでFunの円の上半分(他と重ならない部分)に貼る
    • 例: 「モブプロでスキルを共有したが進みは遅かった」 → モブプロでモチベーションが上がったのでFun、スキル共有したのでLearn、Doneにはつながらなかったので、FunとLearnの重なる右中央の領域に貼る
    • 例: 「新たにVue.jsで機能を実現できた」→ やって楽しかったし、Vue.jsを学べたし、機能をリリース(提供)できたので、Fun/Deliver/Learnの重なる中央部分に貼る
  4. 次にスプリントやプロジェクト全体としてどうだったか、当てはまると思う領域に1人ずつ選ぶ(シールを貼ったり、ペンで印をつけたりするとよい)。スプリントならスプリント全体、プロジェクトならプロジェクト全体についての評価をする
  5. ボードを眺めながら、次のスプリントやプロジェクトではどの領域を狙いたいか話をする

進める中で、LearnやDeliverとはどういう意味なのか、疑問が出てきたり、人によって捉え方が違っていたりするかもしれません。チームとして議論して認識をそろえていくよいタイミングになります。逆に、それぞれの意味をあまり細かく定義したり、一方的に説明しない方が、ふりかえりとしての効果が高まるようです。

https://i.gyazo.com/thumb/1000/f3c228ea84b911ff9eecd7bedd3b9beb-jpg.jpg

https://i.gyazo.com/thumb/1000/a2755d9b7203260ca53c461ae9166e14-jpg.jpg

FDLはScrum Coaches Retreat in Okinawa でのアウトプットとなります。一緒に開発したチームA(Team Almost Done)のみなさん、ありがとうございました!他の参加者のみなさんも(特に実験台になってくれたチームB)、ありがとうございます。

Team Almost Done(順不同)

  • HIDE
  • indare
  • JB
  • Tee
  • yattom
  • YesNo

2018-05-25

ある現場のチームで「チームのコアタイム」について質問を受けたので、簡単に紹介したいと思います。

『スクラム現場ガイド』で、チームのコアタイムを紹介しています。チームメンバーが全員そろっている時間を、ルール(ワーキングアグリーメントの一部)として決めるというものです。フレックスタイムのコアタイムにも似ています。

コアタイムがあると、コミュニケーションが確実にできる時間がわかります。ミーティングの予定を立てるときとか、誰かに相談したいというときに、コアタイム内に設定すれば基本的には全員そろうので、個別の調整をしなくてすみます。特にチームが離れた場所で作業しているときに、時間が節約できるようになります。(リモートはもちろん、同じビルだけどフロアが違う場合など)

さて、このコアタイムは、単にルールとして設定すべきというものではありません。コアタイムを設定するには、なんらかの動機があるはずです。外のミーティングが多いとか、個人や家庭の事情で朝遅い・夜早い人がいるとか、時差があるとか(中国チームがいるなど)。時間とコミュニケーションに関してチームが問題を感じたときに、使えるソリューション(のひとつ)がチームのコアタイムです。

スクラムチームが用いる“ルール”はいずれも、なにかしらの問題に対する解決策として採用するものです。ルールがあるほうがいいから……というだけでは、ルールを導入する十分な理由にはなりません。問題に対する解決策である以上、結果も求められます。問題が解決しないなら、そのルールはやめて他の方法を考えたほうがいい。

コアタイムを設定するときには、全員が無理なくいられる時間の共通部分を取ります。子供のお迎えの日は17時までという人がいるなら、コアタイムは17時までです。朝が弱い人がいるなら、その人が確実に来られる時間がコアタイムの開始です。時間を問わず打ち合わせが急に入る人がいたら、おそらくコアタイムは解決策にならないでしょう。

チームとプロダクトの状況はどうか(透明性、見える化)、なにが問題なのか(検査)、どんな解決策をとるか(適応)、解決策は効き目があるか(次のループ)。ルールや施策を考えるときは、この全体の流れを常に視野に入れておきましょう。

2017-12-10

スクラムガイドにある「リファインメントは開発チームの作業の10%以下」という箇所について、疑問が上がっていました(Facebook上で。限定公開だったのでリンクは貼りません)。そこにコメントしたのですが、私の解釈は以下のようなものです。

リファインメントはいろんなやり方があるので、「開発チームの工数の10%」という解釈がほぼ近いと思っています(工数、作業量、エネルギー、許容量、できること、そこの言葉の捉え方はいろいろありそうです)。POとミーティングをしてもいいし、開発チームだけで相談してもいいし、定例化してもいいししなくてもいいし、開発チームタスクとして作業をしてもいいし、ミックスしてもいい。

2週間スプリントでリファインメント「イベント」を週1回実施して、スプリント前半のリファインメントでは調査タスクを発生させ、後半までに開発チームで調べておく、というチームがありました。このときはイベント(全員)+調査タスク(担当した人)あわせて「10%以下」の対象になります。

別のチームでは、スプリント中に新しい急ぎのPBIが頻発するので、毎日15分確保しておき、急ぎのPBIがある日は内容を調べて見積もるようにしていました。

たしかケントベックが言ってた、「新しいストーリーはホワイトボードに貼っておいて、メンバーは気の向いたときにそれを眺めて、見積もりポイントを封筒に入れる。何人分か集まったら、その平均(だか最大値だか)を見積もりとする」というのも、スクラムであればリファインメント作業になると思います。

リファインメントはプロダクトバックログの「すぐやるやつ」と「今後の見通し」を把握するためにやるので、チームやプロダクトによっていろいろな形になるようです。「10%以下」は、そちらにのめり込みすぎないような、またプロダクトオーナーがやるべきことをチームに押しつけすぎないような、バランスのための目安かなあと個人的に思っています。

2017-09-07

AIIT夏合宿に1日だけ参加し、TDDを紹介して、みんなでペアプロをしてきました。大学生って若いんだなあ。 #enpit

途中から参加者を放置して、メンターの太田さんとペアで書いた、HTML Canvas版ライフゲイムです。最低限ですが、ブラウザ上で動きが見られるところまでたどり着きました(本当に最低限なので、見て驚いてください)。

https://github.com/yattom/tdd_life_javascript

さて、このコードのキモは3つあります。

1.テスティングフレームワークがない。フレームワークの使い方ではなくテストの書き方、考え方に集中するために、その場でテストのロジックを書き、それが関数になり、実行の仕組みを作り…と、テスティングフレームワーク自体を育てていくアプローチをしています(最近のお気に入り)。必要最低限の「フレームワーク」ができて手頃ですし、「これ面倒だからフレームワークで対応したい」というペインポイントを感じながら作れるのがメリットです。

2.テストコードとプロダクトコードが渾然一体している。1ファイル(life.js)にテストコードとプロダクトコードが入り交じった状態で進めました(パターンになかったっけ)。最終的には、テストが「上のほう」、プロダクトコードは「下のほう」にまとまっています。これは配置だけの問題でなく、プロダクトコードの中にテストのためのコードが入り交じっているという状況も作り出しています(例: セルを描画した回数をアサートするために、プロダクトコードの中で数える)。この件は次のキモにつながり…

3.モック(テストダブル)を嫌う。Canvasに描画するという処理そのものをテストするのは困難です。そこでモックライブラリを導入して、描画処理が何回呼ばれたとか、正しいパラメータが渡されているとか確認するのが、常道です。しかし今回は(2.で触れたように)プロダクトコードのロジックの中にテスト用の処理(何回呼ばれたか数える)を埋め込んでいます。大変だ!プロダクトコードがテストで汚染された!

ですが、TDDであれば、あるいはTDDでなくても、プロダクトコードと自動テストとが一体となって作られ、一緒にコミットされ、変更やメンテナンスも同時です。プロダクトコードとテストコードの意味的な分離はそれほど、昔ほどは重要ではないように感じています。今回実際に書いてみて、このくらいなら複雑にもならないし、可読性も悪くないし、扱いやすいコードにできることがわかりました。少なくともモックを導入するよりは、プロダクト+テスト全体としてシンプルになっています(実際の比較はしていませんけれど)。

もちろん、たかだか2時間で書いたコード量ですから、これから質・量ともに増えて複雑になっていけば、いつまでもモック不要とはいかないでしょう。一方で、プロダクトコードとテストコードの分離が絶対である、依存関係は一方通行であるというのは、ルールと言うよりはガイドラインに過ぎず、バランスやトレードオフを考えるべき条項なのではないでしょうか。

P.S.

Jim Coplienがセミナーで言っていました。「製品にアサートを(テストと言うよりはDbC的な表明だと思う)を埋め込んだまま出荷すべきと意見したが、止められた。なので会社を辞めた」。またハードウェアはたいてい、異常時にテストする仕組みを埋め込んでいます(内部の自動テストや、外部からテストする端子など)。

 
ページビュー
588082