IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

責任追及が議論に及ぼす悪影響と、対策

参考になる好例が降って湧いたので書いてみます

 

mainichi.jp

  

 

仕様をfixさせるなどの際、IT業界では議論をして複雑なロジックに落とし込まなければならなりません

その時リスクになるのが責任追及です

 

以前KPTについてQiitaに書いたんですが、その際も責任追及の悪影響について触れました

本当はすごいKPTで強いチームを作る for エンジニア - Qiita

 

 今回は貧困JKうららちゃんのケースをみつつ、考えていきます

 

※なお体調がよくないので文章がモニョモニョですw

 

誰が何を気にしているか

全体を俯瞰すると大体こういう構図だと思います

 

f:id:otihateten3510:20160825233150p:plain

赤い線が責任追及です

これは一例ですが、関係者が揉めているシーンではこういう複雑な状況に陥ることが多いです

 

責任追及がこじれる原因、その特徴

カテゴライズがおかしい

例えばメディアがJK叩きを批判する場合は、過激派を上手く対象化する必要がありますが、もっと大きく囲って「インターネット」と言い表してしまいます

これは早まった一般化に近いです
早まった一般化 - Wikipedia

他の例を挙げるとすると、自分の奥さんがムカつくからと「何で女はこうなんだ」みたいな愚痴をこぼす時も同じです
「罪を憎いんで人を憎まず」も同じ意味ですね

 

カテゴライズがおかしいと、関係ない人も混ざっているためもちろん問題を除去できません
問題が除去できないので未来志向の話ができず、有耶無耶になってしまいます(責任追及に終止してしまう)

 

全体が見えていない人が多い

全体の経緯や、誰が何を気にしているかを分析するには情報が必要ですので
そもそもPMなどのように情報を得られる立場にいるか、そういう人にヒアリングしなければなりません
しかし多くの人は目の前にある情報を鵜呑みにして反射的な反応をしてしまいます

上図で最も近視眼的なのは、まとめブログなどの読者と、メディアの視聴者ですが、ほぼ全体がある程度近視眼的になっています

 

全体をみようとしないと、何が問題でゴールがどこなのか容易に見失います
または簡単に間違ったカテゴライズをしてしまうこともあります

 

全体を類推するのが難しい

誰が何についてどういう情報を取得し、どう考えてどういう結論に至ってどこが問題だと思ってどうしたいと思ってるのか

それを類推するのはそこそこ難易度が高いのではないかと思います

(私はとても得意なんですが、自分以外だとディレクターはできてる人が多い印象です。エンジニアは不得意な人が多いですね) 

 

メディアの存在

炎上させることが目的の人が存在すると一気に混乱します
プロジェクトでは余りいないかもしれません

 

原因追求のつもりが気づかない内に責任追及になる

今回で言うと、皆が「NHKが捏造したのかどうか」をテーマにし始めましたが
この時点で実は犯人探しになってしまっています
しかし面白いことに、皆はおそらくそれに気づいていません

 

大事なテーマがどこかへいってしまう

今回のケースで言うと貧困が大事な話であるにもかかわらず

正常な議論構造にならなかったため、簡単にテーマが逸脱しました

 

何も考えていない人の存在

今回で言うと過激派(愉快犯)ですが
そういう人たちがさらに話しをこじれさせます

特に組織間など、大きな枠では皆が混乱するトリガーになります

 

 

問題抽出の失敗

責任追及に至ると今回のようにどこまでも連鎖反応が起こり、問題の抽出が不可能になっていきます

当たり前ですが問題の抽出が上手くいかなかった場合、ほぼ解決の見込みはないです

例外としては誰かが何とかするケースや、誰かに全責任を押し付けてしまうケースですが、インターネットのこういう事象ではほぼ不可能ですね

 

責任追及に発展した、さあどうする

逃げるか立ち向かうかで、普通は逃げるために責任回避の方向に全力を出しますが

一応このブログは「何とかする系エンジニア」なので、なんとかする方に舵を切ってみます

さあどうしましょうか

 

もう一度図を見て欲しいんですが、彼らの中で目標を収束させ、解決に導くために仲間に引き込めそうな人は居るでしょうか

居ませんね!

なのでこいつら全員無視しましょう

 

案1.無理やり責任を被る

一つの案として、被れそうなら責任をもろに被ってしまう手です

もちろんそれで実害が出すぎるとNGですが

 

責任追及をしている人たちは、基本的に悪気があるわけではありません
彼らは彼らなりに解決しようとして失敗しているだけで、善良なバカです

モチベーションとしてはこんな感じでしょう

1.問題がある、何とかしなければならない
2.問題を解決するために、原因を追求する
3.原因を追求した結果、人・組織に行き着いた
4.あいつが悪い

壊れたスピーカーのように「何もかんも政治が悪い」って言ってるような人と同じイメージです

彼らは当初の目的の1.2あたりを忘れてしまっているので、いざ誰かが責任を被り「私が解決します」と言い出すと、我に返ります

我に返った後の行動としては以下の2パターンがありますが

  • いいや、君よりあいつが悪い、あいつがなんとかするべき(責任論)
  • そうかわかった、こうするべきだ。こうしろ(指示厨)

どちらも「はいはい」と受け流していればそのうち飽きると思います

 

皆が飽きたら問題対処の権利を奪えるので、あとはゆっくり考えましょう

その時、一人ひとりは問題意識を持っているのでアイディアをくれると思います

ついでに愚痴も言ってくるでしょうが受け流しましょう

 

案2.こっそり解決する

責任追及議論は、解決すべき問題を放置して永遠に続いてしまいます

その時はこっそり解決してしまう手があります

 

デメリットとしては2つ

  • 彼らをあまり巻き込めない、巻き込むと責任追及議論に冒される
  • 何で勝手にやったんだ、あいつがやるべきだと言われる

どちらもうざいですが、対処方法はあります

 

前者は、個別にアプローチし、全体像は伝えない方法です
あくまで具体的な話のみに終止させれば暴走は抑えられると思います

 

後者は言い訳を作る方法があります
一番やりやすいのが部長や経営陣など上層部を味方につける方法で、「あの人と相談して、指示されてやりました」と言えば一旦収まるでしょう

 

とは言え、長時間こっそりやって、かつ解決しなければならないので相当つらい作業です
精神を病みます(前職でこれありましたが中々地獄でした)

 

でもやっぱり逃げたほうが良い、というか解決できない

解決しなくてもいいなら逃げたり無視するほうが絶対いいです

というか解決できない問題の方が多いと思います

解決できないパターンとしては、

  • 規模が大きすぎる
  • 解決が難しすぎる
  • 責任を被ると実害が出て詰む
  • 目標のコンセンサスが取れない

などがあります

今回のケースもそうですね
国に関わるのは大抵これです

 

パニック映画などで見たことないでしょうか
「そもそもどうしてこんなことに・・・そうだ、あいつのせいだ、あいつが悪いんだ」

 

未然に防ぐためにできること

  • 責任ではなく、アクションの意思決定を議題にする
  • 問題を明確化する
  • 関係者を増やさない
  • 陰謀論をやめる
  • 責任範囲を明確化して、揉めた時に誰が中心となるか決めておく
  • 責任追及を禁止する

 まあ関係者が自分の制御下にないとそもそも暴走してしまうので

大抵の場合どうしようもないんですけどね(´・ω・`)

私なら、ミーティングに出る人が6人を超えたら制御できる自信がないです

そこらへんはPMが本職なので、そういう皆から信頼されてる人に頼るのも手ですね

 

自分が気をつけること

責任追及のトリガーを引かず、話を本筋に戻すためには

わからない・難しいことを受け入れる必要があります

 

わからないこと、難しいことに直面すると「そもそも論」になり、議題を上流に戻したくなります

これは問題解決の方法としては正しい行為ですが、「人」「組織」「常識」というレベルまで行くと一気に難解さが爆発します

「何が正しいか」「彼は正しいか」まで遡っては行ってはいけません

遡って良いのは哲学者だけです

そこまでいくのは全力でぐっと堪える必要があります

 

※エンジニアは感覚的にこのことを理解しているのか、あまり他者批判までいく人がは少ない印象です。解決しないと仕事が終わらない職業ですからね!

 

あとは、他者が行った責任追及に釣られないことが重要です

これも、思わずやりたくなるんですけどね

同調も、反論もNGなので返答に窮しますし

 

問題に対処するとどうなるか

彼らは今度、その対処方法の質にギャーギャー言い始めます

しかし今度はテーマにできるモノがあるので

変な方に議論が行くのは少なくなるでしょう

逆に中心となるモノがないと、途端に責任論をやり始めます

 

アジャイルなどの開発では、とにかく触れるモノを作ってしまうことがよく求められますが
こういう経緯なのだと思っています