こんにちは！
株式会社ルーデルでUnityエンジニアをしている江連です。
早いもので、ちょうど新卒入社・配属されてから、ちょうど一年ほどが経ちました。
社会人一年目は、あっという間だったなあと思いつつ、私のチームにも、先月新卒の方々が来てくれましたので、これからは先輩としても頑張っていかなければと改めて気を引き締めているところです。
そんな、新卒の方から、「頑張りたいです！」、「仕事についていけるか不安です」と期待と不安が入り混じった声を聞くことが多くて、
「そういえば、自分も期待と漠然とした不安を抱えていたなあ」と思い出しました。
もしタイムマシンに乗って、入社したばかりの1年前の自分に会えるとしたら、何を伝えたいだろう？と考えることがよくあります。
そこで今回は、「一年前の新卒エンジニアの自分に伝えたい3つのこと」 を、ご紹介したいと思います。
今回のお話は、かなり個人的な意見になってしまいますが、これからスタートダッシュを決めたい新卒エンジニアの方へ何か一つでも気づきになれば幸いです。
「何か分からないことがあれば周りに質問しましょう」
新卒の方なら一度は聞いたことがあるアドバイスだと思います。
私も「沢山分からないことを質問するぞ！」と意気込んでいましたが、まず直面したのは、情報の大洪水でした。
社内ルール、開発環境のセットアップ、プロジェクトに関するドキュメント、膨大なコード、MTGや先輩たちの会話で出てくる専門用語の数々…
どれもこれもが全く知らないことだらけ…当初は分からないことが多すぎて何から聞けばよいのか分かりませんでした。
ただ、ここで、お伝えしたいのは、「分からないのは当たり前」 だということです。
例えば、運用中のサービスなら、これまでの開発体制や実装機能の仕様、不具合、新規機能などの開発側しか知りえない情報を理解したうえで、MTGをしていています。
そのため、これまで一ユーザーだった自分が、一回MTGに参加しただけで全て理解するのはかなり難しいです。
よく複数人で話しているグループの会話に混ざろうとしたときに、何の話をしているのか全く分からない。あの状態です。
だからまずは、分からないことについて、優先度を決めることをオススメします。
ここでいう、優先度とは、「自分の仕事を前に進める」 ことかどうかになります。
優先度を決めずに、闇雲に分からないことを聞いても、理解しにくいものや、直接自分の担当範囲に関係しないこともあるからです。
優先度が低い分からないことは一旦メモしておいて、まずは優先度の高い分からないことから質問していきましょう。
例えば、配属直後に優先度が高いものだと、開発体制や環境構築のセットアップが挙げられます。
- 開発体制なら、まずは直接やり取りする方の顔と名前を覚えることなど
- 環境構築のセットアップなら、プロジェクトの実行確認やGit等の周辺ツールの導入など
少し前置きが長くなってしまいましたが、これで優先するべき分からないことが整理できたので、次は、分からないことを質問していきます。
とはいえ、自分もそうでしたが、いざ質問をしようと思っていても、
- 先輩が作業に集中しているから、話かけづらい
- しっかり自分で調べてから、質問しないと先輩の時間を奪ってしまう
- 前にも同じ質問をしてしまったので、もう一度同じ質問をしづらい
- そもそも何をどう質問すればよいのか整理できていない
等など、実際に質問しようとすると、躊躇ってしまう場面が意外に多いです。
「そんなことは気にせず、とにかく質問してみよう！」と言われればそうなのですが、
ここでは、もう少し深掘りして、質問することに対して、ぜひ皆さんに2つのことをお伝えしたいです。
それは、
- 「質問することは、メリットだらけ」
- 「質問の仕方って実は色々工夫できる」
の2つです。
質問することは、メリットだらけ
一番のメリットは 「すぐに質問することで、問題解決までの時間が短くなる」 ことです
これは、私の失敗談ですが、
開発環境のセットアップをする際に、開発に使用するリポジトリをクローンして、プロジェクトを開いたのですが、実行するファイルが見当たらず、詰まってしまったことがありました。
解決しようと、リポジトリのクローンが上手くできているのかを確認したり、他の場所にファイルがあるかもしれないと必死に探していました。
結局、自分で解決することができず、先輩に聞いたら、「開発用のブランチが違うから、このブランチにチェックアウトすれば大丈夫だよ」とアドバイスを頂き、数分で解決することができました。
他にもエラー解決や実装に詰まってしまったときに、なかなか相談ができず、解決までにかなりの時間がかかってしまうことがありました…（恥ずかしながら、今でもたまにあります）
特にはじめは、躓いている箇所が、
- プログラミングの知識のような「調べたらすぐ解決できること」なのか
- プロジェクトの情報が必要になる「調べても分からないこと」なのか
- 「誰かに相談しないと進められない部分」なのか
など、自分で判断することが難しいです場合が多いです。
この辺は、仕事をしていく中で徐々に分かってきますので、エラーや分からないことに数時間費やすよりも、仕事を前に進めることを意識して、すぐに聞いてしまうのがいいと思います。
少し話はそれてしまいますが、エンジニアと聞くと、集中して黙々と手を動かしている時間が多いイメージを持っている方が多いかもしれません。
実際自分も入社前は、そう思っていました。ただ実際は、黙々と作業する時間と同じくらいコミュニケーションも取っています。
それは分からないことを質問したり、共有したりするからです。なので、積極的に声をあげてくれると周りは嬉しいと思います。
話を戻しますが、質問することで、「問題解決までのスピードが早くなる」メリットもそうですが、
それ以外にも、
- 質問することで自分の理解が合っているかどうかの確認ができる
- チームメンバーとのコミュニケーションのきっかけになる
- 間違った理解のまま進めることが少なくなり、手戻りが発生するリスクが削減される
などのメリットが挙げられます。
なので、気軽に質問してみてください。
質問の仕方って実は色々工夫できる
もちろん、なんでもかんでも質問することは相手の時間を奪うことになります。
（さっき、気軽に質問してねって言ったばかりですが…）
一度、新卒の方から質問を受ける自分を想像してみてください。
おそらく、新卒の方が質問せずにずっと考え込んでいるのを見ると、あなたはもっと質問してほしいと思うはずです。
ただ、何度も「分からないので答えを教えてください」という丸投げの質問をされてしまうと、あなたの時間も多くとられてしまい、困ってしまうはずです。
つまり、「自分で考えずに答えだけを聞く」 質問の仕方が、あまり良くないということです。
なので、ここでは、簡単にシチュエーション別の質問の仕方を紹介しますので雰囲気を掴んでもらえたらと思います。
紹介の前に、同じことを質問するにしても質問する側の理解度によって質問の仕方が大きく変わってくると思うので、まずは理解度を3つに定義してみました。
- やりたいことが分かっていない
- やりたいことは分かっているが、「こうしたらできるかも」が分からない
- やりたいことは分かっており、「こうしたらできるかも」とアイデアを持っているが、他にもっと良いやり方があるかもしれない
これらを元に、質問を考えていきます。
まずは簡単な例として、「今日の晩御飯に何を食べるのか」を上の3つの理解度に当てはめて考えてみようと思います。
■ やりたいことが分かっていない
晩御飯に何を食べたいのかが決まっていない状況です。
この時の質問としては、やりたいことを聞く。つまり「何が食べたいのか？」になります。
こちらの例だと相手ではなく自分に向けた質問にはなってしまいますが、ハンバーグなのか、カレーなのか、ぶりの照り焼きなのか、食べたい料理が答えになります。
■ やりたいことは分かっているが、「こうしたらできるかも」が分からない
今日の晩御飯はカレーに決めました。しかし、カレーを食べるにはどうすればよいかわからない状況です。
この時の質問としては、「どうすればカレーを食べることができますか？」とやりたいことを達成するための手段を聞くことになります。
この時の答えの一例として、「食材があれば家でカレーを作ることができます」になります。
■ やりたいことは分かっており、「こうしたらできるかも」とアイデアを持っているが、他にもっと良いやり方があるかもしれない
カレーが食べたくて、家で作るために必要な食材を買いに行こうと考えています。
ただ、もっと手軽にカレーを食べられる方法がないか探している状況です。
この時の質問としては、
「食材を買いに行って家で作るより、もっと手軽にカレーを食べる方法はありますか？」
となります。
とこんな感じで、多少無理やり感はありますが、雰囲気が伝わっていればOKです。
では、今度は実際によくありそうな
- エラーが発生したとき
- 実装で困ったとき
の2つのシチュエーションで見ていきましょう。
エラーが発生したときのケース
■ やりたいことが分かっていないケース
コンソール上でエラーメッセージが表示されたが、それが何を示しているのか、何を解決しなければならないのか分からない状況です。
ー 質問例 ー
○○をしたときに画像のようなエラーが表示されました。
こちらのエラーは何を意味しているのでしょうか。
また、どうすればいいでしょうか。
■ やりたいことは分かっているが、「こうしたらできるかも」が分からないケース
エラーメッセージを読んで、何が原因でエラーが発生しているかはわかっているが、どうすれば解決できるのかが分からない状況です。
ー 質問例 ー
○○をしたときに画像のようなエラーが表示されました。
こちらのエラーは○○が原因だと考えているのですが、その原因を解決する方法が分かりません。
原因を解決するために、どのようなことをすればよいのか教えていただけないでしょうか。
■ やりたいことは分かっており、「こうしたらできるかも」とアイデアを持っているが、他にもっと良いやり方があるかもしれないケース
エラーメッセージを読んで、原因と解決策は分かっているが、それが最善なのか分からず、他にもっと良い方法があるかを知りたい状況です。
ー 質問例 ー
○○をしたときに画像のようなエラーが表示されました。
こちらのエラーは○○が原因になっており、解決のためには、○○のような対応が必要になると考えています。
ただ、他にもっとよい方法があればお聞きしたいです。
実装で困ったときのケース
■ やりたいことが分かっていないケース
○○という機能やツールがあるが、何ができるのか、どこから手を付けたらよいのか分からない状況です。
ー 質問例 ー
この機能/ツールは、何をするためのものでしょうか。
また使ってみたい場合は、どのような手順で始めるべきでしょうか。
■ やりたいことは分かっているが、「こうしたらできるかも」が分からないケース
実現したい機能は分かっているが、実装方法のイメージがついていない状況です。
ー 質問例 ー
○○を実装したいのですが、○○の部分で詰まってしまい、どのように実装すればよいか悩んでおります。
何かアドバイスいただけますでしょうか。
■ やりたいことは分かっており、「こうしたらできるかも」とアイデアを持っているが、他にもっと良いやり方があるかもしれない
実現したい機能が明確で、自分なりに「こうすればできるだろう」という方法もあるが、それがベストプラクティスなのか、他に良い方法があれば知りたい状況です。
ー 質問例 ー
○○の機能を実装するために、○○のような実装方法を考えているのですが、
他にもっと良い方法があれば教えていただけますでしょうか。
かなりざっくりには、なってしまいますが、自身の理解度に応じて質問の仕方を変えるといいのではないでしょうか。
ただ、はじめから理解度を高くすることは難しいと思います。
そんな時は、「○○にした理由を教えてください」 と答えを出すための背景を聞くようにすると、徐々に自分の意見を入れられるようになると思います。
「はい、なんとなく理解しました」
これは、質問に答えてもらった際に、私がよく口にしていた言葉でした。
分かったような、分かっていないような、そんな曖昧な状態。
相手に理解したかのように見せる、まさに魔法のような言葉です。
この「なんとなく理解したつもり」の状態が、後々どれほど自分を苦しめることになるかも知らずに…
まずは「なんとなく理解したつもり」が引き起こす問題について2つの事例を交えて紹介していきます。
一つ目は、これから実装する仕様を曖昧に理解していたケースです。
仕様書に従って実装を進めていく場合に、記載漏れや矛盾点がない仕様書は珍しいです。
そのため、実装する側は疑問点について企画の方と、すり合わせる必要があります。
ただし、その確認を怠り、実装する側で勝手に解釈してしまうと、
実装が完了した後のテスト工程で、企画が想定していた挙動と異なる場合があります。
そして、不具合として報告され、修正をする手間が発生します。
二つ目は、実装に悩んでいるあなたが、リードエンジニアの方に実装の相談をした際に、提案された実装に対して「なんとなく理解しました」と答えたケースです。
相談した後、いざ実装していくと確認できていなかった細かい部分に気づきました。
ただ、すでに理解しましたと言っていたので、今更聞くのは恥ずかしいと思い、あなたはそのまま実装を行い、なんとか動かせたので、PRを出してみます。
すると、レビューコメントで、
「ここは、○○というケースがあるので、こういう実装はしてはいけません。これは、さっき話した部分ですよね。あの時、理解しましたって言っていましたが、理解できていなかったということですよね。すみませんが、修正をお願いします」
と、かなり心をえぐるような…レビューが返ってきました。
なんとなくの理解によって、これまでの実装にかけていた時間が無駄になり、手戻りが発生してしまいます。
「なんとなく」をなくすためには
先ほど挙げた悲惨なシチュエーションを避けるために、どうすれば、「なんとなく」の理解を少しでもなくせるか考えていきます。
個人的には、
「理解しました という前に、理解したことを自分の言葉で説明する」
これに尽きると思います。
特に2つ目のような実装の相談については、
- 目的・実現したいこと
- その目的の達成を妨げるもの
- どんな障害があるのか、その障害が起こる要因
- 課題を解決する方法
- 特に解決方法が複数ある場合は、それぞれメリットとデメリットを抑えつつ、どんな判断で選択したかを把握する
この三つを意識するとよいと思います。
内容によっては、システムの全体像やコアな部分についての理解が必要になる場合もあるため、一度で理解することは難しいかもしれません。
そういった場合は、理解している部分と理解していない部分をまずは分けてみて、理解していない部分については、実装を進める中で改めて質問してみるのもありだと思います。
先ほどの「なんとなく理解しました」をなくすところでも触れましたが、理解することは本当に難しいです。
ベテランエンジニアの方々が話しているのを聞いて、私が気づいたのは 「理解している＝実装のイメージができている」 ということです。
会話をする上で、実装のイメージができているからこそ、コードを見せなくても、ある程度話を進めることができます。
また、エンジニアはコードを書きますが、実際にはコードを書く時間よりも、コードを読む時間の方が圧倒的に長いです。（体感的には、「コードを読む時間：書く時間 ＝ 7：3」ぐらいです）
考えてみれば、当然なのですが、
ある程度作られているプロダクトに何か新しい機能を足す場合に、既存のコードを読まずに、みんなが好き勝手に書いてしまうと、
- どこに何が書かれているのかわかりづらかったり
- 既にある便利な機能のメソッドを見逃して、まったく同じ機能を作ってしまったり
- 拡張性に乏しかったり
と、動くものができたとしても、それは今後の開発に必ず影響してきます。
（おそらくレビューしてもらう際に、ここら辺は指摘されるとは思いますが）
正直なところ、私もコードを読むことは苦手で、読んで理解したと思っていても、コードを書くときに手が止まってしまったことがよくあります。
これは、まさに 「なんとなく理解していた」 状態になります。
そして、ベテランエンジニアの方が読むだけでコードを理解できるのは、これまでの実装経験があるからです。
そのため、個人的には、ログを出したりコードの一部を変更してみるなど、「小さく手を動かすこと」 で一歩ずつ理解を積み重ねていくのが良いと思います。
また、ログを使うときは「あるメソッドがどの順番で実行されているのか」、「変数の値や計算処理の前後の値の出力」を確認してみるのもオススメです。
まとめると、
「質問して、手を動かしながら理解していく」
という当たり前のことかもしれませんが、それが一番大事だと感じています。
まとめ
長くなってしまいましたが、ここまでお読みいただきありがとうございました！
いかがだったでしょうか？
今回は、自分の体験談を踏まえて、「一年前の新卒エンジニアの自分に伝えたい3つのこと」を紹介しました。
「共感できる」や「もっと伝えるべきことがあるだろう」と色々な感想があるのかと思いますが、これを読んで少しでも意識してみようかなと思ってもらえたら嬉しいです。
新卒の皆さん、頑張ってください！
レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい”当たり前”を作り続ける」というミッションを推進しています。
現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。
Views: 0
