はじめに
この記事はこの記事はサイバーエージェント24卒内定者 Advent Calendarの24日目になります。クリスマス・イブの日をゲットしました🤶
今回は技術の話とはちょっと離れて、私的脱初心者エンジニア論のお話をしようと思います。
自分がエンジニアとして実務開発を始めてから気づけば2年半。色んな縁あって様々な開発現場に携わらせていただきました。
当然ですが、エンジニアとして働くというのは、ただコードを書くだけではありません。コードを書くだけの人は真っ先にAIに潰されると思います。
経験を積むうちに、こう動けば頼りにされる、出来るエンジニアだと思われる、というのが自分なりに分かってくるようになったので、言語化したいという個人的モチベもあり、アドベントカレンダーの記事として皆さんにご共有できたらなーと思います🚀
実装編
1. 実装前に方針を決める
実装をする時は、あらかじめ「どの部分を、どのように実装するのか」の方針を立てます。
自分はつい最近まで、とりあえず手を動かして突っ走って実装を進めるタイプだったのですが、結局途中で全く違う実装の方がいいことに気づいたり、考慮漏れがあったりで、実装時間が無駄にかかってしまうことがしばしばありました。
トレーナーがいる場合は、実装方針を共有出来ると、手戻りもより圧倒的に少なく出来ると思います。
2.エラー対処法は発生箇所特定から
エラーにぶち当たった時は、まずはどこで発生しているのかを特定します。
エラーの強い見方console.logを色んなところに生やして、どこまで処理が進んだのか、出力されているレスポンス・変数は正しいのか、などを確認しながら発生箇所を特定します。発生箇所が分かったら、考えられる原因を洗い出し、その原因に対する解決方法を調べながら色々試してエラーを解決します。
よくありがちなのは、とりあえず吐かれたエラーログをコピペしてそれっぽい解決方法がヒットしたら、試しに変更してみてをエラーログが消えるまで試す、という対処法ですが、これは結果的に非効率になりがちで、対処できた時も「結局何が原因だったのかわかんないけどとりあえず動くからいっか🙄」で進めてしまい、何も学習せずにエラー再発を招きます。
3.公式ドキュメントリスペクト
技術について調べる時は、出来るだけ公式ドキュメントから情報をかき集めます。
極たまにやる気のない公式ドキュメントもありますが、大抵は公式ドキュメントにやりたい事の正しい答えが載っています。Stack overflowやMedium, Zenn, Qiitaなどの技術記事サイトよりも、公式ドキュメント第一優先で調査を進めます。
チーム開発編
1.相談をする時は背景も忘れずに
実装中に人に相談・質問したい時は、「何を実装しているのか・どこで悩んでいるのか・自分が思考した事」 を説明します。
特に一個目の 「何を実装しているのか」を背景含めて具体的に説明出来るといい です。
コードやUIが表示された画面を共有しながら話せると、より相手も理解しやすくなると思います。
話が長くなりそうな時は、途中で「ここまでで何か質問ありますか？」的な感じで都度相手の理解度を確認できると、相手の混乱も免れると思います。
また、相談のレベルを上げる方法論について以下の記事がおすすめなので、ぜひ読んでみてください。
2.現状共有で無駄な察し合いを断ち切る
ツイートする感覚で、今何を実装しているのか？何で詰まっているのか？などの現状共有出来ると、チームメンバーの安心感を獲得できます。
現状共有が少ないと、〇〇さんは今何をしているのかな〜もしかしたら実装に詰まっているのかな〜でももうちょっと様子みた方がいいかな〜みたいな無駄な察し合いが発生すると思っていて、これが開発効率を下げていたりします。特に新米エンジニアはしつこいくらいが丁度いいです。
3.テキストでの情報共有は「空・雨・傘」のストーリーを作る
これは内定者バイト時代のトレーナーさんにおすすめしていただいた、『ドキュメントコミュニケーションの全体観』という本で学んだ事で、何かテキストで情報共有するときは、
「空があって、雨が降ってきたので、傘をさす」
といったように、
- 背景
- 現状
- 現状に対するアクション
で説明出来ると、読む相手も圧倒的に理解速度が早まります。
コミュニケーション時の話で「結論 → 理由」という順序がいいとよく言われますが、これはどちらかというと口頭コミュニケーションの話で、テキストコミュニケーションの時は、ストーリー通りの説明が好まれると思います。
4.適度なアピール
自信を持って、「自分はこれくらい出来る！」と周りにアピール出来ると、任せてもらえる仕事もレベルアップします。
もちろん過剰なアピールは逆に反感を招きますが、適度にアピールすることで、「〇〇さんにこれ任せてみようかな」と思われるようになります。謙虚だといずれ損します。
5.レスの速さは信頼の獲得
レスは出来るだけ早く行います。これだけで、不思議なことに信頼を得て、仕事が出来る人だと思われます。自分にとっても「後でこれ返信しなきゃ…」という蟠りから解放されます。
自己成長編
1.自分だけの武器を見つける
どんなチームにジョインしても、これだけはチーム内で誰にも負けないと言えるような武器・専門的な知識があると、存在価値が一気に高まって相対的に強いエンジニアになれます。
自分も以前までは、エンジニアは物作り・サービス作りの手段としてしか考えていなかったので、この技術が好き！とか、この分野極めたい！みたいなものが特にありませんでした。
しかし、エンジニアとしてこの先生きていくためにということを考えると、何かしら武器に出来るものがあった方がいいと思い、とりあえずWebパフォーマンスに強くなろうという思考に、つい最近辿り着きました。
2.アウトプットを怠らない
何事もアウトプットが出来ると、言語化することによってより理解を深められ、それを他者へ共有することで自分はこんなことも知っているんだぞとアピールにもなります。記事を公開するとなると、それなりに時間をかける必要があってハードルが高くなりがちですが、転職などを見据えた時に自分の資産になるというメリットもあると思います。
3.自分を安売りしない
受託開発などの案件を引き受ける時は、出来るだけ自分の能力に見合ったお給料をくれる案件を選ぶことをおすすめします。
単価が安いということは、その分求められているクオリティ・技術力が低いという事だと思っていて、そのような案件を受けても、自己成長には繋がりにくいですし、コスパも悪くモチベーションが保てないと思います。
これであなたも脱初心者⭐️
これからお金を貰いながら開発の仕事しようと思っている方や、既にエンジニアとして働いている方も、今回お話しした私的脱初心者エンジニアと照らし合わせながら、自分を見つめ直すきっかけになれれば幸いです。
ハッピーホリデー！メリークリスマス！🎄