2.処理型と解決型

「処理型」は一見頭脳明晰、人間コンピューターのごとく鮮やかに、問題を解決しているように見えるヒト達です。これまで言及してきたように、課題の議論が少なかったり議論を行わずに、解決者の過去の経験や自己の認識を優先した判断をし因果関係を共有する対応をします。これはこう、あれはこう、それはそうして…とその対応は端から見ても、一見鮮やかに見て取れます。がしかし、鮮やかである反面、問題における課題形成が不十分であるため、二次的三次的に新たな問題が発生してきます。
一方「解決型」は、市場や顧客が変わろうとも、組織自体が変わろうとも必要とされる個人そして組織に求められる力です。この解決型人材は、常に過去の成功体験をゼロベースで見直し、現時点での課題から問題形成(本質を多様な視点から探る)を行い、解決された状態を明確にイメージすると共に、プロセスを共有する普遍的な思考&行動プロセスを有するヒト達です。

 

解決型の特徴

この解決型は、過去の成功や失敗の経験を認識しますが、常にゼロベースで今の問題に対峙し、問題の全体像を把握することに努めます。つまり「森を見て木を診る」或いは「着眼大局着手小局」的な、問題そのものに対する視点移動が可能で、問題をシステミックに(全体感をもって)捉えることができるのです。問題の置かれた状況、問題の関係者・ステークホルダーの関係、そして対応策における制約事項やリスクに対し、予めどの様な対応策があるかを検討し、メンバーと共有し更に補完ができます。
つまり、問題は見る人や立場によって捉え方が違うことを前提に、自己の思考特性や癖(思考リスク)を踏まえ、問題を問題として捉えています。単眼的に物事を見て判断するのではなく、複眼的に物事を捉え、一人で考えるだけではなく他人の見方をも取り入れた上で、問題を正しく形成することができるスキルと言えます。
解決型のチームでは問題事象に対してその本質を十分に理解した上で解決策を検討するため、解決の方針に対するメンバー間のズレは少なく、スムースに解決方針の合意に至ることができます。
一方、処理型チームの場合は、問題は1つでも解決者の数だけ(視点の数だけ)解決策が発生します。何故なら個々人の問題に対する捉え方が異なり、個々人の問題のまま解決策が議論されるため、解決策は個々人バラバラのままで合意形成には至らないのです。ここではバラバラな状態から唯一声の大きなヒトや上司の一言で選択された決定方針に移されるが、その結果が良いも悪いもまさしく運次第なのです。

処理型に発生するリスクと解決型のリスク

「処理型」の対応は、問題を正しく認識できなかったりその場の処理で終わらせてしまうため、問題の本質は「先送り」されることになります。その結果、後々問題が肥大化して漸く気づくことになり、その時点で発生した「問題処理」は行えても本質的な問題解決に至りません。このため、得るべき利益が得られなかったり、顧客を失うなど損害を拡大させていくことになります。
また、思い込みや決めつけによる自分の考え方から抜け出せないまま、良い悪い等の自己基準で取捨選択して意思決定を行います。さらに物事の関係を考えるのではなく、思いつきによる当て込みが多いため、手戻りや、やり直しが多数発生します。

では「解決型」にはリスクはないのでしょうか?
問題の全体を捉えようとしても、その全容把握は中々できるものではありません。したがって「リスク-X」というリスクの存在はどの様な場合でも必ず存在します。ただそのリスクの存在を認められるかが問題です。また、解決型は様々に思考を巡らし、関係者と議論したりするため、処理型に比べ判断に時間を要することは避けられません。でも考えてみてください。新たな問題を引き起こす処理型に比べれば検討要素に漏れが少ない分、手戻りも発生するリスクも少なくなるのです。時は金なり!利益を先送りする組織に先はありません。
システム開発のプロジェクトで考えてみよう。システム開発時の各開発段階での差は歴然で、解決型ではそれぞれのフェーズで100%に近いアウロプットを提供できます。しかし処理型ではそれぞれのフェーズの完成度はことの外低くなります。このため納期が近づくと徹夜をして作業にあたるものの、検討段階での完成度が低いため、仕様項目の漏れや項目内の完成度が低く完成に至らないばかりか、各フェーズのアウトプットもままならない状況が殆どです。


このコンテンツは会員限定のコンテンツです。
会員登録または、ログインしてください。

あわせて読みたい