Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待 をやってみて

f:id:rocky_manobi:20180729001257p:plain

Nextremerが主催する勉強会「Nextremer Tech Meetup@高知」の第二弾として、「Active Book Dialogueで"エンジニアリング組織論への招待"を読む」というやつをやりました。その際に「あ〜このイベントは場の心理的安全性の確保が大事っぽい」と思ったのでその話を書きます。

nextremer.connpass.com

イベントの様子はこちら!(本当にありがとうございます)

ABD - Active Book Dialogue とは

ABDはざっくり以下のような流れで進行するアクティビティです。

  • みんなで集まる
  • 一冊の本を切り刻む
  • みんなで分担して読み、要約する
  • 成果物を張り出し、順番に発表する
  • みんなが興味を持った所について対話する(ダイアローグ!!)

ねらい/効果等は以下、公式サイトより開発者様の言葉を引用します。

アクティブ・ブック・ダイアローグ®は、読書が苦手な人も、本が大好きな人も、短時間で読みたい本を読むことができる全く新しい読書手法です。 1冊の本を分担して読んでまとめる、発表・共有化する、気づきを深める対話をするというプロセスを通して、著者の伝えようとすることを深く理解でき、能動的な気づきや学びが得られます。 またグループでの読書と対話によって、一人一人の能動的な読書体験を掛け合わせることで学びはさらに深まり、新たな関係性が育まれてくる可能性も広がります。アクティブ・ブック・ダイアローグ®という、一人一人が内発的動機に基づいた読書を通して、より良いステップを踏んでいくことを切に願っております。

同サイトにてマニュアルも配布されていますので、やってみたいと思われる方はぜひ。

また、タイトルにもありますが、今回はエンジニアリング組織論への招待 という本でABDしました。

場の心理的安全性の確保が大事

奇しくも対象とした本にも書かれているワードですが、このアクティビティを運営するにあたっては、場の心理的安全性を担保することが何より大事だと感じました。

本の一部分のみから得た情報を要約するわけです。「完璧なものを出さなきゃ」「変なまとめしたらバカにされる」などという心理が働いていては手が動きません(きっと)。対話においても「いいこと言わなきゃ」「コレを言ったらバカにされるのか」なんて思っていたら発言なんてできません(きっと)。

前提条件や目的を丁寧に共有する(した方がよさそう)

参加者同士は学びを得るための仲間であり、競争相手ではないこと。対象の本を読んだことがある人も入れば読んだことの無い人もいること。対象の本を専門としている人もいればそうで無い人もいること。同一の事象/事実でも、重要だと感じる部分は人によって違うこと。要約や発表に慣れている人もいれば慣れていない人もいること。何より 目的は対話を通じて得られる能動的な気づきや学びであり、完璧な要約を分担して作ることでは無い ということを丁寧にインプットすることが、より質の高い場づくりに寄与するのだと感じました。

もっと言うと、これは僕の所感ですが、多様なバックグラウンド、多様な受け取り方の人がいた方が、むしろその場の学びの総量は大きくなるのでは無いかと思いました(コレはあとで)

現場ではどうしたのか...

なにぶん作業している途中で気づいたので、超アドホックな対策であることを先に言い訳しておきます。

一応僕なりの工夫としては「これ難しいです」「要約ってこんなに難しいんですね」「これ、完璧なのは無理ですよね..全体読んでいる訳では無いし(僕は読んでるけど)」「完璧じゃなくてもいい!ていう場の心理的安全性が大事ですよねコレ...」「時間足りないかもしれないです」のような発言を時折することで「そもそも難しいことをやっていること」「失敗が許容される場であること」を発信してみたりしました。効いたかどうかは分かりませんが、最後まで参加者全員で要約/発表./対話と、勧められたので良かったと思っています。

その他感想/気づき/学び

チームビルディングに使えそう

松浦春選さん によるレポートでも触れられている通り、これはチームビルディングに効果がありそうです。 お互いについて知り、価値観を共有するのに有用なツールだと感じました。週一でチームで時間をとって、取り入れようとしている考え方、導入を検討しているプラクティスなどの書籍を対象に実施して見ると良いかもしれません。

ある事柄について、担当個人がまとめたものをベースにディスカッションするのも良いですが、ABDのように一冊の本を分担し、そのなかで皆の関心の高い事柄について対話をすることで、皆で作り上げた解釈/価値観を共有することができるような気がしています。

多様なバックグラウンドのある人でやると面白そう

今回は参加者全員が「IT系」という属性を共有しつつ、「学生」「社会人」という属性に大きく別れていました。対話における発言の色にも「学生 vs 社会人」の差が出ていて、やはり同じものを見ても背景によって捉え方は違うのだと改めて認識しました。加えて、自分が発言するときにも「この例え方だと SE経験者にしか伝わらないからどう伝えようか」というトレーニングにもなったかと思います。受け手に合わせた情報発信の心ですね。

というわけで、デザイナーさんの仕事の仕方について書かれた本をビジネス屋さんとエンジニアとデザイナーさんで読んでみるとか、アジャイル開発系のプラクティスをユーザ企業さんとエンジニアで読んでみるとか、特定の業務知識の本を同じくユーザ企業さんとエンジニアチームで読んでみるとか。やってみると面白そうですね。

あ〜、それぞれの立場について主張したい本を一冊出して、それについてABDをやる、、ってすると本当に相互理解できそう。なるほどチームビルディングに使えそう(前項につながる)。

f:id:rocky_manobi:20180727141107p:plain
皆さん認知の歪みに興味があった模様

(というか学生さんでエンジニアリング組織論への招待を読んで何らかの感想がもてるなんてすごいな〜最近の学生さん本当に頭いいな〜)

個人のトレーニングとしてもやはり良い

本を読んで、要点を抽出して、視覚的に表現して、発表して、対話する、、とまぁ普段なかなかやらないというか、数が稼ぎにくい作業だと思いますので、単純にその手のことに取り組めるのは良いです。特に「発表」のトレーニングとして、とても有効なのではと感じました。

発表が上手くなるには「発表することと、その時のフィードバックを得ること」の積み重ねが大事だと思っています。上達のためになるべく数をこなしたい一方で、毎回「発表すべきネタの採掘」という作業が発生し、これが中々時間をくいます。そう言う意味で、ABDに参加すると嫌が応にも発表するネタが降ってくるので、それは良いなと。また、必然的に似たようなトピックに対して皆が発表するので、「上手な人の発表を参考にする」という作業がやり易いというのも良いです。

あとは、普通に読むよりも「深く読める」という効能も確実にあります。僕は以前に「エンジニアリング組織論への招待」を読んだことがありましたが、作業中には「こんなこと書いてあったっけ?」と思うことがなんども。やはり「要約して伝える」を前提にして読むときとは、読む深さが違うのだなと改めて感じました。

ABD x エンジニアリング組織論への招待 をやったきっかけ

A. エンジニアリング組織論への招待めっちゃいい本だよ!みんな読んだ方が良いよ! と言っていたら「じゃあ Active Book Dialogueやろうよ」と言われたから

ぼくは「エンジニアリング組織論への招待」とう本が大好きです。

これはもう良書中の良書というか、凄い本です。どれくらいすごいかというと、読みながら「そうそうそうそう!!!」と叫ばずにはいられないくらいです。チームや組織で仕事をしている人皆が感じ、直面しているであろう課題感(もちろん解決策も)を見事に言語化していて、普段感じていたモヤモヤが一気に晴れるというか、そんな気分にさせられます。

絶対みんな読んだ方がよい。チームを作る人も、チームに所属する人も、人類みんな読んだ方が良い。そうすればみんな少しだけでも優しくなれるというか、ちょっと幸せになるというか、不幸が減る。

まぁ、めちゃくちゃ雑ですがとにかくそんな本です。

と、そんなことをNextremer主催の勉強会@高知 の場で話していたら、その場にも参加頂いていた松浦さんに「Active Book Dialogueやりましょうよ」とお声かけ頂き、開催することになった次第です。

追記: あまりにも雑すぎるので書評へのリンクを... (おんなじ感想感覚だと思っています)

blog.shibayu36.org

note.mu

shufo.github.io

最後に

企画/準備/ファシリテーションと、イベントのほぼ全てを取りまとめて頂いた松浦さん、ABD経験者としてアドバイス頂いた杉尾さん、参加頂いた参加者のみなさま、僕の「やりたいっす!」に協力頂いたNextremerスタッフのみなさんにこの場を借りてお礼を申し上げます。ありがとうございました!

最後の最後に

Nextremerではエンジニアを募集しています:) ぜひ!!

www.wantedly.com