エンジニアをデスマに巻き込むときにやるべきこと・やるべきでないこと

下の記事を読んで、大変共感しました。

実際は、様々な状況でデスマや残業をせざるを得ない事が多々ある。会社として頑張らなければならなかったり、金銭的なものであったり、色々な事情がある。
そうなったら僕は、残業もするし、デスマもするし、炎上の火消しもする。

この辺りを読んで、
エンジニアをデスマに巻き込むときにやるべきこと・やるべきでないことを書きます。

真っ当なエンジニアは自分が抱える問題を共有し、エンジニア同士で解決を図ります。
エンジニアが解決できない問題は適宜マネージャーに相談します。
仮にそれがエンジニアの力不足によるものだとしても。

正直になることでチームは前に進みます。
マネージャーもエンジニアのこのような行動を望んでいるはずです。

それなのにマネージャーがエンジニアに対して正直でないとすれば、
エンジニアのやる気を削ぐに違いありません。

* リリース間際に今のプロダクトが顧客にとって価値が低いことがわかった
* ステークホルダーが納得していない
* 実は会社がヤバイ

事情はさまざまだと思います。

大抵のエンジニアはデスマを過ごしつつも、
それをデスマでなくすために解決策を考えます。

誰だってデスマはイヤです。
エンジニアがいろいろな提案をマネージャーにしてくることでしょう。

マネージャーが提案に何でも否定的ではデスマは解決しません。
もしかするとその提案は、既にマネージャーが試みた提案かもしれません。

面倒臭がって、
「それはダメだ」
ではなく、
「実は同じことを考えてたんだけどダメだったんだ」
とでも言ってあげてほしいです。

もう一度（ステークホルダー）に言ってみると、
意外とうまくいくかもしれません。

時（When）と誰（Who）が変われば結果が変わる
なんてことはよくあるものです。

エンジニアはもちろんマネージャーも含めて、
チームがプロジェクトを諦めない姿勢が必要でしょう。

やるべきことの逆説なので簡単に。

マネージャーが報告していたことがステークホルダーに伝わっていない。
など、多少マネージャーにも否がありそうな事情は言いづらいかもしれません。

それでもチームを支えるのは正直さです。
お互いを信用しない、ギスギスした環境で働きたいですか？

そういうことです。

プロジェクトが無事？完了したら、必ず振り返りましょう。
（デスマでなくともそうなんですが、デスマなら特に。）

ステークホルダーも参加できれば理想ですが、
最低でもチームの意見としてステークホルダーに届ければ何か変わるかもしれません。

デスマの原因をどうにかしなければ、また次のデスマが生まれます。

当然のことですが、デスマにならないのが一番です。

デスマにならないようにするのは、
エンジニアやマネージャーだけの力では無理で、
ステークホルダーの理解・協力が必要です。

デスマが一つでもなくなり、ITエンジニアにとって働きやすい世の中になりますように。