Tbpgr Blog

Organization Development Engineer tbpgr（てぃーびー） のブログ

面接の場で「会社に不満があって辞めるのは他責。なぜ改善しないのか？」といわれる状況が発生する原因を詳細化する

組織 問題解決

たまにツイッターなどで見かける議論として、

「今いる組織に不満があって辞めるやつは他責で改善意識がないやつだ。もっと自責じゃないといかん！」

という意見や

「会社が提案を受け入れないからだ！」

という意見のぶつけ合いを見かけます。
これはこの議論の両極端という気がして、ここにはかなり多くの要素があると考えています。
しかし、実際に面接などにおいてこの両極端のみで語られるケースが発生しているのではないかと思います。

そこで、改善のステップと改善の難易度の2つの視点で詳細化していこうと思います。

改善のステップ

なにか改善提案をするにあたって、問題を見つけてから実際に提案が受理され、改善が実施され、効果が生むまでを並べてみます。
問題の発見部分は省略してます。

  1. 提案をする
  2. 提案が受理される
  3. 提案が実行計画に落とし込まれる
  4. 改善施策を実行する
  5. 改善施策の結果を確認する
  6. 不足があれば、成果を生むまで改善施策を練り直す
  7. 成功するまで 4 - 6 を繰り返す

という形になります。
例えば、改善を成果につなげることができなかった人を他責とするのならば, 4 - 6 の結果、成功まで持ち込めなかった人はすべて他責になります。
それは違う気がします。
また、逆に、提案をすべて受け入れる組織が良い組織かというとそうでもありません。
改善提案は

  • 問題のある現状 - As-Is
  • よりよい理想状態 - To-Be
  • これらのギャップとしての問題 - Problem

があり、これを元に売上・利益など組織に対してプラスの効果を生むことが期待されるものに対して提案されるものです。
ちなみに売上・利益といっていますが、顧客の利益とその利益を生み出す効率、的な話です。
直接的に売上・利益などで表現しにくい要素についても、間接的にはこれらにプラスの効果があるからこそ「改善」であるはずです。
そのため、まずはこの差＝ギャップ＝問題が明確になっているはずです。

その上で、この差を詳細化し、要因を洗い出し、その内容が納得できるものであること。
そして、その上で、その問題の要因を解決するための解決策としての How が提案されているはずです。
図だとこういう構造です。

alt

今やっていること、これからやること、組織・チームの現状も踏まえた上で、この問題を解決することがプラスになる場合に提案が受理されるのが好ましい状態です。
そのため、少なくとも提案者は、提案を受ける相手が判断するための材料として上記のような問題構造と解決策としての提案の合理性を説明する必要があります。
もちろん、細かいメリット・デメリットを判断するまでもなくやったほうがいいこと、というのもあるとは思いますけどね。それはこの記事では別の話にしておいてください。

例えば 「A 社がアウトプットしていた手法がよさそうだからうちもやりたい！」というのは問題ありきではなく、 How ありきになっています。
提案するからには提案者には現状の問題とその解決方法としての提案を体系立てて説明する責務があります。
逆に受け入れる側も頭ごなしに突き返すのではなく、その構造を引き出すような質問をすることで検討するに値する内容なのかを判断し、その判断結果を相手に伝わるように丁寧に説明する必要があるでしょう。

改善の難易度

一口に他者が関係する改善といっても

  1. 上司と部下の範囲のもの
  2. チームに関わるもの
  3. 組織全体に関わるもの
  4. 組織外のステークホルダーも関わるもの

など多様です。規模によってはチームと組織の間に事業部があったりするかもしれませんね。
そして、面接のケースで考えると、その人がチームメンバーなのか、マネージャーなのか、部長なのか、経営者なのかによって解決を求められる範囲は大きくことなるはずです。
例えば、メンバークラスの人が苦しんで転職を決意した要因が組織全体にまつわるものだった場合、ある程度そこに顔を突っ込んで取り組んだとして実際に解決できるケースはまれでしょう。
もし、解決できているならその人はメンバーにとどまっていないでしょうし、やめてもいないでしょう。

というように、取り扱う問題にも難易度があります。

解決策としての構造化面接

仮にこの話が面接の場だとして、一つの解決方法としては上記のような要素があることを踏まえた構造化面接の実施です。
仮に行動面接でやるとします。行動面接・状況面接については

を参照してください。

例えば、メンバークラスに対して質問するなら

「過去、他者を巻き込んで解決が必要な問題があった場合に、あなたがどのように取り組み、解決に導いたかを教えてください」

チームのマネージャークラスに対して質問するなら

「過去、チーム全体に関わる問題があった場合に、あなたがどのように取り組み、解決に導いたかを教えてください」

などのようになるでしょう。

その上で状況・課題・行動・結果を引き出す質問をして掘り下げます。
これは、 STAR 面接という質問技法です。

設問の使い分けで、「改善の難易度」の問題を解決し、掘り下げの質問の「行動」の部分で、「改善のステップ」のどこまで切り込んだ人なのかがわかります。

まとめ

よくある問題として問題の一部だけ語る事によるケースがあるように感じています。
下記の図だったら、その人が想定する「課題1」とそれに対する「解決策」のみを語っているようなケースです。

alt

よくよく確認すると As-Is と To-Be が不明確だったり、 As-Is と To-Be を確認したらそもそも問題は別の話だった、とかいうのは自分の周りでもとても多いように思います。
一度立ち止まって問題構造を整理してみることは大切だな、とよく思います。

関連情報