読者です 読者をやめる 読者になる 読者になる

@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

回避型愛着スタイル

はじめに

私は

  • 共感能力に低い
  • 他人に共感されることを避ける
  • 「共感されたい」という欲求を過小評価する

性質があります。 世の中では、これを「回避型愛着スタイル」と言うようです。 エンジニアにはこのタイプが多いように思います。

今わかっている範囲の情報を書きます。

愛着障害

精神医学の分野には「愛着障害」という障害があります。 他人との「愛着」を安定して築けないため社会生活に困難がでる障害です。

○○型愛着スタイル

自閉症」や「発達障害」と同じく軽い人もいれば重い人もいます。 軽い人は一見社会生活に全く支障がない人もいます。 そういう人に「○○障害」とつけるのは引っかかるので、ここでは「○○型愛着スタイル」と表現します。

原因

発生する原因は、両親(育成者)との間に「愛着」を上手く築けないから起きるようです。 わかりやすい例は幼い時の親との死別や、一定期間預けられていた場合などです。 他にも親の愛着スタイルが安定していない場合も起きるようです。

不安定型、回避型

大別して不安定型と回避型の二種類があります。

不安定型は十分な愛着が得られなかったために、愛着を過剰に求めたり、愛着を失うことを過剰に恐れます。 回避型は十分な愛着が得られなかったために、愛着を求めることをやめてしまいます。

不安型はラオウ、回避型はサウザーと思えばわかりやすいと思います。

共感

共感されたい

回避型愛着スタイルの人は「共感されたい」という欲求を過小評価します。 これは、以前から自覚がありました。

ずいぶん昔の話ですが、当時お付き合いしていた女性から「相手をしてほしい」アプローチをされたときに逃げ回っていました。 逃げると、相手からの「相手をしてほしい」アプローチが強化され、辟易して破綻しました。

当時の実感としては「めんどうくさい」でした。 今思うと、「相手をしてほしい」感情に共感できていなかったのだと思います。 さらに共感したように振舞うこともできず、どう反応してよいのかわからず戸惑っていたように思います。

共感できない

「相手をしてほしい」感情に共感できないのは、「自分の考えや感情が共感されるわけがない」と思っているからです。 「回避型愛着スタイル」の人が考える、共感される予想確率は限りなく低いです。 例えれば「空から女の子が降ってくる」確率と同レベルです。 このため、「共感されない」不満は「自分のところには空から女の子が降ってこない」不満と同レベルに思えます。 最初から失敗しかないチャレンジに失敗して、何が不満なのかが理解できません。

社会生活

共感能力の低さは、社会生活に影響が出ます。学生時代はあまり上手くいかなかったように思います。 共感できないため、ウェイウェイ出来ません。 ウェイウェイ出来きない人間がスクールカーストの上位に入ることはないので、中学高校は暗黒時代です。 ウェイウェイしなくてもよい仲間が見つかると楽しく生活できます。

社会人になると、社会生活への影響は少ないです。 会議であれば、論理的な説明さえできれば成り立ちます。 飲みニケーションなどで共感を求められることもありますが、拒絶さえしなければ、共感しないからといって迫害されることはありません。

共感能力が低くて、嫌われることもありませんが、特別好かれることもありません。 いわゆる人望に欠けます。ポジションによっては不利になるかもしれません。

個人的な対応

私は外見上は、実際どう見られているのかはわかりませんが、人の感情が読み取れないようには見えないと思います。 せいぜい愛想がないぐらいではないでしょうか?

共感能力がある人がどうやって人の感情を感じているかはわかりません。 私の場合は、心理学のように感情の原因を推測して理解しています。 たくさん本を読んだせいか、脳内にある人間の感情の原因リストは長いです。 そのうちで、現在の状況に一番近いものをパターンマッチして推測しています。

これは有利な面と不利な面があります。 誰かが怒っている時に、「口で言っている怒りの原因と真の原因が違いそうだ」と推測ができることがあります。 問題解決には有効です。 一方で、怒っている人は「とにかく怒っている感情を受け止めてほしい」と思っているようですが、 これに対しては「受け止める is 何?」となります。

おかげさまで対面でのコミュニケーションより、文章でのコミュニケーションの方が得意になりました。

治療?

治療が必要な性質のなのかはわかりませんが、共感能力を育てることはできるようです。

共感能力が低いといってもゼロではありません。 まれに共感出来ることがあるようです。 また「共感された」経験が少ないため、「共感されたい」という欲求を過小評価します。これは他人に共感することを放棄する原因になっています。

自分が他人に「共感する」「共感される」体験を繰り返すことで、共感能力を育てることはできるようです。 *1

典型的な例

1年前に ledsun.hatenablog.com で「生きる技法」を読んだと書きました。

いまの知識で思えば、著者の安冨さんは「強迫性パーソナリティ」でかつ「回避型愛着スタイル」でした。 「回避型愛着スタイル」の人間が感情を論理的に解釈しないと理解できない好例だと思います。

参考文献

愛着障害の克服 「愛着アプローチ」で、人は変われる

愛着障害の克服 「愛着アプローチ」で、人は変われる

愛着障害一般の話です。愛着障害の不安型と回避型を両方取り扱った本です。 過去の文豪や心理学の大家の愛着障害の例がふんだんに載っています。

回避性愛着障害 絆が稀薄な人たち

回避性愛着障害 絆が稀薄な人たち

上の本と同一著者です。回避性愛着障害に焦点を当てています。 回避性愛着障害をいくつかのタイプにわけて説明しています。 心理学の人には回避性愛着障害の人が多いようです。 共感能力の低い回避性愛着障害の人は、心理を論理で整理せずには居られないのかもしれません。

異性の心を上手に透視する方法

異性の心を上手に透視する方法

恋愛をテーマに、回避型愛着スタイルの男性と不安型愛着スタイルの女性がくっつきやすく、かつ上手く行きにくい理由が書いてあります。過去の経験がもろに該当していました。自分以外でも、該当する組み合わせは見かけるので、自分が当てはまるかもしれない人は読んでおくと心の準備ができて良いかもしれません。

タイトルは半分ぐらい詐欺です。特定の組み合わせのカップルが、お互いと心が全く噛み合わない理由を説明しています。

*1:世の中にはもっと良い方法があるでしょう。確実なことは専門家に聞きましょう。

サービス開発チームの拡大期におけるリーダーのレスポンシビリティ移譲に関する1アイデア

開発組織に関するポエムです。

背景

常駐や請負で、サービス開発チームのお手伝いをしたことがあります。 私に依頼がくる時は、サービスは売れていて、開発チームは拡大期にあります。 その時、開発者の人数は増えているが、開発リーダーの負荷は減らず、逆に増え続けるという現象を観測したことがあります。 過去に2件、目撃しました。

課題

開発リーダーはすべての「問い合わせ」と「機能拡張の意思決定」に参加する必要があります。 おまけに自分の実装タスクも持っています。 必然的に労働時間は伸び、「いつ寝てんだこの人?」という働き方をしています。

はたから見ていると、何年も続けられる働き方はないので、いつか破綻しそうな危機感があります。 実際、2件のうち1件の開発リーダーは退職しました。

果たして、我々はこの状況に対して何かできるでしょうか?

経験談

開発メンバーの視点

開発メンバーからはリーダーが大変なことはわかります。 ただ、どんな問題を抱えているのかはわかりません。 この立場でできることは

  • 要件を一度でなるべく細く聞き取る
  • リファクタリングを避けてレビュー工数を減らす
  • 修正点を最小にしてレビュー工数を減らす

などでした。このためには、受け入れるタスクを小さくする必要があります。 タスクが大きいと、リーダーとの相談量が増え、リーダーへの割り込み量が増えます。

アウトプットが少ないと評価されるのを覚悟で、手戻りにリーダーを巻き込まない強い心が必要です。 実際は、これができる人とやっている人は、とても少ないように思います。

開発リーダーの視点

今年の9月から11月に掛けて、炎上プロジェクトのリーダーをやりました。 立場は違いますが、共通する点もあるかもしれません。

炎上中のリーダーは手を止めることができません。 次のいずれをやめても、プロジェクトの進捗止まります。

  • 各機能の仕様や実装方針の意思決定
  • ボトルネックになる機能の実装
  • 進捗の把握
  • 顧客への進捗の報告とスケジュール調整

特に困るのがタスクを切り出す作業です。 タスクとして切り出したものは、開発メンバーにお願いできます。 問題をどのように解決するか、考えタスクに落とす部分は一番負荷が高いです。 一方で、それまでの経緯などコンテキストへの理解が必要であり、簡単に移譲はできない部分です。

また、プロジェクトの遅れに責任を感じているリーダーから、「プロジェクトを一度停止して体制の修正をしたい」とは言い出しづらいです。

方法の一つとして、リソースプランナー役の人に入ってもらって

  • 進捗の把握
  • 顧客への進捗の報告

を巻き取ってもらうと、だいぶ楽になります。 経験するまでリソースプランナーは要らない役職だと思っていました。 実際はすごく頼りになります。 ただし、感覚としては20%ぐらい楽になるぐらいです。 すでに120%以上の稼働に達している場合は、それほど効果がありません。

問題

  • 開発メンバーからはリーダーの本質的な課題が見えない
  • 開発リーダーは作業を止めることができない

開発チームからボトムアップで状況を改善することは難しそうです。

イデア

ワイガヤやったらいいのではないかな?と思います。

この手のコミュニケーションのミスマッチは、「サービスに対する熱意の差」みたいな誤解に基づいている気がします。

  • リーダーは、俺がこんなに頑張っているのにメンバーのやる気が足りない
  • メンバーは、俺も頑張りたいのに、どう頑張ればリーダーの役に立つのかわからない

熱意とかやる気は、見た目に差があっても内部的に差があるかはわかりません。 一方で、サービスに対する興味のある点や価値観は、開発メンバー全員が違うはずです。 今のフェーズに、たまたま価値観が合っている人が「熱意がある」ように見えているだけではないでしょうか?

そんなわけでワイガヤです。 サービスの開発を数日止めて、 二泊三日の合宿でサービスに対する思いを表明しあってはどうでしょうか?

  • 次の施作案
  • 既存の気にくわない点
  • 俺の感じるかっこよさにマッチする点、マッチしない点
  • どんなユーザーに使わせたいか

色々なアイデアがあると思うので、決めるためでなくて、「みんな、そんなこと考えてたのかよ!」と思うための会をとことんやるといいのではないかな?と考えました。

参考:「ホンダ流ワイガヤ」実践のコツと方法を、元ホンダ 本間 日義氏にインタビュー |ビジネス+IT

実践したことはないので、与太話です。

うまくいけば

すくなくとも開発リーダーの気持ち面で時間は稼げそうです。 その隙に、「雑用タスク何でもできるマン」*1を投入して、開発リーダーの持っているタスクまで落ちていない作業をタスク化。 チーム内に振りまいていけばなんとかなるでしょう。 開発リーダーの稼働が80%ぐらいまで落ちれば、もともと優秀な人ですから、あとは自分で改善できるはずです。

*1:例えば、私。ただ、目に見えるアウトプットは、通常の開発者とは違うので、そういうjob descriptionの元でないと怖くてできません。