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

重箱の隅をつつくようなクレームの対処方法

会議に出る人が全員協力的かといえば、そんなことは全くなくて、出席している人が所属する組織の立場やそれぞれのしがらみで物言いをするので会議、特に、出席者が何かしら会議の決議によってコミットしなければならない場合には抵抗を試みたり、重箱の隅をつつくようなクレームをつけてくるものです。

まあ、様式美といえば、会議であるあるの一つの流派かもしれません。

「実はこんなことを言われまして」

お昼にメンバと食事を摂っているとあるメンバからそんな言い方で話を始めたんですね。まあ、お昼を食べながら担当しているタスクの状況をインプットしようと思ったのでしょう。

「昨日のミーティングでスキームのことについて某氏から、過去の経緯から機能ごとに分離すべきではないか、と突然発言がありまして」
「それで」
「そうなると機能の両方を当社でやるわけにはいかなくなるかもしれないと」
「過去の経緯ってなんだっけ」
「現行でトラブルがあったときに分離して管理した方が良いと方針が出て」

まあ、あるあるだと思うのですが。さらにあるあるはシステムエンジニアの対応ですね。システムエンジニアの性というか、特性というか、ポーリングすると必ずレスポンスするんですよ。何も考えずに。ポーリングするとそれだけに必死になってレスポンスを返す。

それはそれで必要なことなんですが、時と場合によるんです。

ロジックを作る

前出の例で言えば、スキームについてクレームがついているのですが、じゃあ、そのスキームを

組み立てるロジックがあるんだよね

と。それがないと、言われるがままにいちいち言われることに対して応えなければならなくなります。

どういうことかというと、クレームがついたときに、クレームを解決することを優先的に考える思考に陥ってしまう、ということです。

また、そういったクレームは重箱の隅をつつくような物言いですから、それに脊髄反射しているとさらに相手に燃料を供給するような事態になってしまうんです。

だから、そうならないように元々のスキームならスキームを組み立てる際の、

・制約条件
・前提条件
・(例の場合はスキームの)仕組み

 を整理しながら物事を進める必要があるんです。

こうした考え方は、何もクレーム対策のためではありません。システム開発のプロジェクトでも、要件を整理したり、しようを決定する際に使わなければならない手法です。

クレーム対処は基礎スキル

ワタシの考え方では、これは社会人としての基礎スキルに分類する能力です。特に、システムエンジニアは持っていなければならないスキルです。

じゃあ、その基礎スキルを育てる際に参考になることは何かと言えば、交渉力とゲーム理論ですね。

交渉力は意図する方向に結果を持っていかなければ意味がないです。前出の例で、落とし所を考えずに無意識にレスポンスを返してはいけない、ということです。

ゲーム理論は情報の把握と状況設定を理解して意図する方向に持って行くための情報戦を制するために活用します。

 

ハーバード流交渉術 必ず「望む結果」を引き出せる!

ハーバード流交渉術 必ず「望む結果」を引き出せる!

 

 

マンガでやさしくわかるゲーム理論

マンガでやさしくわかるゲーム理論