【補助線】「任せる」と「丸投げ」

◆実行責任と結果責任

「任せる」と「丸投げ」の違いがよく分かっていないマネジャーが少なくないことに愕然とすることがある。両者の違いは、「責任」の負い方にある。

任せるというのは、実行責任（業務プロセスに対する責任）は任された人が負い、結果責任は任せた人が負う。丸投げというのは、任せて結果責任も負わないことをいう。

レスポンシビリティとアカウンタビリティをきちんと分散するのが任せることで、双方を末端に押しつけることが丸投げだと言ってもよい。

◆職務を全うすることによって責任を負うのが「任せる」ということ

結果責任を負わないということができるはずがないと思う人も多いが、実際にはまかり通っている。この議論には責任を負うとはどういうことかがついて回る。

以前の日本的な考え方は、ある立場で何か問題を起こしたら、とりあえず、その立場を退くことによって責任をとっていた。政治でいえば大臣が辞めるというのがそうだし、企業であればトップが辞任する。

しかし、この１０年くらいの風潮をみていると、「職務を全うすることによって責任をとる」という「当たり前の考え方」がかなり広まってきた。要するに責任をとるとは、問題を何とかすることである。

結果責任を負わないというのは、問題を何とかしよう（職務を全うしよう）とせず、「任している」という金科玉条のもとに、見て見ぬふりをする。経営陣に説明をするような場面がくれば、平気でプロジェクトマネジャー一人のせいする。これは丸投げ。

プロジェクトマネジャー育成ブームはこの延長線上にあった。プロジェクトマネジャーの悩みの中に今でも「丸投げ」というキーワードがあるのはある意味で当たり前で、丸投げ保護施策をしていた訳だ（もちろん、それは枝葉末節の話で、育成の意味は十分ある）。

◆プロジェクトでは起こる問題の解をマネジャーはもっていない

この話は、プロジェクトというものに対するとんでもない勘違いに基づくものだ。一昔前の日本型の組織では、このようなやり方を丸投げとは言わなかった。もちろん、本当に丸投げをしていたマネジャーもいたとは思うが、おおむね、育成のために「やらせていた」のだ。かといって、「任せていた」わけではない。あくまでも自分の代わりに「やらせていた」のだ。

なぜ、そのようやり方ができたかというと、マネジャーは経験的に「うまくいく方法」を知っていたのだ。だから、いざとなると自分が介入していけばよかった。

ところが、今はマネジャーもよく分からない。いわゆる「正解のない問題」が増えている。プロジェクトでよく起こる問題をみても、どの業界でも、「正解のない問題」だと思えるものがある。少なくとも、経験で正解を導けそうもない問題がある。

だから、「プロジェクト」として取り組むのだ。にもかかわらず、自分が正解をもっていると考えるのは勘違い以外の何者でもないのだが、勘違いをしているマネジャーは少なくない。

◆部下への対応にも潜む「経験の落とし穴」

もう一つ、経験が問題になっていることがある。部下の育成である。自分は上司に「やってみる」ことで育成された経験を持っているマネジャーが多い。とりあえず、マネジャーになってどうやってよいか分からないときに、この経験に基づいて行動する。

丸投げしようと思っているマネジャーは少ないと思う。「やってみろ」と言ってみたものの、問題が生じたときに「答え」を示せないで、結果として丸投げになってしまったというケースが多いように感じている。

そのようなマネジャーが飛びつくのがコーチングである。ある意味健全で、「自分は答えを出せないので、頑張ってくれ」と考えているわけだ。

◆「正解のない問題」の２つのタイプ

ここで考えるべきことがある。正解がないという状況（問題）には２つの種類がある。「決めなくてはならない」問題と、「決めようのない問題」である。前者の典型的な問題は、ＱＣＤＳのコンフリクトである。仕様がふくらみすぎて、どのように工夫をしても今のスケジュールで十分な品質の商品を開発するのは難しい。これは決めなくてはならない問題である。逆にいえば、決めれば解決する問題である。

これに対して、ある機能がどうしても実現できない。その機能が計画通りに実現できないとこの商品は価値が全くない。代替技術はあるが、機能は低下する。という場合、これは「決めようのない問題」、本当の意味で正解のない問題である。

後者の場合にはコーチングは有効だと思う。しかし、前者の場合には、まったく見当違いで、状況を解決するには自分が決めるしかない。このような状況をコーチングを行い、決めさせようとするのは、丸投げ以外のなにものでもない。この判断は最終成果に対する責任を伴う判断だからだ。

少なくとも、ＱＣＤＳのプライオリティ、あるいはもう少し抽象的なレベルでのプライオリティ（たとえば、まず、十分な品質の成果を達成できるメンバーの心身の健康が優先、次に顧客満足度、最後が収益といったもの）を決めて、その上でプロジェクトマネジャーに具体的な方策を練らせる。その上で、そのプライオリティに基づき問題解決を行った結果についてはすべて責任を負う。これが任せるということだ。

◆プロジェクトマネジャーにとっての「任せる」問題

さて、マネジャーとプロジェクトマネジャーを意識して意見を述べてきたが、当然、プロジェクトマネジャーとメンバーの間にも同じ関係がある。これはプロジェクト制度のよいところで意識していなくても結果的にそうなる。マネジャーの方針を受けて作成したプロジェクトが達成できない場合の「結果責任」はプロジェクトマネジャーにある（上に述べたようにこれはあくまでもプロセスの責任である）。

ただし、そのためにはプロジェクト管理計画を細かく作る必要があるのはいうまでもない。プロジェクト管理計画というのは勘違いしている人もいるが、作業段取りではなく、プロジェクト内のガバナンスを明確にするとことに作成意義がある。

ここをしっかりと認識しておかないと、結局、プロジェクトのスケジュールの遅れや品質の未達成を「メンバーのスキル」というキーワードで逃げてしまうことになりかねない。これはマネジャーに対する責任転嫁に他ならない。

マネジャーとプロジェクトマネジャーで責任の転嫁の泥仕合をしている中で、迷惑するのはメンバーだということを認識しておく必要があろう。