駒鳥です。
僕は前職が、いわゆるSE/SIer（システム・インテグレーター）でした。
正確にいうと、SE/SIerの下請け的に動いていたソフトハウスに勤めていて、下流工程、実際のプログラミングやテストの実施を行なっていました。
現在は自社でサービス展開をする会社で、おもにweb開発をしていて、労働環境に困ることはありません。
しかし、前職では、非常に闇が深い案件をいくつか経験していました。
【SIerの闇】SE/SIer時代に体験した、闇が深い案件、つらい案件３つをご紹介
ふとした機会に、今の会社の人たちに前職での体験を話すと、驚かれることが多く、
「こういうのよくあることだと思っていたけど、そうでもないんだな、、」
と感じます。
なので今回は、これらの経験を思い出しながら、かつての闇深案件を追想、体験談としてまとめていこうと思います。
こういう世界もあるんだな、、と感じていただければ幸いですが、SE/SIerで働くエンジニアのみなさんからしたら、あるあるなのかもしれません。
個人情報全部丸見え事件
とあるメーカー系のクライアント向けの、DBリプレース案件での話。
SE/SIerの仕事は、クライアントが社内の情報を外部に出すことを嫌って、客先常駐での作業になることが多いです。
このリプレース案件も、そのパターン。僕はクライアントのオフィスに席を借りる形、つまり客先常駐の業務でした。
もともとフルスクラッチで開発された取引管理用システムがあり、それをなんらかのCRMツールに移行したい、というのが案件の概要。
僕が担当になったのは、移行元DBを参照していた帳票系システム部分の移行。
そんなに難しい案件ではない予定だったのですが、、これがかなりつらい案件となることになっていくのです。
しかし、フルスクラッチで実装されていたテーブル構成と、パッケージとして提供されるCRMツールのDB構成は、全く違うものです。
帳票のためのSQLをひたすら書き直しては、出力されるデータに差分がないか、またレスポンスは問題ないかを確認していく作業でした。
当時SQLに苦手意識を感じていましたが、この案件を通してRDBへの理解が深まり、今も役立っている点では、この案件に感謝しています。
今ではデータマイニングエンジニア、なんて大層な肩書きが名刺にあるくらいです。
さて、書き直したSQLの出力結果が、移行元システムと同じかを確認する手段について。
確認方法として、新旧２つのSQL実行結果をExcelに貼り付け、差分チェックする、という方法を取っていました。
この作業、データをExcelに貼り付けているという手順が示す通り、SQLの実行結果が全部見えるわけなんですよね。
そのメーカーの取引の委細すべてが、目に見える、人に読める形でエクセルに貼られていたのです。
どこの店舗でどの商品が、いくつ売れたかという情報なら、まあいいわけです。
集計した数値ですからね。「へえ」くらいの感想にしかなりません。
問題は、そのメーカーの商品を購入したお客さんからのクレームや、返品返金対応に関するデータ群です。
購入した製品、購入した店舗の情報とあわせて、問い合わせたお客さんの住所氏名年齢電話番号、全部見えていました。
それを僕がExcelに貼り付けてエビデンスとしてクライアントに提出してたわけです。
一歩間違えればとんでもないことになります。
軽くクビが飛ぶところか、これ分かってて持ち出したりしたら逮捕されることもあるのでは・・・？
できるだけ不必要にデータを残さないように、かつ内容も意識的に見ないようにしながら作業していたのを覚えています。
DBリプレース案件の失敗
さて、神経を使いながら行なった帳票の移行はなんとか完了しました。
あとは本体と合わせて移行するだけ、だったのですが、どうも本体側の進捗が芳しくない。
元請けのSE/SIer（A社）とクライアント（B社）との調整がどうだったかというと、、
とても調整と言えるようなものではありませんでした。
B社の部長がA社のメンバーに対して「君たちは無能だねぇ。本当にできるの？」
とネチネチ煽るやり取りばかり。
▲画像はイメージです
はたから見ていた身としては、この部長の無茶振りとマネジメントの甘さで余分に工数取られてそうだな、という印象でしたが。
協力会社の立ち位置である僕のいた会社としては、
- 明らかに無理な工数だから人（お金）を増やすべき
- それができないのならスケジュールを見直すべき
という主張をずっとしていましたが受け入れられず。
クライアントであるB社は、最初に決めた額以上は支払おうとしないけれど追加の作業もどんどん投げてくる。
元請けのA社は、お金・人を追加することなく今のリソースで追加されたタスクも吸収しようとする状態でした。
僕のいた会社もかなりのとばっちりを受けていましたが、A社との関係が準委任契約であったことが功を奏しました。
SE/SIerとその下請けになるソフトハウスの契約は、準委任契約と請負契約に分けられることが多いです。
請負契約は、請負人が仕事を完成することを約し、注文者がこれに対して報酬を支払うことを内容とする契約です。
一方、準委任契約は、仕事の完成ではなく、一定の事務処理行為を行うことを約する契約です。
引用元
最終的には自分たちがやるべきことはちゃんとやって、あとは知らんというスタンスをとることに。
結局、煽りはするけど何も決定しないB社部長は、超ギリギリスケジュールの移行計画を数カ月間一切見直すことなく、しかしタスクは増やし続けました。
A社だけでなく僕のいた会社にとっても相当の負担になりながらも、いよいよ移行作業、切り替えの当日を迎えました。
前日、日付が変わるまで作業をして、集合はまさかの朝６時。
近くのビジネスホテルにみんなで部屋をとって宿泊、数時間寝てから栄養ドリンクをかかえて出社しました。
いざ始まると、僕のいた帳票チームはすんなり終わり、他チームのフォローに入ることができました。
しかし、現場では異様な空気が流れています。
これやっぱり移行完了できないんじゃない？
最悪、すぐ戻せるように準備しとくか。。
そんな空気感。
お昼を過ぎても、やっぱりすんなり切り替えできていない。
細かいトラブルが起きては対処療法的にクリアしていきます。
そうして17時を迎えた頃。
重なる細かいトラブルについに耐えかねたのか、B社の部長が遂に決断をします。
「切り戻そう」
切り戻す、ということは、システム切り替え前の、元の状況にもどす、ということです。
つまり、移行・切り替えが目的のプロジェクトなのに、予定した日に移行ができなかったのです。
これはつまり、実質プロジェクトとしては失敗したとも言える状況でした。
そんなことになるんじゃないかと予想はしていましたが、実際こうなってしまっては仕方がない。
各々が切り戻し作業と、その後の確認を終えたのがおおよそ22時。
奇跡的に問題なく、完璧にもどす事が出来ました。
そして、契約上この日の作業が最後であるので、A社の主要メンバーに挨拶をして退社。
その時の、マネージャの、この世の終わりのような顔は未だに忘れられません。
マネージャのプロジェクト全体の進行管理にも問題があったとはいえ、流石に気の毒に思いながら、その現場を後にしたのでした。
▲画像はイメージ。実際はこの10倍くらい生気の感じられない顔をしていました
後になって思うのは、
- 本来かかるはずのお金を払わず、安く済ませようとしたB社部長
- 結果として自分たちを安売りしてしまい、自らの首を締めたA社マネージャ
この双方のやり方に問題があったのでは、と思います。
お金が必要なのであればちゃんと払うこと。
払ってもらっている範囲を明確に区切って、出来ない事はやらない姿勢を貫く事。
これらがあれば、もっとうまく進んだんじゃないか、と思います。
「24時間体制で終わらせろ」
別の現場での話。
今回の案件は、経費の申請や稟議を通したりするワークフローシステムの導入案件で、やはり客先常駐の案件です。
作業をしていたビルは空調の効きも悪く、さらに常駐する人数に対してデスクの数が足りず、机２つに３人座ったりしているような環境。
ここには元請けとなるSE/SIer（c社）と、その下にいくつかの会社が協力会社（うち、話に登場するのがD社）としてついていました。
D社と横並びの関係であるのが、僕のいる会社でした。
作業自体は忙しかったものの、僕のいる会社はなんとかスケジュール通りに進めていました。
しかし、同じ部屋のすぐ隣で作業しているD社の進捗が芳しくないことには、薄々と気づいていました。
プロジェクトも後半に差し掛かった或る日の朝。
工程としては単体テストや結合テストと呼ばれるフェーズ。
当時の僕は、右に座ったまだ新人の女の子と２人チームでした。
僕がサポートする形で、毎朝進捗状況と、何か困った事がないか、などの確認をしていたその時。
「もう私やりたくない！！！」
突然、左に座っていたD社の女性社員が絶叫。
どうやら進捗が悪いおかげで残業も重なっていたらしく、精神的にも辛い状況だったのだと思います。
後から聞くと、進めていた検証作業のやり直しをC社から指示されたようで、それがきっかけとなり泣き出してしまったというのです。
その女性の方は、同じD社の社員に心配されながら一旦その日は退社。
それ以来姿を見せることはありませんでした。
それから数週間してさらに検証も進んだ頃。
件のD社のお偉いさんが、C社の部長に呼び出しを食らっていました。
先日の女性の件かな、、、と思いきやそうではありません。
あの一件で作業するメンバーが減ってしまったのもあり、D社の進捗が相当まずいことになっているとか。
スケジュールの調整をするのかと思いきやC社の部長がD社に対してした指示は、
「24時間体制作ってでも終わらせろ」
というものでした。
当然24時間働けるわけはないのですが、それならシフトを組んで、日中組と夜勤組別れて作業しろというのです。。
D社はこれに逆らうこともできず、急遽夜勤組としてメンバーを増やして、本当に２４時間体制で対応しだしました。
それを見て困惑する僕達。
そこにD社からある相談が持ちかけられました。
「夜勤組は日中組より人が多いのですが、PCが足りないので貸してくれませんか？」
え、そんなことする・・・・？
しかしどうやら本気で言っている様子。
いや、急なのはわかるけど、それは自分たちで用意しなさいよ。。
と思っていたのですが、僕のいた会社と話した結果、なんと夜間に貸し出すことに。
まじかよ。。
これはこちら側の対応がまずいよなあ、と思います。
端末、貸しちゃダメでしょ。
朝、出社して自分のPCの電源を入れると、デスクトップにファイルが散らかっていて、嫌な気分で1日をスタートするのでした。
SE/SIerの闇は深い
つらつらと思い出話を書いていたら、とんでもない分量になってしまいました。
でもこれだけじゃないんです。
ソフトハウスに努めた3年間で、もっと色々な経験をしています。
「１週間で一番早い退社時間が終電」とか「ヘルプでやってきたおじさんが作業全くできなくて数日で来なくなった話」とか「積荷崩壊事件」とか色々あるんです。
あまりにも長くなるので、３つに減らしました。
SE/SIer（の、一部）として働いている中で自分が体験したことも、結構強烈な内容ですが、同期として働いていたメンバーも、各々がハードな経験をしていました。
きっとこの話は氷山の一角なんだろうな、と思います。
いやあ、SE/SIerの闇は深い。
こうした闇が深い案件が発生してしまう理由は、やはりエンジニアを安く買い叩いてしまうこと、自分たちを安売りしてしまうところにあるんじゃないかと思います。
SIerの仕事を、つらいと感じたら
もしかしたらこの記事を読んでくれている方の中には、今現在SIerで仕事をしていて、つらいなあ、と感じている方もいるかもしれません。
今のSIerの仕事が辛くて、続けていく自信がない、と言う状況であれば、こちらの記事も読んでみてください。
次のアクションを取るための指針をまとめました。
また、SIerでプログラミングがしたいのにできない、と悩んでいる方であれば、次の記事をぜひ読んでみてください。
SIerがプログラミングとどう向き合ったら良いのかをまとめています。
★転職の際に活用したい、オススメエージェントサービス3選★
それでは。
