もはやプロジェクト炎上を防ぐ手段は無い

ＩＴ業界にいると、プロジェクトが「炎上」するという言葉をよく耳にする。納期が迫っているもののシステムを納品する目処が立たず、ＳＥやプログラマが徹夜も厭わず過酷な状況で働き続けなくてはならない状態。僕はそれをプロジェクトの炎上だと理解している。これをさらに突き進めたのが「デスマーチ」で、デスマーチはその「炎上」状態が日常的に続いてしまう様な職場環境を表すものだと考えている。

ソフトウェア産業において、デスマーチとは、長時間の残業・徹夜・頻繁な休日出勤といった、プロジェクトメンバーに極端な負荷を強い、しかも成功の可能性が薄いプロジェクトを主に指す。プロジェクトが死に向かって過酷な状況でメンバーが行進する、という意味で「デスマーチ」と呼ばれる。メンバーに心身ともに強い負担が生じるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、最悪の場合には過労死、自殺に至る危険性を孕んでいる。その発生要因はプロジェクトに対するマネジメント（プロジェクトマネジメント）が不適切であることとされている。―Wikipedia

さて、うちの部署では来年の春辺りにプロジェクトが「炎上」しそうだ。分かっているなら対策を取れよ、と思われそうだが、そうもいかないのが現実だ。
そもそも炎上だとかデスマーチだとか言うと、プログラミングを行っている会社を想像してしまいがちなのだが、僕が働いている部署では、プログラミングなどは行わない。と言うか、「ＩＴ企業」である事に間違いは無いのだが、あまりアプリケーションの開発などは行わず、もう少し違うところで仕事をしている。だから、ＳＥという職種柄忙しい事は忙しいのだけれど、そんな中でも結構皆さんまったりと仕事をしている。死人が出るとかそんな環境とは無縁の、人に優しい職場だ。
そんな部署で、なぜプロジェクトが炎上するのか。今までは言葉を耳にするだけだった「炎上」という状態がどうして生まれるのかということを、今日余りにも簡単に理解してしまった。と言うか、なぜこんな事に気が付かなかった(もしくは見て、聞かなかったのか)のかと、自分の思考の浅さに久しぶりに驚愕した。

僕が今まで考えていたプロジェクト炎上の原因はこうだ。

• プロジェクトマネージャの力量不足
• 各プロジェクトメンバーのスキル不足
• 初めから成功の見込みが無い納期

「炎上」と聞くと、僕はＰＭの力量やＰＪメンバーのスキルに依る所がほとんど、もしくは全てだと思っていた。実際に、設計・構築段階でＰＭがきちんと要件定義をしていなかったせいで、開発やテスト行程にしわ寄せが来て、プロジェクトが失敗に終わってしまうことがとても多いと、集合研修でも習ったものだ。また、ＰＪメンバーのスキル差がある場合も、それぞれの要件が納期に間に合わずにスケジュールがずれ込んでゆき、デスマーチを強いても納期に間に合わなかった事例などは、過去多くあったはずである。
結局、プロジェクトを炎上させているのはＰＭ、ＰＬ、ＰＪメンバーの力量不足に依るものが多いのであって、しっかりと先を見越して要件定義を行い、スケジュールを組み、各メンバーのスキルを把握しておけば、プロジェクトは無事成功するのものなのである。僕は今までずっとそう思っていた。

確かに今挙げたような属人的なスキルは、プロジェクト炎上の一つの要因であることは間違いない。しかし、現実問題として来年春に炎上しようとしている我が部署のプロジェクト。その唯一つの原因は、各人のスキルがどうだとかそれ以前の、何とも簡単な事だったのである。つまりそれは、商談を獲得していく際にどうしても生まれてしまう納期の重なりである。これこそが、避けようとも避けることの出来ない、プロジェクト炎上の原因であった。
要するに、クライアントが要求している納期が偶然にも同じ時期に重なってしまっていたのだ。大きなプロジェクトであっても、しっかりと人数を確保して回していれば、少しくらい納期が重なっても問題は無い。しかし、今回は偶然にも通常よりも多くのプロジェクトがほぼ同時期に納期を迎えることになっており、まだ１０月の段階にも関わらず来年春のプロジェクトに炎上が予見できてしまうのだ。これはもはや誰の責任でもない。ＰＭの責任でも無ければ、必死に商談を獲得してきた営業の責任でもない。プロジェクトの炎上は、完全に個々のクライアントの都合に委ねられている。

ここで、納期が重なったとしても、その時期までにまだ時間的余裕があるならば、対策を練って準備を万全にしておけば問題ないのではないかという疑問が生まれる。例えば、今年中に納品するシステムは０であるが、年明けが納期となるシステムが５個あったとする。それならば、年明け直後に急に忙しくなることのないように、年内中にしっかりと計画を策定し、直前にやらなければいけない仕事を極力減らしておけばよいのではないかということだ。
結論から言えば、これは机上の空論に過ぎない。ＩＴシステムというものはもはや業務システムと同義となってしまう場合が多く(マッキンゼー ITの本質 - THINK CIRCUIT)、システム構築過程において、想像以上にクライアント側の作業というものを要求することになる。そして、ＳＥがクライアントの要求に応えるためには、その一つ一つの作業を受けて、システムを設計・構築していく必要がある。つまり、プロジェクトの進捗はクライアントの作業度合いに依る部分がとても大きく、こちら側で納期が重なっているから作業を前もって推し進めておこうとしても、簡単に限界が見えてしまうのである。
このクライアントの作業に依存しているという点が、大規模なプロジェクトの進行を妨げかねない隠れた要因なのである。そしてその結果、我々ＳＩｅｒが複数のプロジェクトの進行を調整することが困難となり、プロジェクトの炎上という結果がかなり早い段階で予見できるという奇妙な構図が生まている訳である。

第3回 プロジェクト炎上を防ぐには：エンジニアのジレンマ ～悩む立ち位置と仲間の境界～｜gihyo.jp … 技術評論社
http://urasoku.blog106.fc2.com/blog-entry-243.html
http://ja.uncyclopedia.info/wiki/%E3%83%87%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%81
http://www.hyuki.com/yukiwiki/wiki.cgi?%a5%c7%a5%b9%a5%de%a1%bc%a5%c1%a4%ac%b5%af%a4%ad%a4%eb%cd%fd%cd%b3
なんでデスマーチが発生しちゃうのか…伝言ゲームの恐怖:らばQ
組み込み開発フォーラム - MONOist（モノイスト）
http://d.hatena.ne.jp/Kazzz/20070830/p2
http://d.hatena.ne.jp/tnet/20081206/1228582598
http://d.hatena.ne.jp/takihiro/20080204/1202135920

こんな事をのたまっていたら、先輩方にちげーよと言われそうだ。。。
まあいいや。再来週家を引越します。

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか