見出し画像

仕事をしない上司

今となっては上司を持たない身ですが、それでもビジネスに携わっている関係上、「上司」「部下」と呼ばれる人たちと密接に関係することはあります。そんな時に、ついついため息をつきたくなることというのはやはりあります。

上司に限らず「承認」権限を持つ人…すなわちそれなりの権力を持つ人がボトルネックになることって、けっこう多いですよね。

  • さっさと決断すればいいのに、なかなか遅い人

  • 決断するのはいいけど、その根拠や基準に不安がある人

こういう人の下にいる部下はたいていの場合、不幸です。

ここでは頻繁に「上司」という言葉を使っていますが、上司に限らずリーダー、マネージャーあるいはクライアントの担当者、責任者など、多くの決裁権/決定権を持つ人を思い描いてください。

あらかじめ断っておくと、私は「上司が直接プロジェクトマネジメントしてくれたこと」というのは20代中頃の時のたった1プロジェクトしかありません。

とはいえ、新人の時から終電まで働くようなケースや幾度となく倒れるようなケースはありましたが、当時の時代背景もありましたし、むしろ「新人でロクに成果も出せなかった私をよく最後まであきらめず使ってくれたな…」と感謝することの方が大きいかも知れません。

それよりは、取引先の責任者の方によく煽りを食らった経験があります。

私はこれまで大小数多くのプロジェクトに何らかの形で参加させてもらってきた中で
延べで言うとおそらくは3000人以上の関係者とプロジェクトという形でつながりをもってきましたので、確率論的にどうしても似たような問題に対処せざるを得なかったというのが実際のところです。

大きなプロジェクトで関連企業の担当者の上司がそういった自ら動こうとしない(動くだけの実力がない)タイプだったり…ということもありましたし、ちゃんとした取引相手を選ばないと大変なことになる可能性もあるのだということを身をもって知っています。

一口に「仕事をしない」とか「仕事ができない」とか言っても、様々なパターンがありますよね。

そのタイプのごとに「対応法」「攻略法」は違うのですが、それらを説明する前に権限が十分でない時にプロジェクトをリードする際の基本的な考え方を説明しておきます(ちなみに、現実的にはプロジェクトをリードする際に必要十分な権限が与えられているケースのほうが少ないと思います)。

ずっと同じ企業、ずっと同じ部署、ずっと同じ顧客でずっと似たような仕事しているとどうしても視野や考え方が狭くなりがちですが、下記のような考え方を持っていると「上司が仕事しない/できない」時に無理をしすぎたり、悩みすぎて精神を病んだりすることを回避することができます。

1. 世界の広さを知っておく

基本的にはこれに尽きると思います。

私は一般的に言うところの"転職組"ですし、その転職もちょっとしたルールを作って行ってきましたので、否応なく世界、世間の広さをそれなりに知っています(1社目は大企業、2社目は100人前後の中小企業、3社目は10人未満のベンチャー企業、…2社目からは目的を持って選んできました)。

プロジェクトをリードできる人は比較的「責任感」の強い人が多いと思いますが、ポイントとしてあまり自分のうちに抱え込みすぎないことが大事です。

莫大な予算や人が動いているプロジェクトでは「失敗したらどうしよう…」と夜も寝られなかったり、なかには上手く行かない時に心が折れて会社に来なくなる人などがいますが、私などは失敗プロジェクトにばかり参加させられてきたせいか、そもそも 失敗するプロジェクトというのは 83.6% と多いことを知っています。

しかしITで失敗しても、医療などと違ってミスで直接人が死ぬことはありません。

だから「失敗していい」ということではなく、

 「新しい物事に取り組んで成功させるのはそれほど難しいことなのだ」

と考えて、積み上げ式で前向きに取り組むのが正しい姿勢です。失敗させないよう、慎重に検討し、行動するのは当然の責務ですが、過剰に悲観的になりすぎてストレスを抱えてパフォーマンスを落としてしまう方が現実の問題としてプロジェクトに影響を与えます。

不確実性に対して取り組むべき姿勢が整ってさえいれば不確実性そのものを極小にし、確実性を高めるのはそれほど難しいことではありません。難しくするのは、それを阻害する「人」が紛れ込んでいる場合だけです。

また、プロジェクトの規模や成功率がさほど高くなかった時期から、それをリードする中で得られる経験や知見というのは自分の中で確実に積み上がるもので、プロジェクトが終わった後にも役立ちます。

名前も知らないスタートアップ企業があっという間に成長して上場したり、東芝やシャープのような老舗の大企業が報道されているような状況になってしまう昨今、一つの企業で「勤め上げる」ことは極めて難しい時代ですが、転職や独立した時に頼りになるもの…つまり価値ある自信の源は

 前職の名刺や肩書きではなく
 「実際に自分で何をやってきたか」

です。

逆に言えば、自分の手で経験してこずに、早々に誰かにやらせているだけの人は転職や独立できる可能性はほぼ皆無です。どんな企業でも新しい収益を求めるために新しいプロジェクトや新規事業をやっており、それを担える人材は極めて不足しています。

ちなみに2014年のIT人材白書によると、実に 96% もの企業が

 「新しい事業やサービスを創出できる人材を確保できていない」

と回答しています。つまり、実際にプロジェクトをリードして得られる経験や知見はとても高く評価され、上司や周囲に頼ってプロジェクトを成功させるよりも自分自身にとって役に立つのです。

「大事なプロジェクトがあるのに決定権を持つ者が仕事しない、できない」

という状況はその場だけで見ると悲劇ですが、後々評価される実績につながると思って試行錯誤してみることはキャリアパス上のチャンスでもあるといえるでしょう。


2. ロジックとアウトプットをベースに仕事をする

相手がどんなタイプかでプロジェクトをリードする方法は変わりますが、基本となる方針は

 「ロジック(論理性)とエビデンス(論拠となる事実)、
  アウトプット(資料)をベースに仕事をする」

ことです。

仕事の経験が浅いうちに上司やクライアントが仕事しなかったりあるいはできない場合に、周囲や上司のさらに上司に文句や不満を言ってどうにかしようとするケースがありますが、これはまず上手く行きません。

なぜなら、企業の上層部は社歴が長かったり肩書きが重い人のほうを重視するものですし、実績もないのにただ批判を口にする部下は「めんどくさい奴」だと認識するからです。

仮に言い分が正しかったとしても、マネージャーの言動をただしたり異動させたりするよりは社員クラスを動かすほうが楽なので、どうしても軽視される傾向にあります。

特に「事なかれ主義」のマネージャーが多い日本企業ではそうなりやすいでしょう(まぁ、だから優秀な人材がどんどん離職していき、前述のIT白書のような事態に陥っているのでしょうが…)。

また、仮に経営層や上層部に問題意識がうまく伝わったとしても、「じゃあお前の言い分を立証するものを用意しろ」となるはずです。

何の根拠もなく、自分の意見の正当性を貫こうとしてもそれは無理です。大事なプロジェクトをアサインしたマネージャーが仕事できなかったり、あるいは仕事していないというのは企業の経営にとって大きな問題ですので、証拠無しに物事を動かすのは極めて難しいことです。

「仕事ができていないのではないか」と疑われる上司もきっと抵抗するでしょう。

それは経営陣や上層部にとって「面倒なこと」です。物事を動かす際に自分の手を離れて人々を動かすのは感情的な物言いや個人的な主張ではなく「論理性やそれを支える事実、それらが記された資料」なので、これを常に意識して作成する必要があります。

たとえば私は、ソフトウェア開発プロジェクトにおける品質保証…QA活動を行うにあたって明確なルールを設けています。

suda流QA禁則事項

もちろん成果物の評価をするうえでもしっかりとルールを設けていますし、手順化しています。基準だって作りますし、そうして定めた内容に準拠します。準拠できないような根拠が明確になればルールや基準を見直します。

たとえば設計工程の成果物を確認するのであれば、決して「人の記憶や認識」には頼りません。頼った時点で品質保証は失敗です。

事実情報を「正」とする以上、上位文書との整合性こそが絶対的な評価基準でなければなりませんし、そうして確認するうえで不整合が生じた場合は上位文書側に不手際があるものだと判断する…とあらかじめ決めています。

そうした明確な根拠に基づくプロセスがあって初めて、

 「どうやらこいつが言っていることは本当らしい。
  あのプロジェクトには〇億円の投資が懸かっているので動かさないとまずい」

という話になるのです。

こうした考え方ができない上司は、よほど個人スキルが高い場合でもない限り、何一つ信用できず、何一つ頼れる要素がない…ということにもなりかねません。その人の中で明確な根拠がなければ「都度言ってることが違う」という問題を引き起こす可能性が出てきますし、仮に明確な根拠があっても「誰も理解できない」ものであればやはり誰もついていこうとは思わないでしょう。

これは外部企業の担当者やその上層部を動かす際も同じです。


3. 社内政治にとらわれない

上司⇔部下の関係のことを考えたときに、今でもやはり多くの企業で「派閥」のような社内政治は避けられません。

金融機関のように出身大学で「学閥」が形成されているようなところはもう少ないでしょうが、営業畑か技術畑か人事畑か…みたいな話は今でも一般的に語られます。

社内政治は特に人が多い企業ではキャリアコースを非公式に形成するものとして、人事面では人材登用の意思決定をシンプルにしたり、社員の視点では特定の上司に取り立ててもらって効率的に出世できる…という効果がありますが、

 「会社の全体最適」
 「プロジェクトの成功」

という観点で見るとデメリットが大きく出ます。そもそもそのような派閥、学閥を含む村社会を形成したところで、そのグループの中に必要とされる才能や実力などを持ち合わせている人材がいなければ、結局失敗を誘発してしまうだけということもありえます。

特に能力が無いまま出世すると、その下の組織メンバー全体に負担がかかります。無能な上司、仕事をしない上司が多くの有能な人材を流出させてしまう可能性もありますので、村社会の形成は使い方によっては倒産の危機にもつながりかねません。

また、あるマネージャーがプロジェクトを自分の「手柄」にしようとすると、敵対するマネージャーやその部下は積極的に協力しようとはしないことも出てきます。むしろ"妨害行為"を仕掛けてくる可能性もあるでしょう。国会等を見てもわかる通りです。

乱闘
野次

やってることは子供以下ですよね。
こういうことをした時点で早々に辞任してほしいところです。

切磋琢磨する分にはいいのですが、成功を阻害するだけの邪魔になる人が出てくるとそれはもう何にも勝るデメリットとなります。時間と金の無駄です。

しかし、派閥等はそんな人すらも守ろうとしてしまうのでなおさら改善しにくく、一度そうした人が出てきてしまうとそのままそう言う風土が醸成されていくことになります。

多くの組織では、誰かを見る際に「どこそこ部署の人」とか「誰それの部下」という見方をすることが一般的で、そうした肩書に縛られて

 上司に取り入ったりしていることが客観的にも明らかになると、
 それだけでプロジェクトの成功率は大幅に下がる

ことにもなりかねません。組織で仕事をする以上はどこかの部署に所属することは避けられませんが、特定の上司に取り入るこことができてもプロジェクトが失敗して上司ごと飛ばされたりすることになれば本末転倒です。

プロジェクト的に仕事をして自分のキャリアを作っていくのであれば、上司にゴマをするためだけの飲み会に付き合うより客観的に物事を判断できる資料作りなどに時間を割きましょう。


いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。