作業には、作業指示者と作業者の人間がいますが、どちらにも関係ある話です。
また、色々な所に応用が利きそうな話ですが、一つ例を書いてみます。
例えば、ソースコード内に、空の文字列を代入する処理があった時に、以下の対処をする作業だとします。
あるパターンがあったとして。
パターンA→空文字列をnullに置き換える
パターンB→空文字列を代入しない(何も代入しない)様に置き換える
パターンC→そのまま
を行います。
で、この作業の目的(本質)が、「文字列型の変数の、宣言時の初期化の値を変更する」だとします。
でもここで、作業指示者が作業の目的を伝え「なかった」としたら。
作業者は、パターンAの時にはどうすれば良いのかと思い、
パターンBの時にはどうすれば良いのかと思い、
パターンCの時にはどうすれば良いのかと思うと思います。
だって全部、パターンが「違う」のですから。
「一から十まで言わないと分からないのか」って話があると思うのですが、
残念ながら、目的を伝えなければ同じ状況になるのではないかと思います。
なので、作業指示者は必ず作業の目的を伝え、
作業者は、それをよく理解する様に努める必要があると思います。
作業指示者は作業者に、目的を理解したかどうかをよく聞き、
作業者は作業指示者に、作業の目的は何かをよく聞けば良いのです。
それをしなければ。
上記の様にパターンが少ない場合ならまだしも、
10も20もパターンがあった場合には、コミュニケーションコストが半端ない量になって、
作業ミスを誘発する結果に陥るのではと思います。
逆に、筆者が最近感じている印象では。
目的「だけ」伝えて作業者が目的を理解出来れば、
個別のパターンは、別に伝える必要は無いのではとも思っております。
まあ、目的を理解している作業者が念の為に確認するとかが、絶対ダメだと言うつもりもないですがね。
筆者は、最近口癖でよく「作業の主旨が分かったので大丈夫です」と言うのですが、
この「主旨」というのが本質だと思います。
これが分からないと、質問の嵐になってしまって大変なんですよね。
作業指示者と作業者が、作業の本質を共有出来れば、お互いが楽になると思います。
ということで、ホント頼みます。
まあ、コレ、読まないと思うけど（苦笑）
