ここは地獄か戦場か？火を噴くプロジェクト　悦楽編

前回ご好評をいただきました「ここは地獄か戦場か？　火を噴くプロジェクト　死闘編」。その続編として「悦楽編」をご紹介します。火が噴いたとはいえ、そこはやはりエンジニア。渦中に何かしらの楽しみを見つけているものです。そんなものあるかって？　8割の人が「一応はある」と答えているのです。

（取材・文／総研スタッフ　高橋マサシ　イラスト／CLAP）　作成日:07.01.10

　前回と同様、300人のSEに質問した「最悪だった火を噴くプロジェクト」の回答です。ただ今回は、「その中での楽しみ」にフォーカスしました。こじつけに思われるかもしれませんが、皆さんは地獄の中で一条の光を求めているのです。でしょ？

某通信社の電話帳関連システムを開発。私は入社4年目で、課長の下で20人程度をまとめるサブリーダーだった。当社の受注はプログラム開発だけであり、仕様書や開発環境は顧客側が用意するとの契約。それが参入時点で、仕様書もその開発環境下での開発実績もなく、結局は仕様書から作成。開発は遅れに遅れた。

業種：ソフトハウス　職種：汎用機系SE（30歳）　PJ規模：12カ月／1000人月

メンバーの月労働時間が400時間を超え、1カ月に1日も休みがなく、終電で帰ろうとすると「そんなに早く帰られては困る」と言われるような状況。仕様書を作成しようにもまだ基本設計が固まっておらず、変更が度々発生し、仕様書の作成もプログラムの作成も修正のために全く進まなかった。

開発メンバーの結束が固まる。そのうち崩壊するが、プロジェクトが終了した後でも仲良くなる人がいる。

某メーカーの携帯電話の新機能開発で、指定された海外企業の音声エンジンを搭載。要件定義からシステムテストまでの全工程を実施した。私のチームは問題なく工程を進んだが、ほかのチームでの問題が収束せず、プロジェクトが火を噴いたころからサブリーダーとして入った。

業種：通信系企業　職種：制御系SE（38歳）　PJ規模：9カ月／180人月

参加当時から後々火を噴く可能性があると指摘したが、プロジェクトの責任者はどうにかなるだろうとの楽観視。結局は技術的な難易度や海外とのやり取りがうまくいかず、徹夜の連続でも進捗は全く進まない状況で火を噴いた。プロジェクトリーダーは解任されて私が代わりに。迫る納期に対して携帯電話会社の突き上げが厳しく、工数確保のための徹夜作業はプロジェクト完了まで続いたが、最終的には納期に間に合ってプロジェクトは完了した。

夜中にメンバーとともに食べるカップラーメン。

海外向け携帯電話システム大手の携帯電話の初海外向け製品で、ある機能のサブリーダーとして参加。アメリカ向けだったため、日本の開発部隊とアメリカの常駐部隊で、時差で効率よく作業開始したはずだったが、始まった段階で4カ月遅延。アメリカ部隊は労働時間規制が厳しいために現地時間の9時から19時まで作業し、日本部隊は日本時間＋アメリカ時間で作業を進めた。

業種：ソフトハウス　職種：制御系SE（34歳）　PJ規模：10カ月／50人月

日本にいた私は、土・日なしで朝9時から次の日の朝6時まで作業をほぼ毎日続け、残業は毎月200時間以上となった。協力会社のメンバーは出社拒否、行方不明、裁判ざたにもなったが、開発費が底をついたために途中でメンバーが削減された。最終的に2カ月遅れで納品し、それなりの評価を受けた製品となった。しかし、会社から表彰され特別ボーナスをもらったのは、営業だけだった！

生き残ったメンバーと団結力が増す。

某企業の造船工場で、造船の溶接を自動化するシステムを作成。ロボットとソフトの制御、ユーザーインタフェース部分を担当するプログラマとして参加。もともと某企業の副社長の一存で受注した案件であり、開発期間も予算も練られてなかった。ある程度開発したものを某県の造船工場へ持って行き、そこでロボットとの擦り合わせ作業を行うようなものだった。

業種：ソフトハウス　職種：制御系SE（34歳）　PJ規模：24カ月／15人月

当初は日帰りで作業を行う予定で現地へ行ったが、最終的には足掛け3年ほど張りつくことになった。毎日夜の12時ごろまで仕事が続き、完成するめどが立たないまま膨大な経費が掛かり続けた。私は一度黙って逃げ出したが、後に説得されて現場に戻った。最終的にはなんとか動作可能なものができたが、結局は数億円の赤字が発生し、最終的には意地で納めたものだった。

膨大な時間外手当、出張手当、宿泊手当などで、毎月ボーナスのようだった。

某アミューズメント系企業の基幹システム構築のプロジェクトにて、要件定義から運用までの工程を一貫して請け負うシステム開発だった。私はリーダー的な役割。

業種：SI企業　職種：Web・オープン系SE（30歳）　PJ規模：14カ月／60人月

テスト工程に入っても仕様が確定せず、上から仕様変更が降ってくる状態。そんな状況でテストしても意味があるはずもなく、現場の士気は最悪で、チームメンバーは皆、さっさと火を噴いてプロジェクトが頓挫することを願うありさまだった。

残業代で収入が増えるので楽しみ。

某社の機械の制御システムを受注した。私はメンバーで入ったが、規模が大きいことと、機械の仕様がなかなか決まらなかったことで開発期間が延びた。そして、リリース前に重要な改修が頻発した。

業種：メーカー・ベンダー　職種：汎用機系SE（31歳）　PJ規模：37カ月／3000人月

プロジェクト発足後から、機械の設計に振り回されながら制御システムを開発。仕様未決定の部分が多く、制御系から機械の設計の逆提案をする羽目になる。しばらくして問題が発覚し、機械と制御システムの両方に大幅な仕様変更が発生した。結局は2週間泊まり込み＆徹夜作業となった。

給料明細の残業欄。

転職後の初仕事で顧客管理システムに携わったが、チームメンバーに開発言語のスキルをもっている人がおらず、22歳でほぼ新人の私がいきなりリーダーをさせられた。メンバーはすべて年上でコミュニケーションすら取れず、当然うまくいくはずもない。プログラムの精度も悪かった。

業種：メーカー・ベンダー　職種：Web・オープン系SE（31歳）　PJ規模：9カ月／5人月

言語知識はないがエース級の人がいたが、開始早々にほかのプロジェクトと掛け持ちで戦力外に。私はほかの新人と開発を進めたが、簡単なプログラムすら完成させられない。自分の開発そっちのけで新人教育を進めたため、自分の開発に充てる工数が定時後となり、毎日夜中4時ごろまで仕事をしていた。その後、メインの部分はほかのベンダーが手直しをし、バッチ処理系と帳票系の担当になったが、ほかのメンバーは使い物にならないと客先に言われ、無償で6カ月間、客先で毎日夜中まで張りついた。

火を噴いたにせよやはり完成までこぎ着けたとき。

某銀行の某協会ネットへの接続システムを構築した。ほかのベンダーがGWを構築し、当社が基幹系のプログラム開発とテストを実施した。開発側は私と同レベルのリーダーがまとめ、私はそのテストのまとめを対応した。銀行にとって必須かつ重要なプロジェクトのせいか、銀行の人たちはスキルが少ないのに理想は高く、仕様はなかなか決定せずにあいまい。当然ながら変更が多くなった。

業種：メーカー・ベンダー　職種：Web・オープン系SE（35歳）　PJ規模：6カ月／100人月

開発後半にはほとんどの者が電車の時間を見ながらの残業となり、判断力と思考能力を失いながらの進捗。仕様が頻繁に変わるので、テスト時期になると多くの不良が出て、仕様見直し、プログラム修正、見直しと、ほかのプロジェクトの人も引きずり込んでの対応となった。システムリリース時も不良が発生して徹夜の泊まり込み対応。次の段階の開発が少しずつ始まると、顧客や上長から「また同じことをするのでは？」という目で見られ、弱い立場での進捗を引きずっていった。

無事リリースできたとき。うまく稼働したとき。

ソフト開発のプロジェクトにメンバーで入ったが、ほかのメンバーは2人だけ。この人数では、どんなに頑張っても納期を守るのは無理だった。しかも、徹夜で作ったものが仕様の変更で中止となることが多く、開発中止は仕事として認められないので客先からは低い評価となった。

業種：ソフトハウス　職種：汎用機系SE（31歳）　PJ規模：5カ月／3人月

平日の終電帰りと土・日出勤で体を壊し、医者から入院を勧められた。プロジェクトリーダーに掛け合ってみたが、「残業のできない人間はいらない」と言われてチームから外された。そのときの体の状態がもとで数カ月後に医者からドクターストップが掛かり、やむなく職場を退職した。

プロジェクトをやり遂げたときだと思うが、体を壊してチームから外れたりとなかなか見届けられることが少ない。

回答は「ない」がいちばん多くて66人だが全体の22％にすぎず、残りの約8割の人は何らかの「楽しみ」を答えてくれた。その中で最も多かったのが「達成感」。次が「仲間との一体感」で、「終了後の打ち上げ」などもここに含めた。「残業代」というエンジニアも多かったが、「残業代が出ない（上限がある）ので楽しみはない」という返答も少なからずあった。

　やっぱり、火を噴くプロジェクト。「楽しみは何ですか？」と聞かれて、まともに答える人ばかりではない。そして、そんな彼らに罪はない。ここではちょっと変わった「愉しみ方」を紹介します。ひょっとしたら同じ思いをしている人がいるかもしれません。

　火を噴いていちばん困るのはだれか？　4択で答えてもらった結果が以下のグラフです。「それは現場のメンバーだろ」という結果ですが、ちょっと複雑なんです。だって、答えている人はメンバー、リーダー、プロマネの3人なのですから。

　アンケートでは本人の職種をメンバー、リーダー、プロマネの3つで聞いています。「プロジェクトに入るときにいちばん多い立場」というわけです。ですから、全員が「本当に大変なのは俺だ」と思えば、三者の割合がそのまま結果となるわけです。ちなみにその割合はメンバー41％、リーダー47.3％、プロマネ8.7％、その他3％で、実はリーダーがいちばん多いのです。
　それがなぜ、全体的には「メンバーが困る」になっているのか。小さなグラフを見てもらえればわかりますが、メンバーの多くが「自分が困る」と答えているのに対して、リーダーとプロマネの多くは「自分でなくメンバーが困る」と答えているのです。

　しかもよく見ると、リーダーは「自分」と答えた人が最も少なく、「顧客」と答えた人が最も多い。一方のプロマネは、「リーダー」と答えた人がゼロで、「顧客」はメンバーと同数。大ざっぱにいえば、メンバーは多少自己中心的で、リーダーは現場と顧客の大切さを考え、プロマネは現場を心配しつつもリーダーへの配慮なし、となります。プロジェクトに真摯に向き合っているのは、中間管理職的な役割のリーダー職なのかもしれません。
　これで終わります。今年は皆さんのプロジェクトが火を噴くことのないように、Ｔｅｃｈ総研を代表してお祈りいたします！

	Ｔｅｃｈ総研ブログピンク少佐の秘密工作室
「火を噴くプロジェクト　死闘編」に寄せられたエンジニアの方々の声です！

あなたを求める企業がある！

まずはリクナビNEXTの「スカウト」でチャンスを掴もう！

高橋マサシ(総研スタッフ)からのメッセージ

さすがはエンジニアです。どんなにつらく苦しいプロジェクトの中にでも、一筋の光を得ているものですね。とはいえ、ここには出すことははばかられた悲惨すぎる例もあり、決して笑い事ではすみません。私の友人のベテランSEは、「この道20年だけど、火を噴かなかったプロジェクトってなかったと思う」と言います。やっぱり変ですよね？