炎上プロジェクトに見られる3つの共通点
わたしは、これまでのキャリアのほぼすべてを派遣先で過ごしています。もともと「火消し部隊」と呼ばれていた派遣先。運良くデスマーチは回避してきましたが、それでも問題のあるプロジェクト、俗にいう「炎上プロジェクト」のヘルプを行ったことがあります。
振り返って考えると、この「炎上プロジェクト」には、必ず共通する特徴がありました。ここでは、その3つの共通点を紹介します。
■♯1 うそをつく
うそをつく……いったい、プロジェクトにかかわる誰にメリットがあるのでしょうか？
わたしが長年お世話になっている顧客からの要請で、直接関係のないA事業部が外注したプロジェクトの手伝いを行うことになりました。作業に着手した時点（＝プレス・リリース前日）で、サーバがSIGSEGV（セグメンテーション違反シグナル）でダウンする状況でした。サーバのダウン状況を再現してほしいと依頼されたものの、サーバの実行形式ファイルは次々に更新。再現できるはずもなく、結局、何の役にも立てずに引き上げることになりました。
このプロジェクトの手伝いを行う前にA事業部から状況を聞かされていたのですが、丸投げした下請けの（うその）進ちょく報告を信じて、外注先がA事業部に対して「来週には完成します」と報告し続けていたようです。報告を疑ってA事業部が外注先に乗り込んだときには手遅れで、結局、プレス・リリース前日になってもろくにサービスを提供できない状況になってしまったようです。
わたしは早々に引き上げましたが、他の技術者の努力で無事サービスインできたようです。
■♯2 増員の受け入れに時間がかかる
手伝いに行くのは構わないのですが、大抵「作業環境が準備できていない」とか「忙しいから」と手伝いに来た増員を待たせます。いったい何のために呼び出したのか……
あるとき、顧客のソリューション製品を採用してもらった経緯があり、B事業部のプロジェクトへ手伝いに行きました。3稼働日（5日）後に製品のプレス・リリースを控えており、即、作業に着手できると想定していたのです。しかし、まずは3時間の放置プレイ。やっと不具合対応に着手できると思いきや、今度は彼らが製造しているシステムの素晴らしさの説明が始まります。さすがに業を煮やしたわたしは説明をやめさせ、発生した不具合の状況と作業手順を確認しました。
休憩時間中に顧客から進ちょく状況を尋ねられたので、ありのままを報告したところ、顧客責任者がB事業部に乗り込み、顧客とB事業部の大ゲンカに発展してしまいました。わたしが作業場所に到着してから8時間、このうち実際に作業できたのは、たった2時間でした。
帰り間際、プロジェクト責任者に「君は徹夜や休出はできるのか？」と尋ねられました。「契約上、派遣先の責任者の指示が必要です」と逃げました……。そんなこと尋ねるよりまず、作業場所に到着した時点から作業をさせろ（怒）。
B事業部では、この不具合は3日あっても解消できないと大騒ぎしていましたが、結局、1.5日で完了でき、無事プレスリリースに間に合いました。
プロジェクトが炎上し始めると、プロジェクト・リーダーは、対処方法などを決めかねていて作業量を見積もることができなくても、とにかく人員を補給したがりますが、確保した人員を効率的に作業をさせる環境ができていないことが多いです。
■♯3 責任を転嫁する
どんな状況下でも保身を図ることに注力する人がいます。そんな状況ではないことは、その人自身も十分に承知しているはずなのですが……
顧客とB事業部との間で喧嘩が勃発した、プロジェクトでの（上記の）不具合。顧客が提供したフレームワーク（わたしが実装しました）の仕様に従ってB事業部がメタデータを作成していないことに起因していました。もちろん、仕様が変更になるたびに顧客担当者がB事業部へ出向き、説明していたはずなのです。
しかしながら、B事業部は一貫して「いままで動いていたのに動かなくなったのはお前たちのせいだ」と主張しました。挙句、問題解決が進まない状況を指摘した顧客に対して「非協力的な奴は出て行け！！」とわめき散らしました。
彼らはようやく始まったデバッグ作業にも消極的で「俺たちは被害者だ」オーラ全開。わたしとペアプログラミングを行っていたB事業部の社員は、「面倒くさいなぁ、（この作業を）代わってくれない？」と、わたしにあてつけるように近くを通りかかった同僚に話しかけます。
メタデータの修正作業のほとんどがテキスト置換なので、正規表現によるテキスト置換機能をもつテキストエディタの使用を提案しましたが、かたくなにメモ帳（Notepad.exe）で作業していました。このときばかりは sedコマンドの便利さを痛感させられました。
■おわりに……
派遣先では、これまでに例示した（＝わたしが経験した）プロジェクトよりもひどいプロジェクトの支援を行っていました。おかげで、問題プロジェクトの状況を自分なりに分析したり、支援活動を行う技術者から話を聞くための貴重な機会を得ることができました。
プロジェクトが炎上するきっかけは何でしょうか。うそをついたり、隠し事をしたり、ごまかしたり……プロジェクト・マネージャやプロジェクト・リーダーの不誠実な行動が原因となることが多いようです。何が彼らにそのような行動にかきたてるのか……わたしには分かりません。しかし、プロジェクトを運営する立場にある技術者はいつでも誠実でいられるように心がけるべきだと思います。
わたしはいま、担当するプロジェクトにおいて誠実でいることができているのだろうか……。