2021年4月に入社してから、もうすぐで1年になるので、この1年で学んだことを振り返りたいと思います。
ただ、学んだことと言っても技術的な学びになると数えきれないくらいあるので、仕事の進め方やマインドセットの部分を中心に振り返っていこうと思います。
1人で抱え込まずに他人を頼る
入社した最初の頃は、Javaの研修からスタートしました。エンジニアって自走力が大事だとよく言われるじゃないですか。。その自走力を、僕は他人を頼ってはいけないことだと思い込んでいたんですね。
未経験で入社したので、最初はどうしてもロジックの組み方であったり、エラーが解消できないであったり、様々な壁にぶつかりました。「1人で解決しないといけない」という考えだったので、誰にも頼らず進めていたのですが、やはり限界がありました。
周りの同期や講師の方に質問すると、あら不思議、詰まっていたところが簡単に解決できました。講師の方も、「詰まって1人で悩むのは時間の無駄だから、すぐ質問してください。」と言っていたので、他人の力を借りながら進めることの大切さを学びました。
アラートは早めに出す
実際の業務では、スケジュールに基づいたタスクが振られると思います。でも…割り振られたタスクがスケジュール通りにこなせない時もあります。実務に入りたての頃とかは特にそうです。そもそも仕事の進め方が把握できていないとか、エラーにぶつかりまくるとか、スケジュールの遅延には様々な理由が考えられます。
ただ、そこで絶対にやってはいけないことが、進捗を盛ることです。僕が参画しているプロジェクトでは、朝会と夕会があって、そこで進捗の共有をします。
正直なところ、その日の進捗が良くなければ言いたくない気持ちもわかるし、進捗が悪いことを咎められるかもしれないと思う気持ちもわかります。ただ、進捗をごまかしたところで後で絶対に自分に返ってきます。
遅延を起こすと思ったら早めに言うこと、遅れるかもしれないと報告しても、案外詰められることはないです。PMの方がタスクの振り直しをしてくれるので、早めに言うほど自分のためにもチームのためにもなります。
1人で勝手に判断しない
実務を行なってるとどう実装しようかなとか、この部分の仕様はこれで良いのかなど、いろいろ悩むことが出てくると思います。先輩にいちいち聞くのも気が引ける…と思って、自分で考えてやろうとします。
しかし、残念なことにそういう時ってだいたい手戻りが発生します。手戻りが発生すると、進捗の遅れにも繋がるし、何より自分のメンタルがやられます。
技術的な質問をしまくると、「少しは自分で考えろ」と思われるかもしれませんが、方針や仕様の確認は何回やっても咎められることはありませんでした。先輩たちも、手戻りは絶対に発生させたくないはずなので、認識を合わせる努力は積極的にしていきましょう。
公式ドキュメントはマジで読め
公式ドキュメントを読めばわかるってよく言われません？実務に入るまで意味がわからなかったんですよね…。公式ドキュメントは英語のものが多いからそもそも読めないし、日本語のドキュメントでもどこに自分の欲しい情報があるかわからないしで、見たところで全然解決しないと思ってました。
でも、先輩に技術的な質問をしても、「公式ドキュメントに書いてあるけど、ここはこうでこうして〜」って言われるんですよね。。「いや、書いてるか…？」と思ってドキュメントを見直すと、しっかり書いてました。
人間は不思議なもので、ドキュメントを読み続けると何か読めるようになってくるんですよね。。英語のドキュメントであっても、DeepLなどの翻訳ツールが優れているので、変な日本語になる時もありますが、何となく読めるレベルには翻訳してくれます。
公式ドキュメントは、いわば取扱説明書のようなものだと思っているので、どんどん活用していきましょう！
手を上げるとタスクを振ってもらえる
1つ目に参画したプロジェクトでは、私はフロントの方を担当していて、次のプロジェクトではバック側も触ってみたいなという思いがありました。しかし、2つ目のプロジェクトでも何だかんだでフロントとして参加することになってしまいました。
ただ、PMの方からバックの実装のタスクもあるという話を聞きまして、「ダメ元でやれるか聞いてみよう」と思ってその意向を伝えたところ、めちゃくちゃあっさりタスクを振ってくれました。
何事も手を上げてトライすることは大事ですね🤔
コードレビューで同じ指摘を食らうな
プルリクエストを出した際に、書いたコードを見てもらってレビューをもらうことはあると思います。レビューをもらうこと自体は仕方のないことですし、レビューする側も完璧なコードが来るなんて思ってないでしょう。(もちろん、適当なコードを書いていいということではありません)
ただ、ここで問題となるのが、同じ指摘を何回ももらうことです。まあ人間なので、2回同じミスをすることもあるでしょう。。でもエンジニアに限らず、同じミスを繰り返す人は信用を失います。
とある参加プロジェクトでは、あまりにも同じ指摘をもらう人がいたので、プルリクを出す際のチェックシートのようなテンプレートが用意されたくらいです。
レビューする人が口を揃えて言うのが、同じ指摘はしたくないということです。セルフチェックは怠らずにやっていきましょう。。
常に横展開の意識を持つ
先に書いたレビューの話と近くなるのですが、とある部分のコードに対してレビューをもらった際に、他の部分にも適用できるのではないかということがよくあります。
横展開するようにレビュワーの方から言われることもありますが、毎回言われるわけではないです。(横展開できることにレビュワーが気づいていないということもあるので…)
横展開しなかった際の問題点として、レビュワーが指摘漏れに気づいてレビューが後からどんどん増えることです。自分の中では、修正が終わった！！！と思っても、後からどんどん指摘が増えるので、時間も取られますし、精神的にもダメージが来ます。指摘のリターンはできるだけ少なくするように努力していきましょう！
仕組みを理解することの大切さ
実務で新しい技術をキャッチアップすることがあると思います。自分が今まで触れたことのない技術なので、見たことのないエラーに出会ったり、そもそも何もわからなかったりで詰まりまくることもあるでしょう…。
僕が経験したのが、Reduxを触り始めた時に何回も同じエラーを出して、それが解決できないということがありました。そこで先輩に質問するのですが、先輩から言われたことが、そもそも仕組みを理解していますかということ。
仕組みを理解していないからエラーが出ても原因がわからない→原因がわからないから解決できないのループに陥っていたという感じでした。。
その1件があってからは、公式ドキュメントやいろんな記事を読んで仕組みから理解するように努めました。同じ質問をしまくるのも避けないといけないですね…。
チャットを送る際の気遣い
リモートで仕事をしていると、チャットで質問とか相談をする機会があると思います。ただ、チャットだとどうしても対面よりも質問の難易度が上がります。その理由として、
- 文章だけで自分の意図を確実に伝えないといけない
- チャットを送ってもすぐに返ってくるわけではない
- 文章だけでお互いの認識を合わせないといけない
などなど、他にもいろんな理由があるのですが、対面にはない難しさがチャットではあります。
例えば、実装でエラーとか詰まっているところが出て質問したい…という時に、もちろん文章だけで伝えられたら良いのですが、どうしても文章だけだと伝えられる情報に限りがあります。そこで使うのがスクショです。該当の箇所のスクショを撮って送るだけでフォローを入れやすい、と先輩には言われました。やっぱ視覚的な情報は大きいですね。。
また、すぐに返事が返ってこないことを考慮すると、会話の往復はできるだけ減らしたいところです。わかりにくい言葉を使わないとか、Yes/Noで答えられる質問にするとか、1往復で質問の会話が終わるように心がけていきたいです。
あとは、返ってきた答えに対して自分の認識が合っているかの確認はマジで必須です。「〜はこういう認識で合ってますでしょうか」という一言を挟むだけでも、認識違いによる大きな手戻りを防ぐことができます。チャットは難しいな、、
1年経ったけどわからないことだらけ
最後に、学んだことというか感じたことですが、やっぱりエンジニアという仕事は難しい…。
一応エンジニアとして1年働いてきたわけですが、次から次へとわからないこと、知らないことが出てきます。今参画中のプロジェクトでもわからないことだらけです。でも、自走力であったり質問力であったりと、成長を感じた部分もたくさんあったし、自分の思い通りにできたらやっぱり楽しいです！これからもどんどん積み上げていきたいですね〜
最後までお読みいただき、ありがとうございました！