こんにちは！入社2年目エンジニアの宇都宮です。

私は普段、SESのエンジニアとして、お客様先に常駐する形で仕事をしています。

そして先日、入社して初めて現場に着任してから約1年となりました！

ついこの前着任したような気がするのに、時間が過ぎるのは本当に早いですね…。

ということで、今回は、

現場でどのような流れで仕事をしていたのかのご紹介と合わせて、

一年を振り返り、「初参画現場で得た学び・気づき」について共有いたします！

初めて本格的にエンジニアとして業務をしていく中で、
私が感じた「エンジニアとしてどんな視点や考え、姿勢が必要か」ということについてご紹介していきますので、

エンジニア職に興味を持ってくださった方の参考になれば幸いです✨

◇前提

私は未経験エンジニアとして入社いたしましたが、入社前後で研修を受け、必要な基礎知識を学びました。

研修の様子については下記に掲載しておりますので、ぜひ合わせてご覧ください！

（内定者研修についてはこちら！外部研修についてはこちらからご覧いただけます）

◇仕事の流れ

参画した現場において、開発における大まかな流れは下記のようになっていました。

お客様から頂いた要件を基に調査・分析
　⇒　要件確認　⇒　設計　⇒　製造　⇒　テスト　⇒　リリース

また現場によっては、「設計」「テスト」など工程ごとに担当することもありますが、

私が参画した現場では、ある機能について、調査・分析からテストまで一貫して担当していました

チームメンバーは約10名ほど。
上記のように各自別の機能を担当していましたが、最終的にはすべてつなげて動かす必要があるため、
「どう実装していくか、どのような方針にするか」の話合いを適宜行っていました。

一日の仕事の流れについては、下記のようになっていました。

9時：出勤
9-10時：週次で他チーム合同で全体進捗会。ないときはチャット・メールで未読のものをチェック。
10-12時：作業
12-13時：昼休憩（お昼ご飯は弁当持参 or 社員食堂を活用）
13-17時：作業（必要に応じてチームメンバーや他チームとのMTG）
17-18時：チーム内進捗会
18時：退勤

◇学び・気づき

１．「その現場にしかないもの」をいかに早く習得するか

研修でJavaやWebアプリケーション作成に必要な基礎知識、チーム開発の流れは把握していましたが、
現場に入ってから、その知識だけでは業務は行えないんだ…、ということを学びました。

例えば、その現場でのみ使われている技術があったり、
命名規則、レビュー様式、進捗管理など、現場独自のルールが存在します。

そういった「その現場にしかないもの」を習得しないことには、業務だけでなく、チームに迷惑をかけてしまうことに繋がってしまうなと、現場に入って最初に感じました。

なので、現場に入ってからすぐ行ったのは、

現場独自のルールや技術がまとめられたドキュメントを読み込み、把握すること

でした。

技術については、ドキュメントだけ見ても理解が難しい部分があったため、
開発環境で実際に動かしてみたり、デバッグなどを用いて色々試してみたりしました。

設計や製造を行いながらドキュメントを見返すことも多々ありますが、
事前にしっかりと把握しておくことで、作業スピートを上げることができたと感じています。

２．「わからない」「多分こうだろう」を残したまま進めない

「実は自分が考えていたものと求められていることが違った…」ということが起こったとき、
それまでに作ったものとそれにかけた時間が無駄になってしまいますし、

何より、チーム全体の遅延に繋がってしまいます。

そのため、たとえ小さなことでも、認識のすり合わせを行うことを大切にしていました。

ただ、やみくもに「わからなければ聞く」のではなく、
まず疑問が浮かんだら、要件や設計書などを確認し、自分が見落としていないかをチェックします。

「本当に自分の力で解決できないか」を見極め、「わからない」「多分こうだろう」としか結論が出ないときは、可能な限り

「自分はこういう風に考えているのですが、認識あっていますか？」

と、自分の認識をちゃんと話せるように用意してから質問を行うようにしていました。

３．チャットベースの会話は、意図通りに伝わるか必ず一度確認する

現場では、会話は基本チャットベースで行っていました。

そこで気が付いたのは、

「書いた言葉が自分の意図通りに相手に伝わる難しさ」

です。

これは、自分が読み手側になったときにより強く感じていました。

文章作成の得手不得手は人それぞれですし、書いた人の頭の中だけで前提となっていることがあったり、無意識に省略している事柄があったり…。

そのようなときは、２．でも述べた通り、「今のは○○ということであっていますか？」と確認するようにしていました。

また、それを踏まえて、自分がチャットを送るときは、特に下記の3つを意識していました。

• 自分の頭の中だけで前提となっていることをなくす
• 複数の事項や物事の流れを伝えたいときは、項番を用いる
• 送る前に必ず読み返し、誤解を生んだり過不足がないかを確かめる

４．受けた指摘はまず受け入れ、やってみる

これは私自身が働く上で大切にしている、「まず受け入れる」ことです。

チームの中で私が一番若手だったこともあり、チームメンバーは自分よりエンジニア歴・現場歴ともに長い方ばかりでした。

書いたコードの内容はもちろんですが、設計書やその他作成した資料なども、
「これはちょっとわかりにくいなぁ」「もっとこうしたほうが良いよ」
といった指摘を頂くことも多々…。

例え自分の中で指摘に対して思うことがあったとしても、とりあえず実施してみるのです。
その結果、「あ、こっちの方がいいな」と気が付くことが多くありました。

もし実施しても納得いかなかった場合は、認識のすり合わせを行います。

指摘でいただく具体的な指示の裏には、必ずそう思う原因・理由があるはず。

それが見えないままだと、納得できないこともあるかもしれません。
「先ほど頂いた指摘は、○○だから□□したほうが良い、ということであっていますか？」などと確認することで、

誤解があれば解消できますし、その原因を取り除くため、

お互いが納得する解決方法を探すことができる

と感じています。

５．自分の力量・スケジュールを把握しておくこと

仕事の流れでも記載した通り、定期的に進捗報告するMTGがありました。

そのとき、「今日は○○に取り掛かりました」「○○が終わりました」だけでは、
進捗報告としては不十分だと学びました。

タスクに取り掛かる前には、必ず全体のスケジュールを確認し、

• 今自分はどのあたりを進めているのか
• 自分の力だとどこまで進められるか
• いつまでに何をやれば余裕を持って期日に間に合うか

を常に考える必要があります。

それを踏まえて進捗報告では、

「今日は○○の工程の□□に取り掛かり、○○％ほど完了しました」
「躓きそうな点も今のところなく、明日の夕方までには終わる予定です。その後、レビューをお願いいたします」

「本日進めている○○の作業についてですが、○○の課題解決に少々時間がかかっております」
「本日中に解決しない場合、ご相談のため明日MTGを招集させていただいても良いでしょうか」

など、数字を用いたり、その後どうなりそうか、ということまで報告することを意識していました。

また、もし作業を一緒に進めている人がいれば、

一緒に仕事をする人の仕事内容や進捗を把握しておく

ことも重要だと感じています。

例えばその人が休んだり、何かしらの理由で作業ができなくなってしまったとき、
進捗報告ができるようにすることもそうですし、作業を引き継いで実施する可能性もあるからです。

そのような不測の事態に備えるだけでなく、
もちろん、チームメンバーの仕事内容や進捗をある程度把握しておく方が、チーム内のやり取りや自分の作業も円滑になります。

◇終わりに

いかがでしたでしょうか。

少し長くなってしまいましたが、ここに書ききれないくらい、もっとたくさんのことを学びました。

少しでも皆様の新たな気づきや学びに繋がりましたら幸いです！

お客様や、他のチームメンバーに少しでも貢献するため、大変だな…と感じたこともありましたが、
チーム全体が上手くいき、無事役目を果たせたときは、本当に嬉しく思いました。

学び吸収したことを、自分自身、そしてBlueStarの成長につなげていけるよう、今後も頑張ってまいります✨

この記事が少しでもいいなと思ったら、ぜひ「いいね」をお願いします！！