「デスマーチ」はソフトウェアエンジニアにとって、避けたいがなかなか避けられないものであり、多くの人が悩まされているのではないだろうか？
この記事によって、そのような悩みを少しでも解決に近づけることができれば幸いである。
国家資格である情報処理技術者試験「プロジェクトマネージャ」の過去問題のある問題文内に、「デスマーチ」に至る開発要員の心理について記述されていた部分がある。この内容は現実にも起こりうる内容であり、その前兆からどのように「デスマーチ」に至ってしまうのか、「デスマーチ」を未然に防ぐにはどのようにすれば良いのか考えてみたい。
1.「デスマーチ」とは過酷な労働環境に加えてプロジェクトが破綻に向かっていく状況
まず、前置きとして「デスマーチ」の用語説明から入る。
「デスマーチ」とは、プロジェクトにおいて過酷な労働状況をいう。ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期直前等の状態が破綻寸前で、関係者の負荷が膨大になったプロジェクトの状況を表現するのに使われる。プロジェクトが死に向かう過酷な状況でプロジェクト要員が行進するという意味から、「デスマーチ」は「死の行進」とも呼ばれる。
具体的には、長時間の残業や徹夜・休日出勤の常態化といった、プロジェクトメンバーに極端な負荷・過重労働を強い、通常の勤務状態では成功する可能性がとても低いプロジェクト、およびこれに参加させられている状況を指す。
プロジェクト要員は、心身ともに極めて重い負担を強いられるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、場合によっては過労死や過労自殺に至る。その発生要因は、
- 顧客からの無理な要求
- 開発側による無理な計画
- 前行程の遅延を後行程で長時間労働といった力業によって穴埋めする企業体質
- プロジェクトマネジメントが不適切である
こととされている。
「長時間労働」「過重労働」「デスマーチ」「ブラック労働」、言葉はどれも良く似ており、過酷な労働環境を表している。その使い分けについては、こちらの記事を参照していただきたい。
o08usyu7231.hatenablog.com
2.「デスマーチ」に至る心理はエンジニアとしての使命感が大半
国家資格である情報処理技術者試験「プロジェクトマネージャ」の過去問題のある問題文内に記述された部分を引用し、システム開発プロジェクトにおいて、進捗が遅延しているチームのメンバから４つの意見を紹介する。いずれも現実の世界でよくあることだと改めて思う。
●意見①
遅延を解消するために、他チームから応援メンバを入れて対応することがあった。しかし、応援メンバは開発する機能についての経験や知識がないので、応援メンバを受け入れても、チームの生産性はすぐには向上せず、むしろ、一時的には低下することがある。そこで、工程の後半では、応援メンバを受け入れるよりも、現在の要員１人当たりの作業量を増やして対応したいと申し出ることが多かった。しかし、１人当たりの作業量を増やすと作業品質が下がり、結果として生産性が低下した。
●意見②
改修すべき障害が蓄積してくると、行程完了期日までに全ての障害を改修しなければならないというプレッシャーから、余裕のない改修予定日を設定してしまう。その結果、要員が焦って、改修ミス、デグレードを発生させ、当初設定していた改修完了予定日に間に合わなくなることが多かった。
●意見③
当初設定した改修予定日に間に合わなくなったケースでは、遅れる可能性についてかなり前から察知していることが多かった。しかし、”改修完了予定日に間に合わせたい”、”他チームに迷惑をかけたくない”という思いから改修予定日の直前まで頑張って、それでも間に合わない場合に見直しを連絡していた。
●意見④
他チームに依頼したい作業はいろいろあった。しかし、既に障害が多発して迷惑をかけている他チームに、更に作業を依頼するのは気が引けて、ためらうことが多かった。
どの意見も、進捗が遅延しているチームが他チームやプロジェクト全体に迷惑をかけているという自覚が鮮明であり、エンジニアとしての使命感に溢れている印象だ。そして、遅延しているチームで可能な限り進捗遅延の挽回の努めている様子が伺える。ソフトウェアエンジニアとしての責任感、こだわり、謙虚な姿勢には、素晴らしいと感じる。
しかし、どの意見もその方法に問題があり、遅延しているチームで頑張ることで片づける、もしくは他チームを安心させようとギリギリまで頑張る行為が、かえって全体にとって悪影響となることがある。上記の各意見に対して、どのように捉え、どのように進めるべきなのか、次章で検討してみよう。
3.「デスマーチ」に至る心理を分析し改善すべき点について考える
遅延しているチームにおける４つの意見を精査してみよう。
●意見①
遅延を解消するために、他チームから応援メンバを入れて対応することがあった。しかし、応援メンバは開発する機能についての経験や知識がないので、応援メンバを受け入れても、チームの生産性はすぐには向上せず、むしろ、一時的には低下することがある。そこで、工程の後半では、応援メンバを受け入れるよりも、現在の要員１人当たりの作業量を増やして対応したいと申し出ることが多かった。しかし、１人当たりの作業量を増やすと作業品質が下がり、結果として生産性が低下した。
この意見のようなケースに遭遇した場合、もしくはリスクとして考えられる場合、そもそも「遅延」の原因が何で、「単なる要員の追加投入だけで解決する問題なのか」という点の見極めが必要である。
ここでは単に「遅延」と表現しているが、根本的な人員配置ミスや見積りの失敗、顧客や上層部からの無理な要求など、「遅延」では済まされない程度の要因により、開発要員がそのしわ寄せを受けてブラック労働に陥っているということも数多くあることを理解しておく必要がある。
まず、意見の前半の内容である、他チームから要員を増やす方法についてである。開発対象システムを熟知した要員であれば良いのだが、そうでない場合の方が多いだろう。そのような場合は慣れるまで時間がかかることを想定しておかなければならない。慣れるまでの時間を見越しても、それでも長い目で見て遅延を挽回することができる場合にのみ、この方法を適用すべきである。
よくやる失敗は、何も考えずにただ空いている要員をアサインするケースである。この意見のように既存要員のリソースをますます奪われ、デスマーチになりかねない。
次に、この意見の後半に記載されている「要員１人当たりの作業量を増やす」方法では、やはり要員への負荷が高くなり、要員が疲弊して作業品質が下がり、結果として生産性が低下してしまうのはその通りだろう。残念であるが、一番やってはいけない力技である。しかし、現実にはよくやってしまっている。
労務面の観点からいうと、人間は朝起きて13時間以上経過すると、酒酔い運転と同じくらい作業効率が低下するということが、医学的に証明されている。普通の企業であれば、この生産性が低下した状態の開発要員に対し、割り増しした残業代を支払っているのである。よくあることだが、このような観点で考えるととても恐ろしいことである。
開発要員の追加が困難であれば、納期の延長が現実的だろう。納期の延長も許されないなら、開発スコープの縮小が最も良いだろう。
こちらの書籍を参考にしていただきたい。
●意見②
改修すべき障害が蓄積してくると、行程完了期日までに全ての障害を改修しなければならないというプレッシャーから、余裕のない改修予定日を設定してしまう。その結果、要員が焦って、改修ミス、デグレードを発生させ、当初設定していた改修完了予定日に間に合わなくなることが多かった。
この意見のようなケースに遭遇した場合、まずすぐに改修しなければならないのか、優先度を落とすことができるのかといった見極めから入るのが良いだろう。
重大な障害に対する改修であれば、余裕のない改修予定日に設定することで、かえって状況が悪化することだけはあってはならない。かといって、あまりにも時間をかけた対応は、状況からして現実的ではない。
重大な障害に対する改修を行う場合は、対応要員がその作業に専念できるような環境作りが必要ではないだろうか。また、プレッシャーによって要員が焦って作業することのないような声かけや配慮も必要ではないだろうか。ブラック企業のような、パワハラでもって人を動かすのはもってのほかである。
●意見③
当初設定した改修予定日に間に合わなくなったケースでは、遅れる可能性についてかなり前から察知していることが多かった。しかし、”改修完了予定日に間に合わせたい”、”他チームに迷惑をかけたくない”という思いから改修予定日の直前まで頑張って、それでも間に合わない場合に見直しを連絡していた。
この意見のようなケースに遭遇した場合、「改修予定日に間に合わなくなること」が、「早い段階から分かる」ケースと、「直前に分かる」ケースでどちらが全体にとって良いかを考える必要がある。おのずと前者であることが分かるだろう。前者のほうがスケジュール面での対策や打ち手を考える時間的余裕があるからである。
特に、現場の開発要員にギリギリまで頑張って挽回しようとする傾向があり、マネージャは「悪い知らせは早く報告してほしい」と考えていることが多い。
マネージャが「間に合わなくなるなど、甘いこと言わずにギリギリまで頑張れや！」等とパワハラ的なことを言ってしまうと、ギリギリまで頑張る開発要員が増え、報告がしにくい、風通しが悪い職場環境となってしまう。
ギリギリまで頑張ることが更なる迷惑につながることを、マネージャは開発要員に対して常に発信し、開発要員もできるだけ早く「悪い知らせ」を報告する職場環境にする必要がある。
●意見④
他チームに依頼したい作業はいろいろあった。しかし、既に障害が多発して迷惑をかけている他チームに、更に作業を依頼するのは気が引けて、ためらうことが多かった。
この意見のようなケースに遭遇した場合、そもそも「元々のリソース配分や計画が適切だったのか」についての考えるが良いだろう。リソース配分に偏りがあったり、不十分なところがあれば、そこを是正することが必要なのに、遅延しているチームが業務を抱えてしまい、サポートを求めることをためらってしまうため、周囲へもなかなか大変な状況が伝わりにくいのである。
これも「意見③」の解決策と同じく、遅延チームがサポートを求めるよりも、遅延チームが業務を抱え破綻することによる全体への悪影響のほうがよほど迷惑であることを共有し、声を挙げやすい職場環境にすることが必要である。
4.このような時こそ「報連相」を！労務トラブルに発展すれば全て水の泡だ！
長時間労働のような力技は、一時的には切り抜けることができたとしても、次に示す通り様々なリスクを抱えることになる。
- 疲弊による作業効率低下
- ミス発生による品質低下
- 健康面の悪化による休職のリスク
- 品質低下によるリカバリ作業の追加
- 人間関係の悪化
- 優秀な人材の離脱
- 労働環境の悪化
- 人材獲得可能性の低下
- 健康被害者からの訴訟のリスク
- 行政指導・是正勧告
いずれも、将来に渡ってデメリットが大きいことを留意いただきたい。労務トラブルに発展すれば、全てが水の泡だ。
まず、上記の内容をプロジェクト内で共有し、予定に間に合いそうにないなど、不都合なことがあれば、声を挙げやすい体質にすることである。都合の悪い話でも、早く知らせることができれば、状況把握や対策検討に時間的余裕がある。要員の頑張りには限度があるのだ。普段からのコミュニケーションの改善が必要である。
こんなときこそ、思い出してほしい言葉が、「報連相」である。実はこの「報連相」、間違った意味で使われることが多く、本来の意味を知っている人は少ないのではないだろうか？ 本当の意味での「報連相」（報告・連絡・相談しやすい環境）ができる状態になってほしい。
o08usyu7231.hatenablog.com
最後に、デスマーチの前兆をよく目の当たりにする人は、デスマーチに巻き込まれないようにすべきと言いたいところだが、残念ながら顧客・経営陣・管理職からの圧力やマネジメントの未熟さにより避けられない場合もあるだろう。デスマーチに巻き込まれても、抜けることができるように準備をしておこう。
今、在籍している会社が全てではない。デスマーチを乗り切りことが、絶対的な正義ではない。見切りも必要だ。デスマーチを乗り切りことができるくらい、フィジカルやメンタルがタフな人間は、会社にとって都合が良いだろう。しかし、私はこのタイプは必ずしも優秀な人材だとは思わない。会社にとって都合が良いだけだ。
o08usyu7231.hatenablog.com
本当に優秀な人間は、自身で可能な対策を行い、自身で取り組んだことを明確にすることに加え、劣悪な環境から逃れるよう行動を起こすことだ。会社のために自分が犠牲になってはいけない。私も、デスマーチに巻き込まれたプロジェクトのあるIT企業から、大手メーカーへ転職した人間だ。
