エンジニアにおける"難しい人"への対処法

はじめに

以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。

“難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

上の記事ではオーストラリアにあるニューサウスウェールズ大学のウィル・フェルプス准教授が行った「腐ったリンゴの実験」において「難しい人」がチームの生産性を30～40%低下させたことを紹介しています。
そこで引用されている『THE CULTURE CODE ―カルチャーコード― 最強チームをつくる方法』（ちなみにこの本は、良いチームとは、良いマネージャーとは何かという観点で素晴らしい本です）では、チームに悪影響を与える人（難しい人）を、性格が悪い人、なまけ者、場を暗くする人の3種に分け、いずれもチームに対して同程度の生産性の低下をもたらすという結果が示されています。
また、その実験においてはジョナサンという特定の人の振る舞い（たとえば誰かから攻撃的な発言がされた後、微笑みを投げかけたり周囲に簡単な質問をして傾聴し、緊張を和らげるような振る舞い）が難しい人の毒を中和し生産性の低下を防いだことも併せて示し、心理的安全性を確保することの重要性を主張しています。
ただ、個人の見解ではジョナサンのような振る舞いができる人は、特にエンジニアにおいては非常に希少で、20人に1人いるかいないかだと感じています。
ですのでもちろんジョナサンのような振る舞いを参考にチーム改善に取り組むことは重要だと思うのですが、それとは別に、本記事では「難しい人」の定義を少し広げた上で、その特徴と対処法について自分なりの見解を示したいと思います。

私個人の経験に基づくため定性的かつ主観的な意見にはなりますが、メガベンチャーにて8年間様々なチームメンバと開発業務に携わりながらスクラム開発の各役割を1年ずつ、それからミドルマネージャーを2年経験し、さらに周辺チームや他部署の同期、社外コミュニティなどでの事例もいろいろと見聞きしてきたうえで、現在は2社目で開発部門責任者をやっており、それなりに蓄積されている情報量は多いと思っております。

ただ、そのうえで「難しい人」というラベリングを使用した記事を公開することには抵抗もあります。
なぜならそれが、自分自身を「難しい人」だと思っている人にとっては呪いの言葉となってしまう可能性があるからです。
それはたとえば学習塾で「数学的センスの無い生徒の特徴」という資料を先生だけでなく生徒に対しても公開するようなものです。
一度、自分が数学的センスの無い生徒だと思ってしまうと、この先センスを獲得できる可能性もあるのに、数学の勉強の意欲が吹き飛んでしまうかもしれません。
それでも自分は今回ラベリングを使用して記事を書くことにしました。
ラベリング、つまり名前をつけることは、特定の概念を表現し様々な結論を導き説明するのにとても便利です。
本記事では「難しい人」を単なるレッテルではなく具体的なコミュニケーションアンチパターンとして分解したうえで、マネージャーとしての対処法だけでなく本人の捉え方についても説明し、呪いの言葉ではなく、今後このようなアンチパターンとどのように付き合っていけばよいのかを前向きに考えられるようにすることを意図しています。

ところで『Team Geek』では「難しい人」を「有害な人」と表現しています。
『Team Geek』においても有害な人というラベリングの危険性については触れていて、有害な「振る舞い」に焦点をあてるべきだとしています。
私も半分はそのとおりだと思っていて、だからこそ「難しい人」の特性はその人のスキルの一部であり、その人の人間性そのものではない（スキルのように凸凹があって当然のもの）と考えます。
残り半分は、結局重度の有害な振る舞いを改善できない人もいる以上、それによって酷く被害を受けている人からすればやはり難しい「人」となってしまうので、振る舞いだけを分離して扱えるほど単純な話題ではないと思っています。
なお、『Team Geek』で紹介される具体例は海外のOSSコミュニティで現れるようなパターンが多いですが、本記事では国内のWeb系自社開発企業で観測されやすいであろうパターンを記載しました。

難しい人は、こんな振る舞いをする人

この記事では「難しい人」を「チームの生産性を下げたり心理的負担を与えるような振る舞いやコミュニケーションを行う人」と定義したいと思います。
そしてそのような振る舞いやコミュニケーションとはどのようなものなのかについては、具体例を列挙します。
（なお具体例は今までの経験や観測、及び伝聞を総合して整理したもので、特定個人にのみあてはまる振る舞いを示して批判する意図は無いことをご理解いただければ幸いです。）

• チームの創造的な議論を阻害したり他者の時間を奪う
  • 他者の話に割り込んで自分の意見を差し込む
  • 常に自分の興味を優先して脇道にそれたり特定の技術領域の細かい話を続けて議論の進行を遅らせる
  • 自分の意見が理解されないとき、特定の本やドキュメントを事前に読んでくるように要求し、議論を投げ出す
• 自分が完全に納得した状態になるまで他者を操作しようとする
  • 他者の意見に違和感を感じた時、自分が完全に納得するまで質疑応答を繰り返し、際限なく時間を消費する
  • 自分が納得できない場合、他のチームメンバ全員が折れるまで自分の意見を譲らない
  • 関係部署全体で取り決めた方針と自分の考えが食い違った時、チーム内での議論を経ずにいきなり社内チャットで意見をブロードキャストして関係部署に混乱をもたらす
• 誤った意見に対して恐怖心を植え付けるような指摘の仕方をする
  • 他者の発言中に誤りを見つけると即座に割り込んで詰問し、誤りを認めさせる
  • 逆に自分は誤りが露呈することを恐れて自信のある領域でのみ発言し、発言という行為自体に不要なハードルを設ける
  • コードレビューでは見つけた改善点を細かく指摘するが、改善が必要な理由や重要度の説明が不十分なまま、修正するように一方的に指示する
• 言語化能力が低いのに他者に負担をかける形で自分の気持ちや意見の内容を察してもらおうとする
  • 攻撃的な言葉を好んで使うが、その具体的内容は他者が丁寧にヒアリングすることでようやく明らかになる
  • 急に議論の参加に消極的になり、気持ちを察してもらおうとする。察すること無く決められたチームのルールは守ろうとしない
  • タスクで認識のすれ違いが発生したとき、相手に要件の明確化を要求するが、自分が欲しい情報が何かは明確化できない
• 匿名コミュニティのノリを持ち込んで他者をおちょくったり意欲をくじく発言をする
  • レビューコメントで、こんなことは分かって当然とばかりに断片的な情報や参照URLのみを書いて反応を見る
  • 自分が決めた高い水準を満たさない人に対し、こいつは何も知らないというレッテルを貼って恥をかかせ、成長意欲をくじく
  • 関係者も見ているような場所（社内SNSなど）で、特定の対象や人がクソであるなど攻撃的な言葉を発して雰囲気を悪くする
  • 皮肉やブラックジョークを好み、真面目な提案をしにくくなるようなネガティブな空気を作る
• 苛立ちや怒りの感情をあらわにすることで他者に（自分に都合のいいように）動いてもらおうとする
  • 怒りの感情をぶつけ、相手を威圧して自分の主張を通そうとしたり、自分に従わせようとする
  • 自分の都合が悪くなると機嫌を損ねたように振る舞うことで、他者が常に自分を最優先に考えて動いてくれるようにする
• 不満の表明に終始し、改善に目を向けたり改善のための行動を取れない
  • 問題が起こるたびに誰が原因であるという主張をしたり非難をしてチームの雰囲気を悪くする
  • チームでの共同作業中に問題が発生して行き詰まると不満や文句を言い始め、チームで協力して解決しようとする気持ちをくじく
  • 特定の部署や人に対する不満を主張するが、自分が行動する気はなく他人任せ
• チームにとって困難な課題がある時に怠けようとする
  • 自分にとって都合の悪い話題になった途端、嫌がる素振りを示したり議論への参加をやめる
  • この話題は結論が出ない、時間がもったいないなどと主張してさっさと切り上げようとする
  • 自分が負担したくない役割は虚偽の理由を作り上げて他者に押し付けようとする
• 好き嫌いで行動し、気に入らない相手を拒絶する
  • 嫌いな人に自分の納得行かない役割を割り当てられた時、業務を放棄する
  • 嫌いな人の行動を誇張や虚偽を織り交ぜて吹聴し、自分の味方を増やそうとする
  • 嫌いな人が自分に悪意を持って嫌がらせをしていると（思い込みで）主張し、チームメンバを困惑させる

自分が今まで見聞きしてきて印象に残ったものを全方位からかき集めたので、さすがに「全部盛りな極端に難しい人」はそうそういないと思いますが、部分的にあてはまったり程度が軽いものを含めたらちょくちょく聞く事例じゃないかと思います。
また、一部の項目はその人のコンディションが悪かったり（いらいらが溜まっていたり）、知識がなくて良い代案や改善策を思い浮かばなかっただけだったり、たまたま仲の悪い人と一緒に働いている時に表出してしまったりなども含めれば結構な人があてはまったりもするのではないでしょうか？
これらは一種のコミュニケーションアンチパターン集です。

全てに共通していることが1つあります。
それは相手が困ってしまう自分の欲求をそのまま言葉やふるまいとして発してしまっているということです。
コミュニケーションの主体が100%エゴになっているとも言い換えられます。
たとえば言語化能力が低く他者からのフォローが必要なのであれば、攻撃的な言葉を使いたいという欲求は抑えないと周囲の人はつらい思いをします。
しかしそのことに気が回らず、とにかく使いたくなる攻撃的な言葉が思い浮かんだらそれを（相手のことを考えず）衝動的に発してしまうのは、アンチパターンです。
程度にはグラデーションがありますが、あてはまる項目が多ければ多いほど、程度が深刻であればあるほど、難しい人としての問題行動となってチームメンバやチーム全体にダメージを与えることとなります。

ちなみにコミュニケーションアンチパターンを避けようと意識を集中するあまり、逆に自分の主張を抑え込んでしまう人もいるかと思います。
それに対する解決方法の1つとして、アサーティブネスという考え方があります。
これはもともと心理学における行動療法の分野で提案された概念で、最近はビジネス界隈でも多用されているようですが、以下の3つの分類を基本とする考え方です。

• 受身的なコミュニケーション：言いたいことが言えずに、自分の意思や権利を自分自身で守れないようなコミュニケーション。
• 攻撃的なコミュニケーション：相手の権利を尊重せず、自分の権利ばかりを主張するコミュニケーション。
• アサーティブなコミュニケーション：相手の自己主張する権利を認めたうえで、自分自身の意思や権利を主張するコミュニケーション。

難しい人が「攻撃的なコミュニケーション」、自分の主張を抑え込んでしまう人が「受身的なコミュニケーション」をしているため、「アサーティブなコミュニケーション」が望ましいという考え方です。
これ自体は非常にシンプルな考え方ですが、実践するのは難しく、様々な解説書やトレーニング本が発売されているのでそれらを読むことで改善する人もいるかもしれません。

難しい人は、ソフトスキルの足りない人

難しい人は、相手が困ってしまう自分の欲求をそのまま言葉やふるまいとして発してしまっていると前節で説明しました。
これは相手に意地悪をするためというよりも無自覚にしているケースが多く、純粋にソフトスキルの不足から来ていると考えられます。
たとえば他者への配慮ができていないのは、先天的要因として根本的に幼い頃から他者の気持ちを想像する力が欠如していたり、後天的要因として個人で没頭する分野があったがために他者と触れ合う機会が少なく他者を想像する経験が不足している場合などが原因の例として考えられます。
また、自らの苛立ちや怒りで他者を操作しようとするのは、たとえば自分の感情をコントロールする能力が欠けていたり、自分の願望を言語化する能力が足りていないことが原因であったりします。
そして技術力の低い人がシステムに問題を引き起こすのと同様、ソフトスキルの低い人はチームに問題を引き起こします。
そのためそれらを全て能力として扱って、たとえばよくエンジニア界隈で言われる「優秀だが攻撃的なエンジニア」というのは、技術力は高いがソフトスキルが低く、総合的な能力は中くらいの人物（ただし能力値が凸凹でリスクが高く適材適所が要求される人物）と評価するのが妥当かなと思います。
もちろん厳密には会社の事業内容や組織体制によりますし、たとえば事業の命運が純然たる技術力にかかっているような高度なものであればその人の評価は相対的に高まるでしょうし、逆にチームプレイが最重要なのであれば評価は最低となるでしょう。

難しい人が能力の足りない人と捉えるのにはもう一つ理由があります。
それは他者への配慮ができていないケースでも、難しい人本人はむしろ会社のために最善を尽くしているつもりであることが多いということです。
多いというか、自分が知っている限りでは全員、本人なりの使命感を持って取り組んだ結果だったり、無意識のうちに引き起こしてしまっているように見えます。
たとえば他者の話に割り込んで自分の意見を差し込むのは、本人としてはその方が議論がスピーディに進んでより多くの成果を出せるだろうと考えてのことだったり、すぐに言わないと自分の意見を忘れてしまうので忘れる前にチームに共有した方がいいと思ってのことだったりします。
あるいは他者の誤りを厳しく指摘したり、自分の意見が理解されない時に本やドキュメントを読んでから議論に参加することを要求したりするのは、もっと真剣に技術レベルを高める姿勢を持ってもらわないと長期的には事業の成功を期待できないと考えてのことだったりします。
実際、攻撃的だが優秀なエンジニアというのはこういう人が多い印象があります。
そしてあまりに技術力の差が大きい場合や事業が高度な技術を要求する場合などは、むしろその難しい人の姿勢を尊重したほうが結果として会社のためになるという可能性すらあるといえます。
ただ、いずれにせよ他者に配慮する能力があればより良い進め方をすることができるわけですから、やはり難しい人というのは純粋に能力の問題なのかなと思います。

難しい人にマネージャーが悩まされる原因

難しい人にマネージャーが悩まされる原因は、ずばりマネージャーの評価と難しい人の自己評価とのギャップです。
技術力が低い人は、問題を自覚しやすいです。
なぜなら技術力が低ければコードレビューで手取り足取り教えてもらうことになりますし、タスクの進捗遅れやバグの多発で自分の能力不足が明らかになるためです。

一方「難しい人」は、自身の問題を自覚しにくいです。
そもそも他者への配慮ができず問題を起こしている場合、他者にダメージを与えていても気づくことができないためです。
また、他者にダメージが加わった場合に調整するのはマネージャーであり、当然ながら難しい人はマネージャーにかかっている負担を認識することができません。
マネージャーもタダ働きしているわけではありませんから、難しい人の対応をするためにかける時間分のコスト（マネージメントコスト）がかかっているわけです。（実際にはマネージャーの心理的負担や退職リスクも勘案されるべきでしょう。）
また、チームメンバ全体の時間を奪う振る舞いをしている場合はチームメンバ人数分の時給がコストとして降りかかります。
結果として、マネージャーは本人にどのような問題が発生しどのような負担やリスクが生じているのかを説明して理解してもらうか、この問題に目をつぶって自己評価に近い給与を与えるかをしない限り、難しい人は不当に低い評価をされていると認識してしまいます。

そして難しい人とされている当人にとっては、この不当に低い評価というのは心理的ダメージとなります。
つまり厄介なことに、難しい人の被害者は周囲のメンバだけでなく、難しい人本人もまた被害を受けているともいえるわけです。（難しい人のことを批判したところで問題を解決できないということです）
こういう背景があって、周囲にダメージを与えている人でも技術力に応じた給与を与えてしまっているマネージャーも結構いるんじゃないかと勝手に推測します。
ただ、それは企業がお金持ちな場合に限るので、そうでない場合はやはりできるだけ総合的な能力に応じた給与を提供できるように、後述する「難しい人に対するマネージャーの対処法」の3を実践した方が良いのかなと思います。

難しい人が引き起こす、より大きな問題

難しい人が引き起こす問題はチームの生産性低下やマネージメントコストだけでも十分に大きなものですが、それ以上に問題なのが、「他者に与える心理的ダメージが大きく、うつ病や退職に追い込んでしまうリスク」です。
そして悲しいことに、実際にうつ病や退職に追い込まれる事例は本当に数多く（様々な部署や会社で）聞いてきました。
（数多く聞いてきたからこそ、特定個人に結びつかないように話すことができます……）
うつ病は本人にとって取り返しのつかないダメージであるとともに、嫌な表現ではあります（し、そこまで放置してしまったのはマネージャーの責任です）が会社としてはうつ病になったメンバのケアに大きなコストが必要となります。
したがって重度の難しい人はこれらのリスクがあまりに大きいため、もはや自己評価とのギャップは測定不能なレベルにまで拡大してしまいます。

現実的には、このような大きな問題を引き起こすリスクが高い人は採用の時点で弾く必要があります。
たいていの面接官はこのような観点で問題のある人かどうかをチェックしていると思いますが、私自身も面接官として、最低限、他者に対してどれだけ配慮する力があるのか、そして他者への配慮の方法として具体的にどれだけ引き出しがあるかは確認するようにしています。

難しい人に対するマネージャーの対処法

軽症な場合

軽症な場合は、難しい人としての振る舞いがなされているものの、周囲へのダメージは限定的で現状のチーム体制を続行できる状況です。
この場合、難しい人に対してフィードバックを行い、指導し改善させるのがマネージャーの役割である、と言われることもありますが、私はこの考えを支持しません。
というのも難しい人に対して直接このようなフィードバックや指導を行う場合、以下の2パターンのリスクがあるためです。

A. 当人がショックを受けてやる気を失ってしまう
B. 悪いのは自分ではなく相手だと主張する

Aは、意地悪な言い方をすると「拗ねてしまう」状況です。
急にフィードバックをした場合、本人の心の準備ができていないので、どうしてもショックを受け、抵抗を感じることになります。
もちろん『Team Geek』で紹介されていた例のように、そこで素直に改善してくれる人もいると思いますが、個人的にはこのリスクを無視できません。
拗ねてしまうと、たとえば今まで攻撃的ながら周囲に意見やアドバイスをしていたのが、それらを一切やめて手助けや協力もしなくなり、さらなる混乱がチームにもたらされます。

Bは、急なフィードバックによる抵抗がフィードバック内容そのものに向かった場合で、そもそもフィードバックの内容に疑いを持ったり、それは本当に自分が改善すべきところなのか？相手が改善しないといけないことなのでは？と反論します。
そして片方が100%悪いというパターンはほとんどありませんので、一度反論されると意外と説得が難しくなります。
これは当人が周囲の人からの評価に興味がない場合やマネージャーを信頼していない場合に特に起こりやすくなります。

さらに、仮に運良く1と2が起きなかったとしても、指導になりますので改善の姿勢は受け身になります。
受け身な場合はよほどマネージャーを信頼していないとやる気を出すのは難しいです。
もちろん、信頼関係を作って発破をかけるのが上手なマネージャーの場合や、指導を通して改善を進めるのが得意な部下の場合はうまくいくかもしれませんし、たとえば評価制度として360度評価があり本人が周囲から評価されたい意欲があったりする場合は直接フィードバックすることも有効だと思いますので、マネージャーの特性や状況に応じて判断するのがベストだと思います。

さて、直接フィードバックするのが難しい場合に自分が考える対処法が以下の3つです。

1. 難しい人としての振る舞いが出現しないようなプロセスやルールをチームで定める
2. 難しい人をうまくコントロールしながらファシリテーションできる相性のいい人をパートナーとして組ませるようにする
3. 目標設定や評価制度を工夫して周囲の人からの評価に興味を持たせ、自主的な改善を促す

1はもっとも再現性と再利用性が高く、推奨できる方法です。
たとえば他者の話に割り込んで反対意見を言ってしまう人がいる場合、アイデア出しのフェーズと批評のフェーズを分けるようにし、事前にその進め方について合意を取るようにします。
合意を取ったのですから、アイデア出しの段階で反対意見を言ってしまった場合、チームメンバから指摘が入っても本人はすんなり受け入れることができます。
また、コードレビューで理解しづらい指摘や一方的な指示をする人がいる場合、コードレビューでどのようなコメントが必要なのか、事前にチームで合意を取ることが有効です。
たとえば指摘内容の緊急性、重要度のラベリングを必須としたり、改善点の指摘の説明に不足がある場合はレビュワー側に説明責任があることを明確化したり、具体的にどのような内容のレビューコメントをつけることがチームとして望まれているのか、事前に認識合わせをします。
言葉足らずな指摘や攻撃的なコメントは基本的に衝動的な欲求であって意図的に相手を攻撃したいわけではないはずですので、事前にどのようなコメントをすれば良いのかを具体的にガイドしてあげることで、本人も（面倒に思いながらも）前向きに協力してくれるはずです。
他に、自分の意見を譲れない人に対してはボルダルールが有効です。
単純な多数決では少数意見があまりにも簡単に無視されてしまうデメリットがあるのに対し、ボルダルールでは票に重みを持たせられるため、自分のこだわりをその重みに表現することができ、難しい人のこだわりをある程度は尊重しつつ、最後の決定はボルダルールというルールに従ってもらう、ということができます。
似たような意思決定サポートツールとしてトレードオフスライダーも難しい人に対して有効です。

ただ、1はその代償として仕組みづくりやルール化にコストがかかりますし、そのための知識も必要です。
参考になるプロセスはアジャイル開発のベストプラクティスに数多く示されていますが、それをチーム内の誰かが知っているか、勉強する必要があります。
また、この手法でカバーできる範囲も限られており、難しい人の振る舞いを全て抑制することは現実的に不可能です。
一方でこのようなプロセスやルールは難しい人でなくても取り組みやすくなる工夫だったりしますので、チームの資産になることを考慮すればコストパフォーマンスは良いと思います。
さらにその上で（難しい人の毒が緩和された状態で）『Team Geek』で書かれているようなHRTの3本柱をチームとして重視する文化づくりをしたり、冒頭で触れたジョナサンみたいな振る舞いをチームで実践していこうとするのは高い効果が期待できると思います。

2はもっともお手軽で即効性のある手法です。
冒頭で触れたジョナサンのような素晴らしい振る舞いをする人間もこのパートナー役に適任です。
ただ、このようなパートナー役が務まる人は希少なため異動がしづらくなり、チーム間の人員調整に大きな制約がかかります。
最悪、パートナー役となっているメンバのキャリアや人間関係が固定化されて飽きが生じ、退職されるリスクも上がります。
往々にしてパートナー役が務まるメンバは能力全般が高かったりしますので、退職時のダメージは相対的に大きくなります。
とはいえ現実問題この手法に頼るマネージャーは多いのではないかと想像します。
相性のいい人を選んでチームを構成するのはあらゆる業界のマネージャーにとって普遍的な基本手段だからです。

3は即効性も確実性も無いものの、当人が自主的に難しい人から脱する取り組みを始めるきっかけになりえます。
前半で述べた2つのリスクは当人が周囲の人に興味がないほど大きくなるという話をしましたが、であれば何とかして周囲の人に興味を持たせようという解決策です。
もちろんその取り組みは（個人差はありますが）大変なものとなるはずですので相応のマネージメントコストはかかりますが、もしその人の技術力が高い場合は見返りも大きいですので、改善することに賭けて全面的に支援することもありだと思います。
たとえば次のステップに進むためにはこういう能力が必要で、周囲からこういう評価を得ている必要があるなどを説明した上で、周囲からの評価を随時フィードバックします。
本人がやる気なのですから、多少厳しいフィードバックでも受け入れる余裕がありますし、マネージャーの心理的負担も小さくなります。
そして実際に改善する期待も、一方的に指導するよりも遥かに大きいといえます。
ただし、先天的要因によってそもそも他者への配慮ができない場合は本人が苦しむだけになる可能性もありますので、その点はマネージャーが気をつけなければなりません。
そのような場合は勇気を持って諦め配置換えをしたり、最後の節「精神疾患との関連について」で説明する内容を踏まえて対策を考える必要があります。

重症な場合

重症な場合は、特定のチームメンバに加わっているダメージが大きく、実際にうつ病や退職に追い込まれる疑いがある状況です。
この場合は事態が差し迫ってますので、即座に介入を行って難しい人とダメージを受けているメンバを適当な理由を作り上げて物理的に引き離します。
たとえば、あるチームからヘルプが要請されていて急遽あなたに頼むことになったとか、部門の誰かがこの役割を受け持たなければいけないのだが本日あなたが任命された、など、何でもいいので上位のマネージャーと相談及び交渉してポジションを確保し、難しい人とダメージを受けているメンバのどちらかをチームから引き離します。
都合のいいポジションが得られない場合、何とか自チーム内で特別なタスクやプロジェクトを立ち上げてどちらかをアサインし、レポートラインをマネージャーと当人に限定し、当人同士のコミュニケーションを遮断します。
なお、これもだいぶ具体的に書いてしまいましたが、結構常套手段みたいで、（私の知っている）マネージャーの皆さん活用しているようです。
いずれにせよ、うつ病も退職も一度ラインを超えてしまうと取り返しがつきませんので、疑いが生じた時点で先手先手で対策を進める必要があります。
なお、言動がハラスメントに該当する場合は別途会社の規定に則って対処します。

難しい人に対するチームメンバの対処法

次に、マネージャーではなく同じチームメンバとして、どのように難しい人に対処したら良いのかを説明します。
まず、難しい人を変えようとするのはアンチパターンです。
マネージャーですら難しいことをメンバーがやるのは困難を極める上に、変わって欲しいという願望はそのまま実現されないものとしてストレスに変貌します。
基本はマネージャーに相談すること、それから前節で説明した「難しい人としての振る舞いが出現しないようなプロセスやルールをチームで定める」で改善するのが良いと思いますが、それらで解決が期待できない場合は異動や転職で逃げることが最善手です。
ただ、同時に周囲の人がどう感じているかも聞いておくといいと思います。
周囲の人が特にダメージを受けていない場合、あなたの耐性が低い可能性があります。
相性が悪い場合は逃げると良いのですが、そうでない場合は逃げても再び同じような難しい（とあなたが感じる）人に遭遇する可能性が高くなります。
その場合に私が推奨したいのは、より大きな目標に意識を集中させることです。
あなたが今の仕事で本当に成し遂げたいことは何でしょうか？
そこに意識を集中すれば、難しい人というのはただの目標達成の障害物に過ぎないと感じられ、むしろこの障害物を乗り越え大きな目標を達成することはスキルアップにも繋がり、将来の転職でもストレス耐性や目標達成能力の観点でアピール材料にすることができるでしょう。

また、その人に対する分析と自己分析を行ってストレス原因の解像度を高めることも有効です。
あなたが難しいと感じる人は、具体的にどのような振る舞いがあなたの感情を害したり負担をかけていますか？
その人はなぜそういう振る舞いをしているのでしょうか？
そしてあなたのどういう感性や期待と衝突しているのでしょうか？
こうやって解像度を高めれば、思わぬ解決策が思い浮かんだり、冷静になって気が楽になったりします。
アンガーマネジメントという、イライラや怒りの感情をコントロールする手法も参考になると思います。

最後に、エンジニアであれば技術力を高めることが最大の保険となります。
技術力が十分に高ければ攻撃的なエンジニアの助言に頼る必要はなくなり、大きな目標を持ちやすくなって難しい人という障害物も意識の脇に追いやることができ、逃げの手段も豊富になります。
特に難しい人への耐性の弱い人はフリーランスエンジニアになるのも有効な手段かもしれません。（伝聞ではありますが、フリーランスになると煩わしい人間関係から解放されるとの評判をよく聞きます。）
技術力があれば、少なくとも昨今のエンジニア市場では引く手あまたなので、安心してフリーランスになれると思います。

追記: 難しい人を抱えるチームメンバとしての重要な点を一つ書き忘れていたので追記します。
難しい人が場の空気を悪くした時、空気を良くするためについついその人の発言を拾ってフォローしたり、受容した上で次の話に進めてしまおうとすることが結構あると思います。
ただ、これは（状況によるとは思いますが基本的には）アンチパターンです。
なぜならその難しい人は（特に後述するASDだった場合）、自分の発言が受け入れられたものとして、つまり好ましいものだとして報酬を得てしまうからです。
報酬を得てしまうと、同じことをこれからも繰り返してしまいます。
ASDの特性を強く持つ人からすると想像し難いかもしれませんが、定型発達の人たちは社交辞令や場の空気を良くするために軽い嘘は平気でつきます。（逆に定型発達の人からするとそれが社交辞令だとわからない人がいるなんて想像し難いかもしれませんね）
そして定型発達の人は想像し難いかもしれませんが、ASD傾向の強い人は社交辞令としての言葉をそのまま額面通りに受け取ります。
そのため、ASD傾向の強い人からすれば、別のタイミングで良くない振る舞いについて指摘を受けた時、「だってあの時はみんな自分の振る舞いを受け入れてたじゃないか。なんであの時言ってくれなかったんだ！」のようにトラブルに発展するか、表に出さなくても内心の不満として溜め込みます。
空気が悪くなった時は難しい人をフォローするのではなく、あくまでジョナサンのように、周囲の人に働きかけ、周囲の人の発言を尊重することで空気を良くするようにしましょう。
そのためには、有害な振る舞いを許容しないという毅然とした態度が必要だということでもあります。

追記その2: もう一つ書き忘れてましたが、上司（マネージャー）が「難しい人」である場合、対処の難易度は飛躍的に上がります。
2つ上の上司が信頼できる場合は相談して解決策を見出だせるかもしれませんが、基本的には異動や転職が最適解になるかと思います。
あるいは我慢強い人であればその上司が異動するまで待つ選択肢もあります。（会社によっては部門全体で上司の異動の頻度がだいたい分かるケースもあるかと思いますので。）
とはいえ上司が「難しい人」である場合のダメージは会社としても大問題であり、幸い私が関わった会社ではそのような人が上司の立場に極力ならないように部門が運営されていました。（もっとも、専門性が高い部署や小さな会社では代わりがいないので仕方なく、というケースもあるかと思いますが……）

自分が難しい人としての自覚がある場合の対処法

自分自身が難しい人だと思われているのではないか、そう心配する人も多いのではないかと思います。
そして実際、そう思われていることもあるでしょう。
単なる思い過ごしなのかわからない場合、マネージャーに対し、自分はテックリードやマネージャーに向いていると思うかという質問や、具体的にまずかったと思う振る舞いの例を投げかけて相談するのが良いと思います。
誰がテックリードやマネージャーに向いているかはマネージャーは日々考えてますのでいろいろ答えてくれる可能性が高いですし、振る舞いの例も具体的であれば、マネージャーは勇気を持って率直にフィードバックをくれる可能性が高いです。
一方、チームメンバに相談することはおすすめできません。
なぜなら平凡な人は相手を傷つけたくない気持ちが強いため、「そんなことないよ」、「気にし過ぎだよ」と言ってしまう可能性がとても高いためです。
また、最悪なのはミーティング中にその場で自分の振る舞いがまずかったかどうか周囲の人に確認してしまうことです。
その場合、ファシリテーターは穏便にその場を収めて議論の本題に戻そうと「そんなことないよ」と済ませてしまうため、本当はまずい振る舞いをしているのに承認を受け、しかも周囲の一部の人はそのやり取りを通じてさらに不快な気持ちを強めてしまいます。
もちろん、お互いが素晴らしい信頼関係で結ばれているチームであればミーティング中に確認をしても率直なフィードバックを受けられるかもしれませんが、その場合は既に他者も似たようなやり取りをしていると思うので、それが今まで無かったのなら危険です。

さて、運悪く自分がどうも難しい人に分類される人だと分かったとしましょう。
しかしそのような人は、自覚のない人に比べると既に大きな一歩を踏み出せています。
なぜならその後のステップを自分の意志で選択できるからです。
自覚がある場合、難しい人としての振る舞いを果たして自分が修正できるのか、そして修正したいと思うのかが分岐点となります。
修正できそうであれば劇的に成長できる可能性がありますし、修正できなさそうであれば適材適所で個の力が活かされる分野とポジションに異動または転職する決断ができるでしょう。

修正できるかどうかを判断するために個人的におすすめするのが、一日だけでも良いので「傾聴」に徹してみることです。
難しい人としての振る舞いは多くが「まずいタイミングで」「不快な表現」を言っているので、傾聴に徹していればそのような振る舞いは出にくくなりますし、何より多くの発見が得られるはずです。
それは、実は他の人の話に相槌をしながら「なるほどです」、「いいですね」、「賛成です」、などの簡単な言葉を発するだけで、自分が一切意見を言わなくても案外順調に議論が進むということです。
特に他者の話に割り込んでしまう癖のある人は一度（たとえ途中で他者の意見の誤りを見つけたとしても）黙ってみると、話が終わったタイミングで他の人が自分の言いたかったことを言ってくれたり、少し間をおけば他の人がアイデアを出して前に進んでくれることが分かると思います。
そして黙っていても自分が必要とされている場合は周囲から質問が来るはずです。
もちろん、自分が圧倒的に高い技術力を持っていて、なおかつ嫌われている場合は自分に質問が来ないまま品質の低い設計や実装が進んでいってしまうかもしれません。
ただ、その場合も後から取り返すことはできると思いますので、とにかく一度傾聴を試してみる価値はあると思います。
傾聴はコーチングやカウンセリングの基本でもあるので、それらの講座に通って体験してみるのも良いでしょう。
傾聴では相手の立場に立ち、相手が何を考えていて、何を求めているのかを共感しながら感じ取ることに集中し、自分の考えに思考を取られないようにすることが重要です。
ここで何の手応えも感じられないのであれば、そもそも相手の視点に立つスキルが欠如しているかもしれません。
その場合は運が悪かったと思って、自分はもう難しい人を脱却することはできないと諦めるのも一つの選択だと思います。
ただ、理想的な傾聴を行うこと自体は非常に難易度の高いスキルですので、ちょっとでも手応えがあったなら諦めるのはまだ早いかもしれません。
次に説明するように自分が先天性のASDである可能性を考えて諦めるか判断するのも手です。

精神疾患との関連について

私はエンジニアとして働きながら、通信制大学ではあるものの、公認心理師の学部で必要なカリキュラムを履修し心理学の学士を取得したというバックグラウンドもあり、精神疾患との関連についても触れておきたいと思います。
まず言えるのは、精神疾患との関連を考えたところで根本的な解決にはならないものの、本人も周囲も知っておいた方が心理的に楽になったり対処法を考えやすくなったりなどのメリットがあるということです。
いわゆる難しい人がASD（自閉スペクトラム症）やBPD（境界性パーソナリティ障害）としての特性を大なり小なり抱えているケースは（医師の診断ではない以上単なる推測ではあるものの）多いはずです。
ASDは、以前はたとえば自閉症に加えてアスペルガー症候群など個別の分類がなされていたのが、それらに共通する特性が人によって様々なパターンで様々な強弱で現れるため、それらをスペクトラム（連続体）として扱うようになったという経緯があり、それの意味するところは、ある人がASDなのかそうでないかはどこにしきい値を置くかの話であり、ASDでなければASDとしての特性を全く持たないことにはならないということです。
私が先ほど、難しい人はそれらの特性を大なり小なり抱えているはずだと推測したのは、このようにASDと定型発達の人の間に明確なラインがあるわけではないためです。
医師によって定型発達に分類されるような人であっても、他の人より特定のASDの特性が強く出ていれば難しい人としての振る舞いが目立ってしまうケースがあり得るわけです。

その一方で根本的な解決にはならないとしたのは、ASDやBPDは難治性であり、医師の診断を受け治療すれば治るというものではないからです。
また医師の診断も、DSM-5のような診断基準はあるものの現実的には診断において曖昧な点や主観的な点が多く残されており、特にボーダーに位置する人は医師によって診断結果が変わることもあるため、自分の振る舞いが果たして精神疾患によるものなのか白黒つけることが難しいです。
したがってASDやBPDについては、診断し治療するという目的ではなく、ASDやBPDがどのような特性を持っていてどのような対処をすれば本人と周囲が楽になるか、という観点で勉強することが役に立つと思います。
一冊を選ぶのであれば、メジャーな精神疾患の全体像を見ることができる『援助者必携 はじめての精神科 第3版』がとても良いです。
これは自分が（通信制大学のカリキュラムの1つである）精神科クリニックでの実習でお世話になった公認心理師の方から勧めてもらった本で、現場をよく知る精神科の先生が非常にやさしい言葉で現場に役立つ実践的な内容を書いてくれています。（本記事では扱っていませんが、うつ病、双極性障害、ADHDは職場において珍しくありませんし、統合失調症も100人に1人程度突然発症したりしますので、より分野を絞った本を読む前に、頻出する精神疾患全般をこの本で学んでおいて損は無いかと思います。）
たとえばASDであれば、対人関係がうまく結べない、こだわりが強い、あいまいな表現が分からない、感覚過敏などの特徴があるのですが、その中のこだわりが強いという特性に注目すると、議論において自分の意見に固執する背景も納得できます。
周囲の人からすると議論において自分の意見に固執するなんてわがまま過ぎると感じるかもしれませんが、自分の意見を捨てて相手に合わせることに対して本人なりに多大な苦痛を感じているのかもしれない、と想像することができるようになります。
そしてASDに対してもBPDに対しても、指導して改善させることは難しいかわりに、解説者として今の状況はこうです、周囲の人はこう考えています、などと「解説するという対策」が有効であることも書かれています。
もちろんこれらは周囲の人の負担を解消するほど強力な解決策にはならないのですが、少なくとも心理的負担は改善するはずであり、これらの精神疾患との関連を考えることは有益なのではないかと思います。

ただし1点注意したいのが、ASDやBPD自体は難治性であるものの、難しい人としての振る舞いの中には自分の意志で大なり小なり改善できるパターンも自分の観測した範囲では多いと思っていて、自分や他者がASDやBPDに該当すると勝手に思い込み改善を放棄してしまうことは非常にもったいないと思います。
そのため本人が（先天的要因で）どうしても改善できないという可能性があることには気をつけつつ、最低一度は（本人にその意志があれば）改善をトライしてみることが重要じゃないかと思います。
これも個人的な感触ですが、たとえばASDでは無いものの内向的であるが故に友人が少なく対人経験が少ない人は、社会人になりたての頃は難しい人としての振る舞いをしていても、周囲からのフィードバックを受けながら改善しやすい傾向にあると思います。

おわりに

本記事では「難しい人」をテーマに自分の経験や周囲の観察に基づく考えを説明しました。
ただ、テーマをキャッチーにするがために「難しい人」というラベリングをしたことには賛否両論あると思います。
実際、社内のエンジニアを眺めてこの人は難しい人、この人は難しくない人、と2値で分類できるようなものではありません。
中間的な人は数多く存在しますし、自分にも難しい人としての振る舞いが現れてしまって改善しなければと思うこともありますし、チームメンバとの相性で難しい人としての振る舞いが現れたり現れなかったりする人もいます。
また、難しい人だけでなく、難しい人への耐性がない人や自分の意見をうまく主張できない人もまた、ソフトスキルが低いと評価される要因となりますし、何もソフトスキルの低下要因は難しい人としての特性に限るわけではありません。
とはいえこのような複雑な状況が逆に「難しい人」についての情報が公開されにくい要因だとも思ったので、今回は思い切って書いてみることにしました。
難しい人への対処に困っている方々、あるいは難しい人としての自覚があって困っている方々に対し、本記事が少しでも役に立ちましたら幸いです。

さらなる追記

先ほどはてなブックマークやTwitterでいろいろなコメントを拝見しました。
思ったよりも反響が大きく、この記事が毒となるか薬になるか分かりませんが、ともかくも考える材料を広く提供できたことを嬉しく思っています。
あくまで私の意見を表明したに過ぎませんので、様々な考え方があって当然だと思いますし、なおかつ私自身、読んでいてとても参考になるコメントが多く、勉強になりました。

そのうえで、いくつか補足しておきたいなと思ったことがありましたので追記したいと思います。

まず、上司が難しい人だというコメントが想像以上に多く寄せられていたことについては自分にとって新しい発見でした。（機会に恵まれたらそのようなエピソードを聞きたいですね。）
なんとなくの推測で上司がそうなりやすい環境が存在するのはいくつか思い浮かびはするのですが、上司についてはいかんせん自分の持っている情報の数が少なく（ありはするのですが特定個人に結びついてしまいそうで……）、あまり憶測であれこれ書くのはやめておこうと思います。
ただ一つ思うのは、会社全体（や部門全体）でコーチングや傾聴といった取り組みを推進していたり、（高いソフトスキルが要求される）アジャイル開発をリードするマネージャーがいたり、マネージャー以外にも細かく権限移譲が進んでいる組織であれば、「難しいと感じる」上司を引く可能性は小さいのかな？とこれまたただの憶測ですが、思ったりはします。

次に、具体例として記載したアンチパターンなのですが、短く表現するがために状況をだいぶカットしています。
気をつけるところはその行動によって周囲の人がどれだけ負担やダメージを受けたのか？になりますので、事前に合意していたり、文化として定着しているのであればアンチパターンから外れます。
なお、難しい人の発している意見が正しいのか正しくないのかは、難しい人の振る舞いとはまた異なる話題ですので、混ぜるのは危険かなと思います。（定義が分かりづらいかもですが、あくまで生産性を下げるような振る舞いやコミュニケーションであって、意見の内容では無いということです。）

・自分の意見が理解されないとき、特定の本やドキュメントを事前に読んでくるように要求し、議論を投げ出す
・関係部署全体で取り決めた方針と自分の考えが食い違った時、チーム内での議論を経ずにいきなり社内チャットで意見をブロードキャストして関係部署に混乱をもたらす

この2つがまさにそうです。

上の項目のポイントは、「この実装や設計の品質を高めるためには事前にこの本を読む必要があると思うのですがいかがですか？」などと周囲の人の合意を得るフェーズが挟まっているか、となります。
議論を投げ出すのは、こういう合意を挟まず自分の意見が正しいから皆はそれに従え、と一方的に要求していることになります。（もっとも、その人がたとえばテックリードで、その人に従うことが事前に合意できている場合は問題ないです。）
提案を挟む進め方であればエンジニア組織では結構あると思いますし、私自身、こういう観点で勉強会を提案したことは何度もあります。（その提案が通るかは、チームで消費されるリソースと天秤にかけ、最終的にはプロダクトオーナーや上長が決定するか、もともと一定時間を勉強時間に費やして良いという合意の範囲内で実施するのがよくある手段かなと思います。）
それでもなお技術的な理解をされず無視されてしまうのであれば、それはもはや本記事のスコープからは外れ、いわゆる説得の技術とか提案力のスコープに入ると考えています。

下の項目は、状況説明が一番曖昧だったかもしれないですね。
意見をブロードキャストされると、誰が拾うんだ？この決定事項はもしかして覆される可能性があるのか？と関係部署の現場は混乱し、チームメンバが事態の収集に慌てて奔走する（＝負担になる）という状況を想定して書きましたが、もちろん組織や文化、状況によっては許容される（奔走せずに済む）ケースもあるはずで、この意味でもアンチパターンをとにかく"額面通りに"ルールとして扱うのは良くないと思っています。

それともう1点、ある組織で難しい人とされていた人が転職した後は活躍するようになった、というコメントは自分も結構想像することができまして、これはより大きな目標というワードで表現したことに繋がるのですが、非常に技術レベルの高い事業や夢の大きな事業に取り組んでいる場合、お互いが難しい人としての振る舞いをしてもそんな細かいことは気にしない、というノリでうまくいくケースは結構あると思ってます。
難しいと見られてしまっている人がそういう職場に転職するのも非常に有効な手段だと思いますし、そういう場がたくさんあって皆が適材適所になれば一番ですよね。（これは理想論になっちゃいますが。）

また、最後に繰り返しにはなりますが、技術力と同様、ソフトスキルについても連続的かつ状況依存なため、難しい人というワードは分断するためのレッテルではなく、是非思考のための概念として使って欲しいなと思います。