オルタナティブ・ブログ > プロジェクトマジック >

あるいはファシリテーションが得意なコンサルタントによるノウハウとか失敗とか教訓とか

ラストパーソンになってもらうこと、あるいは自主性をもたらすもの

»

先日のブログで「PDCAサイクルを回す的なプロジェクト管理を学んでもプロジェクトは成功しないよね」と書いた。一種の極論としてそう思っているのだが、もちろんマネジメント全般には関心があるし、このブログにも結構書いてきた。今日はその一つ、人的リソースマネジメントについて。


今回言いたいことを一言で言えば「部下がラストパーソンになれる様に配慮することは、マネージャーとしてめっちゃ大事ですよ」になる。

ラストパーソンとは「会社を代表して判断し、社外に判断結果を表明できる人」のことである。ある件について権限委譲されている人、と言ってもよい。
逆に「ちょっと私では判断しかねますので、上に相談してから回答させてください」と言う人は、ラストパーソンではない。

ラストパーソンという概念は経営者として大事なマインドだ、という文脈で語られることが多いが、日々の仕事においてはリーダー(プロジェクトリーダーや課長さんくらいの管理職)くらいの階層でも、ラストパーソンとして振る舞えるかどうか、はかなり仕事の質を左右する。


もちろん、「10億円の損失を我が社が被ります」みたいな重大な判断を、課長さんにラストパーソンとして判断を任せるような会社はないだろう。それは極端にしても、「この件であれば自分がラストパーソンになれる」という裁量権は大きい方がいい。
特にプロジェクトみたいに、細かい意思決定事項が山のように発生し、どんどん決めていかないといかないタイプの仕事では。
そしてプロジェクトでは、リーダーの裁量は権限規定として事前に明文化されていない。定常業務であれば「課長の決裁権は◯◯万円まで」みたいにルール化されている会社が多いのに。

だからリーダークラスの人がラストパーソンになれるかは、ケースバイケース、もっと言えばその人の上司の方針次第になる。だからこそ、ラストパーソンになれる幅の広さは、プロジェクトの成否を左右するほど大事だ。


1人のリーダーが社内でラストパーソンとして振る舞えない状況を、もう少し例示してみよう。
例1)経営会議に上申する資料の書きっぷり(表現)にプロジェクトオーナーがダメ出ししまくる
⇒リーダーがOKと言ったらそれでGo、とならない。いつでもひっくり返るリスクがある。だから事前に念入りな確認が必要となる

例2)決定事項がちゃぶ台返しにあう。ベンダーに方針Aでお願いします、と頼んだのに、2ヶ月後にひっくり返り、手戻りが発生する(当然進捗は遅延するし、余計なコストが発生する)

こういうことが発生すると、部下としてはツラい。サラリーマンをやっている人はみんな分かると思うけど、仕事をしていて一番立場がないのは「Aで行きましょう!」と言った後に「上司にダメと言われちゃいまして、やっぱBにさせてください」と言わないといけないことだ。情けないし、カッコ悪いし、先方にも申し訳がない。最悪だ。

最悪の事態を避けるために、こういう事態が少しでも予想できる状況では、思い切った決断ができない。社外ともきちんとした会話ができない。腰が引けた仕事しかできなくなる。


全ての上司は部下だった経験があるだろうから、部下をこういう立場に追い込まないように配慮すべきだ。だが皆さんの身の回りの上司を思い浮かべても、任せてくれる人(上記のようなちゃぶ台返しをほとんどしない人)と、全然ラストパーソンにならせてくれない人の両方が思い浮かびますよね。

なぜ違いが出るのだろうか?(なぜラストパーソンにならせてくれないのだろうか)
それは2つの正義のせめぎ合いが起きるからだ。

正義A)上司が正しいと信じる形で仕事が進むことを担保したい
正義B)部下をラストパーソンにした方が、色々メリットがある

部下に比べて上司の方が経験やスキルが高いだろうから、正義Aはどう考えても重要だ。仕事に真面目に取り組んでいる人であればもちろん、正義Aを重視する。「あるべき仕事」「理想的な進め方」という型や品質基準を持っている。

一方で正義Bにもメリットはある。
まずスピード。持ち帰らなくなるから、ものごとがサクサク進む。
そして主体性とモチベーション。自分が決めなければ、決めていい、自分が会社を代表する、という責任感は「やらされ仕事」とは真逆のマインドだ。もちろん正義Bを重視する上司のもとで仕事した方が成長も速い。
最後に社外からの目。「こいつに言っても、結局部長に話さないと何も決まらんよな」と思われずに済む。ちゃんと交渉相手、相談相手としてリスペクトされるので、事実上能力がアップするのと同じ効果がある。

つまりAもBも両方とも正しい。だから当然、正義Aを重視する人と、正義AよりはBを重視する人がいる。
ところで僕自身は正義Bを重視している。一般的に考えられているよりも、正義Bのメリットはデカいと思うからだ。

なのでしょっちゅう「僕なら○○でやるけど、まあ現場をよく知っているのはあなたなので、任せるよ」とか「○○という考え方さえ外さなければ、後は任せるわ」とか言っている。ひどいときには「興味ないから好きにやれば」とかも言う(文字にするとひどいな)。

もちろん正義Aを大事にしたい気持ちは持っているので、正義Bを優先するのには苦痛を伴う。でも大事なので「俺ならこうはしないけどな・・」と心のなかでつぶやきながら、部下の仕事に文句を言わない選択をする。

特に「もう行われてしまったこと」のちゃぶ台返しは、よっぽどのことがない限りは我慢する。まあまあ疲れますけどね。


ここまで書いた所で、以前全く同じ主張のブログを書いたことを思い出した。

なぜマイクロマネジメントは効果がないだけでなく害なのか?あるいは新米管理者が陥りがちな罠
https://blogs.itmedia.co.jp/magic/2017/05/post_36.html

このブログは「マイクロマネジメントは害が大きいよ」という主張。
今日のブログは「マイクロマネジメントを避け、ラストパーソンになってもらえたらメリットが大きいよ」という主張。同じことの裏と表でしかない。



***********************新刊「プロジェクトを失敗させる55の罠」情報
いよいよ発売日が8/27に決まりましたので、お盆明けからしばらくは、このブログも新刊チラ見せ月間に入ります。
・毎度恒例「はじめに」の公開
・55の罠のうちの1つをまるごと公開
・55の罠のリストを公開

この後は、本に絡めて作った「罠カード」を使ってプロジェクトを具体的に成功させる方法についても書きたい。(何しろ原稿を書き終えてから1年も待ったので、本が出る前に、55の罠を使ってプロジェクトを成功させるチャレンジをやり尽くしているのですよ)

Comment(0)