ただ、このジョブディスクリプションを基準に採用したメンバーであればともかく、そうでないのなら、「この仕事しかやりません」とは本人も言えないし、言われたら言われたでチームとしても困りますよね。
ですから「職務」ではなく「作業」。ゴールからブレイクダウンさせた最小単位の作業（タスク）をジョブと定義したほうがいいと私は考えています。
メンバーも、何をすればよくて、何をしなくていいのかが明確になります。
ジョブが抽象的すぎると、人は自分がすべき仕事に関して勘違いしたり、誤解しやすくなりますしね。
何より、勘違いや誤解は、生産性の「大敵」！ さくさくタスクを処理するために「誤解」は禁物です。勘違いや誤解は、お互いのためになりませんよね。そのためにリーダーであるあなたは、言葉の定義、ルールの定義を明確にし、チームに徹底させます。
リーダーもスッキリすることでしょう。この「ジョブ＝タスク」という発想でマネジメントをすればいいわけですから。メンバーがどんなに遠くに出張していても、在宅勤務をしていても、「あの人は今、何をやっているんだろう？」と考えることはなくなります。つねに持つべき視点が「タスク」中心になるからです。
「人」に意識を向けすぎる弊害
例えば、「顧客ポテンシャル分析」というプロジェクトがあった場合、「営業部長に顧客戦略の確認」というタスクをAさんに、「抽出する顧客条件の策定」というタスクをBさんに、「顧客データベースの整理」というタスクをCさんに依頼し、「顧客ポテンシャルデータの抽出とリスト作成」というタスクをロボットが作業するとします。
この場合、リーダーの役割はとてもシンプルです。なぜなら「進捗管理」が必要ないからです。
え？ と思うかもしれませんが、「それぞれの進捗具合はどうか？」と考えなければならないのは、メンバーに「プロジェクト」を任せたときだけです。サクタスチームでは、プロジェクトを分解した「タスク」をメンバーに渡しているので、「期限どおりに終わったかどうか」をリーダーは考えればいいだけです。だから、気持ちはラクですよね。
メンバーも、具体的に処理すべきタスクがハッキリしているので気分がいいでしょう。あれこれ考える必要がないからです。
リーダーが、AさんやBさん、Cさんというように「人」に意識を向けすぎると、なかなかこうはいかないでしょう。
次ページが続きます：
【「人ありき」の仕事に生まれる不満】
