絵に描いたようなSI炎上案件ですね。
僕も長らくシステム開発業界に漬かっていますので、身につまされる思いです。
自分の拙い経験から、行間からあふれる業界の闇を勝手に解説したいと思います。
営業主導で案件が決まる
30%OFFの激安システムなんですが、設計からリリースまでちゃんとしてくれとのこと。リリース日時は死守しろっていうからがんばりましたよ？でも人を増やしても増やしても終わらない工程。あれ？30%OFFしたのに、人件費で赤字になっちゃったよ？おかしいな？
まず、受託開発の見積もりというのは、基準があってないようなもので「この感じだとこのくらいかな？」という、画面数などを元に、ほぼ勘で出します。
あってないようなものですが、それを元に「人数×期間」が算出されるため、「このぐらいの体制ならなんとかリリースまで持っていけそう」というラインを決めるので、現場にしてみると結構重要だったりします。
それを30%OFFするということは、普通の製品であれば「人数×期間」は、変わらないわけですが、SI案件の場合、期間はそのままで、人数だけ30%OFFされます(!?)。
ここにトリックがあるわけですが、普通1万円のものを30%OFFにしたら、同じものを7000円で売るわけですが、SI案件の場合、7000円分売るわけです。
詐欺ですよね。
そういう意味で、「あってなきようなもの」なのですが、「ないようであるもの」でもあるので、やっぱり人員を3割削られるとキツイわけです。
客は、1万円の買い物を7000円で買ったと思っているのに、売り手(会社＆営業)は、7000円の物を売ったとしか思っていないわけです。
その差額の3000円は、「現場が頑張る」事によってなんとかなると思っています。
プロジェクトとしては、最悪の滑り出しですね。
人を増やしても増やしても終わらない工程
詳しく言及されていませんが、「なぜ？人を増やしているのか？」というと、「終わらないから」です。
なぜ終わらないかというと、開発規模に対して人員が足りないからです。
普通にプロジェクトのスケジュールが遅れるため、客から詰められます。
その時に、SIerは、何故か割りと簡単に「増員します」と人を増やします。
「だったら最初からケチらず人員配備しろよ！」と言いたいところですが、この最初のケチりと炎上してからの太っ腹は、一昔前のSI会社の特徴です。何故か「炎上！→増員」という決裁は光の速さで降りるようです。不思議ですね。
そして、「増やして増やす」ことになるのは何故かと言うと、炎上している所に増員すると、余計遅れるからです。
スケジュールが押している中で、新たに配備された人員のために、教育コストが取られ、タスクの再配分コストが取られ、人員管理コストが取られるわけです。
まさに地獄です。
これが、当時の「典型的な」炎上プロジェクトの滑り出しとなります。
顧客のコントロール
「それ対応したら私、死んじゃうかもしれませんね～。ハハハ～（乾いた笑い）」
そしたらびっくりですよ。お客様ったら、
「それでも構いませんのでお願いします。」
ここまで、顧客との間の信頼関係が崩れる例を僕は体験したことがありませんが、プロジェクトの進行をしくじると、顧客からかなり辛辣な態度をとられることがあります。
ひとえに信頼関係なのですが、典型的なダメなSIでは、内外に対する仕事の進め方が崩壊しているため、客から呆れられ、そのうち汚物を見るような視線で見下されることになります。(^^;
こういうことは、最初が肝心なので、「はじめの一歩」で先ほどのように、「1万円です」といって実質7000円の物を売るところから、スタートしているので、客との話もいきなり食い違うわけです。
その後、SI側がグダグダしているうちに、客側も「発注範囲の境界線」が不明確になり、
「やっぱ変えて。」
というようなことをカジュアルに要求するようになります。
プロジェクトというのは、本来、顧客を管理する必要があります。
SIerは、システム開発のプロなので、システム開発に必要な段取りを数々の経験からお客様が迷うことないように先回りして準備して差し上げて、プロジェクトが遅滞なく進むようにコントロールする必要があるのです。
しかし、ほとんどのSIerには、この思想がありません。
本来システム開発のプロであるはずのSIerが、システム開発の素人である顧客会社に、下駄を預けきっています。
こうして、顧客→SIerという主従関係が発生するのです。
更に言うと、日本のSI業界では、その状態が数十年に渡り続いており、完全に定常化しているところもあります。
ユーザー企業の担当者も過去に何回も煮え湯を飲まされてきている可能性もあり、「SEなんでゴミだ」と思われていることもあるかもしれません。
そういった歴史のあった上で、
「それでも構いませんのでお願いします。」
こういう発言に繋がることは、無くはないかもしれないなと思います。(^^;
プロジェクトマネジメントと品質管理
急いで作業したもんで、案の定、いっぱい間違えましたよ。バグが大漁ですよ。バグは1匹見つけたら30匹いるって言いますしね。そしたらまあでっかいバグがいたんですよ。データを破壊しちゃうやつ。
受注の時点で、典型的な炎上案件として滑りだし、顧客との信頼関係も崩壊した状態で、人員だけじゃんじゃん増員するような案件なので、こうなることも当然といえます。
それでも、前進することができただけ、かなり恵まれていたのだと思います。
最悪の場合、こじれきって上層部での話し合いが始まり、現場が何故か段々暇になって、プロジェクトが空中分解し、訴訟沙汰になるというルートへのフラグが立ちますので。(^^;
まあ、現場としてはそのほうが楽なので、変にリリース出来てしまったほうが、苦しみが大きいという。(^^;;;
それはともかく、開発中にスコープマネジメントができていないと、そもそもほぼ不可能なのですが、リリース時のアセスメント(顧客の評価・受け入れ)プロセスは大事です。
テスト計画や、評価基準を定めて、バグの収束率を取り、品質管理を行う必要があります。
ただし、ここまでの経緯で完全にこじれてしまうと、各工程(設計・製造・テスト)は、スケジュールが押しまくっているはずです。
SI用語(?)で、スケジュールが「刺し身状になる」とか「五月雨」とか言いますが、段々前工程が終わる前に次工程の開始スケジュールが重なってきます。
そうすると、実質的にテスト期間にどんどんしわ寄せが来るので、品質が崩壊するわけです。
- 体制の崩壊
- 顧客との信頼関係の崩壊
- スケジュールの崩壊
- テスト工程の崩壊
- 品質の崩壊
完全に数え役満ですね。
「炎上案件」という題をつけて博物館に飾りたいぐらいです。
この後どうなるの？
炎上案件のその後ですが、だいたい以下の様なことが起こります。
- 現場の人員は何人か鬱になる
- 価格交渉・訴訟
- 会社は何故か儲かる
この話は今では楽しかった思い出になっています。私の中では。仕事は大変だったけど、みんなで一緒に乗り越えた！という達成感がすごかったです。すごく良いチームでした。今でもこの同僚たちとは仲良しで、飲み会をやってます。
炎上案件は、実は結構楽しいです。
僕も、いくつか経験していますが、やってる当時は辛かったかもしれませんが、後日思い出すと楽しい思い出に変わっていたりすので、人間て不思議です。
しかし、気をつけなければいけないのが、燃え尽き症候群で、酷いと鬱になります。
案件中は、テンションも高いのでいくら頑張っても平気だったりするのですが、そのツケは案件終了後、次の案件までにちょっと暇になるタイミングに襲ってきます。
猛烈な喪失感と虚脱感が襲ってきて、体調を崩します。
デスマーチロスが発生するわけです。
そして、担当者レベルがロスに陥っている傍ら、会社はイソイソと価格交渉に入ります。
プロジェクト中、大盤振る舞いした人員を積算して、「xxx万円の赤字が出たから、折半して欲しい」という交渉を始めるわけです。
プロジェクト中スコープ管理なんて全くしていなかったのを棚に上げ、「遅れたのは、仕様変更が一杯あったからです」とボッタクリバーの如く、あとからオプション価格を請求し始めるわけです。
確実に成功するわけではないですが、大概の会社は、「まあお互い頑張ったし仕方ないよね」みたいな、コンセンサスが発生し、お金を払います。
そして、ここにもSIerのトリックがあるのですが、SIerが積み上げる人件費は、「売値」なため、元々結構な額のマージンが乗っています。
最上位のSIerであれば、100%増しが普通です。つまり、粗利率50%なので、「赤字分を折半」したとしても、原価としては元が取れるわけです。
更に、リリース後は、運用保守が発生し、何人かのSEが常駐したりするものですが、この費用も定価でもらうわけです。
こちらは、SIほど大きな金額にはなりませんが、5年10年と続く可能性があるため、トータルでは、開発費用と同じかそれ以上になるという寸法です。
大人って、汚いですね。(^^;
まあ、最近は大規模なSI案件というのは減っていますし、不人気すぎて人が集まらなくなっているし、ブラック体質を改善する動きが社会的に大きくなってきているので、今後はこのような炎上案件にお目にかかることも少なくなると思います。
大方の案件では、炎上していても、末端の作業員は定時か、1,2時間の残業で帰れる感じですし、SEを擦り切れるまで使ってプロジェクトをすすめる事も、SIer側も顧客側もしなくなりました。
これを見てIT業界(SI業界)を目指す人がいるとは思いませんが、年寄りの昔ばなしだと思って聞いてもらうぐらいの温度感が丁度よいかもしれません。
