paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

PMが炎上プロジェクトや残業地獄からメンバーを救うためにとるべき対策5つと心がけ

f:id:paiza:20170327210843j:plain
Photo by Alex Dawsons
高村です。

最近、労働基準法改正案で残業時間の上限が「100時間未満」となったニュースが話題になっていますね。残業に関する東京商工リサーチの調査では、残業時間を減らす努力について「努力している」と回答した企業が79.7%、「努力していない」が12.4%、「不明」が7.8%だったそうです。近頃は世間の「残業は悪!」といった声も大きくなってきたため、働き方改善に取り組んでいる企業も多いのかなと思います。
moneyzine.jp
ただ、この「努力」が本質的な残業削減につながっているのかどうかはまた別の問題です。

例えば一般に残業が多いとされるIT企業の開発現場ですと、「残業削減(禁止)令」を出された経験がある人もいるのではないでしょうか。私も前職で経験がありますが、ただ「残業はダメ、でも納期に遅れるのもダメ」と言われただけでは業務量に対する根本的な解決にはならないどころか、下記の記事のように逆効果となってしまう場合もあります。
itpro.nikkeibp.co.jp
こうした「残業削減令」が出たときに、プロジェクトを管理するPM(プロジェクトマネージャー)はどうすべきかについて、前職での経験や心がけていたことなどから考えていきます。

■私の簡単な経歴

大学(情報工学)→メーカー系の大手SIer→paiza(ギノ)

入社1年目はテスターから始まり、2年目ぐらいから開発チームのサブリーダーとかマネジメント役を担当するようになり、最終的にはPMが別にいるのになぜか自分がPM的業務をやっている状態になっていました。

■残業削減令が出たらすべきこと

f:id:paiza:20170328124953j:plain
Photo by Concerned Reader

◆まずは残業削減令の背景を把握する

上から残業削減令が出た場合、大きく分けてこのどちらかの理由があります。

  • 原価的な理由(残業のせいで利益を下げたくない)
  • 倫理的な理由(社員の健康面も考慮して労働環境を改善したい)

まず、どちらが背景にあって「残業するな」と言われているのかを明らかにしましょう。

背景によってPMの動き方は変わりますし、そもそもプロジェクトのメンバーたちにも「こういう理由で残業削減に取り組んでいきたいから協力してくれないか」と説明する必要があります。「上から言われたから」だけではダメです。

◆別のプロジェクトに起因する「残業禁止令」が出た場合

同じ部内の別プロジェクトが炎上している場合に、これ以上ほかのプロジェクトまで炎上したら部内の利益が下がっちゃう……といった理由で、上から「君んとこのプロジェクトは残業禁止で頼むよ」と言われる場合もあります。(特に売上高が大きいプロジェクトから言われます)

大きなSIerだと部内でこうした利益やリソースの取り合いになってしまうパターンはよくあります。この場合、PMは「それだとうちのプロジェクトも炎上して共倒れになっちゃって、結果的に利益はさらに下がる可能性が高いです」などと言って、ときには上と戦う必要も出てくるでしょう。上から言われたことをノーモーションでホイホイ受け入れるだけでは、PMとしての役割を果たしているとは言えません。

■見積もりの段階ですべきこと

◆リスクを考えてスケジュールやリソースに余裕を持たせる(ことができるようがんばる)

そもそもプロジェクトが走り出してから、それこそ炎上してる最中に「残業を減らそう、なくそう」などと言われてもどうしようもありません。本来であれば見積もりの段階で対策をとっておく必要があります。

なるべく余裕のある工数を確保するために、例えば導入したら開発スピードを上げられそうな便利ツールなどの技術選定をしておくとか、その上で使わない前提のスケジュールを引いておくとか。

また、リソースに関しても余裕を持たせる必要はあります。私が過去に初めてサブリーダーをやったプロジェクトは、PM未経験者がPMを務め、私を含む2人のサブリーダー未経験者がサブリーダーを務める……といったひどいプロジェクトでした。こんなメンバー構成でプロジェクトを問題なく進めていくのは現実的に無理です。

本来であればPMは、単価に対して求められる生産性がマイナスになりそうなメンバーはなるべく入れない方向に持っていった方がよいでしょう。それでも会社ですから、上からどうしても「この人をプロジェクトに入れろ」と言われる場合は、「この人を入れると利益が減る可能性が高いです。それでもよいでしょうか」といったことをきちんと言っておく必要があります。

■プロジェクトが始まったらすべきこと

f:id:paiza:20170327211317j:plain
Photo by secretlondon123

◆お客さんの運用方法をちゃんと把握しておく

根本的なことというか、そんなの当たり前じゃんと思うかもしれませんが、お客さんがこのシステムを「どんな目的のもとにどうやって運用するのか」を把握できていれば、例えば「A機能は最優先で必要」「B機能は一部ができていればよい」「C機能は来期のプロジェクトに回しても大丈夫そう」といったことがわかりますよね。

プロジェクトのメンバーは、タスクが多すぎるから残業しているわけで、当たり前ですが無策のまま残業を禁止してもただ納期が遅れるだけです。

例えば医療系のカルテを管理するシステムのプロジェクトで、お客さんが「カルテを便利に管理したい」と言っていたとしましょう。一言で「便利に管理する」と言っても、お医者さんが診察時に入力しやすくしてほしいのかもしれませんし、そうではなくて看護師さんが後から参照しやすくするのが最優先なのかもしれませんよね。こうしたお客さんの持っている課題を正しく把握できれば、要件やスケジュールなどを調整できそうなポイントが導きだせるかと思います。

◆無駄を削る

残業を減らそうとか炎上を鎮めようとか思ったら、とにかくあらゆる無駄を省いて工数を確保する必要があります。

例えば最初に引いたスケジュールに余裕を持たせていた場合はそこを詰めたり、見栄えや使い勝手向上のためのちょっとした要素は後回しにして調整できないか検討しましょう。

また、おそらく回数や参加メンバーを減らしても構わない無駄な会議や打ち合わせがあると思いますから、それも検討する必要があります。切羽詰まっているときの無駄な会議は害悪でしかありません。

あと、メンバーについては見積もりの段階でも言いましたが、メンバーによってスキルの差があるのはある程度仕方ないにしても、あまりにも生産性が悪い人は入れ替えを検討する必要もあります。これ、社内ならまだしも協力会社の人の場合はめちゃくちゃ言い方を選ぶ必要があります。でも言わなければならない。じゃないとちゃんとできるメンバーに負担がいってしまいます。

この辺の無駄削りに努めまくるだけで、炎上がボヤ程度でおさまる場合も多いです。ノーモーションでホイホイ受け入れるだけでは、PMとしての役割を果たしているとは言えませ(以下略)

■そもそもPMが普段から心がけるべきこと

◆基本のスケジュール管理

基本中の基本ですが、スケジュールを引いたら「この日までにここまで終わらせる」という管理をしっかりやること。そのためには、予定と実績に差異が出だしたら、誤差の段階から軌道修正していく。誤差は誤差、予兆は予兆で済むうちに潰しておく。これができずに炎上するのは、現場で作っている人じゃなくて、管理できていないPMが悪いです。

そのためには、例えば進捗ミーティングで下から上がってくる報告をいい意味で鵜呑みにしないというか……早い段階で「90%できてます」と言われて安心しきっていたら、いつまでたっても残りの10%ができてこない、調べたらその人の手に負えないレベルの複雑な10%だった→炎上とかいうパターンもありますよね。

上としては「何で早めに正しい報告をしないんだ!」と思うかもしれませんが、そういうことを言う前に、普段から新人でも「誤差の範囲で済むかもしれませんが、遅れそうな予兆があります」と言いやすい空気を作っておくのがPMの大事な仕事です。

そのためには「最近あの人よく残業してるっぽい」と思うメンバーがいたら早めに声をかけてみるとか、プロジェクトのメンバーにとって「何でも言っていいんだよ」な相手になっておかないと、予兆の段階で潰してスケジュールを本当に管理していくのは難しいと思います。

もちろんただ話を聞くだけではダメで、「実はこんなことで悩んでます」と言われたら、しっかり解決策を講じて行動で示す必要があります。悩みや不満を聞いてくれて「うんうん君はよくがんばってくれていると思う!」とは言ってくれるけど、それだけで特に何か改善策をとってくれるわけではない……といったPMもよくいますが、このタイプのPMは「話しやすいけど結局何もしてくれない人」として、だんだん信頼されなくなっていくと思います。

◆技術の選定ができるレベルの知識

「便利そうな開発環境や新しい技術を導入しよう!」となるプロジェクトは多々あると思いますが、有識者もいないのに新しいものを導入すると大体まずい結果になります。

前職で有識者がいないのに新しいフレームワークを導入して大炎上したプロジェクトの助っ人に行った経験がありますが、「見よう見まねの突貫工事で作ったせいで、いざテスト工程に入ったらバグだらけ」といった状態だったため、「この技術がいい感じらしいから、よくわかんないけど導入しちゃおう」というのはよくないです。

ライセンスの問題とか、プロジェクトが成立するレベルですぐにみんなで使えそうかとか、最低でもリスクをはかれるレベルの知識は持っておく必要があります。導入してからリスクが発覚して炎上しても後の祭りです。

◆管理者として、エンジニア目線に立ちすぎない

あくまで管理に注力するために、PMがエンジニア目線に立ちすぎるのはよくないですね。

開発が好きだった人に多いのですが、PMが「遅れが出たら俺もコーディングするからOK!」とか言っているようではダメです。(こういうPMだと大抵は最終的にPMが手を動かしても終わらないレベルで炎上してしまう)「俺が手を動かさなくても予定通り進んで行く」のが正しいプロジェクト管理のはずですから。

■まとめ

プロジェクトメンバーの負担や不利益になりそうな事態が発生した場合、本来であればPMがきちんと「こういう理由でそれは厳しいです」と各方面に言って働きかけなければなりません。また、会社なのである程度不利な条件を飲むことになったとしても、その背景や原因を把握しておいて、実際に開発を担当するメンバーに説明しなければなりません。

「上に言われたからこうします」というだけでは、メンバーからの信頼も失いますし、モチベーションも下がってしまいます。

ただ、あまりにもヤバい案件しか回ってこない場合は、そもそもその会社に問題があったりするので……転職を考えるのもよいかと思います。


paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。paiza転職では「残業30時間以内」「一部在宅勤務可」「裁量労働制」といった条件からもエンジニア求人を探せます。

paiza.jp




paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。

paiza転職」は、自分のプログラミング力が他社で通用するか(こっそり)腕試しができる、IT/Webエンジニアのための転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
paiza.jp
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
paiza.jp

ITプログラマ・エンジニア向け転職・就活・学習サービスのpaiza