nunulkのプログラミング徒然日記

毎日暇なのでプログラミングの話題について書きたいことがあれば書いていきます。

『他者と働く──「わかりあえなさ」から始める組織論』を読んだ

はじめに

この記事について

「他者と働く──「わかりあえなさ」から始める組織論」(宇田川元一著)を読んだのでその感想文です。

これまで会社員あるいはフリーランスとして働いてきて思うのは、ソフトウェア開発の仕事においても解決困難な問題は能力起因ではなくほぼ人起因であるということです。人が苦手だからコンピューター相手の仕事に就いたはずなのに、けっきょく人と向き合わないと仕事ができない、というジレンマを感じつつ、フリーランスになることでそういったしがらみから少しでも距離を置きたい、というのがいまの自分のスタイルを形作ったといっても過言ではありません。

かねてより組織に関する本は読んでいたものの、やはり実践の段になるとうまくいかないことがほとんどで、近年は半ば諦めてしまっている領域です。

そういう意味では、この本を読む動機はそれほどなかったんですが、いまの現場でもこの「わかりあえなさ」を感じていて、たまたま X で流れてきたのを見てタイムリーだなと思ったので手に取ってみました。

他者との関係性における私のスタンス

私はこれまでの人生において、対人の問題に対して消極的というか、関係性の構築とか維持とかに執着を持たずに生きてきました。プライベートでも友達と呼べる存在はほぼおらず、唯一バンドのメンバーくらいです。仕事でも、人間関係起因の問題が起きた場合、それが簡単には解決できないと思った場合は、契約を更新しない、という選択を取ってきました。

人起因の問題は、解決するよりも回避するほうが何倍も楽です。とくに私の場合は途中からチームに加わることがほとんどで、出来上がった(てしまった)チームに異物(私)が入ることで不協和音が起こった場合、簡単には取り除けません。自分は意固地な性格ではないので、チームのやり方に合わせることはそれほど苦にしませんし、単にスタイルの問題であれば、これまで色んなスタイルのチームで働いてきたのでそこはぜんぜん問題ないです。

しかし、仕事がうまくいってない/成果を出せていないのに、自分たちが変わろうとしないチームに入ったときが問題で、私はその状況を変えたいと思い提言などするものの、ほとんどのケースではそれは暖簾に腕押し状態になります。

そうしたことが続くと次第に、暖簾を押すのを止めてしまいます。

プライベートでは他人に期待しない、他人を変えようとしない、というスタンスで生きていますが、仕事においては、変わらなければ強くなれないという意識が強く、そのスタンスを適用できていません。

最近はとくに、参画するかどうかを決めるポイントとして、課題解決があります。面談時にマネジャーやリーダーからどんな課題があるか聞いて、自分がそれにバリューを出せそうかどうか、出したいと感じるか、事前にそういったことは話します。なので、課題を認識していて、その課題解決のために私と契約して、いざ実際に現場に入ると話がまったく進まない、みたいなことがあると、なぜなんだ?!と思ってしまいます。

期待値調整がうまくやれてない、というのもあるでしょうし、リクルーティング段階の方便という可能性もあるかもしれないですし、わかっちゃいるけどできない、のかもしれないですが、最終的には「人間は難しい」となって諦めてしまいます。

「他者と働く」概要

さて、前置きが長くなってしまいましたが、本書を簡単に要約すると、

  1. 組織の厄介な問題は合理的に起きている
  2. 厄介な問題のほとんどは、技術的課題ではなく適応課題である
  3. 適応課題の解決には各人のナラティブを理解することが必要である
  4. 他人のナラティブを理解するには対話が必要である
  5. 対話の仕方・ポイント

を順序立てて説明しています。

1. 組織の厄介な問題は合理的に起きている

自分がソフトウェアエンジニアだからか、合理性にこだわってしまう傾向があるのは自覚していて、うまくいかない/成果を出せないのは、合理性が乏しいからだと思いがちです。「理」があればあとはそれに合わせていくだけなので簡単なはず、どうしてそれができないのか、と思っていました。しかし、本書では、そうした状況にも合理性があると説きます。

2. 厄介な問題のほとんどは、技術的課題ではなく適応課題である

「技術的課題」と「適応課題」はもともと Ronald Heifetz さんが定義したものです。それぞれの定義は ChatGPT によると、

「技術的な問題は既存の知識、手続き、または専門知識を用いて解決できる問題です。これらは明確な解決策があり、既知の実践を適用することで、または分野の専門家によって実装できます。一方で、適応課題は、効果的に対処するためには学習、革新、価値観、信念、または行動の変化が必要とされる複雑な問題です。」

とのことです。本書ではさらに加えて、

人と人、組織と組織の「関係性」の中で生じている問題

と定義しています。

技術的課題は、難易度の高低はあれど、比較的入力パラメータの少ないソルバー関数が存在するものである一方、適応課題は、人それぞれの置かれた状況やこれまでの経験、培ってきたマインドなど、膨大な入力パラメータを必要とする、しかもそれが「私」と「あなた」双方に存在するソルバー関数が必要なものである、と解釈しました。

また、技術的課題なのか適応課題なのか一見して区別できなかったり2つが絡み合っていたりこともあり、複合的な場合には、適応課題部分を解いてから技術的課題に取り組まないといけないために、厄介さが増してしまいます。

3. 適応課題の解決には各人のナラティブを理解することが必要である

ナラティブは(またも ChatGPT によると)「人々が自分自身や自分の人生を理解し、意味付けするための枠組み」とのことです。

本書では、

語りを生み出す世界観、解釈の枠組みとしての「物語」

であり、

ナラティヴとは、視点の違いにとどまらず、その人たちが置かれている環境における「一般常識」のようなものなの

としています。

たしかに、なにかの出来事に遭遇したときにそれに対して感じることや行動することが、個人のナラティブによって変化するなら、ナラティブを理解しなければその結果としての感情や行動は理解できない、というのは納得できます。

4. 他人のナラティブを理解するには対話が必要である

対話といってもざっくばらんに話す、とかではなく、準備や予備知識、臨む際の姿勢など、本書が推奨するやり方みたいなのが載っています。

本書では、自分のナラティブ(世界観、解釈の枠組み)と他人のナラティブの間にある溝を、文字どおり溝にたとえ、それに橋をかけることで関係性を変えていくアプローチが紹介されています。

  1. 準備「溝に気づく」
  2. 観察「溝の向こうを眺める」
  3. 解釈「溝を渡り橋を設計する」
  4. 介入「溝に橋をかける」

本書では、この4つの段階をだいたい以下のような感じで説明しています。

まず自分のナラティブを一度棚に置き、相手がどんなナラティブに基づいて動いているのか観察して掴む。それが見えてきたらその相手のナラティブに基づいて自分がどう見えるのかシミュレートし、ようやく最後に行動を起こして関係性を変える、というステップです。

このように急がず順序立ててアプローチしないと、うまくいかないと説きます。

そもそも、関係性が構築されていない段階では、「私とあなた」という関係ではなく「私とそれ」になってしまっていて、道具を使う感覚で他人と接してしまう状態であるので、どうやったら「私とあなた」の関係に相互になれるのか、その辺りが最初の難関なのかな、と思います。

5. 対話の仕方・ポイント

ここからが本書のコアの部分になるわけですが、個別の事例や具体論が続くので、要約が難しく感じたのでスキップします。

一箇所だけ引用しておきます。

しかし、相手との間に橋を架けようと躍起になるあまり、あなたとあなた自身の間に橋がなくなっている状態にあるかもしれないのです。仕事のナラティヴだけになってしまうと、自分自身のその他のナラティヴとの間で乖離が起きてきてしまいます。

「他者と働く」の感想と読んだあとのマインドの変化

フリーランスなので、ぶっちゃけ価値観の合わない組織で働く必要はまったくなく、実際これまでにもときたま良いと感じるチームに出会えていて、その確率はそれほど低くはないと感じています(体感的には半分以下ではありますが)。

自分の理想のチームをここで言語化しておくと、

  1. プロフェッショナルの集まりでそれぞれが自分の専門性を活かして難題に取り組むチーム
  2. 専門性を持ちつつも改善のためなら専門性の壁を乗り越えて一緒に取り組むチーム
  3. 多様な価値観や人間性を持った集団でありながら一体感があり、問題解決に向き合うチーム

過去を振り返ると、20年以上前に参画した某 JTC で結成されたチームに参画したときがもっとも理想に近いチームでした。メンバー数は20-30人くらい、営業、企画、開発、さまざまな部門が2つの隣り合った部屋に集まり、ミーティングはいつも建設的で、ミーティング以外のコミュニケーションも頻繁にあり、田舎(いちおう東京でしたが)にオフィスがあったのでレストランも少なく、たいていはいつも決まった店に行き、結果的にそこでもコミュニケーションが発生する、みたいな、関係性でした。

技術的には、メンバー間でばらつきがややあったものの、開発チームでもそれぞれの役割を果たすことでチームの成果になる、という感じでした。技術的にチャレンジングなこともあり、リーダーがめちゃめちゃ優秀だったので、それに引っ張られるように、みんながそれぞれプロジェクト期間中に成長していった感じもします(もちろん私も含めて)。

自分が上に書いたような理想を追ってしまうのは、そのときの体験(あるいは以降の似たような体験)が、本当にソフトウェア開発者として、充実していて、楽しかったので、またそれを味わいたい、という思いがあるんだろうと思います。

良い/強いチームに入るともれなくその感覚に近いものが得られるんですが、そうでないチームに入るとそのギャップを埋めたくなってしまいます。そしていつも、他人を変えるのは難しいと感じ、そのチームを離れる選択を取ってきました。

本書では、他者との関係性は対話によって変えられる、という希望を少し抱かせてくれたような気がします(単純なので、本を読んだ直後はだいたい洗脳状態になる、という部分は差し引いても、ちょっとやってみようかな、という気にはなっています)。

そもそも、人間絡みでものごとがうまくいかないとき、問題は相手にだけあるのではなく自分にもあるんだろうと思います。自分が友達のほとんどいないEQの低い人間であることもありますし、あまり人間に興味がないこともありますが、それは確信があります。プライベートでは別にそのスタンスで困っていませんが、仕事では(少なくとも契約が残っている間は)そうもいきません。

仕事においては、いつでもどこにいっても、自分の成長がチームの成長に繋がり、結果的に会社の成長に繋がるのを理想にしているので、自分の問題なのであればそれは改めたいですし、成長を阻害するのが適応課題という難題であるならば、それを解いてみたいと思いますし、本書によって「そもそも適応課題は解決が困難な問題である」というのを改めて認識しましたし、いまはもう少し粘ってみようかな、という気持ちです。

あまり関係ないですが、本書を読むちょっと前から、Awarefy というメンタルヘルスアプリを使っています。

www.awarefy.com

AI によるコーチングは正直まだ満足できるレベルではありませんが、自分の感情を吐露できる場として、内省できる場として、いまのところしばらく使ってみようかなと思っています。

まずは自分を見つめ直すところから、自分のナラティブを言語化するところから、じっくり取り組んでいく所存です。

おわりに

Kindle で似たような本をいくつか購入して読んだことがあるので、また読み返そうと思います。