ダイアローグ 対話する組織

気づいたら2ヶ月近くブログを書いておらずやばいと思ったので、今日読んだ以下の本について書く。

ダイアローグ 対話する組織

ダイアローグ 対話する組織

なんで読んだのか

弊社には、新卒入社社員の各々に対して既存社員(=メンター)を1名ずつ組み合わせ、各組で月に1回お昼ごはんを共にし、いろんな話をする、という制度がある。メンターは対象の新入社員と異なる部署から選出され、半年で組チェンジする。

自分は昨年の前半と後半で2名の新卒氏と組になっていて、今期で3人目になる。自分を選出し続けている人事部に重大な欠陥があることは明らかだが、せっかくなので先輩面で話をしつつ、会社の金でお昼ごはんをいただいている。 メンターを対象にした事前ガイダンスで「参考にどうぞ」と配布されたのが、上記の書籍だった。自分は精神がひねくれているので、普段こういうビジネス書的なものは敬遠しまくっていて手を出さない。今回はせっかくもらったし、人間とのコミュニケーションが著しく苦手な自分にとって助けになりうるかも、というわけで読んでみた。

著者は中原淳さん、長岡健さん。いずれも経営学社会学を専門とされている大学教授らしい。研究室のウェッブサイトが信じられないくらいポップでキュートな仕上がりで、違う世界線のアカデミアをみた。

東京大学 中原淳研究室 - 大人の学びを科学する

俺なりのメモ

読みながらメモってたやつを晒す。日本語と注釈を少しなおした。引用ではなく自分の解釈とかごっちゃになって書いてるので、興味のある人は本を読んでください。読みたい人いたら言ってくれれば授けます。

第1章: 「伝わらない」組織

  • 導管メタファー
    • ビジネスの場で支配的なコミュニケーション観。
    • 情報は送り手から受け手へ伝達され、主観などはノイズとされる。
    • 受け手の共感や行動変化は得られにくく、「伝わらない」。
  • ストーリーテリング
    • 人はストーリーで理解・記憶する。
    • 導管メタファーの一形態にすぎず、まだ「伝わらない」。
  • コミュニケーション=相互的理解に至る継続的な相互作用のプロセス*1

第2章: 「対話」とは何か

  • 合意に至るためには、客観的な事実に対する意味付けを共有する必要がある。
  • 物事の意味とは客観的事実ではなく、社会的な構成物である。(社会構成主義*2 )
  • 意味は根本的に他人とは共有し得ない。(主観主義)
  • 「聞く」は受動的な行為、「聴く」は積極的かつ意図的な行為。
  • 「議論」は意思決定が目的、「対話」は意思決定の問題や過程に対する理解・吟味が目的。
  • 対話による言語化と他者比較により、他者だけでなく自己理解も深まる。

第3章: 「対話」が組織にもたらすもの

  • 協調的な問題解決
    • 適切な問題設定のためには意味付けの共有が必要であり、議論より対話が有効。
    • ベトナム戦争の泥沼化は、卓越した即興的対応力により局所最適な問題設定が行われた結果。
    • トヨタの問題解決研修では対話による問題設定に重点を置いている。
  • 知識の共有
    • 事実(宣言的知識)ではなく暗黙知・実践知(手続き的知識)を共有したい。
    • 手続き的知識は多様かつ不良定義問題*3であることが多く、共有が難しい。
    • 個人間の知識の伝達ではなく、「協調的問題解決のネットワークを活性化する」という意識。
  • 組織の変革
    • 組織の文化や理念の共有は導管メタファーでは難しい。
    • 個々が自身の体験にもとづいて理解する必要があり、対話とそれに伴う行動が有効。
    • オープンなコミュニケーションとそれが可能な(心理的安全)土壌の実現が重要。
    • 過剰適応によりそこから変化しづらくなるリスクもある。

第4章: 「対話」による新たな学び

  • 学習とは「伝達」ではなく「変容」であり*4、対話はこれをもたらす。
  • 目指すべきコミュニケーション
    • 「情報伝達」ではなく「相互理解」、「組織の結束力」ではなく「個人の主体性」。
    • つまり、「効率的」でも「緊密」でもなく、「オープン」なコミュニケーション。
  • 「振り返り」は自身の語りとそれに対する他者のコメントによって行う共同的なもの。

思ったこと

ちょうど最近、前期の振り返り面談と評価フィードバック面談があった。そのときに「問題設定ムズい」って話をした。「なにが問題でそれがどうなればいいのか」を考えることに苦手意識があるし、実際すごく時間がかかる。本書を経て、自分は議論と対話のバランスにおいて前者の比重が大きすぎるかも、と思った。ゆるふわな対話をもっと許容していくぞ、というお気持ち

そもそも振り返り面談自体、偉い人氏がクソ忙しい時間の合間を縫って全員と面談しており、コストがすごい。それぞれで勝手に振り返っとけばええんちゃうんかと思っていたが、本書を経て、面談という形で時間をとっているのにはそれなりに意味があるのかも、と猛省した。対話による社会構成主義的な意味構成及び共有の場と捉え、今後は積極的に活用していきたい。

個人から組織(例えば自分が所属する部署)に視点を広げると、第3章で言及されている「知識の共有」がたびたび課題になる。各自の知識を相互に伝達すること(例えばすべての知識をオンラインドキュメントに残す)という導管メタファー的なアプローチではなく、そもそもの問題を共有し、各位がその解決に向いた結果として、必要十分な知識が適切な対象に共有される、という状況が理想っぽい。

というところまで書いて、よくよく考えると、新卒氏のメンタリングのために授けられた本だったが、自分の普段の業務に対する学びを得る結果となった。というか、新卒氏はぼくよりしっかりしてるからなにも心配がいらない。メンタリングしてほしい。

*1:『レトリックと人生』https://www.amazon.co.jp/dp/4469211257

*2:『日常世界の構成―アイデンティティと社会の弁証法https://www.amazon.co.jp/dp/B000J8XS4S

*3:問いと答えが一義的に結びついていない問題

*4:『 Seeing What We Build Together: Distributed Multimedia Learning Environments for Transformative Communications』 https://web.stanford.edu/~roypea/RoyPDF folder/A73_Pea_94_JLS.pdf

婚活とMastodon

5/2は婚活の日だったらしい。

www.konkatsu52.com

「結婚したい」とかカジュアルに言うくせにまったく行動しないやつ、10割クズなので気をつけてほしい(ヒュンヒュンヒュン(ブーメランの音))。

概要

国立社会保障・人口問題研究所が平成27(2015)年に実施した「第15回出生動向基本調査(結婚と出産に関する全国調査)」には、結婚しない理由として、以下の記述がある。

25~34 歳 の年齢層では、「適当な相手にまだめぐり会わない」などの結婚の条件が整わないことへ重心が移る。

以上の状況を鑑みて、恋愛・婚活用のMastodonインスタンスをたてた。

paors.lv

登録はお気軽にどうぞ。

Mastodon

説明不要かと思ったが、一部のソフトウェアエンジニア界隈以外ではゴミカスほども話題になっていないっぽいので補足する。Mastodon(マストドン)は、ポストTwitterとして各所で話題になったSNS。特徴は以下のとおり。

  • a free, open-source social network
  • A decentralized alternative to commercial platforms

Twitterと比較して説明する。Twitterはサービス自体のコードはTwitter社が保有していて非公開であり、またサービスを提供するサーバはTwitter社が保有している。それに対してMastodonは、コードがOSSであり、まただれでも自身の保有するサーバからサービスを提供できる。各自の提供するサービスはインスタンスという単位で呼ばれ、ユーザはいずれかのインスタンスに所属する。自身の所属するインスタンスから他のインスタンスのユーザをフォローすることもできる。

みたいな。詳しくて正しい説明はインターネットの各所に転がっているのでググりましょう。

ぼくは戸愚呂兄と同等かそれ以上にひねくれた性格をしているので、こういう話題になるやつはだいたい総スルーするんだけど、インターネットで「こんなもん流行らんぞ!」とか言われば言われるほど可能性を感じてしまうクソみたいな性格でもある。なので、ちょうど直近で出席予定だった社内の技術勉強会のネタにするべくたててみたという運び。Mastodon自体はまったく流行らないと思うがそんなことはどうでもいい。

国内のインスタンスこことかこことかここにまとまっている。ユーザ登録はインスタンスごとにできる。

作りかた

ぜんぶAWSで構築した。mastodon自体はまるっとEC2でDockerで動かしているだけ。メールの送受信にはSES。SESで受信もできるの知らんかった。AWSだとSSL証明書が無料で使えるの良い。

webfood.info

バチクソ簡単。自分の場合はDockerを使うのが初めてだったし、AWSでもCertification ManagerとかSESを自分で設定して使い始めるのは初だった。できるだけ理解して進めるよう努めたので、よいhands onになった気がする。 SESの制限解除ができておらず、verifyしていないメールアドレスにメールが飛ばなくてちょっとハマった。

ドメイン

paors.lvというドメインにした。.lvというのは、ラトビアという国のドメイン。お名前.comでは取扱いがなく、ゴンベイドメインで。申請から取得まで4日待ち、DNSの設定反映に1日待った。

累計会員数500万人突破のFacebookを利用した恋愛・婚活サービスと偶然とはいえドメイン名・サービス名が酷似しているため、万が一怒られるようなことがあれば即座に閉鎖する構え。社会不適合者の内輪ノリ悪ふざけだと思って見逃してくださると信じている。

このドメインダジャレで1笑いをとるためだけに8,640円を消費した。まったく後悔はない。ウケればいい。

運用

ルール等は特にない。公序良俗に違反するようなトゥートだけ謹んでいただければ。清く正しくパオっていきましょう。

開発に関しては、上記のとおり技術力皆無でもっというとLinuxとかRubyに関する知識が0の極みみたいなかんじなので、どうなるかわからん。仮にユーザが増えたら構成含め再考*1*2していくかもしれんが、まあないだろうと思っている。現時点でユーザ数6名でサクサク動いている。

婚活仕様に改造していきたい気持ちはあるのでRubyできる人たちPRください。

GitHub - kbth/mastodon: A GNU Social-compatible microblogging server

展望

承認欲求に駆られたどうしようもないアカウントが幅を利かせ、出会い厨が湧きたち、ネカマが蠢き、LINE IDの取得合戦が繰り広げられるディストピアインスタンスに育ってくれることを願ってやまない。

*1:DBとか外出しするついでにAuroraを試したい

*2:terraform化してみたい

SQLにおける存在仮定の原理

またもやSQLで??????ってなったのちに納得したので書く。

混乱したこと

要素が全てNULLのテーブル

user_id user_name
NULL NULL
NULL NULL
NULL NULL

ここで、「NullTableにuser_id=1のレコードが1つでも存在するか?」を確認する以下のSQL

SELECT (1 = ANY(SELECT user_id FROM NullTable)) AS any_null_result;
any_null_result
UNKNOWN

また、「NullTableのすべてのuser_idは1であるか?」を確認するSQLとその結果は以下になる。

SELECT (1 = ALL(SELECT user_id FROM NullTable)) AS all_null_result;
all_null_result
UNKNOWN

all_null_resultもany_null_resultもUNKNOWNとなる。SQLにおけるNULLは、「将来的に値が決まるかもしれないけど現時点では不明」を表すので、直感的にも正しい。

空のテーブル

では次は、要素が空のテーブルを考える。

user_id user_name

ここで、さきほどと同様に、まずは、「EmptyTableにuser_id=1のレコードが1つでも存在するか?」を確認するSQLとその結果は以下のようになる。

SELECT (1 = ANY(SELECT user_id FROM EmptyTable)) AS any_empty_result;
any_empty_result
FALSE

EmptyTableにレコードが存在しないので、当然user_id=1のレコードも存在しないので、これは当たり前。

問題は次。「EmptyTableのすべてのuser_idは1であるか?」を確認するSQLとその結果。

SELECT (1 = ALL(SELECT user_id FROM EmptyTable)) AS all_empty_result;
all_empty_result
TRUE

???

SQL「すべてのユーザのIDは1です!(ユーザがいるとは言っていない)」

みたいなね。きっつー。でもこれは正しい。

なんでこうなるか

SQLは存在仮定の原理に従うから。

例えば、ぼくは好きな人と付き合えるのかという命題を考えるときに、好きな人がいることを前提としていいのか?でも命題でちゃんと言ってないやん?空気読めってこと?厳密性皆無やん?ということで、古く論理学において議論の種だったらしい。

現代ではそれは「前提としない」ということになっている。好きな人が存在しない場合というのは、単に部分命題にすぎないという整理。

例えば、「ぼくは好きな人と付き合える」という文がTRUEだとすると、以下のように帰納的に理解できる。

  • 好きな人が3人いる場合: 3人と付き合える => TRUE
  • 好きな人が2人いる場合: 2人と付き合える => TRUE
  • 好きな人が1人いる場合: 1人と付き合える => TRUE
  • 好きな人が0人いる場合: 0人と付き合える => TRUE (好きな人が存在しない場合)

3人と付き合えるなら2人とも当然付き合えるし、それなら1人と付き合えるってことだし、じゃあ0人とも付き合える!みたいなね。

これを前段での例に当てはめると以下になる。

  • ユーザが0人いる場合: 0人のuser_idが1 => TRUE

そういうかんじ。

スマブラ強いやつが偉い

ニンテンドウオールスター! 大乱闘 スマッシュブラザーズ

ニンテンドウオールスター! 大乱闘 スマッシュブラザーズ

同世代の共通認識だと思うけど、スマブラ強いやつが一番偉い。なんだかんだで。スマブラ弱いやつが何を言っても説得力がない。スマブラ弱いくせに、ってなる。

ガーリィレコードという芸人コンビの、スマブラのワンシーンを再現した動画がTwitterで流れてきた。爆笑した。で、昨日無限大ホールで生のネタをみた。ファルコンとマリオの漫才。爆笑した。

参考

サブクエリ中のNULL比較

だれにも気づかれないレベルでさりげなくブログのタイトルを変えた。

それはどうでもいいとして、サブクエリにNULL比較を含むときの挙動で混乱したので書く。たぶんみんな知ってること。ぼくは知らなかった。なぜならポンコツだから。

続きを読む

ORDER BY句におけるNULLの同値性

アホすぎてSQLにおけるNULLの扱いが???ってなったので書く。

続きを読む

次に買うキーボード

いま使ってるキーボードはThinkPad USB Tracepoint Keyboardの旧型。Altキーが外れてカパカパしてて使いにくい。キーボード自体は気に入っているので同じのを買いたいけど、もう絶版で買えない。新型は微妙らしくて、次に何を買おうか悩みどころ。

続きを読む

プログラミング言語『Menhera(メンヘラ)』

土日の予定が清々しいほどにスカスカなので、クソみたいなプログラミング言語を作りました。
言語処理系に対する理解度がヤドカリのそれと同等なことに危機感をおぼえ、なんとなくお勉強しようと思ってやってみました。

続きを読む