Photo by Rich Bowen
こんにちは。谷口です。
皆さんの職場では開発プロジェクトの炎上は起きていませんか?
エンジニア、特に受託開発企業にお勤めの方の転職理由を伺っていると、「自分のスキルをいかせる仕事がしたい」などの前向きな理由がある一方で、「炎上プロジェクトばかりが続いていて大変」「勤務時間が長く、休日出勤も多い」という、職場環境の問題も少なくありません。
最近は労働基準法改正案で残業時間の上限が「100時間未満」と規定されたり、厚労省が労働基準関係法令違反企業のリストを公開したりしたことで、労働環境改善の課題が、社会的に注目されています。IT企業も例外ではありません。炎上プロジェクトはできる限り減らしていかなければなりません。
では、なぜプロジェクトの炎上が起こるのでしょうか。
受託開発企業では、開発メンバーの残業時間や仕事のしやすさを左右するのは、多くの場合PMの手腕です。もちろん企業全体の問題であったり、プロジェクトの仕様上、PMではどうにもできないものだったりすることもありますので、一概には言えませんが、プロジェクトの進め方やメンバーのタスクを管理するのがPMの仕事ですから、「メンバーの働きやすさはPMにかかっている」と言っても過言ではありません。
今回は、転職をお考えの皆さんから寄せられたご相談や、先日paizaユーザーの皆さんに実施した仕事への不満に関するアンケート回答から、メンバーが不満を感じるPMに多い共通点についてお話しします。今PMをやっている方は、自分があてはまっていないか確認してみてください。
■ダメなPMに多い共通点
Photo by Axel Schwenke
◆スケジュール管理が下手すぎる
PMの腕の見せ所の1つであるはずのスケジュール管理。しかし、残念ながらきちんとできていないPMも多いようで、不満を抱いているメンバーが多い項目です。
アンケートでは、「開発に関する知識があまりないPMだからか、見積もりが下手で、休日出勤をさせられることも多い」「プロジェクトが突発的で、短い納期での開発を要求される」「ときどき不要な待ち時間が発生して時間の無駄になっている」といった不満が寄せられました。
基本中の基本ですが、スケジュールを引いて「この日までにここまで終わらせる」という管理をする、予定と実績に差異が出だしたらなるべく誤差で済むうちに何とかする……これらはPMの仕事です。見積もりやスケジュールが原因で炎上した場合、現場の開発メンバー以前に、管理が行き届かないPMに問題があると言えるでしょう。以下の3つは残念なスケジュール管理として代表的なものです。
◇最初からキツいスケジュールを引いてしまう
最初からギリギリのスケジュールを引いてしまうと、少しでも遅れや問題が生じたら、その時点でプロジェクトは炎上してしまいいます。PMは見積もりの段階で、なるべく余裕のある工数を確保しておかなければなりません。
もちろんお客さんや営業の人、部署の上司などの都合で、どうしても厳しいスケジュールを強いられる場合もあります。しかし、無理なスケジュールは「引いておけばみんながその通りに作ってくれる」というものではありません。
むしろ無理なスケジュールを引いたせいで、途中から人員の増加や納期の延期が必要になったり、長期的な激務を強いられたりすれば、利益も下がりますし、結果として全員が不幸になってしまいます。
◇PM一人でWBSを作ってしまう
タスクが細分化できていないプロジェクトは、テスト工程で炎上してしまうケースが多いため、炎上を防ぐためには小さな抜け漏れタスクであってもできる限り早めに潰しておく必要があります。
ただ、PMが最初から全てのタスクを割り出せるかといったら、それも難しい話で、後から必ず抜け漏れしていたタスクが発生してしまいます。
特に前述のような、最初からギリギリでスケジュールを引いていた場合、後から発生した抜け漏れを割り振ろうとすると、誰かに無理をしてもらわなければならなくなりますし、「工数が足りないからできませんよ」と言われてしまうかもしれません。
プロジェクトにもよるとは思いますが、WBSはPMが一人で決めるよりも、例えばエンジニアのチームが担当機能ごとにわかれているなら、チームごとにタスクを挙げてもらい、それを元にWBSを作った方が、後から出てくる問題は減らせるかと思います。
◇無駄な会議をやめない
切羽詰まっているときの無駄な会議は害悪です。
少しでも残業を減らしたり炎上を鎮めたりしたい場合は、とにかくあらゆる無駄を省いて工数を確保する必要があります。
上司との兼ね合いでどうしても削れない会議もあるかとは思いますが、おそらくどんなプロジェクトでも、回数や参加メンバーを減らしても問題なさそうな無駄な会議や打ち合わせがあると思います。
例えば、メンバー間の進捗報告は、PM自身が個別に確認して個々の工数をなるべく浪費しないようにする、などといった対策を検討するとよいでしょう。
◆お客さんの要求の意図やシステムの運用方法を把握していない
Photo by kizzzbeth
「指示を出す人が開発要件を全く把握しておらず、出戻り作業が頻繁に発生する」「お客さんの要求とPMの要求に乖離があって、開発が進まない」「営業やお客さんの思いつきで振り回されることが多い」…アンケートではこのような不満も数多く寄せられました。
信じ難いことに、お客さんがシステムを「どんな目的のもとにどうやって運用するのか」を把握できていないままプロジェクト管理をしている人は大勢います。
これが把握できていれば、「A機能は最優先で必要」「B機能は一部ができていればよい」「C機能は来期のプロジェクトに回しても大丈夫そう」といったことをお客さんとすり合わせて、スケジュールやタスク量の調整を掛け合うこともできます。
しかし、PMがお客さんの意図やシステムの運用方法を把握していないと「今回のプロジェクトの最優先目的」や「この機能は必須だけどあの機能はなくても大丈夫」「この機能は次の来期のプロジェクトに回してもらうべき」といった判断ができないため、思いつきで提案された機能なども、言われるがまま追加になってしまうケースがあります。
◆スキルが不足しすぎている
マネジメントをするのがPMの仕事とはいえ、あまりにも技術のない人が、開発プロジェクトを管理しようとすると、多くの場合が大変なことになってしまいます。
アンケートでも、「見積もりがめちゃくちゃ」「PMに技術的な質問をしても回答や指示をもらえなくて困る」といった不満が寄せられました。こんなPMの下では、円滑にプロジェクトが進むはずがありません。
また、例えば「便利そうな開発環境や新しい技術を導入しよう!」となるプロジェクトは多々あると思いますが、有識者もいないのに新しいものを導入するのも、大体まずい結果を招いてしまいます。
ライセンスの問題とか、プロジェクトが成立するレベルですぐにみんなで使えそうかとか、最低でもリスクをはかれるレベルの知識は持っておく必要があります。導入してからリスクが発覚して炎上しても後の祭りです。
◆管理者の目線が不足しすぎている
一方、開発スキルがある人が陥りがちなのは「エンジニア目線で見すぎてしまう」こと。
「管理者が管理をしてくれず、チームの統率がとれていない」といった悩みを抱える人もいました。開発スキルがあるのはとてもよいのですが、PM自身がエンジニア目線に立ちすぎると、本来の仕事であるはずの管理がおそろかになってしまいがちです。
開発が好きだった人に多いのですが、PMが「遅れが出たら俺もコーディングするからOK!」とか言っているようではダメで(こういうPMだと大抵は最終的にPMが手を動かしても終わらないレベルで炎上してしまう)、そもそも「俺が手を動かさなくても予定通り進んで行く」のが正しいプロジェクト管理のはずですので……。
プロジェクトマネジメント知識体系ガイド(PMBOKガイド)第5版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
プロジェクトマネジメント標準 PMBOK入門 PMBOK第5版対応版
- 作者: 広兼修
- 出版社/メーカー: オーム社
- 発売日: 2014/03/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
図解入門よくわかる最新PMBOK第5版の基本 (How‐nual Visual Guide Book)
- 作者: 鈴木安而
- 出版社/メーカー: 秀和システム
- 発売日: 2013/09/09
- メディア: 単行本
- この商品を含むブログを見る
■まとめ
プロジェクトを炎上させてしまうのは、開発メンバーではなく、PMの責任です。
本来であれば、PMは開発メンバーにとって無理のない範囲でタスクを割り振り、無理のない範囲でプロジェクトを進めていかなければなりません。PMが的確にマネジメントをできていれば、炎上を防いだり、もしくは最小限でおさえることもできるはずです。
ただ、もちろんPMだけでは手に負えないレベルのプロジェクトも存在します。PMがきちんと機能しているにもかかわらず、明らかに炎上するとわかっているプロジェクトしか回ってこないのであれば、それは企業に問題があると考えるべきでしょう。そういった可能性はどこにでもあるため、いざ「転職をしたい」となった時に困らないように、普段からスキルアップを心がけておくとより安心かと思います。
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せるよう、「残業30時間以内」「一部在宅勤務可」「裁量労働制」といった条件からもエンジニア求人を探すことができます。
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか(こっそり)腕試しができる、IT/Webエンジニアのための転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら