ハイブリッド人生心理学読者広場

□ 「意図的に非協力的な同僚」への対処と原理原則行動^^ / しまの

引用

No.1043 2015/04/05(Sun) 17:02:50

これは２つのポイントもしくはテーマになりますね。
　1.「意図的に非協力的な同僚」への対処
　2.それ以前の仕事の基本姿勢と行動法

1.「意図的に非協力的な同僚」への対処
まずはご相談の直接的内容。何らかの原因があって、どうも自分に意図的に非協力的になっている同僚にどう対処するのが良いか。

これについて僕が理想に感じる解決法を言うと、
相手に何か問題があるらしいことを一切取り上げることなく、相手をことさら意識してもいない風を装い、多少の問題も可能な範囲で甘く大目に受け流した上で、自分にとっても相手にとっても利益が最大になる結果を生み出し、その上でしばらく様子をみる。
といったものです。
それができればまず言って、相手の行動はこっちに同調してくるというものとしてです。

その対照として、望ましくないと思われる対処法の典型パターンは、「真意を問い話し合う」といったものです。
これをすると、わだかまりとトゲトゲしい感情さらに敵対感に火をくべる可能性がある。もちろん話し合うことが解決につながるケースもあるでしょうが、これは原因がかなり特定的な誤解などによる場合です。
書いて頂いた文脈で「真意を問い話し合う」というのをすると、まず前者になるだろうと直感^^;
その相手は、何らかの原因で、 にーなさんに漠然とした反感を感じているという状況が考えられるからです。特定の誤解というより。
その場合、それを話し合うなんてよりも、上述の「大目に受け流し互いの利益が最大になる結果を生み出し続ける」という対処法の方が、断然解決になります。これはもう経験則から言えることです。

その線で考えるに、まずその相手の非協力がどんな支障なのかを、具体的に考える必要があります。
僕の経験から感じたことを言えば、回りの非協力が仕事の失敗に直結するというのは、あまりないです。あるのは、仕事の顧客相手の責任者や直接担当者が非協力的である場合です。この場合はもうかなり成功が望めなくなる。
こっち側の周りが非協力的で仕事が失敗というのは･･さてどんなものかと。

2.仕事の基本姿勢と行動法

でそれをちょっと具体的に見て進ぜようかと文面を見るに、この一文が気になるわけですね。

>私は、仕事に関係ないことも仕事も協力してやっていきたいと思いますし

仕事の内容と状況の具体的内容は書かれておられないため、とにかく僕の考えからの答えを言いますと、
仕事は「協力し合う」ことで行うものではない、ということです。
仕事は、「明確な役割分担」で行います。

組織の役割分担に明示されていないような「協力」は、むしろすべきではない、とさえ言えると思います。なぜならそれは組織のミッションそのものがしっかり体系化されていないということだからです。まずそれを改善する必要があります。個人の努力としてではなく、組織としてです。
積極的な協力し合いに頼ると、どこかで足元をすくわれる事態が訪れます。そうでなくとも、非効率です。下手な「協力」は時間を無駄にしたり、さらには足手まといになったりすることさえあります。･･とそんな経験沢山あって出てきてしまう言葉^^;
まず個人がしっかりと役割を果たせるということ。そして組織がしっかりと役割の体系化をしていること。これが重要です。

結論

ということで、ちょっと期待外れというか不本意なアドバイスかもしれませんが、まず取り組むといいのは、仕事の進め方、そこでの人の行動のあり方についての基本的な考え方の見直し再構築といったことになるんですねー。
「協力し合い」ではなく「明確な役割分担」という基本理念の選択検討の上でです。

あくまで正確な話はもっと具体的な内容いかんですが、文面から僕が察するに、良かれと考えながらハイブリッド心理学非推奨形にまっしぐら、というような･･^^;　論理的、原理原則的ではなく気持ち的、道徳的というもの。
その人の様子の原因としても、まず考えられるのは、過度に巻き込まれる、自分の時間を奪われることへの抵抗を感じているといったものになります。

>自分が相手よりも知っているものについては出し惜しみせず協力しているつもりなので、

これもちょっと危険な雰囲気を漂わせている言葉^^; さらに不本意な指摘かもですが、押しつけがましくなったり先輩ズラされたという不快感を相手に与える可能性がゼロではありません。
これも僕の経験から言いますと、僕自身が「自分の方が知っている」という意識で相手に接した時、相手との関係は「アウト」になってたと思い返されます。相手も相手なりに工夫するのをまず尊重する、そして相手から聞いてきたり頼んできたりしたら惜しみなくというのが良い姿勢になると思います。

そうした基本的な理念や対処姿勢を見直した上で、具体的行動法を再検討する。
たとえばミーティングの召集の仕方。過剰に人を呼ばない。本当に必要であれば、どんな役割において参加してもらうのかを、組織全体に明示するような形で召集するのが良い行動法になると思います。

そうして、まずは相手に「過度に巻き込まれる」という反発を感じさせないような仕事の進め方ができれば、意図的に非協力的になった相手に対して、上述の「大目に見て様子を見る」という対処法もスムーズにできると思います。
検討してみて頂ければ^^。

参考：
ちょっと古い原稿ですが以下など一読されておくと良いかと。
旧掲示板2006.02
ハイブリッド推奨　人生勝利の原理原則10則-2　　No.894 2006/02/03

□ Re: 職場における同僚との問題 / にーな

引用

No.1046 2015/04/15(Wed) 16:33:32

島野さん

早々に回答いただきありがとうございます。

島野さんへ質問をする時の自分は余裕が無いというか、心理的に追い詰められた状態なので、かなり感情的に流されていることが多いなと思いました。ご指摘いただいた文面もそういった整理できていない気持ちがほとばしったところかも、です。

1について

まずは「大目に受け流し互いの利益が最大になる結果を生み出し続ける」という姿勢で対処しようと思います。相手の非協力による支障として一つの例を挙げさせていただきます。
私の役割はIT部門でのプロジェクト管理、彼女の役割は基幹システムの管理とユーザサポートです。ここに新機能のインストールという業務が発生したとして、私は業務のスケジュール・プラン->人の配置->ミーティングの開催等を行います。私の役割はプロジェクトの管理なので、人の割り当てなどはもっと上位レベルで決まっており、実際私が行うのはメンバーとコミュニケーションを取って、プロジェクトを進め完了するということです。例えば、開発が終わり、テストの段階になったとします。彼女はミーティングもすっぽかすし、テストも誰か他の人にやってもらってくれと言います。仕方なく別の人を代理に立てます。その代理者がテストを行った結果、OKと出たので次の段階へ進みます。そして業務が完了します。そしてその後に、ユーザからの報告でバグが出た場合、突然「どことどこを変えたんだ！」と怒りをあらわにされるといった具合です。私は、変更されたプログラムのリストはすでに彼女にも送られていることを伝えながら、再度自分のメールから探して転送するというアクションを取ります。そして、懸念があれば貴方がシステムをチェックする時間を設けるのだから、ミーティングに出てほしいし、今後は事前に言って貰いたい旨を伝えます。その時には、彼女はもう私の話なんて聞いていません。リストを見ながら、システムのチェックに意識が向いているかんじです。私が何を言っても適当に「わかった」と半分無視の状態で答えられるだけです。前回、島野さんから指摘されたように、自分自身のコミュニケーションの未熟さもあると思います。彼女は私より年齢的にも社歴もかなり上の方で、システムも私より熟知しているので、私なんかの指示は受けたくないし、何も教えたくも無いが、何か不具合があるとこちらに怒りの矛先を向けてくる感じです。

２について

>まず個人がしっかりと役割を果たせるということ。そして組織がしっかりと役割の体系化をしていること

私の働く会社は外資系企業なのですが、上記に問題があると感じています。以下、主観も入りますが、日ごろ感じていることです。

-組織図と役割の構成図はかなりしっかりとあるものの、効率的に機能していない、または海外事務所の末端で働く人まで浸透していない。
-役割の定義があいまいなために(実際やっていることと役割の定義にズレがあり、上の人たちはそれについては放置)グレイゾーンに落ちる問題が多い。
-一度、関連グループのコンセンサスと上司の承認を取ってスタートした課題でも、途中誰かの横槍が入ると、決定が180度翻ることが頻繁に起こる。それについては上司が判断を下さないので、しかたなく放置状態が続き、思い出した頃に「あれ、どうなった？」とまるでボールがこちらにあるような態度を取られる。

社風を理解していただくために参考までに書きました。ちなみに、コミュニケーションの相手は全て海外にいる外国人です。問題の同僚は同じオフィス内ですが、やはり外国人です。役割分担がはっきりしないことへの不安定感が、「協力し合う」という間違った態度へ自分を駆り立てるのかもしれません。
こういった状況について問題提起をして解決を試みるというのは、問題が大きすぎて、島野さんのおっしゃる「真意を問い話し合う」と同じアプローチである気がして、ドツボにハマる危険性があります。一生懸命やろうとすればするほどジレンマに陥るので、適当に流そうとすると不意打ちを食らう、不意打ちを食らった部分に関しては向こうが正論だったりするので反論を言えない。でも、不意打ちを食らわせる人間が原理原則に基づいてしっかりと仕事をしているかというとそうでもない時もある、でもこちら側はそれに対していちいち指摘しない。感覚的なものでもありますが、ざっとそんなかんじです。

組織がしっかりと役割を体系化していないところで、自己主張の強い人間がコントロールをしようとする、こういった中での自衛と建設を教えていただけると助かります。

□ 「プロジェクト」における役割定義と仕事の段取り^^ / しまの

引用

No.1047 2015/04/17(Fri) 11:30:00

僕の経験も踏まえ、ちょっと詳しく「プロジェクト管理ノウハウ」関連の話など。

>私の役割はプロジェクトの管理なので、

ならずばり、また別のノウハウのポイントが出てきます^^。

3.「プロジェクト」における役割定義と仕事の段取り

というものとして。
つまり上記の2.仕事の基本姿勢と行動法において、
まず個人がしっかりと役割を果たせるということ。そして組織がしっかりと役割の体系化をしていること。
というのは、まさに「プロジェクト」ではない一般的職場業務の話です。銀行の支店業務なり役所の窓口業務なりモノ作りの現場業務なり、一つの組織体が永続的な一つの業務を果たすという一般形態における話。
一方「プロジェクト」の場合は、まず期間限定であり、かつしばしば組織横断的になってきますね。

ですので、「プロジェクト」の遂行ノウハウは、かなり特別なスキル領域になってきます。それなりの習得習熟が求められる。
ところが昨今は、プロジェクト遂行ノウハウを教えられないまま、比較的若手段階からプロジェクトを任されて、プロジェクト遂行に合った行動がうまく取れずに板ばさみの中で苦労するケースが増えているかも知れません。

ま話が膨らみますが、社会がそれだけ成熟し、大組織による巨大戦艦軍隊方式のプロジェクトというのから、ゲリラ戦方式の小プロジェクトが五月雨式に（？）という変化があるかも知れません。僕がＩＴの仕事をし始めた時は、銀行の「３次（第３世代）オンラインシステム」など1000人規模のプロジェクトを束ねるためのプロジェクト管理ノウハウなんてものが追求され、「プロジェクト管理者」という役割が極めて重視されましたが、そうしたものがなくなってきた昨今、プロジェクト管理ノウハウという話がないままプロジェクトが行われ、結果苦労する若手が多いという状況がままあるように推測。

いずれにせよとにかくプロジェクト管理というのは通常の組織業務とはまた違う特別なスキルになるという心得をまず心に入れて頂き、今回の話に関連して、僕の経験を踏まえ具体的なポイントとしては、次の３つになるかと。

1)プロジェクトにおける役割定義とその徹底はプロジェクト管理者の業務になる。
一般業務での「組織がしっかりと役割の体系化をする」とは少し異なってきて、多少の役割割り当ては組織がやっていたとしても、プロジェクトにおける役割定義は、そのプロジェクトの管理者が最終的に厳密に定義する必要があります。
組織が行うのは、人の割り当てだけというケースもあります。そして往々にして、組織が個々のプロジェクトの都合よりも大きな損得勘定から人の割り当てを突然変えてしまうことさえあるでしょう。
まさに、

>一度、関連グループのコンセンサスと上司の承認を取ってスタートした課題でも、途中誰かの横槍が入ると、決定が180度翻ることが頻繁に起こる。それについては上司が判断を下さないので、しかたなく放置状態が続き、思い出した頃に「あれ、どうなった？」とまるでボールがこちらにあるような態度を取られる。

というように。実際そこでは、ボールが実に勝手にプロジェクト管理者のところにころがってきているわけですね^^;　それをうまく拾えるかどうかに、プロジェクト管理者の手腕というものが出てきます。
でどうするかが以下。

2)プロジェクトにおける役割分担は「指示」ではなく「合意」で進める。
プロジェクトはしばしば、通常の上司－部下という指揮命令系統を横断的に人集めされて進められますので、プロジェクトの中ではそうした指揮命令系統が使えないケースが出てきます。特に参加者がプロジェクト掛け持ちになるようなケース。
プロジェクト責任者は、「責任者」となったからといって、組織の責任者のようにはメンバーに「指示命令」はできない場合が往々にしてある。
ですので、プロジェクトにおける役割分担は「指示」ではなく「合意」で進めるという基本理念、基本姿勢が大切です。
具体的にどうするかがさらに以下。

3)役割の事前合意確認を３回は行う
具体的には、プロジェクト管理者は参加者に対し、「私としてはプロジェクトをこのように進めたいと思う。そこでのあなたの役割はこれこれでありこうした作業をして頂きたいと思う。よろしいですね？」という事前合意確認を、まずは３回行います。

１回目の事前合意確認は、プロジェクト発足時です。これは「プロジェクト計画書」というドキュメントを作って、関係者を招集し、合意を取りつけるものとして行います。
この「プロジェクト計画書」というのが極めて重要です。精通した人間からは、「プロジェクト計画書」の出来具合で、そのプロジェクトの成否を９割がた予測できます。内容は、実現しようとうする機能内容、プロジェクトの体制、スケジューリングなど。詳しくはここではよろしいかと^^。
でまず参加者には、この「プロジェクト計画書」を渡して、そこで自分の役割と実際の作業内容が分かるレベルで、合意を取る。

２回目の事前合意確認は、フェージングの節目に行います。システム導入であれば、要件定義フェーズ、開発フェーズ、テストフェーズなどのフェーズ移行の節目にと、まず考えるので良いでしょう。
つまりそこで、そこまでのフォーズの状況と、それを踏まえた次のフェーズの確認周知を、メンバーに対して行います。当然そこに、次のフェーズで役割を持つメンバーに、プロジェクト管理者が期待するものをやってもらえるかの合意確認が含まれてくることになります。

そして３回目の事前合意確認は、実際の作業に入る直前の定例ミーティングなどにおいてです。まあ実際の作業の１週間前以内ということになってくるでしょう。

そうしてまず３回は、参加者の役割分担と果たしてもらう内容について、それぞれ本人に合意してもらう。本人の「了解しました」という言葉なり、文書への確認サインなり、はっきりとした言質を取ることが重要になります。
フェージングがあまりない場合は、上記２回目というのは省略し、つごう２回は必ず事前合理確認ということになりますね。
また場合によっては「根回し」というのも、うまくできるかどうかが天下の分かれ目（^^;）になることもあります。

ともかくこんな感じでやれば、実際の作業段階になってすっぽかしなどの問題が起きることは、まずないと思うのですが･･。

一方、上記のような事前合意確認をしっかりできていないプロジェクトというのは、得てして、「各自の裁量で各自なりに役割を果たす」というものになる可能性がありますね。時にこれは「船頭多くして舟進まず」というパターンへ。
上で書いて頂いたその人の様子も、実はこの「各自の裁量で各自なりに役割を果たしている」という結果に見える節もあるのですが、いかがかと。

まずはこんなものを基準に、ご自身の考え方進め方など確認して頂くと良いかと思います^^。
万一、かなりこの通りやってるのも関わらず、書いて頂いたような問題が起きているという場合は、再度状況確認させて頂ければと^^。

□ Re: 職場における同僚との問題 / にーな

引用

No.1048 2015/04/17(Fri) 17:38:53

> プロジェクトにおける役割分担は「指示」ではなく「合意」で進める

これは、なるほどと思いました。反発に会わないための方法だなと思いました。

>まず個人がしっかりと役割を果たせるということ。そして組織がしっかりと役割の体系化をしていること。
というのは、まさに「プロジェクト」ではない一般的職場業務の話です。

言葉で伝えるのは本当に難しいと思いました。
問題がある」と箇条書きで書いた部分(-で始まる３項目）は、プロジェクトではなく、一般的職場業務の話として書きました。プロジェクトはもちろん、プロジェクト管理者がそういったことをクリアにしていかなければならないと感じています。

詳しくは説明できませんが、ちょっと変わった組織構造をしています。組織の構図と役割の定義はあっても、その中で個人がしっかりと役割を果たすことができないと感じます。全員が感じているかどうかはわかりませんが、少なくとも私はそう感じます。私のような末端の人間が、そういった問題提起をして取り上げられるとは思えません。みんながその中で、半分目をつぶりながら、自分が機能していける形を模索しながら働いていると思います。
「まず個人がしっかりと役割を果たせるということ。そして組織がしっかりと役割の体系化をしていること」が無い会社は辞めたほうが良いのでしょうか？
正直、ストレスは感じるものの、良いところもあり辞めるほどではないと感じます。

基本は、「原理原則、建設的」になるかと思いますが、このような環境での個人の働き方はどのようなものでしょうか、島野さんのアドバイスをいただけたらと思います。