大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか

f:id:hisatsugu79:20160706154410p:plain

かるび（@karub_imalive)です。

この春までSI業界にいたので、たびたび大型システム開発案件の大規模炎上を見てきました。そして、ここ最近はみずほ銀行のシステム統合案件が厳しいようです。

2012年頃からスタートし、一昨年くらいからヤバイんじゃないの？と言われていた案件がどうも最終局面な感じになってきているようですね。

規模的に見ても、大きすぎて後戻りできないっぽいので、カネと時間がいくらかかっても最後までやりきるしかなさそう。しかし、みずほ社内オトシマエとしてたくさんの悲しい人事異動が発令されることでしょう・・・。（まぁ、今回はソースがまとめサイトやマイナー雑誌の抄訳なので、詳細については続報を見守りたいところですが・・・)

さて、プロジェクトの炎上にも色々ありますよね。大きい案件なら数千人規模から、小案件なら2～3人規模のプロジェクトまで、規模を選ばず、炎上するときは炎上するものです。

僕は、都内の中小SIerにて、最初はSEとして、次に営業・採用として、残念ながら炎上した案件に多数関わってきましたが。中でも、大規模プロジェクトでの炎上、デスマーチほどキツいものはなかったです。今日は、このエントリにて、なにがどうキツくて、どう対処すればよいのか、簡単に思うところを書いてみたいと思います。

１．大規模案件の炎上案件は、入場時から燃えかかっている
２．大規模案件のデスマーチはなぜ特につらくなるのか
３．プロジェクト終了後の退職者が続出する
４．唯一の対策は、大規模SI案件は燃えそうなら手を出さない
まとめ

１．大規模案件の炎上案件は、入場時から燃えかかっている

大規模案件であっても、プロジェクト序盤は、多くても100名程度の比較的少人数でスタートします。プロジェクトが増員され、一気に数百名～数千名体制になるのは、1次請やコンサル会社が要件定義・基本設計あたりまで完成させ、いざ開発工程に入ろうかとなるところからです。

開発工程で一気に工数を積んで、大規模化するわけです。順次、2次請、3次請、4次請・・・といった会社が、順次体制を作ってピラミッド状に集まってくる。つまり、現在のSI業界の最大の課題である、多重下請構造をそのまま体現したような体制になるわけです。図にすると、こんな感じ。

大規模システム開発体制図 f:id:hisatsugu79:20160706144319j:plain

そして、大規模案件で規模が拡大するのは、開発工程以降から。顧客とのシステム要件整理や基本設計の入り口くらいまでを１次請企業や、コンサル会社でやってから、開発工程全般を、いくつかのブロックに分けて２次請企業に発注します。さらに、2次請企業は3次請へ案件を切り出し、3次請は4次請へ・・・（以下繰り返し）3次、4次となってくると、プロジェクト現場へ人を派遣するイメージですね。

結果として、大規模システム開発案件にかかわる大半のメンバーは、開発工程以降を担当することになります。

しかし！

デスマーチが発生する案件は、前兆があります。開発工程が始まる前からすでに燃えかかっているんですよね。発注側と1次請にて最初に立てたスケジュール案が、はやくも微妙に遅れている。

本来なら、ここで仕切り直すチャンスです。開発に入る直前で、さっさとリスケして立て直せばいいんです。でも、積極的にはリスケされません。それは色々な大人の事情が絡みあうからです。

例えば、すでに株主総会等で投資計画が発表済みなので、経営陣はスケジュールを動かしたくない。また、リスケとなると予算追加＝コスト増から、発注者側にて誰かが責任を取らなければならない。誰も責任は取りたくない。・・・と言った事情から、遅れが出ていても、当初のマスタースケジュールのまんま下位工程で強引に挽回を図ろうとする力学が働きやすいのです。

２．大規模案件のデスマーチはなぜ特につらくなるのか

同じデスマーチでも、大規模案件と中小規模案件では、つらさの質が違います。個人的な経験からは、大規模案件のほうがより数倍キツかった。なぜなら、中小規模案件の場合は、自己への学び・コミュニケーション面でのやりやすさ・継続取引の可能性、といった面で、将来につながる可能性があるから。ちょっと簡単に対比表を作ってみました。

大規模案件と中小規模案件のデスマーチの違い f:id:hisatsugu79:20160706151342j:plain

中小規模案件は、自社案件だったり、お客さんと近い立ち位置で仕事をするため、案件が燃えた場合は、責任はキツいですが、全体像が見えている分、まだわかりやすいのです。何がダメでやり直しとなるのか、お客さんは何を望んでいるのか、どうリカバリーすればいいのか、比較的プロジェクト末端にいても把握しやすいです。

したがって、タスク量から残業・徹夜が発生するにしても、目的がハッキリし、ゴールがつかみやすいので、まだ何とか頑張れます。また、キツいですが、リカバリーで回したPDCAなどから、得られる経験は大きい場合もあります。

それに対して、大規模案件でデスマーチに突入した場合は、基本的に消耗するのみです。何が起こっているのか把握できないまま、方向感・目的感がない終わりなき残業に突入していきます。そして、立て直せないままバッドエンドまで一直線となるのが特徴です。

特に、大規模案件のデスマーチでの問題となる事項を挙げてみます。

2-1：物理的な作業環境が劣悪になっていく

大規模案件でデスマーチが発生すると、とにかく増員につぐ増員となるわけです。開発スペースがすぐに足りなくなります。しかし、1次請or発注元企業に、ゴージャスに新規開発スペースを借りる体力はすでに残っていません。

すると、既存の開発スペースに無理やり長机を持ち込んで、ぎゅうぎゅうで仕事をしたり、倉庫や使ってない汚い会議室に押し込められたりします。

また、往々にして駅から遠く、通いづらいところに行かされたりして、通勤がきつくなる。また、急造環境なので、ネット環境がなかったり、貸与されるPCがなくて、自前で機材持込、とかもよくあります。新浦安とか幕張とかお台場の奥の方とか、遠いしホント勘弁して欲しい

僕がこれまでに見た一番劣悪な環境は、営業として担当したT芝、某特◯庁案件の開発スペース。現場を訪問してみたら、部屋は汚いし、ボロボロの長机に、室内人口過多で、変な匂いがしていました。ネットは接続禁止。また、冷房が壊れ気味で部屋の中は夏でもないのに灼熱地獄。風邪を引いている人も多かったです。あれはヤバかった。すぐに撤退しました。

2-2：何の作業をしているのか全体像が見えない

大規模案件が炎上した場合、今現在担当している作業が、一体何のために行われているのかサッパリわからなくなることがあります。例えば、発注元→1次請→2次請→3次請→僕の会社（4次請）とかだと、情報が錯綜し、全体像も不明、目的も不明。多重請負の下の方だと、情報が落ちてこないので、リーダーすら把握していない事が多いです。何をやっているのか見えない時、非常に不安になります。

2-3：しかし、単純作業は山のように山積・・・

それでも大規模案件の厳しいところは、山のようにモジュールがあって、詳細設計書や単体テスト仕様書、エビデンスなども膨大な量があるということ。山のような単純作業をひたすらオーバーワークで１日中こなすのは、本当につらいです。1日中JUNITとか1日中コピー取りとか、いい年してなにやってるんだかと思いましたよ。

新入社員の時期ならまだしも、何年もキャリアを積んだ後でも、こういう前座修業的な単純作業は、学びにもならず「あー、何をやってるんだろうなぁ」と非常に焦りが出てきます。

2-4：そして、意味不明なやり直し

それでも、何とか割り当てられた工程を消化して、提出しますよね。「あー、おわったー」と安堵していたら、次の日には、上位工程での設計ミスや仕様変更が入り、もう一度また最初からやり直しが判明。大抵は、多重請負構造の中でのつまらないコミュニケーションミスや、人間関係の悪化から来るコミュニケーション不足が原因です。PMOとかがいても、炎上局面では機能せず、お構いなしにひっくり返りますから。

そして、先週１週間かけてひたすらシコシコ書いた詳細設計書が、全部ゴミ箱行きとなった時の徒労感。これは半端ないです。

現役時代は、よく、「あぁ、賽の河原のようだ・・・」と思っていましたが、こういう局面でモチベーションが一気にダウンしていきました。

３．プロジェクト終了後の退職者が続出する

そうはいっても、大規模案件のデスマーチは、たいてい突然の終わりを迎えます。全員のモチベーションが下がりきり、目が死んだ所で大抵は最終局面だったりするものです。やりきって終わり、ではなく、1次請が白旗を上げちゃったり、開発自体が中止・凍結になるんですよね。

しかし、エンジニアの心はこれで晴れるわけではなく、ここで精神的に痛手を負った人は「自分をプロジェクトに参画させた」会社側に不満が向いていきます。日本人エンジニアはおとなしく責任感が強い人が多いので、プロジェクト中はじっと我慢しますが、プロジェクト終了とともに、退職したり、あるいは転職活動を開始したりするケースが多々あります。

僕も、エンジニア→採用・営業となってからは、デスマーチ終了後に沢山の社員を残念ながら送り出してきました。