はじめに
未経験からエンジニアに転職して、気づけば約1年。
この1年で感じた現場で生き残るために大切だった考え方・スタンス・立ち回りをまとめます。
「自分で勉強はしてきたけど、いざ放り出された時に生きていけるかな？？」
一年前の私です。笑
このような方は多いのではないでしょうか。
これまでコンピュータサイエンスの勉強や、実務経験がない方が
初めての現場に出る時の不安は計り知れません。
ですが、本記事の内容を実践してもらえればなんとかなると思います！
大事な前提
この記事を通して大事なスタンスがあります。
それは、、、
”チームに貢献する”という意識を持つことです！
それはそうだよねって話だと思いますが、
なかなか自分の仕事で手一杯の時に全体のことを考える余裕がない時もあります。。。
その上で、行動の価値基準として「チームに貢献できるか」を持っておくだけで
現場で生き残っていけるのではないかと感じています。
貢献するとは？
貢献するっていっても抽象的ですよね、、、
一般的には、、、
- 周りより多くタスクをこなせる？
- 難しい技術を扱える？
- マネジメントが上手でプロジェクトを進められる？
などがあると思いますが、
現場に入りたてのエンジニアは到底できるとは思えません。。。
経験が浅い（もしくはない）エンジニアが貢献できることなんてないんじゃないか、、、
そう思うのも無理ないですよね。
そんなエンジニアでもできる貢献とは、、、
”技術以外の側面でチームの成果が大きくなるように行動すること”
だと考えています。
結局、チームの目的は受託であれ自社開発であれ成果を出すことです。
自分がいることでより大きな成果が出たり、チームが円滑に回ることにつながる
行動できれば、十分貢献できていると思います。
私は、技術以外でも貢献できると気づいて、だいぶ心が楽になりました。
補足
若いエンジニアがチームに入って、すぐにチームの成果が大きくなることはないでしょう。。。
（むしろ生産性は落ちるはず）
即戦力でなければ、長期目線で教育的な側面もあるとは思いますが、
すぐにチームに貢献できる方がいいですよね。
技術面だけでは、すぐに貢献できないという現状を受け止め、
今からでもできる、チームに貢献していくという行動をとっていこうという趣旨です。
（技術があることに越したことはありません。）
というわけで、大事な３つのスタンスを見ていきます！
1.質問する時は練り上げる
現場に入るとわからないことだらけで、質問する機会が多いと思います。
（技術的にもそれ以外でも）
上司や周りの先輩は忙しそうで聞きづらい、、、
でも、聞かないと進めない、、、
という状況の中でできることは無駄なラリーを減らすことです。
次のことを意識すれば防げるラリーがあります。
※ 質問を作るのに時間をかけすぎてもよろしくないので
チームの文化としてどれぐらい煮詰まったら頼るかなどを確認しておきましょう。
思考の跡を残す
いわゆる、
自分がどこまで考えて、理解できているか。
どこからわからなくなっているのか。
何ができるようになれば解決なのか。
を整理することです。
できれば、一度文章にしてまとめてみるのがおすすめです。
いざしゃべろうとすると全然整理できていなくて、
相談相手にむだな時間を使わせてしまいます。。。
ここまでやってきたなら助けてあげようと
相談相手に思ってもらうことにもつながるのでここは重要です！
ログや環境を伝える
エラーが出て相談したい時に重要なのは、再現性です。
相談相手も、情報が十分にないと解決のしようがありません、、、
実際に質問される側になるとわかるのですが、
自分が何も関わってないコードのエラー解決って必要な情報が多いんですよね、、、
なので、最低限エラーログや自分の環境、
エラーが再現できる小さなコードなどを用意しておきましょう。
主語、目的語を省略しない
再現性につながる話ですが、これも意外と忘れがちな観点です。
自分でやってると、当たり前になっている前提は
他の人にとって当たり前ではありません。
前提が揃ってないと、欲しい答えももらえないし
お互いに損する可能性が高いです。
それを防ぐためには、主語や述語、背景、目的などを整理しておくことで
前提が揃えやすくなります。
また、文章で残しておくことで同じような問題が他の人や未来の自分に起こったときに
その文章を見返すことで同じ轍を踏まなくて済みます。
アンチパターン
いわゆる丸投げ質問ですね、、、
これをしているとチームからの信頼を落とすことになるので避けたいです。
なかなか完璧にはできないと思いますが、（私もまだまだですが）
姿勢は伝わると思います。
場合によっては、本当に何も手が出ないこともあると思います。
そんな時は、素直に「わからないので教えてください、、、」とお願いするしかないですね。笑
2.認識を合わせる
チームに入って経験が浅いうちは、
タスクを任せられることが大半だと思います。
そこで気をつけたいのは認識のズレです。
カレーを作ってとお願いされて、家庭的なカレーを作ったら、
実はスープカレーを想定されてた、、、→ やり直し
みたいなことが起こります。（？）
そういった認識のズレをうまないために次のことが大事になります。
理解したことを自分の言葉で話す
何かを教えてもらった時、
「わかりました！」だけになってませんか？？
本当に理解できていて、問題なかったらよいですが、
念の為、自分の言葉で「〇〇はこういうことですね！」と返事をしたいです。
こうすることで、その時点で理解がずれていることが確認できるので、
やり直しリスクを下げることができます！
言葉の定義もあいまいなまま進めると痛い目を見る可能性があるので
その時点で確かめておきましょう。
※ 全て聞いていたらキリがないので、ここがずれていたらまずいという箇所を確認しましょう。
タスクを振られたら、方針を伝える
タスクを渡された時、
「わかりました！」だけになってませんか？？（n回目）
ある程度仕事に慣れていて、方針が見えている場合は問題ないですが、
よくわからないままタスクを始めるのは、
「コンパスや地図を持たずに、山に登ろう」となっている状態です。
（おそらく遭難して救助を呼ぶことになります。。。）
タスクを渡された時は、ざっくりでよいので、
「AAAをして、BBBをして、CCCをしようと思います。」のように方針を伝えましょう。
ここでも間違っていたら方向性の修正ができるし、
よりより方法があればアドバイスをもらえるかもしれません。
その時点で、方針が整理できない時は少し時間をもらって
「後ほど方針のすり合わせをしたいです。」のように伝えましょう。
今取り組んでいることを共有する
デイリーのミーティングなどで、
今日やることや悩んでいることを共有しているチームは多いと思います。
ただ、もっと細かいスパンで上司に自分が今何をやっているか共有できるとよいです。
共有ができていると、変な方向に進んでいた時にストップをかけられるし
上司も進捗を把握しやすくていいことだらけです。
具体的には、Slackなどで今やっていることをつぶやいたり、
次に取り組む予定のタスクをつぶやいたりすると手間もかからずできます！
3.アクションは素早く
これについては、エンジニアだけではないですが重要です。
アクションというのは、チャットの返信だけではなく
自分が困っている時にヘルプを出すことも含まれます。
例えば、
「ここってどうなってる？？」
「ここを〇〇みたいに修正しといて〜」
となった時に、みなさんはどう反応するでしょうか？
どうしても完璧に情報をまとめて返事をしたいですよね、、、
ただ、かなり時間かかることが多いです。
そういう時に、いったん現状わかることを返信するをやってみてください。
上司があなたに何かを聞いているということは、
それについての情報が欲しいからです。
あなたの回答によって、上司は次のアクションを考えます。
ということは、あなたの返事が遅れると、、、
そうならないように、
まずは現状でもよいのでアクション（返事）を返しましょう。
すぐに回答が出せないこともあると思います。
その時は少し時間をもらって、「〇〇までに回答いたします。」と伝えましょう！
レスを早くすることは、技術があるかどうかは関係ありません。
それだけで信頼が貯まるなら、やるしかありませんね！！！（圧）
まとめ
経験が浅いエンジニアが、新しくチームに入った時に意識したいことをまとめてきました。
技術面以外で貢献できると知ることだけでも価値はあったのではないでしょうか？
もちろん日頃から技術を勉強していくことは前提ですが、
私たちは仕事をしているので、いわゆるソフトスキルに目を向ける機会になればと思います。