デスマーチと別れよう。プロジェクトリーダーが押さえておくべきものとは？

どうも、じんせいサンドです。

プロジェクトを担当した事ありますか？

大なり小なりどなたも体験したことがあるのではないでしょうか？
新年会やお花見の開催もプロジェクトって言えばプロジェクトに当たります。

そんなプロジェクトにおいて、一般的に良くないと言われているのが、デスマーチと呼ばれる状態です。
IT用語辞典を引用しますと、

デスマーチとは、「死の行進」という意味の英語表現で、IT業界では過酷な労働環境や極端な過重労働を課されるシステム開発プロジェクトの現場を表す俗語として用いられる。

という意味です。
簡単に言うと誰も幸せにならないプロジェクト進行。
略語でデスマと呼ばれるものです。

大抵のプロジェクトはデスマに陥っているのでは無いのでしょうか？

デスマに陥ってしまう理由と回避策を考察してみました。

この記事で学べること

・デスマに陥る理由
・デスマを回避する3つの方法

デスマに陥る理由

僕的には大きく3つだと思っています。

1.要件定義の甘さ
2.関係者の洗い出し漏れ
3.甘い見積もり

他にもあるとは思いますが、この3つにスコープを当て説明していきます。

1.甘い要件定義

これを返す魔法の言葉があります。
「仕様です」
ですね。はい。

基本は要件漏れが発覚しても、これで基本的には回避できます。

しかし、その言葉を使ってしまうプロジェクトは果たして成功と言えるのでしょうか？

サイロ化した組織で自分たちの責任だけを負うと言ったような縦割り構造において、自分たちを守ることが目的であれば、それでも良いでしょう。

しかし、そもそもなぜそのプロジェクトは始まったのか？に立ち返ると、その魔法の言葉はひどく空虚なものへと変わります。

そもそも考慮漏れに気付く仕組みを作るべきですし、仮に気付ける知識があるのであれば、それを提案して然るべきだと思います。

要件定義をする際に必要な能力はMECEで考えることが重要です。

MECEとは、日本語では「もれなくダブりなく」という意味です。

僕的にはもれなくダブりありで良いとすら思ってます。漏れているよりはダブっている方がタチが良いです。というのも、ダブってた場合はどちらかが引っ込めれば良いだけだからです。

あらゆる可能性を考えて、
想定しうるパターンから考慮漏れがないか考えていきます。
想定しうる全てのパターンを加味した要件を定義していければ良いのだと思います。

要件定義はプロジェクトの序盤にするものです。

ですので、序盤がとても重要ということになります。

2.甘い関係者の洗い出し

「これは、あの部署には直接関係ないから言わなくて良いっか？」

こう思いこんで、進めてしまうと命取りです。

自分たちで決めてしまうのではなく、
相手に決めてもらうことが重要です。

先ほども書いた通り、ダブりがあったって良いのです。

とにかく、関係ないと思ったとしても巻き込んでしまうことが重要です。

その上で、「僕たちこれ関係ないので、大丈夫っすよ」この一言だけもらえれば大丈夫なのです。

プロジェクトを進める上で、一番良くないのは
「僕たち、これ聞いてなかったんですけど」
これは、デスマの要因にしかなりません。

なぜ、デスマになるかと言うと、
プロジェクトはそもそも有期限です。

ということは、終了日は定義されているものです。みんなでワイワイ集まって仕事することはプロジェクトではないです。

ですので、終了日は変えられないのが前提です。
フジロックフェスティバルがプロジェクトメンバーのミスで遅延はあり得ませんよね？
それと一緒で基本はズラす性質のものではありません。

終了日は決まってる。しかし、予期せぬ関係者への説明不足で進捗が止まる。後工程にしわ寄せが来るのは当然で、そうなるとデスマが発生するというわけです。

関係者の洗い出しについても、
社内・社外・社会という枠組みで捉えれば抜け漏れがなくなるのではないかと思います。

また、関係者の洗い出しもプロジェクトの序盤に済ましておくべきことなので
これまた、序盤が重要ということになります。

洗い出した関係者の中でも、意見の強い人をしっかりと押さえ、先に根回しし仲間につけておくことが重要です。

説得するのに苦労する人は、味方になった時はめちゃくちゃ強いカードに切り替わります。

3.甘い見積もり

言葉を見ただけでヤバい感じがしますね笑

これは、現場でのスキルや知識が足りていないプロジェクトリーダーが起こしがちです。

というのも、そもそも工程や作業といった現場感を持っていないので、そもそも上手く見積もることができません。

人に聞けば基本解決すると思うですが、
自分より目上の方にふいに聞かれた場合、即座に答えることが正だと思い込んだり、その場を取り繕おうとし、良く考えずに答えてしまうときに起きがちです。

これがデスマの入り口になります。

そうならないためには、
「正確に見積もれないので持ち帰らせてください。」と言えば良いと思います。

それでも、良いからとにかく感覚で良いから教えてくれと言われることもあるでしょう。

その際は正しくない見積もりであることを伝えてから一旦答えて、後で正しい見積もりを共有するようにすると良いでしょう。

まずは、しっかりと自分の目で現場を見ること。しっかりと現場感を身につけておくことが先決です。

そのあとは、とにかく見積もりに関しては、一旦ひと回りくらい大きく捉えることが重要です。

小さく見積もりそれが後で膨らむのは、自分の首を絞めるだけなので避けるべき行為だと思います。

ところが、どんなに正確に見積もったとしても想定外のことは起こってしまうと実績はズレてしまいます。それを極力、ズレないようにすることがプロジェクトリーダーとしての腕の見せ所でもあります。

現場を見たり経験したとしても、それでも現場で長く働いてる人には知識や経験で勝ることはできません。

その場合は周りの力を借りれば良いでしょうし、
経験が豊富にあったとしても自信がない場合はレビューをしてもらうなどすれば良いと思います。

現場感は持ってないにしても俯瞰する力は持っているはずですので、そこは強みとして生かすべきだと思います。

見積もりに関しても、基本的には序盤に発生する工程だと思いますので、

こちらも序盤が重要ということになります。

まとめ

プロジェクトを円滑に進めるのは、とても難しいです。
が故に、円滑に進められる人というのは価値があります。もし、プロジェクトリーダーに任命された時には、是非この記事を参考にしていただければと思います。

プロジェクトについては、これ以外にもKGIやKPIの設定や効果検証など重要なことはありますが、今回はプロジェクトでデスマを起こさないための序盤の大切さを話しました。

・要件は考え抜く
・関係者は全て洗い出す
・全工程を洗い出し正しく見積もる

これを実施する際に必要なこと。

MECEで考える

もれなくダブりありでも良い

デスマーチが少しでも減りますように。

最後までお読みいただきありがとうございました。

では、また。