マネージャというポジションは複数の人を動かして成果を上げるのが基本的な役割と思っています。そのため、やはり人の感情とか心的な問題を無視しては厳しいです。これは相手に迎合するのとは少し違うと思っています。そのような問題をある程度考慮した上であえて無視するという事もやってましたので。
ところが、根がヒッキー(某ラノベの主人公ではないですよ)な私にはこれが難しい課題でした。が、最終的には失格の烙印を押されたとはいえ、数年間ごまかす事に成功しました。
これは何故かと言うと自分では2つあると思っています。
1 20代に無線工事系の現場で下働きした経験がある
2 これも20代に交流分析をある程度興味を持って調べていた
1は工事現場での仕事の回し方という事で、気が向いたら今後書くかもしれません。
今日は2の方で。以下の解釈は我流ですので注意。
概要はペディアの記事(これ)に書いてあります。また、交流分析の要素で比較的広まっているものとしてエゴグラムというものがあります。これはよく性格診断と誤解されているようですが、少し違います。固定されたものではなく、現時点での傾向を示したもので、変えることが可能とされています。
交流分析が面白いというか、プログラマ上がりのPMに向いていると思うのは、人の交流がある程度論理化され、目視可能な状態で表現されている事だと思います。可視化された例がここにあります。
リンク先にもありますが、相補交流なのか交差交流になっているかを把握することで双方の状況をある程度客観視できます。また、エゴグラムはどの立場から発信しやすいかという目安になります。例えばCPが異常に高い人同士は基本交差交流になってしまうので、揉め事が増えそうだとか。俗な例えですが右な言論人と左な言論人でしばしば論争起きますが、お互いに P->C という典型的な交差交流による揉め事になってるなーとなります。
ここで注意して欲しいのですが
「あー P->C 同士になっている」というように見ることが出来ると、ある程度揉め事が客観視できている状態になっている事です。
これがPMやる上で結構重要。
上記の交流は言論人だけでなく、プロジェクトでも結構起きています。この場合、PMの観点では、A -> A の形に持っていくのが基本的な対応と私は思っています。例えば不具合対応に関して、変更範囲を狭くやるか、あるいは構造をあるべき姿に直すかで派手な論争してるとします。一見、 A -> A の論争に見えるかと思いますが、多くはお互い P -> C になってたりします。
この場合の教科書的には A に訴えかけるように進めると良いという事になります。だとすると、本来は範囲狭め派の人には設計上の不具合によるリスクについての見解を、構造改革派の人には工期との兼ね合いについての見解が欲しいところです。ただ難しいのはどっちを先に口に出すかで、片方に味方していると取られます。そうなるとA -> A で出しても P -> A or C で返されてしまう可能性が高いです。そのため、話題を変えるか、一度時間をとって個別に話すかとかになります。
後者が私は望ましいと思っています。もし後者が選択できれば、まずは主張する事を再度聞き出し、言葉を少し変えて「つまり××ってこと?」と確認します。ただし言葉を置き換えはしますが、相手の主張(もちろん推察)はそのまま返すのです。で、相手の意図と違っていた場合は謝りましょう。
これは傾聴という方法です。本来の傾聴の目的だと、オウム返しという手もあるのですが、相手の主張を確実に理解するためと、適当に返しているだけという批判を防ぐため、言葉は変えます。ここまでやると多くの場合 A -> A を出すと、 A -> A で戻る率が上がります。そうなると、相手の主張との差分分析の話がしやすくなります。この時も「相手の主張にもメリットがあるから」と切り出すと、P -> A を出していると誤解されるため、「相手はなぜああいう事を言ったんだろうね」として、差分を認識させる方が良いと私は思います。ここで「バカだから」とか「ものが分かってないから」と返って来た場合は、以下のどっちかである事が多いです。
・まだ P->A の構えでいる。
・本当に相手が技術的に間違っている。
ここらの目利きが実は重要なのがPMの辛いとこです。前者だと思って後者だった場合、特にエンジニア出のPMだと信頼の失い方が半端ないので、注意が必要です。それぞれの対応とか、会議内である程度解決しないといけない場合については、すみません省略させて下さい。
対顧客に関しても基本は同じでまずは傾聴(メールで傾聴って結構難しいですけどね)して、A -> A が効く状況にして、対応を行うように心がけてました。あとは、顧客が出している要求が本当に顧客が望む事なのかについて、特にトラブっている時は注意が必要です。
状況などにもよりますが、例えば品証データを要求してきてるけど、実はトラブルが解決することを望んでいて、症状再現が難しいので、代替で要望しているに過ぎない場合とかです。これは交流分析的な置き換えという要素を相手組織自体がやっていて、担当者がそれを執行しているケースも多いですけど(むこうも実績として出さないといけないですから)
これは議論があるかとは思いますが、この場合データ作成に全力を捧げるかどうかは判断になります。例えばデータ作成が遅れたり、多少完成度が下がっても、問題解決に優先度を割り振るかどうかです。私は問題の難易度にもよりますが、データ作成は比較的軽視するダメなPMでした(苦笑)。だって、相手が品証データ出しても「やっぱりダメだ」となるケースが多かったんだもん。というかそれが裏の目的みたいな(おお交流分析的かなこれ)
やや脱線しましたが、交流分析がシステム開発である程度有用と思うのは、エンジニアリングが背景にあるというのもあってか、A -> A に持っていくことが通常の生活や他の業務と比較すると、やりやすいと感じているからです。また、状況の客観視・可視化もある程度できます。
なので、人間関係でお悩みの方はちょっとかじってみても良いかもしれません。
ちょっと古いのですが、私のおすすめはこれです。諸々のバランスが取れています。