見出し画像

【SES日記】第4章①はじめましてThe炎上案件

現場歴で言えばまだ4年目とは言えないギリギリ3年目です。
今月から新しい会社に入社し、1日から現場に行きました。

総合テスト工程からの参画で2ヶ月遅れ。
営業からの案件詳細の段階で、炎上しているだろうことは察していました。

炎上案件に入るのは初めてです。
不安がありつつも数ヶ月の任期なら我慢するかぁという感じでしたが、実際入ってみて炎上案件の実態とそうなってしまった理由が分かりました。

「公共系」と言うのも危ういですが、そんなきちんとしているだろう大規模システムの内情がこんなにめちゃくちゃだとは思いませんでした。
某大手Slerがこんなにクソだとも思いませんでした。
(過去の公共系大規模システム案件は細かいくらいしっかりしていたので同じかなと思っていました)

なんとか1ヶ月やりましたが、5回くらいエンジニアを辞めたいと思いました。
フリーランスだったら確実に1ヶ月で退場する現場です。
会社に所属していると自社の中で後任を探すことになります。同じようなつらい思いをさせたくありませんし、もしかしたら私のことを恨むかもしれません。

よくしてくれた自社メンバーにも合わせる顔がありません。
幸い自社メンバーは良い人で、この現場が「やばい」ということはみんなの共通認識としてあります。
彼らのフォローのおかげでなんとかやり切れた日もあります。
しかし、自社メンバーとは別作業ですし、体調を崩したり、リモートだったりだったりで一人で抱え込んでしまうこともありました。

あと数ヶ月の任期やり切れるだろうか。。いややり切りたい。
と毎日思いが揺れていた1ヶ月目の記録です。


作業実績

計20日、実働時間合計180時間(残業20時間)

・PCセットアップ
・環境構築
・調査5件

最初の1日はまだアカウントが払い出されておらず資料の読み込みでした。
2日目以降PCセットアップを行いました。
2ヶ月前に参画した先輩に教えてもらいながらだったのですが、忘れている・メモもない状態だったので苦労しました。
さらに増員するなんて思いもしなかったでしょうしね。

ローカル環境構築がかなりの難易度でした。
ローカル環境が動かせるのはバグ改修チームとわずかな人とのことでした。
なんと開発もローカル環境が動かない状態でやっていたとか。
その話をしてくれたリーダーが「自分でも何言っているか分からない」と言うくらいこのプロジェクトはかなりいかれているようです。
環境構築に何日もかけ、精神がだいぶすり減りました。

月半ばからは調査業務に入ります。
Javaが久しぶり、調査業務は初めて(もちろん担当機能を設計からテストまで一貫してやっていたので自分のバグ解析と修正はやっていました)、新規参画で業務知識が全くない状態で調査するのは不安だったので面談の時から話していました。
しかし、テスターは充分にいるとのことで調査員になりました。

はじめはフォロー者が割り当てられていましたが、その人も分からない内容になり、自社のリーダーに聞いたり、一人でねばりすぎたりしてしまいました。

総労働時間が180時間を超えたのはびっくりでした(超えるのは日数の多い3月くらいです)。
9時フル出社(ドアtoドア1時間超え)なので定時に近い時間に上がらないとしんどいのですが、仕事の熱が入ってしまって毎日1〜2時間の残業でした。

入館証がなくトイレを6時間以上我慢

入場からしばらくは入館証がない。
SESあるあるだと思うのですが、私は今回が初めてでした。
10日ほど前に入館証の写真と書類を送っているのに、入場2日目にやっと申請をしたようで4日ほど入館証がない状態でした。

居室のドアを開けるのに入館証でピッとしないといけないので、トイレに行きたい場合は開けてもらわないといけません。
言えばよかったのですが、私は我慢してしまいました。
ギリギリ我慢できたからではあるのですが、長くて7時間近く我慢していました。

ゲストカード借りるにも借りっぱなしにできず毎日返却する必要がありました。PMに依頼するのも遠慮してしまいました。

「入館証は入場初日にいただけますか」
今後案件面談の際は必須の質問事項になりました。

調査員に全てを押し付ける

総合テストのバグ解析を行うことになりました。
データを見て、ソースを読み込んで、ハッとしました。
ソースが間違っているなら単体テスト、結合テストで発見されているのではないか。
単体テスト、結合テストの結果はどうだったのか。
結合テストと総合テストとの差分とは。
環境面とかデータが問題の可能性が高いのではないか。
今回使用しているデータはどんなデータなのか。

そう思ってテスターに質問しました。
「結合テストを持ち出すのは違う」といった返答に驚きました。

あとあと知ったのは、単体テスト、結合テストでは画面が開けず「環境要因」として次工程に先送りしていたとのことでした(スケジュール上遅延なしで報告するため)。
今回のテストケースも総合テストで初めて実施するケースらしいです。
「画面でボタン押下する」そんな単純で単体レベルのテストを、現地で初めてテストするとは。。
データについてもテスターは把握していませんでした。

設計者も、製造者も、テスト仕様書作成者も、テスト実施者も全員違う。
私は今まで全てを一貫してやってきたのでやりにくさを感じました。
知りすぎていることによる漏れはあると思うので、テスト実施は別の人にやってもらうのがいいかもしれないですが、工程ごとに0から仕様理解するのは無駄ではないかと感じました。
理解できてない故にバグを見逃したり、新たなバグに繋がってしまうことがあると思います。

テスターはテスト仕様書に書いてある結果と違えばチケットを発行する。
それ以外のことは「知りません」で、一番の尻拭いをさせられるのが調査員なのです。
しかも単体テスト、結合テストで無視してきた膨大のバグチケットが溜まっている。
それを新規参画者がやっているのはどういうことだろう。

最初こそ真面目にがんばり精神的にこたえましたが、だんだんアホらしくなってきて、「開き直る」を身につけつつあります。

炎上する理由

炎上案件1ヶ月目、歴3年ほどの私が言うのもおこがましいですが、感じたことをまとめてみたいと思います。

①まともな設計書がない

画面設計書、DB設計書、プログラム仕様書…基本的な設計書は全てあるのですが、みなさんこれらをあてにしていません。
修正が反映されていないようです。
例えばあるテーブルを登録している画面を探すなら、CRUD図を見れば一発です。
しかし改修のたびに修正されているわけではないのでソースから探す必要があります。
ソースは複雑な構成で読みにくいです。Java・Springってこんなだっけと思うくらい、掘っても掘ってもなかなか出てこず時間が過ぎます。
10年、20年以上経験あるリーダー2名が「ソースから理解するのは厳しい」と言うレベルです。

また、私にシステム開発において最も重要な設計書はER図だと考えており、データの関係から理解することが多いです。
しかし、このプロジェクトのER図はテーブルが個々に並べられているだけで、つながりも多重度も分かりません。
テーブル定義も、とあるテーブルの定義書がどこにあるか分からず探すだけで時間が過ぎました。

②有識者がいない

このシステムは元は別の大手Slerが開発を行っており、今回の改修から引き受けました。そのため一番知っている人でも歴1年程度です。
しかも設計書があてにならないのでソースの読み込みや動作確認での理解です。
大きく分けてユーザ側システムと管理側システムがあるのですが、それぞれ専門家がいればいいものの「この画面・この機能はこの人」というのがないので誰に聞いたらよいのかも分かりません。
(みなさん宛にメンションしている)

③チーム構成や作業の振り方が悪い

調査員の場合だと、毎回別リポジトリの調査依頼が来ます。
画面とかAPIとかバッチとかそれぞれリポジトリがあって総数50以上あるのですが、どれも使っている技術や構成が違い戸惑います。
一度そのリポジトリに慣れたのならば、他にもそのチケットはいくつもあるはずなので、よく知っている人がやるのが効率的だと思います。
現状作業を振っているのがあまり開発のことを知らなさそうなPMですし、チケットの内容からどのリポジトリかなんて分かりません。
理想なのは、まず調査リーダーが0次解析をして、これはこの人に振るのがいいと振り分けで行くことだと思います。
また、ある人が詰まっていたら、よりそのことを知っている人に振ったり、フォローをつけたりするべきだと思います。
現在調査員はチームがなく、個々で作業をしている状態です。進捗会議もありません。調査員は誰、何人いて、チケットがどれだけあって、どれくらいのペースで消化しなければいけないか全く分からない状態です。
私同様、新規参画者が調査員になっているようで、分からずに一人で抱え込んでいる人もいるかもしれません。

他にも、私だからかもしれませんが、チケットは完了ごとに1つずつもらう方式です。
優先順位順に並べてあってそこから取っていってという感じならば、待ちも発生せずどんどん進めていけるのになぁと思います。

上の人たちは各所で問題が起き過ぎて回らなくなってしまっているのでしょうか。
せっかく人を入れたのに何のために入れたの?と思います(「お客様に何人入れました」と言って対処しているように見せるためだと思いますが)
技術力の高い人に負荷がいきすぎるのは良くないことだと思いますが、自社リーダーを遊ばせているようにも思います。

適材適所でその人それぞれを生かし切れていないと思います。

こんな現場で働くくらいならエンジニア辞める

私はこんな現場が初めてで衝撃的なのですが、ある人からすると「あるある」らしいです。
まともな設計書がない、そもそも設計書なんてないというところばかりだったという人もいました。
自社のベテランリーダーもあるある側の人間で、「ここでやっていけないなら他でもやっていけない」と思う部分があるのか少し厳しいと思う場面もあります。

しかし、私は二度とこんな現場に入らないように営業への根回しやアピールをするし、それでもまた同じような現場に入れようとするならば退職します。
他の会社もこんなところばかりなら、もうエンジニアも辞めます。

私はどこででもやっていけるわけではなく、こういう環境でないとダメとかこういうのが得意というのがしっかりあると気づけました。

大規模案件が全てダメなわけではないと思いますが、設計や品質を重視していて細かく整理することを求められる環境なら、自分の強みも活かせて働きやすい環境だと思います。

設計がないところも多いと聞くと、設計工程から入れる案件というのは少ないのかなと感じました。
過去2回設計工程から入れたのは幸運だったのかなと。

早くも転職活動(笑)

調査は没頭できて楽しい時もあれば、全然分からなかったり、どこまでやらなきゃいけないのか(修正するにもとんでもない化け物なので)荷が重くて逃げたくなる時もあります。

疲れたある日、指が勝手に転職エージェントの面談予約をポチっていました。

先日面談したのですが、エンジニアの前は管理職をしていたり、基本設計からの経験があるのに「4次請けでこんな現場なんてありえない」とのこと。
求人と全然違って会社は嘘をついているので、短期離職しても問題ないとのことです。

ポジショントークもあるかもしれませんが驚きました。
実際、前の転職活動は苦戦したのでこれが現実かなと思っていました。
12月という中途半端だししょうがないと思っていました。

少し希望が見出せたものの、いざ求人という現実を見ると、自分が理想とする求人はないなぁという感じでした。
真面目、責任感が強い、品質に強みがあるとすると、勧められるのは官公庁・公共系や金融系。
そこからは脱したいんだよなぁというのが本心です。

今回の現場で少しJavaやSpringが嫌いになりましたが、それでも1つの技術をまずは極めたいという思いがあり、Javaで希望を出しています。
それなのに、大規模案件ばかりの会社や金融系は嫌だなんて無理難題を言っているような気がします。

さいごに

1ヶ月やり切るのも本当につらかったです。
あと数ヶ月続けられるかなんて分かりません。
ある時ぷっつり来て、飛んでしまうかもしれません。

SESと言えども、一度入ってしまうと抜け出すのは難しいです。
無理のない程度に続けていくことが大事だと思います。

もう今はネタ集めみたいな感じのモチベーションになっています。
ひどい環境で感じたことをいっぱいメモして、バレない程度に発信していきたいと思います(いろいろ誓約書書いたけど、具体的なこと書いてなければ大丈夫だよね?)

また所属会社を変えてみての感想も別のnoteに書いてみようと思います。


この記事が気に入ったらサポートをしてみませんか?