KNOWLEDGE - COLUMN ナレッジ - コラム

プロジェクトリーダーが壊れるとき―その背景と対策

ITインフラ事業本部 ITS第3部
テクニカルスペシャリスト 秦 拓郎
顔写真

はじめに

こんにちは、テクニカルスペシャリストの秦です。

先日感染症で体調を崩してしまい、私がプロジェクトリーダーを務めるプロジェクトに2週間ほど参加できませんでした。その間、私に代わり、チームのメンバーがプロジェクトを推進してくれて本当に助かりました。

私が不在でも仕事が進むのはありがたいことです。一方で、私がいなければ進まない仕事ばかりだったら、どうなっていただろうとも思いました。

今回、現場から少し離れたことが、過去に関わった社内外のプロジェクトを振り返り、プロジェクトリーダーという役割について改めて考える機会になりました。

この記事で扱う言葉の意味

「プロジェクトリーダー」とは

今回のコラムでは、プロジェクトにおける、ある担当範囲のリーダーのことをプロジェクトリーダー(以下、PL)と呼びます。機能ごと、あるいはアプリケーションやインフラといった領域ごとに置かれるリーダーをイメージしてもらえればよいかと思います。

担当範囲の進捗や品質を管理し、メンバーに仕事を割り振り、技術的な判断をし、関係者と調整する。さらに自分自身も設計書を書いたり、アプリケーションやサーバーを構築したりします。

管理だけでも実作業だけでもないところが、この役割の難しさです。

「壊れる」とは

タイトルでは少し強い表現を使いましたが、ここでいう「壊れる」とは、負荷が積み重なり、PLがそれまで担っていた判断・調整・実作業を持続的に行えなくなることを指します。

具体的には、担当範囲の進捗が滞ったり、判断や調整に手がまわらなくなったり、仕事への意欲が尽きたり、心身の不調によって仕事を続けられなくなったりすることです。

仕事は続けていても、必要最低限のこと以外には関わらなくなる、いわゆる「静かな退職」も、ここで踏まえておきたい問題の一つです。

ただし、仕事の担当範囲を適切に線引きすることまで問題にしたいわけではありません。ここで目を向けたいのは、改善への働きかけまで控えるようになってしまう状況です。

こうした状況を、本人の力量や責任感だけで説明するのは難しいと思います。まずは、PLが置かれている環境から考えてみます。

プロジェクトや組織の問題

プロジェクトと会社の板ばさみ

我々SIerは、大規模なプロジェクトに協力会社として参画することがあります。その場合、プロジェクトマネージャー(以下、PM)とPLが別会社に所属する体制もあります。

PMからは、一般的にプロジェクトの品質・コスト・納期を守ることが求められます。一方、自社の上司からは「残業を減らしてほしい」「メンバーを別のプロジェクトへ異動させたい」といった話が来ることがあります。

どちらにも事情はあります。残業の削減も、会社全体での要員配置も必要でしょう。ただ、人や時間を減らしても、プロジェクトで求められる仕事が減るわけではありません。

PLは間に入って調整しますが、調整だけでは埋まらない差もあります。そこで「ここは自分がやるしかない」と引き受ければ、その場はなんとか収まります。

厄介なのは、それで収まってしまうことです。

本当は条件を見直す必要があっても、予定どおり進んでいれば、その必要性は周囲には伝わりません。次も同じ条件で進められると思われてしまいます。

PLのがんばりによって見直すべき問題が見えなくなっていないかは、PMや上司も、PL自身も気にしておく必要があります。

プレイングマネージャーへの上乗せ

PLが会社組織上のリーダー(上司)を兼任している場合は、契約関連の処理、部下の勤怠管理、人事評価なども担当します。

どれも必要な仕事ですが、その分だけプロジェクトの作業が減るというわけではありません。

日中は会議や調整に追われ、自分の設計やレビューに取りかかれるのは夕方から。そこへ契約処理や評価の締め切りが重なる。こうなると、本人の時間管理だけで解決するのは難しいでしょう。

そもそも、一人分の実作業を割り当てたうえで、管理や組織の仕事を上乗せしていないでしょうか。

PLに何を担当してもらうのかを決めるなら、そのために何を担当から外すのかも、あわせて考える必要があります。

責任と権限のずれ

PLには担当範囲を完遂する責任があっても、自由に要員を増やしたり、予算を使ったり、納期を変更したりできるとは限りません。

もちろん、すべての権限をPLに集めればよいわけでもありません。重要なのは、PLの権限では解決できない問題を誰が引き取るのかです。

誰かに相談しても「そこをなんとかするのがリーダーでしょう」と返ってくるなら、相談先があるようで実際にはないのです。

こうしたやりとりが続くと、PLは問題を上げること自体をやめ、改善には関わらず自分の担当範囲だけを守るようになるかもしれません。先に触れた「静かな退職」は、意欲が足りないからというより、声を上げても変わらなかった経験が積み重なった結果として起こることもあると思います。

責任を持って対応することと、一人で引き受けることは分けて考えるべきでしょう。

チームの問題

「自分でやったほうが早い」の、その先

チームの経験やスキルと、求められる仕事の難しさが合っていない場合もあります。かといって、必要な人材をすぐに追加できるわけではなく、今いるメンバーで進めなければならないこともあります。

仕事を任せるには、背景や目的を説明し、途中で相談に乗り、成果物を確認する時間が必要です。期限が迫っていれば「説明して直すぐらいなら、自分でやったほうが早い」と考えたくなります。

実際、その一件だけなら早いかもしれません。

ただ、それを繰り返すと、メンバーが経験を積む機会は減り、PLにしかできない仕事が残ります。忙しいから任せられず、任せられないからさらに忙しくなるわけです。

教育は、余裕ができたら行うものではなく、仕事を分担できるようにするために必要な作業です。説明やレビューにかかる時間も、最初から計画に入れておく必要があると思います。

甘えられるリーダーと頼られるリーダー

PLとメンバーの関わり方についても考えてみたいと思います。

「何も言わなくてもPLがなんとかしてくれるだろう」と思われ、問題が共有されないPLを、ここでは「甘えられるリーダー」と呼んでみます。

PLが気づいたときには期限が迫り、そこから引き取って対応する。これが続くと、問題を早めに共有する必要性も伝わりにくくなります。

では、報告や相談が集まる「頼られるリーダー」ならよいのでしょうか。

こちらも程度によります。細かな確認までPLに集中すれば、そのたびにPL自身の仕事が止まります。「気軽に聞いてください」と伝えたものの、自分の作業が進まない、ということもあるでしょう。

相談しやすいことと、すべてをPLに確認することは別です。

期限や品質に影響する問題は早めに共有する。一方、繰り返し出る質問については、手順や判断の理由を残し、次はそれを使って進められるようにする。また、PL以外にも相談できる相手をつくる。

相談に答えて終わりではなく、その後のチームに何を残すかまで考えたいところです。

PLのがんばりを前提にしない体制づくり

ここまでの問題は、別々に起こるとは限りません。

例えば、要員が減り、組織の仕事が重なり、教育する時間がなくなる。問題の共有は遅れ、確認もPLに集まる。そうしてPLが実作業を引き取るうちに、PLだけが事情を知っている仕事が増えていく。

その先にあるのは、PLが体調を崩して倒れることだけではありません。先に触れたように、改善への働きかけを控えるようになることもあります。どちらも、外からはある日突然そうなったかのように見えるかもしれませんが、見えないところで少しずつ進行しているのだと思います。

この状況を変えるには、まずPLの上司が、プロジェクト内の作業だけでは見えない組織の仕事も含めて負荷の全体像を把握し、PMと調整する必要があります。進捗だけでなく、その進捗を保つために、誰がどんな対応をしているのかまで見てほしいと思います。

そのうえで、担当範囲を減らすのか、期限を調整するのか、支援をつけるのかなどを決めます。PL自身も、黙って引き受ける前に、足りない時間や判断してほしいことを伝える必要があります。

チーム内では、進捗や判断の経緯、次に行うことなどを共有しておく。最初から完全な代行体制を用意できなくても、「PLに聞かないとわからない」を少しずつ減らすことはできます。

ただし、こういった引き継ぎや教育、情報共有の仕組みづくりにも時間はかかります。その時間を確保せず、PLの追加の努力に任せてしまっては、結局同じ問題を繰り返すことになります。

PLが自分で手を動かしたほうがよい場面はありますし、踏ん張らなければならないときもあるでしょう。ただ、それがいつもの進め方になってしまうのは避けなければいけません。

おわりに

今回、私が不在の間もメンバーがプロジェクトをまわしてくれました。実はその少し前に長い連続休暇を取得しており、奇しくもそれがPL不在の予行演習となっていたのでした。

突然の不在は避けられませんが、予定された不在は計画できます。それはPLがいなくても仕事が進むかを確かめる機会にもなります。

誰が何を進めているのか。判断に迷ったときは誰に相談するのか。PLにしかわからないことは何か。休暇に向けてこうした点を確認すると、普段は自分が対応することで済ませていた仕事にも目を向けられるのではないでしょうか。

PLが壊れるまでがんばるのではなく、がんばり続けなくても役割を担えるようにする。自分も休めてメンバーも休める。それでも仕事を続けられる体制を周囲と一緒につくっていきたいと思います。




当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。

メルマガ登録ボタン


秦 拓郎

ITインフラ事業本部 ITS第3部 テクニカルスペシャリスト

この執筆者の記事一覧

関連するナレッジ・コラム

世界初のAI規格、ISO/IEC 42001 取得の裏話

ノートで「問う力」を鍛えよう -AI時代の思考整理術

ロード・トゥ・「現場に強い」ITインフラエンジニア