問題解決の方法を100パターン作っておかないと動けない人材

今、組織が欲しい人材は、目的を示すことで自分の持ち駒（経験）を組み合わせて実現する方法を見つけ出すことができる人だ。

その対極に具体的な手順を示さないと動けない人がいる。例えば、目的はひとつ、工程が2つあって、それぞれの工程内での活動の選選択肢が10パターンずつあったら、サンプルのパターンを一つか二つ例示するのではだめで、今自分が置かれている立場にぴったり合う10×10=100のパターンの中から最も近い一つを示せと言われてしまうケースだ。

その程度はまちまちで、いくつかのケーススタディをするだけで済む場合もあれば、手取り足取り手順を示さないと動けない場合もある。

問題解決能力が高い人は、経験値が低くても工程を何回か繰り返すうちに具体的な手順から抽象度の高い解決方法を体系化することができる。

だから、組織は問題解決能力の高い人材が欲しい。

【1. 問題解決能力を身に付ける方法】

1. 達成すべき目的や要求を伝え「なぜ」も含めて合意する
2. 集中できる環境だけ用意して解決方法は示さない
3. 定期的に進捗を報告させてアドバイスを与える
4. 成果を当事者以外（一番いいのは要求を出した人）に評価してもらう
5. 2～4を何周か繰り返す

※たぶん、これがよく言う PBL(Project Based Learning/Problem Based Learning）なのだろう。

【2. 問題解決能力の低い人の学習環境（予想）】

1. 問題が指定される
2. 解決するために必要とされる一般的な知識を教わる
3. 試しに一つの解決方法を教わる
4. 複数の問題を解かせる
5. 採点して落第だった場合は補習をする

※この学習方法で訓練されると、そのパターンで解けない問題がくると最初から解けないと「問題」と「ソリューション」は一対一だと決めつけられてしまい、ぴったりくる解決方法が記憶の引き出しにないとさじを投げられてしまう。

問題解決能力があるかないかを判断するには、答えのない問題を実際に解決してみてもらえばすぐに分かる。

2の学習方法しかやってこなかった人は比較的早くあきらめて、解決方法を教えてもらえるまで指示を待つ。1の訓練を受けている人は、少なくとも解決方法の提案をレビューしてくれといってくる。自信があるものは問題解決に着手する。

Process （工程）を Activity （活動）や Task（仕事）に分解して Procedure（手順）に落とし込むというアプローチは問題解決能力が低い人にも成果を期待できる反面、不測の事態への対応が十分にできない。手順になれてしまうと、手順から逸脱する行為は悪と見なされる。

同じ品質のものを効率的に生産しなければいけない工場の生産ラインはこの方法でよい。製品ごとに手順は変わるので、工場の中でも手順を作る側の人は問題解決能力が高くないといけない。

商品を作る側の技術者は、新しいものを創造するのだから、不測の事態への対応能力は高くないとまずい。ただ、もしかすると要求仕様が固まった後のコーディングだけを行うプログラマの場合は、手順通りに手を動かしていればいいのかもしれないが、一生その仕事ではたまらないだろう。

技術者はProcess （工程）を、分解された Activity （活動）や Task（仕事）を Procedure（手順）に従って開発を進めることが求められる一方で、不測の事態、変化しなければいけない状況下では、Process や Activity, Task を柔軟に変更できる能力も求められている。

P.S.

日本の組織では「強くお願い」と「強制」の垣根がないと思うことがしばしばある。「強制」とはそれに従わなければクビということだが、日本の組織ではそれはないし、「ヤレ」と言われてやらないで、何もとがめられないこともある。それが「あたたかい人間関係の中のやさしい一員」という特性だ。

そういう環境下では「強くお願い」と「強制」の垣根がないので、権限がなくても「強くお願い」すれば、それを義務ととらえる者が多い。「何の権限があってそんなことを要求するのか」なんてことを言う人を見たことがない。

たぶん、普段から自分の責務もあいまいしているから、それを言ってしまうと自分に返ってきてしまうからだろう。

責任と権限が曖昧な日本の組織では頭ごなしに「強制」するのではなく、徹底的に「強くお願い」するのが効果的だと感じる。どっちもやることは同じなんだけどね。

ようするに誰かに言われて動いたという形になっていた方が安心して行動できるということ。（それって責任回避の心理？）