第四章.経験者（笑）としてSES企業へ転職した後について。

前章でSES企業に入社し碌な開発経験を積めないまま、別の中小SES企業へ転職したリアルについて書いて行こうと思う。
・入社前から面談開始
当然SES企業である以上現場がないと始まらない。これに関しては、内定が出てからすぐに面談を行っていた。
そこで、経験は1年半あるんだけど、コーディング実務がない筆者の面談のリアルについて書いて行こう。
結果で言うと、面談件数：3件でSpringBootを用いた企業系基幹システムの開発案件にアサインされた。
うろ覚えであるが、この辺のついて書いて行く。
Ａ社：なんか、ShellScriptを書く案件だった気がする・・・？コーディング未経験という事と、Shellも読んだことしか
ないよ言うことで落とされた。まぁ、しゃーない。

Ｂ社：受託開発企業でメンバー募集の案件。SpringBootを使った詳細設計～テストまでだった。面談の時もJavaを勉強
していました！！と必死にＰＲしなんとかアサイン決定。最終的にこの現場に1年程お世話になった。

Ｃ社：ここも、SpringBootの開発案件だった気がするけどコーディング実務経験なしと事で落とされた。しゃーない。

という感じだった。今書いていると相当運がよかったなぁ・・・
ただ、先のＢ社の面談を受けた時は、もう一人一緒に受けていたのだが、はたから聞いても、受け答えがダメっぽかったので案の定落ちていた。
最低限、自分が何のスキルを持っているのか、スキルシートを見ながらキチンと説明できるようにはなっておこう。

・入社後について。
現場も決まっていたのでいきなり現場にポイである。（無情）
できれば、経験者と組んでアサインしてほしいのだがそんな余力は中小SESにはない。（後々発覚するのだが自分のスキル感でも中堅レベルだった・・・）
自社に関してはマジで特段書くことないのでこれで終わりだ。

・いきなし開発現場に入ったら・・・？
参画フェーズは詳細設計からだったので、基本設計書を読み見まくり、不明点があれば常駐先の方に質問しまくる。
とにかく開発するシステムの目的を知らなければ何をすればいいのかもさっぱりなのだ。
以前の現場で行っていた、ドキュメントを読む力はここで活きてきたと思う。

・詳細設計書の作成
参画フェーズはここからだったので、いきなし設計書を書くことになった。
詳細設計書と聞くと少しおぉ・・・と思う事があるかもしれないが、この現場でいえば中々緩いものだった。
詳細設計書の書き方のフェーズとしては以下になる。
①スケジュールで自分の担当機能が振り分けられる
②担当機能で何がしたいのかを、基本設計書から読み解いておく
③すでにあるフォーマットを基に担当機能でやりたいことをプログラムで実施するにはどう処理をしていくか日本語で説明ベースで書いて行く。
といった具合だ。
※③の中には、画面の設計図・バックエンド処理の設計図（なんの処理をして～なんのテーブルからデータを引っ張って～）といった事を書いてくぞ。
このフェーズに関しては、現場のフォーマットありきだから一概に言えないが、現場の有識者の作成済みドキュメントを見ながら
書いて行けば何とかなるはずだ。
最悪ＰＭからのレビューで修正しながら進めるのでどうにか乗り切ろう。国語力があれあ何とかなるフェーズだ。

・製造工程
問題はここからだ。当時の筆者はプログラミングなんて1年半前にやったきりで全然覚えていない。
では、どう乗り切ったのか書いて行こう。
1.コピー忍者のカカシになりきるのだ。
まず、同じプロジェクト内にできる人がいるはずだ。
その人の書いているソースコードを読もう。そして読み込んでどのクラスでテーブルからデータを引っ張っているのか、バックエンド処理を書いているのか、
フロント側のソースはどこに書いているのか把握していくのだ！！
それができれば、その人のファイルをコピーし、自分の担当機能の処理に書き換えていく。これが一番だ。
ふぇえ・・・既存のソースに何が書いてあるかわからいよぉ・・・と困っているかた。安心してほしい。当時の筆者もほぼ同じ事を経験している。
対処法は次に記載する。

2.ChatGptに聞け。
知っとるわ！！って人が大半だと思うが、筆者はこれで（今も）乗り切った。
わからん・・・ってソースコードはとっととコピペしてChatGptに張り付けて、このソースコードはなにをしているの？って聞けば
大体何をしているのかすぐに応えてくれる。
細かい処理を追えなくなったら、一行づつコピーしていって細分化して聞きながら自分でまとめていくのだ。
SQLに関しても、テーブルの定義を書いて、このデータを取得するにはどうSQLを書けばいい？と質問すれば基本的なものは生成
してくれる。それをベースに作成していくのだ。
画面側にしても、表示変更のJSの生成も聞けばベースの部分を生成してくれる。そこから自分の担当機能としてきちんと作っていけば問題ないのだ！！

3.デバッグは出来るようになっておこう。
Eclips等に搭載されているデバッグ機能に関しては絶対に使えるようになっていた方がいい。
これは、他人のコード読み込んでいくときに解析する際にも非常に役に立つし、自分の担当機能がなんで動かないんだ？
といった際の調査に非常に役に立つ。
システムなんて突き詰めれば値の受け渡しなのだ。
この値の受け渡しがうまくいけば何とかなる。そのためにもデバッグは必須事項になる。
本記事は技術記事じゃないので詳しくはググってくれ。

製造工程に関しては、上記1～3の方法を使用すれば逃げ切れるだろう。
一応言っておくと、参画予定のフレームワークが事前に分かっていれば事前にある程度学習しておけばなおOKだ。
決まっていないor独自フレームワークでも、どのソースが画面側orコントローラーorロジックと大体わかれているハズだから
そこを把握できるようになれば何とかなる。まじで。

・単体テスト工程。
この辺に関してはテスト項目書の作成時に大体レビューが入るし、できる人のドキュメントを参考していけばよいのだ。
単体テスト仕様書はあくまで担当機能を動かすときにどんな入力パターンがあるのだとか、ユーザーの場合だとかを
抑えて仕様書作り+実施をし、バグが出てくれば測修正→再テスト。こんな感じで乗り切ろう。
バグが出てくるのは何もおかしなことじゃないのでめげずに実施だ。

・結合テスト工程
これに関しては、あまり仕様書を作る機会がないかもしれないが、単体テストとは違い、自分作成の機能のテストではなく、
システムを一通り動かしてみてのテストという形で仕様書を作ってみよう。
筆者が仕様書を作ったときは、単体テストとごちゃまぜな感じで作ったからかなりリテイクを食らった。
でー丈夫だ。どうせ仕様書のレビューがあるんだから指摘通りに直せばいい。

こんな感じの工程を経験できる案件を1つの現場で4回ほど経験した。
受託企業のメンバーでのアサインだったので、システムが完成すれば次のシステム作成案件にアサインされる形だ。

・一つの現場の終焉
とそんな感じで入社と同時にアサインした現場で丁度1年が経過したときだ。
受け持っていたSpringBootの案件が落ち着いたときに次は何の案件かな～と思っていた時だ。
元々現場からの評価も上々でそろそろ単価交渉やろ！と高をくくっていた。
そんな中、月の最終日突然に、現場担当者からアサインできる案件の空きがないから今日で最後ね！と言われたのである。
こちらとしてはファッ！？となり慌てて自社に連絡を行う。自社側も当日話を聞いたとの事で突然ノー現場となってしまったのである。
まぁ、悲しいかな。SESエンジニアなんて所詮そんなもんである。客先だって案件の空きには自社のエンジニアを突っ込むのは当然だ。
そんな中で突然現場が無くなってしまったので1ヶ月ほど待機期間に突入する（当時はもっと早く客先さんも言ってくれればよかったのにと愚痴ったものだ。）
そんなわけでSES→SESへ転職した際のリアルについて記載していった。
次の章からは、開発経験を積んだSESエンジニアの現場面談のリアルとこれからを書いて行こうと思う。