後輩職員への指示や相談事において、なんだか話が通じていない感が否めないことは多々あります。 その感覚をどう説明したらいいのか、うまい説明方法が見つかりません。

多分それは、野球のピッチャーが「肩に違和感を覚えた」というのと似ているかもしれません。 痛いというわけでもなく、動かせないというわけでもなく、でもなんだかいつもと違うという感覚が違和感というものでしょう。

後輩職員と話をしているときの、なんとなく感じる違和感の原因は一体なにものなのか。 こちらの説明がヘタなのか。

しかし丁寧に説明をすればするほど、ますます違和感が強くなって話をしているこちらの頭がヘンテコリンになってしまいそうなケースもあります。

まだ試行段階ですが、最近試しにやっていることをまとめてみようと思います。

後輩とのやりとりで、どうも噛み合わないなっていうときはままあって、”ボク：タスク”、”相手：タスクの内容不明”、っていうケースが多いことに気がついた。で、最近自分のノートで1タスクを分解して相手に合わせて理解度チェックポイントを作ったら、これもうプロジェクトだった。 #WRM感想

— takaki kobayashi (@takaki_co8ya4) 2014, 11月 10

タスクで指示をしていたけれど…

例えば融資の案件を進めるとなると稟議書を作成しなくてはいけません。 そのためにはお客さんから聞き取ること（定性情報）、決算書や試算表、資金繰り表といった定数情報を手に入れる必要があります。 定数情報はルーティンで概ね手に入りますので、案件を進める上で新たに必要な情報は定性情報になります。 つまり数字に表れていない情報、もしくはこの数字になった理由の情報という、言葉で手に入れる情報です。

定数情報をもとに、お客さんから話を聞いてきてほしいことを指示します。 世の中全てが一問一答で片付けられるほど単純な仕組みで動いてはいません。 当然、お客さんからの回答によってはさらに聞きたいことが増えることもありますし、角度を変えて聞きなおしてみることが必要なケースがあります。 ボクが指示したことは⚪︎⚪︎を聞いてきて、というように1つのタスクとして認識していました。

それは決して1タスク1質問というわけではありません。

ここでボクのいうタスクは、疑問点を解決するということであり、その方法として⚪︎⚪︎を聞いてきてほしいということになります。 問題を解決することがこのタスクのゴールですので、お客さんから返ってきた回答でまだ不足があればさらに質問を重ねて情報を集めるものだという前提条件がこの指示の中には入っています。

しかし帰ってきた後輩職員から投げかけられた言葉は問題解決には程遠く、もう1回聞いてきてとなるケースがほとんどです。 もう1回話を聞きに行かせたはいいものの、お客さんからすればまた同じようなことを聞いてきたと思われてしまうことがありますので、できれば1回の質問で問題解決してきてほしいというのがこちら側の本音でもあります。

タスクじゃなくて、プロジェクトだった

さて、ここでどうしてこのような行き違いが発生してしまったのかを考えてみました。 いつもであれば、どうしてそういう回答だったらさらに突っ込んで聞いてこないんだ、と指導という名の叱咤が入るわけですが、どうもそういう問題ではなさそうです。

ボクが認識しているタスクは、わからないことについて問題解決をするためにお客さんから話を聞くというタスクでした。 しかしこのタスク、ゴールに行き着くまでにはお客さんと相当な会話のやりとりが必要であるわけです。

Aを聞いて答えがBであったらCを聞く、答えがDであったらEを聞く、それを繰り返してゴールに行き着いたところで1タスク完了です。 しかしこれ、指示をされた側にとってはその指示内容によって何を解決してこればいいのかわかっていないことが相当あることにまず気がつきました。

1タスクの中でゴールに行き着くまでに複数のやりとりをする場合、それをタスクではなくてプロジェクトとして考えてみることにしたのです。 そこで、Aを聞いて答えがBであったらCを聞く、答えがDであったらEを聞く、を1タスクとして考えるのではなく複数に分けて、つまり1タスクをプロジェクト扱いにしてタスクを細かくしてみました。

プロジェクトにした方がゴールが見つけやすい

あくまでボクの捉え方の問題ではあるのですが、タスク＝処理完了（問題解決）と考えています。 ボクが自分で行動するのであればタスクの処理方法をわかっていますのでそれで問題ありません。 ところがそのタスクの処理方法がわからない人の場合、⚪︎⚪︎を聞くという行動をする＝タスク処理であって、それがタスク完了まで届いていないことがあるような気がします。

そこで、指示すること自体はボクのタスクですが、指示された側はプロジェクトを指示されたというふうに捉えられるようにしました。プロジェクトを完了するためのタスク処理という考え方であったのですが、人によってタスクには得手不得手がありますしそれによって時間がかかることもあります。

そこでプロジェクトとタスクの間に、というよりもタスクの上に小さいプロジェクトがあるという考え方を持つことにしました。 この小プロジェクトこそ後輩指導にほかならないので、こちらも指示＝タスクではなくて指導＝プロジェクトとして捉えるいい反作用がもたらされます。 こういう観点でしばらくの間仕事をこなしていこうと試行錯誤中の今日です。