仕事の最小単位--アクティビティの構造を学ぶ
仕事の最小単位--アクティビティの構造を学ぶ (2010/01/16)
「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。単に作業とか行為と呼ばれる。
あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。でも、何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。はっきりした依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。
「はっきりした依頼」とは何だろう? まずは、具体的な作業の内容である。なにかをとってもらうという行為は、大げさに言えば輸送の作業である。輸送であるからには、対象物(荷物)、現所在地、そして送り先が必要になる。“そこ”にある“塩”を“(自分の手元に)”とって、という事項を最低限伝えなければ、相手は動きようがない。
それが何かを作る作業だったら? たとえば玉子を焼いて欲しいとき、具体的に言うべきことはなんだろうか。まず、欲しいアウトプットを正確に伝えなければならない。目玉焼きなのか、厚焼きなのか、錦糸玉子なのか。卵1個分か2個分か、はたまた100個分なのか。味付けは濃いめか薄めか。つまり、アウトプットすべきマテリアルの種類・数量・品質属性を指定するわけである。
ついで指示すべきは、いつまでに欲しいのかである。今すぐなのか、夕食の時でいいのか、あるいは3日後のパーティの時の話をしているのか。つまり納期を指定するわけだ。
さらに、インプットを指定してやる必要があるだろう。材料である。相手が母親ならば、どこに何があるか全て承知している。しかし、アパートを訪ねてきた友人に依頼するときは、「卵は冷蔵庫にあるし、油と調味料は食器棚の横に」と教えてやらなければなるまい。自分で支給できないときは「来るときコンビニで買ってきて」と、相手による調達を頼ることになる。
アウトプットと、納期と、インプット。これだけでいいだろうか? 大事なものが、まだある。『リソース』である。リソースというのは、作業を完遂するために必要な道具や場所や用役のことを指す。フライパンはどこ? あ、それは流しの下だ。ガスレンジは? えーと、電磁調理台しか無くてね・・
インプットとリソースの違いは、インプットが作業に使われて無くなる(アウトプットに転換する)のに対し、リソースは作業が終わったら解放されて元に戻ることだ。フライパンもガスレンジも、消えて無くなりはしない。ただし多少減耗する。そしてリソースは、作業中には占有される。つまり、いってみればリソースというのは化学反応における触媒のようなものなのである。
(念のため、注。ここでいうリソースとは、あくまで生産管理やプロジェクト・マネジメントでいう用語であり、「生産資源」などと訳されることもある。資源工学の世界で言う、海の底に眠っているかもしれない利用可能な物質やエネルギー類とは異なる)
リソースの中で、最も重要な種類のリソースは「人」である。作業に必要で、作業中は占有され、作業が終わったら解放される。これを英語で、Human
resourceという。直訳すると人的資源だが、リクルートの場面では人材とか人財とか訳され、本社上層の会議室の中では要員・労働力などと呼ばれたりする。作業を終えて解放したときは多少減耗しているので、再生するためには、休ませたり眠らせたり食事をとらせたりお酒を飲ませておだてたりしなければならず、けっこう手間暇のかかるリソースである。
それでもまあ、ある局面では稀少な価値ももたらすことがあるので、大事にしなければならない。君でなきゃダメなんだ、君の作ったのを食べたいんだ・・・。「君の作る味噌汁を毎朝飲みたい。」--などという陳腐な文句が、いまどき意図した通り機能するかどうかは知らないが、リソースの指定はたいていの場合、重要である。
アウトプットと、インプットと、リソース。そして納期(これはもう少し一般化して、「完了条件」と言ってもいい)。これで完璧だろうか? じつは、マネジメント上、とても大事なことが抜けている。それは情報である。「指示情報」と「報告情報」のやりとりが必要だ。
指示情報とは、これまで列挙してきたアウトプット・インプット・リソース・完了条件などの伝達である。さらに、必要に応じてはレシピ(つまり設計情報ないし作業手順情報)も渡してやらなければならないかもしれない。もっとも、家族や、同一組織内では、お互いに了解している事項が多いので(これを「コンテキスト・レベルが高い」と形容する)、アウトプットと完了条件だけ指定すれば、あとはくだくだ言わなくても通用するはずである。
報告情報とは、完了時、ならびに(必要に応じ)途中途中で、作業がどういう状態であるか、アウトプットはどうなっているかを、指示した人=マネジメント主体に対して伝達するための情報である。誰かに働いてもらっているとき、終わったのか終わっていないのかも分からず、どういう状態にあるのかもさっぱり把握できていないのでは、「マネジメントしている」とは到底言えない。「お塩とって」のように、目の前で一瞬にて終わる作業ならば別だが、海を離れたところにいる誰かに2ヶ月かかる仕事をしてもらう際は、報告情報をもらわなければ困ってしまうだろう。
なお、ここまではインプットもアウトプットも物(マテリアル)である場合を記したが、作業の種類によっては、統計分析や企画書作成のように、インプットもアウトプットも情報やデータとなる場合もある。この場合、作業インプットとしての情報・データと、指示情報とは区別して理解すべきである。
ところで、指示/報告情報に関連して一点注意したいことがある。マネジメントにおいて、上記のアウトプット・インプット・リソース・完了条件を指定して依頼した場合は、原則として、依頼を受けた側がどのような手順で進めるか(すなわち相手の業務の「内部プロセス」)については、途中でいちいち口をはさまない。小姑のように、箸の上げ下ろしまでいちいち指示をしてはいけない。マネジメントというのは、際限のない命令-服従関係とは異なる。ある仕事のまとまりを、他者に指示したら、その内部には立ち入らず、相手の権限範囲とする。相手が自発的に改善できる領域を与える。これがマネジメントにおける「仕事の最小単位」の意味である。
プロジェクト・マネジメント理論において、この仕事の最小単位を『アクティビティ』と呼ぶ(「タスク」と呼ぶこともある)。WBSを作っていくとは、プロジェクト全体を、このようなアクティビティに階層的に分解していく過程を指している。アクティビティはいくらでも下位のサブ・アクティビティに際限なく分解可能だが、適切なレベルでとどめておく(最下位レベルのアクティビティを「ワーク・パッケージ」とも呼ぶ)。
このような形でアクティビティを定義しないまま、共通経験の乏しい(コンテキスト・レベルの低い)海外子会社や外注先に仕事を依頼したって、うまく仕事がマネジメントできるわけがない。オフショア開発を上手に進めたかったら、自社の求めるアクティビティをきちんと規定するところから、まず始めるべきなのである。