ジーザス小川です。
今日は、ひさしぶりに、スキルアップの話を。
プログラミングスキルと、手順書作成のスキルには、大きな相関関係がある。
僕は、そう思っています。
プログラミングとは、要するに「パソコン」に渡す手順書。
相手がパソコンか人間かっていうだけで、本質的には、違いはありません。
そんなわけで、実は、僕は、業務手順書作成のコンサルティングも得意としています。
今日は、業務手順書作成のコンサルティングで使っているネタを、ひとつ披露。
手順書を作って、人に渡します。
でも、渡した相手が、そこに書かれているとおりに仕事をしてくれなかった。
さて、そういうとき、どうしましょう？
相手に要求するスキルレベルを上げるというのもそうですが。
手順書を作成する側のスキルアップにも、注目したいです。
というか、業務手順書作成のコンサルティングにあたっては、そっちのほうが、僕が興味を持ち、また、成果を出すべきところです。
つまり、手順書を手なおしするわけなんですが。
その解決策を考えるときには、手順書を渡した相手に、以下の3つの要素にわけてヒアリングをしていくとよいです。
not read : 読まなかったのか
not understand : 読んだけど理解しなかったのか
not act : 読んで理解したけど行動しなかったのか
「not read」だったら、「読んでもらう工夫」をします。
「not understand」だったら、「理解出来るような工夫」をします。
「not act」だったら、「実行できるような工夫」をします。
では、それぞれの場合、どういう具体的な解決策を実施するのかということについては、また今度☆
