ryohei.nagaoka for Seattle Consulting, Inc.

Posted on Sep 3, 2019 • Edited on Sep 10, 2019

未経験中途入社エンジニアが初現場で学んだこと

#beginners

はじめに

不動産賃貸管理会社の営業という割とローカルな仕事に３年間務めた後、IT業界へ飛び込みました。入社後３か月の研修を経て、初の現場に参画することになりましたが、参画初日の正直な感想は本当にこのプロジェクトやっていけるのか・・・というとても大きな不安でした。

そんな不安からスタートした初現場でしたが、なんとか走りきることができたので、そこで学んだことをこちらに残していこうと思います。

私のように、研修や自己学習と実際のプロジェクトの"規模"の違いから大きな不安に駆られる人は少なくないと思います。そんな人達の助けになれば嬉しいです！！

"分からない"を知ってもらう

私がプロジェクトに参画して最初の業務は要件定義書を読み、既存の設計書を元に今回のプロジェクト用の設計書を書き起こすというものでした。

しかし、既存の設計書があるにしろ、設計書を書いたことも無ければ、何が書いてあるのかも良く分からない。"分からない"が多すぎて本当に困った。というのがその時の感想です。

こんな時に重要なのが、"分からない"ということをメンバーや先輩に知ってもらうことです。

基本的に先輩方は、新人エンジニアに対して"仕事ができる"とは思っていません。
"分からないこと"をキャッチアップして成長することを期待しています。

逆に一番やってはいけないのが、分かっているかのように振舞うことです。

私は前職でお客様との話の中で分からないことが出てきた際に、正直に分からないと伝えてしまうと「そんなことも分からないのか！！無能め！！お前の会社とは契約しない！！」なんてことになりかねないので、虚勢を張ってその場を凌げと先輩に教えられて来ました。
その為、そんな窮地に立たされた際に虚勢を張って上手いこと窮地を回避する悪い癖がついていてしまっており、本当に苦労した点です。
未だに癖が出てきてしまうことがあるので、常に意識して業務にあたっています。

"分からない"に直面した時は

"分からない"を知ってもらうことはできましたが、それで解決ではありません。
"分からない"を"分かる"状態にして初めて解決です。
その方法ですが、即上司やメンバーに聞くのはNGです。
自分で解決する気は無いのか？？と疑念や不安を与えてしまいます。
それに、自分で解決する能力も成長しません。
なのでこんな時は、
「自分で調べる→解決できなければ上司やメンバーに聞く」このステップでやってみましょう。
自分で調べることによって、自己解決力が上がります。
そして、そこで解決できれば上司やメンバーに聞く時間も取ることはありません。
しかし、"調べすぎる"のは良くありません。
1時間調べて分からないこともあります。というより、15分調べて分からないことは大体1時間調べても分かりません(※個人差があります)
なので私は、15分調べて分からなければ聞くという風に実行しています。
調べることに熱中しすぎて15分過ぎていることもあるので、タイマーを設定しておくのも良さそうです。
そうして分かった事、解決したことはメンバーに展開したり、コミュニケーションツール等でアウトプットすると、ほかの社員の知識にもなりますし、自分の知識の定着にも繋がります。
ここまでできれば120点ですね！！

質問の仕方を考える

15分調べて、分からない。
次のステップは質問をすることだと思いますが、ここも注意が必要です。
私が質問をするとよく言われた言葉があります。
「何を聞きたいのかわからない」
なぜこのやり取りが発生してしまうのか。
それは質問の仕方に原因がありました。
私の場合、何をやったのか1~10まで全て話した後、聞きたいことを話すという順序で質問をしていました。
質問の仕方としては0点です。
いくら仕事のできるスーパーエンジニアといえど、1~10まで話を聞いてられません。
では、どう聞くのが正解か。
仕事のできるスーパーエンジニアな上司に聞いてみました。
上司曰く、

①やりたいことを伝える
②起きている事象を伝える
③事象を引き起こした行動となぜその行動を行ったのか伝える

この順序で質問をしてもらうのが聞きやすいようです。

質問を受ける側としては、どこまで自分で考えて何を行ったのかを知りたい。
考え方が合っていて行動が間違っているなら行動のヒントを与えるし、
考え方がそもそも間違っているのであれば、考え方から教える。

とのことです。
ここに関しては、正解は色々あると思うのですが、
"やりたいことを伝える"の手順を一番最初に持ってくるのは、変わらないと思います。
その後の説明の部分が明後日の方向に向かってしまっていても、やりたいことは分かっているからアドバイスしやすいはずです。

"分からないこと"が"分からない"

初めて設計書やソースコードを見たときに起こった現象ですが、新人エンジニアにはよく起こります。実際、新人エンジニア間では、
A「何が分からないのか分からん！！」
B「出た出たいつもの笑」
なんて会話がよく発生してました。
この現象が起きるときは大体、ドキュメントの中に"分からない"が混在しています。
"分からない"と"分からない"が手を繋いでできているドキュメントです。
そりゃ分かるはずがないのです。
なので落ち着いて一つ一つ解決していきましょう。
具体的には、ドキュメントの単語やトピック一つ一つに対して、これが何か説明できるか？という疑問を自分にぶつけてみましょう。
ここで説明できないものは全て"分からない"ものです。
この"分からない"を全て解消したころには、ドキュメントが読めるようになっています。
ただこの過程は時間がかかるので、一度上司に相談をしましょう。
先程も言った通りここで"分からない"を隠蔽してはいけません。
"分からない"ことは悪ではありませんが"分からない"を隠蔽することは確実に悪なので、意識しましょう。

認識合わせをする

新人エンジニアのタスクといえば、基本的に上司から「こういうものを作って」と任されるのがほとんどだと思います。
そんな時、自分の成果物のイメージと上司の成果物のイメージに違いがあることは本当によくあるパターンです。下手をすると、意気揚々と成果物完成しました！！なんて上司に持っていっても、「全然違うじゃねえか！！！全部やり直せ！！！」なんていう大事故に繋がりかねません。
作業していた時間が全て無駄になってしまうので、なんとしても避けなければなりません。

こんな大事故を避けるには、認識合わせが重要になってきます。

上司からこういうものを作ってと説明があった場合は、その説明を復唱するのも一つの認識合わせですし、簡単に成果物を絵に書いてみて、こんな感じのものを作ろうとしていますと一度見せてみるのも良いと思います。
お互いに認識を合わせて、無駄な時間の使い方をしないようにしましょう。

定点報告をする

「定点報告」非常に重要です。
定点報告をすることによって、認識合わせのステップでは拾いきれなかったイメージのズレを修正することができます。1時間間隔の報告であれば、1時間の間の進捗に対してイメージのズレや修正点のアドバイスを頂けるので成果物がよりクオリティの高いものとなります。
また、1時間の間に"なにをやったのか"を報告しなければならないので、無駄な時間の使い方をしなくなり、作業効率アップにも繋がります。

図を描く

画面からサーバー側へどのように情報が渡って、どのような処理が行われてデータベースから欲しい情報が得られるのか・・・
このような複雑な情報は頭の中でイメージするには、限界がある上に、頭の中のメモリを大幅に取られてしまいます。頭の中のメモリを取られて過ぎてしまうと、本来の作業に割くメモリが無くなり作業効率が落ちてしまいます。
こんな時は、図を描いてみましょう。図を描くことによってイメージで頭の中のメモリが取られることがなく、本来の作業に全てメモリを使うことができます。
そしてこの作業の中で出てきた発想は図に書き足す事によってメモリが埋まっていくことを防ぎ、さらに新たな発想に繋げることができます。
頭の中のメモリは有限ですが、図を描くための紙さえあればメモリを無限に増やすことができるので図を書きまくりましょう。

タスクの目的を常に意識する

"何の為に今のタスクに取り組んでいるか"ここを捉えているかいないかでタスクのクオリティに大きな違いが出てきます。
例えば、大半の新人エンジニアが最初に担当するのがテスト工程ですが、ここでありがちなのが"テストを消化する"ことが目的になってしまっているパターンです。
このパターンだと、テスト項目書に書いてある結果になるかどうかだけを見てしまう為、タスクの完了時の評価を5段階評価(☆☆☆☆☆)にすると星3(★★★☆☆)といったところでしょうか。
テストは作成したアプリが正常な動きをするか、異常な動きをしていないかを確認する工程です。
この点を意識できていると、テスト消化の際に「項目書通りの動きはしたけど、レイアウトが崩れているなぁ」とか「項目書通りの画面は表示されたけど、表示されるまでのローディング画面が長かったなぁ」とか項目書で拾い切れていない不具合も拾うことができます。(実際に不具合かどうかは別として)ここまでできれば星5(★★★★★)じゃないでしょうか！！
このように、タスクの目的を意識することによって視野が広がりますし、求められている成果物に限りなく近いものを作ることができます。場合によっては求められている以上の成果物を作ることも可能です。
結果自分の成長にも繋がるところだと思うので、ぜひ意識してみましょう！

手を動かす

これは実際にプログラムを組む際に大きく役立ちます。
思っている処理にする為には、
どのようなプログラムを組まなければいけないのか。
ずっと頭の中で考え、進捗が上がらないことが多々ありました。
このような状態を抜け出すには、とにかく手を動かすことが重要です。
では具体的に何をするのか。
ポイントは3点

①仮説を立てる
②仮説を実践してみる
③振り返り

このサイクルを素早く繰り返すことが、ゴールへの近道です。
頭の中で仮説がたったら実践してみる、そこで失敗したとしても
振り返りを行い、それを元に新たな仮説を立てる。
頭の中だけでは絶対に答えは出ません。
手を動かしてみましょう！！

タスク完了の時間は想定よりも多めに伝える

上司からタスクを振られると共に、どれくらいでタスクを完了できるのかも
一緒に聞かれることが多々あります。
この場合、根拠のない想定時間をそのまま伝えるのは圧倒的に間違いです。
私はよく、やったことのないタスクではあるがなんとなくこのくらいの時間で終わるだろうという想定で完了時間を報告していましたが、一度も報告通りの時間に完了したことはありません。
基本的に、報告した時間内にタスクが終わらないというのはNGです。
その為、根拠のある想定時間とイレギュラーが発生した際のことも含めて+αのタスク完了時間を報告するのがベストです。
根拠のある想定時間の算出は、経験があるタスクであればある程度割り出すことは可能ですが、新人エンジニアには経験が無い為、すぐに算出することはできません。
その為、少しタスクに着手してみて着手した上での進捗と掛かった時間から想定時間を算出するのが良いです。
想定時間を算出できたら、＋αの時間を乗っけて報告するのがベストです。
＋αの時間についてはなんとも難しいのですが、想定の3倍の時間で報告→了承を得るができればベストです。
しかし、上司ならまだしもお客様との対話の中で安易に3倍の時間を報告するのは危険です。
お客様の想定が1時間だった時に3時間で報告をしてしまうと、信用を失うことに繋がりかねません。
まぁ上司だからと言って何も考えずに3倍の時間を伝えるのもまたちょっと違う話かなとは思いますけどね・・・
ここは上司との対話の中で丁度良い頃合いを見つけていきましょう。

ショートカットキーを使いまくる

スーパーエンジニアの上司曰く、仕事ができない人には決まって共通点があるとのこと。
それは、ショートカットキーを使わないことです。
細かい点ではあるのですが、１日の限られた時間のなかで多くの作業を行うにあたり、一番わかりやすくタスクの時間短縮ができるのがショートカットキー。
アプリやウィンドウを切り替えるAlt+Tabキーや指定範囲をコピーするCtrl+C、ペーストするCtrl+v等はよく使った印象があります。
一番感動したのは、エクセルのセルに文字を打ち込むときに、毎回セルをダブルクリックしていたのをセルを指定してF2キーを押すこと。
こういったショートカットキーは、ショートカットキー一覧等で検索すれば紹介しているページがたくさん出てくるので調べて便利そうなものはどんどん使っていきましょう。

エラー文から逃げない

エラーが起こった際は、ログを見て原因を特定し、修正をするという流れになりますが、新人エンジニアの場合、原因を特定する場面でかなり躓く印象があります。
私を含め、周りの新人エンジニアも良くやっていたことなのですが、
エラー文から目を背けるのはやめましょう。一生解決できません。
何故か新人エンジニアがそろってやりがちなのですが、

①エラー発生
②ログを見る
③エラー文をを発見
④よくわからないから、原因と思われる部分をなんとなく修正してみる。

何故なのか。自分でやっていてよく分からないのですが、
無意識にエラー文から目を背けてしまっています。

エラー文には問題解決のヒントが書いています。
エラー文と向き合いましょう。
調べればエラー文の意味は分かるはずです。
エラー対処はエンジニアである以上避けては通れないので、
今のうちにコツを掴みましょう！！

最後に

長文にお付き合い頂きありがとうございました。

私自身、まだまだ注意されることも多いですし、
今回書いたことの中でも意識から外れてしまう点がいくつか
あったりするので戒めの意味も込めて書いてみました。

新人エンジニアというのは、できないことばかりで
自信を失ってしまうこともあると思います。

ですが、コツコツ積み重ねていけばきっと結果はついてくるはずです。
現に私は初現場で、分からないことばかりで上司からコテンパンにされましたが、
結果として多くの成果物をプロジェクトの中で残すことができました。

どんどん挑戦して、レベルアップしていきましょう！！

Create and maintain end-to-end frontend tests

Learn best practices on creating frontend tests, testing on-premise apps, integrating tests into your CI/CD pipeline, and using Datadog’s testing tunnel.

Download The Guide