仕組み化と経験学習モデル

「仕組み」仕事術を読む。レベルが低くてちょっとがっかり。

最少の時間と労力で最大の成果を出す 「仕組み」仕事術

最少の時間と労力で最大の成果を出す 「仕組み」仕事術


仕組みとは、成功体験やルーチンワークを「誰が、いつ、何度やっても、同じ成果が出せるシステム」に落とし込んだもの。
仕組みを造ることで、作業系(ルーチンワーク)時間を削減し、考える系(思考・判断・コミュニケーション)時間を増やす。


考え方はBPRと同じ。ただし本書では実現方法の落としどころはチェックリストというツールに限定。
チェックリストは、作業ステップと内容を詳細に記述し、判断基準を定量的に明示することがポイント。
使う人の才能、意志、記憶に頼らないものにすべし。トヨタのヨコテン。


仕組み化を検討する際にはソリューションのイメージがないとなかなか難しい。
ソリューションはチェックリストだけではないはず。
自分の周りにも意外と普段気づかないで自然と使っている仕組みがごろごろとあるはず。


たとえば一部の社員の間で出まわっている経費精算の入力補助ツール(Excelのマクロ)なんかもそうだ。
これは新人が自発的に作成したツールだというが、経費入力作業が簡易になり、非常に役に立った。
これはマクロでどういうことが実現可能か知っていないとできない。
この補助ツールだとマクロがExcelの表に入力した内容を経費精算システムに自動転記してくれる。


米国・ケースウエスタンリザーブ大学の組織行動学者、デービッド・コルブは、経験学習モデルとして「実践のステージ」「経験のステージ」「省察のステージ」「概念化のステージ」を定義している。
(まるでPDCAサイクルのようだ。)

仕組み化は、ここでいう「省察のステージ」、「概念化のステージ」で検討・実装していくことになるだろう。


ちなみに省察と概念化を意識的にアウトプットするように仕事をするだけで仕事の質がまるで変わってくるというのがjmorの実感。
インフォメーション⇒インテリジェンス。

概念化では、具体的行動レベルにまで落とすことで実践・経験・省察を真に活かしたと言える。
たとえばプロノバの岡島氏が、「吉野家ではお茶のおかわりのタイミングとして、『お客が湯呑みを45度以上傾けたらお茶をついでください』という指示を出した」という話を出していたが、ここまで落とし込むかどうかがやりきる人とやりきれない人との分かれ目。
イメージの具体化・詳細化ができているかどうかは書いてみると一目瞭然。


一方で実践⇒経験⇒省察⇒概念化と経験学習を直線的に進めるだけでは底の浅い学習になってしまう。
というのも「修正のヒューリスティクス」にはまる懼れがあるから。

たとえば省察のステージで振り返りをし、何らかの結論を導き出したとする。
しかしそれはあくまである状況下での実践や経験にもとづく結論であり、適用範囲は限られているかもしれない。
またそもそもその結論は実践や経験とすら論理的に結びつかないかもしれない。

けれども政策研究大学院の北岡氏によると人間はとりあえずの結論を修正するのが下手だという。

わずかの肯定的なインフォメーションによる「とりあえずの結論」は、同じ量の否定的なインフォメーションが出てきても崩れない。
その何倍も突きつけられないと、崩れなくなってしまうという。
これは自分においてもずばりあてはまる。自分の出した仮説に自家撞着してしまいがちなのだ。


これを避けるには、もっと面白いものを造るという意識をもち続けること。
できたものを組み替える作業自体を楽しむこと。
そして仮説と検証の反復横跳びのスピードを速めること。