「これがデスマーチか！」
今になって現状が自分の知っているキーワードと紐づいた。散々今まで仕事がつまらないだの退屈だの抜かしていたが、SEという職種の厳しさや恐ろしさを最近になって気づいた、というのが正直なところだ。
「デスマーチ」という言葉を知らないエンジニアはおそらくいないはずだ。直訳すれば「死の行進」、端的に言うと、毎日終電帰り、週末出社しているにも関わらず一向に明るい兆しが見えない状況のことを言う。3Kだの7Kだの言われている職業であるSEによく起こる事象だ。
単純にすごく忙しい、というだけでなく、たくさん働いても一向に楽にならない、課題が増えていくばかり、というのが辛い点だ。私などは言ってもまだ3ヶ月にも満たないが、こんな働き方を2年近く続けている人たちは狂っているとしか言いようがない。そうは思いません？
私がこのまま今のプロジェクトを続けていくのが一番嫌なのは、こんな狂った価値観で働いている人たちで構成されたチームの中で働く、という点なのかもしれない。仕事自体の面白さなんかは二の次で、もう少し正常な働き方ができるようにまず動いて欲しいと切に願う。（が、先ほども述べたように実際にはほとんどのプロジェクトで当たり前のように起こっている問題だというのだから日本人はやはり狂っている。）
そもそもなぜこんな状況になってしまうのか。なぜデスマーチは生まれるのか。少し分析してみよう。
シンプルに考えれば、何かを成し遂げる上で失敗する理由は二つしかない。①計画が悪い、②計画通りに実行できない、これだけだ。正しい計画を立てて計画の通りに実行できれば必ず成功するのだから。
例えば、「カップラーメンを3分で作る」という計画を立てれば必ず失敗する。なぜなら、ふたを剥がしたり、お湯を注いでいる時間を含めると3分には収まらないからだ。これは計画が悪い例。逆に、「カップラーメンを4分で作る」という現実的な計画を立てたとしても、かやくや液体スープを開けるのに時間がかかってしまうと達成できない場合もある。
カップラーメンを作るという実に簡単な作業の場合でも時間通りに何かを達成するというのは困難なことなのだから、正しい計画を立てその通りに実行する、なんてことができれば誰も苦労はしない。ほとんどの場合は、未知の作業計画を正しくなんて立てられないし、計画通りに実行することもできない。だから計画は変わるし、残業が必要になったりするわけ。
では間違った計画とは何か？基本的には次の二つしかない。
①作業に漏れがある
②作業にかかる工数（時間）が誤っている
シンプルに考えればプロジェクト達成のための総労働時間は「全てのタスク（作業）にかかる工数の総和」で決まる。だからMECEに考えると、作業が足りないのか、工数が間違っているのか、この二つだけ。
強いてあげるなら、もう一つ。
③作業の順序性が誤っている
これは本質的には問題ではないが、柔軟に雇用を確保するのが難く、連続的な要員計画を立てる前提が一般的なので、人が沢山いる時に仕事ができないような順序性の組み方をしてしまうと、致命的となる。
ただ、私が最も計画で問題だと思っているのは「作業の漏れ」ではないかと思っている。というのも、どんなプロジェクトでも必ず計画から漏れている作業項目があるからだ。
それは何を隠そう、コミュニケーションコスト、である。おそらく、もっともコストのかかるものでも1回1時間ぐらいなので軽視されがちなのだろうが、頻度で考えた時のトータルコストは全くもってバカにならない。小規模チームであれば、バッファで吸収可能かもしれないが、大規模になると、途端に膨れ上がる。
チームやステークホルダーの数を考慮した会議体・時間・頻度、そして、想定されるメールの件数なども本来であれば考慮すべきだ。さらに増員に伴う教育稼働や学習稼働、逆に減員に伴う引き継ぎ用稼働もちゃんと想定しておくべきである。
初めからプロジェクトにいないメンバの場合、どんなに優秀であろうが、現状や前提条件を把握するために時間が必要だし、ナレッジトランスファーする人の稼働だってかかる。この辺を「よろしくやってくれるだろう」とか考えているPMはバカとしか言いようがない。
が、PMだってバカではない。そんなことはおそらく理解しているはずだ。にも関わらず、現実問題この辺の話が計画に組み込まれることはないのだ。なぜかって？そんなに馬鹿正直に工数を積むと、金額が跳ね上がって売れなくなるから。つまり、問題の本質は「計画をどう間違ったか」ではなく「計画をなぜ間違ったか」にあったのだ。
で、結論から言うと、正しい計画を立てて進めることは99%不可能なのだ。SIerはお客さんに承諾される金額に収まるような費用を提示しなければならない都合上、費用から単金を割った分の工数しかあたえられない制約の中でやりきるしかない、という現実がある。
だから、無事受注しプロジェクト開始が決まった途端、実行でカバーするしかない運命にあるのだ。しかし、実行の中にこそ本当の難しさがあるのだが。。。
その辺は次回に記載するとしよう。
