女性ポートレイト

【PM必読!】燃えてからでは手遅れ。エンジニアのデスマーチを回避する6つのテクニック。

2017.07.10

【PM必読!】燃えてからでは手遅れ。エンジニアのデスマーチを回避する6つのテクニック。

女性ポートレイト

長時間残業、徹夜、休日出勤の常態化など、現場に過度な負荷がかかるデスマーチ。普通に働いていてはプロジェクトが成功する可能性は低く、現場のエンジニアたちが帰れない状態が続くことも。そうなれば、エンジニアたちは疲労困憊、精神疾患状態に陥り、最悪、「エンジニア人生に幕を降ろす」なんてことにもなりかねません。まさにITプロジェクトにおける「死の行軍」と言えるでしょう。

デスマーチに突入する理由はいくつかありますが、一般的には「期日が足りない」「工数が足りない」「人手が足りない」「仕様が突然変更される」などが挙げられます。総じてこれらはプロジェクトマネジメントが失敗に終わっているケースで、そもそもの計画が甘いことが一番の原因。業界の性質上、IT業界には多重下請け構造があり、元請けが下請けに丸投げするケースも珍しくありません。

このような発注をしてしまうと、納品されたシステムが当初計画していたものと整合性が取りにくく、計画的に進めることが困難になってしまいます。そのため、プロジェクト管理が甘ければ、どんな会社や現場でもデスマーチは発生する可能性があります。また、ITプロジェクトにおけるデスマーチは気合と根性では物理的にどうにもならないことも。そんな状況を防ぐためにも、今回はPMがデスマーチを回避する方法をご紹介します。

pixta_27321824_M

テクニックその1:PMOを設置する。

通常、プロジェクトが立ち上がったタイミングで各分野のプロフェッショナルが集まり、プロジェクト終了と共にメンバーは解散するため、プロジェクトマネジメントのノウハウはPMに集約される傾向にあります。そのため、管理ノウハウを体系的に集約し、メンバーに伝える機会が少ない傾向にあります。こうした課題を解決するのが、PMO(Project Manegement Office)。PMOとは組織全体のプロジェクトマネジメントの能力と品質を向上し、個々のプロジェクトが円滑に実施されるようサポートする専門部署。

プロジェクトマネジメント手法を標準化し、品質管理や人材育成などに責任を持つため、体系的にノウハウを管理・集約し、新人を育成することができます。PMOが設置されている組織では、ノウハウが属人化することがなく、新人も炎上の予兆を察知するスキルが身につくので、デスマーチに突入するリスクを減らすことができます。そのため、PMOを設置すれば、危険な案件を回避しやすいと言えるでしょう。

テクニックその2:管理・マネジメントの工数も見積もる。

プロジェクトの目標や成果物を定義してその後の承認や検収についてもトータルに管理するスコープ管理。このスコープ管理ではまず工数などを見積もりますが、一般的には「設計→コーディング→テスト→リリース」の工数までしか見積らないケースがほとんど。プロジェクトを管理・マネジメントする工数を見積もっていないため、要件や仕様を固めずに開発を進めてしまうこともしばしば。そのため、最初の段階である程度バッファを見積もっておくことがポイントです。適切なバッファを設けていれば、突発的な仕様変更があっても冷静に対処することができます。

テクニックその3:リスクに順位をつける。

事前に把握したリスクには緊急度や重要度を判断できる順位づけをすることがポイント。プロジェクトには様々なリスクが潜んでいますが、放置していても問題にならないケースもあります。しかし、ほとんどのリスクは放置すればするほど肥大化し、最悪の場合手がつけられなくなってしまうことも。こうした事態を防ぐためにも、各リスクにどれだけのコストインパクトがあるか分析し、優先順位をつけてリスクを管理していく必要があります。

pixta_14953977_M

テクニック4:メンバーのモチベーションを上げる。

当たり前のことですが、厳しいプロジェクトを乗り越えるには、チームのモチベーションが非常に重要。メンバーが意欲的に働けるように、PMはマメにスタッフとコミュニケーションをとりましょう。

もちろん、ただ仲良くすればいいというわけではありません。プロジェクト内にしっかりとしたヒエラルキーを作ることもプロジェクトを円滑に進める秘訣。リーダーの意思がサブリーダーやメンバーに伝わる仕組みを作り、トップの意思に迅速に対応できるチームを構築しましょう。

また、メンバーとコミュニケーションを図る際は、一人ひとりの性格に合わせた接し方をすることも大切。褒めて伸びる人、叱って伸びる人を見極め、対応方法を変える柔軟性もPMが身につけるべきスキルです。

テクニック5:クライアントに伝えるべきことを伝える。

ITプロジェクトでは仕様を固めてから仕様が変更することもしばしば。そのため、要件定義のフェーズから頻繁にクライアントのキーマンとコミュニケーションを図り、仕様を固める際にしっかりと合意を得ることが非常に重要です。合意を得ることで、その後仕様変更があっても、責任の所在を明確にすることができます。

また、要件定義の段階で仕様を固めるポイントは、ユーザー企業側のトップに対して、必要なスキルセットを提示すること。仮にそれに合わない人材が選出された場合、勇気を持って人材の変更を要求することも大切です。

テクニック6:メンバーのミスより事実に焦点を当てる。

チームのモチベーションに影響するため、ミスが発生した場合でもマネージャーはメンバーを個人的に攻撃してはいけません。フィードバックする際は、あくまでその個人、チームの成長のためという視点でアドバイスすることが重要です。もしミスを犯した本文が個人攻撃をされたと感じてしまうと、情報開示をしなくなり、現場で起きている問題や情報のキャッチアップができなくなる恐れがあります。結果、プロジェクトがさらに悪い方向に進むという悪循環になりかねません。ミスを犯した本人よりも、起こっている現状や事実に焦点を当て、その解決に注力しましょう。

Document Marketing Strategy Business Concept

それでもデスマーチに突入してしまったら。

一般論ですが、まず行うべきことは残っているタスクを全て洗い出すこと。計画していた一つひとつのタスクに対して、何が終わっていて、何が残っているか確認しましょう。その上で、タスクを実行する上での課題やリスクを把握し、打ち手も考えます。解決策を実行する上での優先順位も決め、それに対しどうリソースを割り当てていくかを決めます。

優先順位を決める際に重要なのが、「must(絶対にやらないといけない)」「should(やった方がいい)」「could(できればやった方がいい)」というカテゴリーに分けること。既にプロジェクトが炎上しているため、振り分けに時間をかけることはできなと思います。まずはざっと割り振りを行い、「must」のタスクに集中しましょう。もし余裕があれば、「should」に取り掛かり、奇跡的に時間が余れば「could」に手をつけます。ただ、現実的には「could」は諦めることになるケースが多いので、「must」や「should」を「could」に割り振らないように注意しましょう。

プロジェクトが炎上する背景には、メンバーの力量不足、納期の重なりなど、個人の力ではどうすることもできない要因もあると思います。ただ、PMの力量や段取りがプロジェクトを円滑に進める上で、大きな要因になることも事実。自分の評価や成果はもちろんですが、メンバーの健やかな心身維持のためにも、ここで紹介したテクニックをぜひ活用してみてください。

<了>

Content from:【PM必読!】燃えてからでは手遅れ。エンジニアのデスマーチを回避する6つのテクニック。

このトピックスをみんなとシェアする
このエントリーをはてなブックマークに追加
女性ポートレイト

この記事が気に入ったら

Work Switchの最新情報をお届け



Follow on twitter