はじめに
どうもこんにちはもきお(@mokio_50)です。早いもので未経験からエンジニア転職し1年が経ちました。
なので今回は自社開発企業に入社してからの1年間を振り返り、エンジニアに必要な要素って何なのかを考えていきたいと思います。
自分自身の振り返りと自社開発企業での働く風景がどんなもんなのか少しでも感じてもらえたら幸いです。結構なボリュームになっているので何回かに分けて読んでいただいた方がいいかもしれません。
簡単な企業概要
イメージを持ってもらうために弊社のフワッとした企業概要を記載しておきます。
- 従業員200名前後
- 自社サービス4つ稼働中、来月より新サービス開発予定(Rails, React, TypeScript)
- 既存サービス：バックエンドRails、フロントHTML、CSS、JS、一部React
- データ分析でPython使用
- かなりDBのレコード数が多く検索が重くなるため、ところどこでElasticsearch使用
１年間に完了したタスク数
まず1年間にこなしたタスク数は、、、
231件！意外とやってましたね笑
これからどんなタスクを今までやってきたのか、何が大変だったのかを振り返っていきたいと思います。
入社1〜2ヶ月目
まずは自分も気になっていた初日から。
初日に何をやったかというと午前中に入社オリエンテーションでコンプライアンス研修等(よくあるやーつ)を受け、午後からPCセッティング、開発環境の構築で1日が終わりました。
弊社の開発スタンスとして研修なんてもんは一切ありません。開発しながら学んでスタンスです。OJTまではいかないですが基本的にわからない事があれば相談できる先輩がついてくれてました。
なので入社二日目から早速簡単なタスクから着手させていただきました。具体的にどんなタスクをやったのかというと簡単な文言修正やCSSの調節などです。こんな簡単な事ですが実際に使用されているサービスを変更し反映された時は楽しさを感じていたのを今でも覚えています。
1週間後くらいから簡単なCRUD機能(新規、編集、削除等の一連の流れができる機能)を実装させていただけることになりました。そこで早くも軽い挫折を味わうことに。笑
プルリクでのレビューコメント数がなんと62件笑
それくらいこのタスクだけで指摘を受けたということになります。
中々プルリクが通りませんでしたね。それだけ細かくレビューいただけるのはありがたいです。
大変だったこと
このフェーズで何が一番大変だったかというとコードリーディングでした。膨大なコード量により、とにもかくにも修正する箇所がどこのファイルに記載してあるかたどり着くまでが大変。知らなかったメソッド沢山出てくるし、メソッドがメソッドを呼んでそれであれがこうなってわーってなってました笑
こればかりは慣れと言いますが地道に読み進めるしかなかったですねー。ある程度慣れるまではこのメソッドは何をしているか、思い込みで読み進めていないか等、コードをちゃんと理解して読み進める事ができているか自問自答しながら読み進めていく事が必要であると感じました。
入社3〜4ヶ月目
ここら辺から少し複雑なタスクに着手するようになってきました。
具体的には簡単な自作メソッド作成、Slack通知機能追加、JSの改修など。
大変だった事
このフェーズで大変だったことは以下
- 質問するのが億劫になってくる
- 自作メソッド、変数名の命名に苦戦
質問するのが億劫になってくる
これは決して質問しづらい環境になったわけではないのです。自分自身が少しずつ慣れてきたせいで、自分でもっとできるんじゃね？と思い、質問せずひたすら自分自身で検証を繰り返してしまう現象がこの頃から起きました。
ここに関しては難しいところなのですが、適切な報連相タイミングを自分で明確に定められるよう日頃から意識する必要があるのかなと思いました。
どこまでやったら質問するのか、そもそもどの段階までは実装前に確認しないといけないのか。その辺を意識しながら失敗と改善を繰り返していく必要があります。
これは今でも課題として自分の中であり、適切なタイミングでの報連相は未経験からタスクをこなしていくにあたって一番必要な要素だと感じています。
自作メソッド、変数名の命名に苦戦
少し複雑なタスクを実装するにつれて、自作でメソッドを作成したり、変数定義する機会も増えてきました。それにより命名で苦労することに。命名は今でも苦労したりするのですが、
自分なりの命名力向上の流れとしては
1.リーダブルコードを読み基本的な命名原則を理解する
2.そのメソッド、変数名が本当にしていることは何かを考えて命名する
3.その命名が正しいかどうかをひたすら自問自答する
入社5〜6ヶ月目
5ヶ月目からはバッチ処理を1から作成したり、重複コードが沢山書かれているファイルをリファクタリングしたりとロジックをしっかり考えないといけないタスクに着手するようになりました。
この頃からはJupyter NotebookでPythonを使用したデータ分析に携わらせてもらったり、Elasticsearch使用している箇所の改修を行なったりとRuby、Rails以外の分野に携わることも増えてきました。
Ruby、Railsに少しずつ慣れてきたなと思った矢先、また新しい技術に触れることになり全然できねーなーと自己肯定感が下がり始めたこともしばしば笑
バッチ処理とは？
一定量の(あるいは一定期間の)データを集め、一括処理するための処理方法のこと。
定期的に行いたい処理をファイルにまとめ、スケジュールを設定することにより、手動で処理を実行しなくても定期的に自動でバッチファイルを実行してくれるようになる。
Railsだとlib/tasks配下でバッチ処理ファイルを作成し、cronで定期実行する事が多い。もちろんcron設定しないバッチ処理ファイルもある。
具体例：一定期間経ったメールを自動削除する。一週間ごとにあるテーブルのデータを一括更新するなど。
大変だったこと
- 新しい技術のキャッチアップ
- しっかりとしたロジックを考える
- 既存コードのリファクタリング
新しい技術のキャッチアップ
一つの技術をある程度極めれば他の技術にも応用が効いて技術のキャッチアップが早くなるというけれど半年程度の実務ではあまり応用が効かない事がわかりました笑
とは言ってもそんなに似ている技術でもないので応用が効きづらいということもあるけども。
そんな中でもデータ分析で想定通りの値が取れたり、Elasticsearchを改修し、実際に検索した時の速さに驚いたりとやはり新しい技術に触れるのは楽しいなとつくづく思わされる期間でもありました。
しっかりとしたロジックを考える
今まではある程度明確に実装が決まっていたタスクをこなしていましたがこの頃からある程度抽象化されたタスクに着手するようになりました。
行いたいことをどうロジック化し、コードに落とし込んでいくか。これがなかなか大変。
まぁどう足掻いても最初は最短ルートなんてもんは辿れるわけなくて、どうしても遠回りした実装になってしまい、何度もレビューで戻される日々。
その中でもどう抽象的なタスクに対してなるべく遠回りしないで実装できるかを自分なりに考えてみました。
1.ロジックを考えた時点でGitHubのissueに記載し必ず先輩にレビューをもらう。
2.実際どう実装するか列挙する。(俗にいうタスクばらし)
3.実装
とりわけ1が重要かなと思います。ある程度自分でロジックを考えたらすぐ実装したくなりがちなんですが、そのロジックに穴があったり、そもそもそのロジックだと要件を満たさないよね、なんてことがしょっちゅうあります。
ここで確認することによって大きく道を逸れることが基本的になくなるため、実装後のレビューで大きく出戻りする、なんてことを防ぐ事ができます。
2の具体的な実装手順を列挙するのも大事です。実際タスクばらしせずに実装に入り、詰まってしまった際に、タスクばらしをしても遅くはなく、一定の効果があると思うのでぜひやってみてください。
既存コードのリファクタリング
今までちょっとしたリファクタリングはしてきたのですがガッツリとした既存コードのリファクタリングは初めてでした。
リファクタリングが上達するためにはコードを読んだり書いたりしている時に、常にそのコードをリファクタできないかを考える事が重要だなと思います。そうしないといつまでもリファクタリングのパターンを覚えられない。
リファクタを意識→実際にリファクタ→自分の中でのリファクタのパターンが増える。この循環ができればリファクタリングが自然と上達していくのかなと感じました。この循環を生み出すにはまずリファクタリングしようという意識を日頃から持ち続ける事が大事というわけです。
どのような観点でリファクタリングしているかは以下の記事に書いてるのでもしよければご覧ください。
入社7〜8ヶ月目
この頃からスクレイピングにも着手することになりました。スクレイピングって難しそうなイメージあったけど人間が実際に操作してるのをそのままコードに落とし込んでいる感じでした。
また、今までもちょくちょく簡単なレビューはさせてもらってたんですが、8ヶ月目からは2人のレビューを正式に担当することになりました。しかも担当した2人ともエンジニア歴自分より上 笑
大変だったこと
- スクレイピングのコード追うの大変
- レビューするのむず過ぎ問題
スクレイピングのコード追うの大変
スクレイピング自体は自作のGem使ってるしレスポンスのデータを保存していくコードもRailsでなくRuby直書きでクラスを継承しつつ記載されていたのでなかなかコードを追うのが大変でした。
ここら辺になってくるとちゃんとした継承やモジュールの知識が必要になってきたので改めてチェリー本で復習し始めました笑
レビューするのむず過ぎ問題
8月から正式に2人のレビューを担当させていただくことになったのですが、最初それはそれは大変でした。自分の実装する箇所でも難しいのに他人が書いたコードを理解し、レビューしていくなんて。笑 最初はレビューに業務の40%くらい使ってしまう日もありました。
とはいっても1ヶ月くらい経つとプルリクに対するコードの理解は結構早くなっていったかなと思います。しかしまだまだより良いコードにするための指摘はできるにはまだ時間がかかりそうです。
レビューをすることによって感じているメリットは以下の２点
1.初見コードに対するコードの理解が早まる
レビューを定期的に行うことによって自身が実装する際、既存コードに対する理解がかなり早くなった気がします。未経験の方からすると意外かもしれないですが、1日の業務の大半はコードリーディングや実装方法を調べることで終わります笑
そう、エンジニアって完全なサービスの新規開発でない限りはそんなにコード書かないんですよ笑
圧倒的に書いている時間より読む時間のほうが長いです。なのでコードを読むスピードが早ければそのまま業務をこなすスピードも早くなるというわけ。
2.より良いコードを書くための提案機会が増える
最初からある程度形になっている状態のものをレビューする訳なのでリファクタリングを意識せざるをえない状況に自然となるわけです。
3.他人が書いたコードを読む機会が増える
まあこれは当たり前ですが他の人がどう実装しているのかを知る事ができるし、その実装を自分の実装に生かすことができます。
そしてレビューで自分の技術力を最大限上げることができるなと感じている方法をご紹介したいと思います。それは自分のレビューに対するレビューをしてもらう(追加レビューをしてもらう)という事です。これはねー控えめに言って良いですよ笑
自分はよく少しでも自身のレビューに不安があったら、すかさず自身のレビューに対して先輩に追加レビューをお願いする事があります。
これはすごく有効で(といっても先輩の時間を奪ってしまうかもしれないけど笑)自分が気付かないところを指摘してたり、自分のレビュー自体が間違っていることもあるのでそこを指摘していただいたりと本当に参考になることばかりです。
レビューって自分のレビューが正しいのか不安になったりどうレビューしたらわからなくなったりするので正しいレールを引いてくれているのを直で感じられる機会ほど有難いものはありません。環境によっては忙し過ぎてそんなの依頼できないよとなる方もいるかもしれませんが、ある程度余裕がある企業ならぜひやってみてください。
入社9〜10ヶ月目
ある程度業務が一巡したのでやっと慣れてきた感は出てきました。もちろんインフラ周りやモダンフロント技術はまだまだだったりするのですが。
また、10ヶ月目くらいからはレビューも結構慣れてきた感じはありました。レビューで指摘する点もある程度パターン化してきて、コードの品質を担保するための指摘も段々とできるようになってきた実感はあります。
それでもまだまだ難しい実装へのレビューに対しては秘技「先輩への追加レビュー依頼」を使っていますが笑
実装自体はActiveRecordを使用しSQLをゴリゴリ書いたり、Polymorphicを使用した関連付けをしたりしてました。
大変だったこと
- SQLを意識した実装
- レビューに対する指摘
SQLを意識した実装
Railsでパフォーマンスを意識する上で一番重要視すべきなのは「いかに発行するSQLを最適化するか」だと思います。
テーブル同士を結合する方法もjoins,includes,preload,eager_loadなど様々です。その中からその実装にあう最適な結合方法を選んだり、かなりデータ量の多いテーブルを結合する場合はあえてテーブル結合せずにSQL分割してデータを取得する場合などもあったりします。
そういった感じでただ実装するだけでなくパフォーマンスを意識した実装もここら辺から(というか前から要所で求められてはいるんだけども)求められ、色々調べていくうちに時間が溶けていきました笑
レビューに対する指摘
段々とレビューに慣れてきたことでそんなに複雑な実装でなければ比較的指摘することができるようになってきましたが、まだまだ複雑な実装に対するレビューは納得のいくレビューができていない気がしています。
ここに2,3ヶ月がっつりレビューする事が増えて一番感じていたのは、プルリクに対するセルフレビュー(プルリクを作成し、レビュー依頼する前に自身で記載したコードに対してGitHubで事前にコメントを残しておくこと)の大切さです。
セルフレビューがほぼされていなかったり、プルリクでの概要欄の説明があまりに薄かったりするとマジでレビューする気が失せます笑 これはレビュー側のコストが格段に増えるし、セルフレビューがないとレビューする側が実装の理解に乏しくなり、レビューの質も下がってしまう傾向にあるかなと思います。
なので最近はより自身の実装ではセルフレビューを大切にしているし、レビューする際にセルフレビューがほぼない場合はセルフレビューを依頼します。
セルフレビュー、プルリクの概要欄、issue(どういったバグの原因とかどういう実装をしたのかとか)は丁寧すぎるくらいがちょうどいい気がします！
入社11〜12ヶ月目
この頃になると、振られたタスクに対して全く実装の想像がつかない、なんてことはなくなってきました。ある程度の実装方針を持って上司に相談できるようにはなってきたかなと思います。
初めてやったこととしてはdelayed_jobによる遅延処理ですかね。背景としてはCSVダウンロードを実装している箇所のデータ量が多くなることによって、SQLのクエリが重くなり、タイムアウトしてしまいCSVダウンロードが失敗してしまっていたことがありました。それを遅延処理を使用しCSVダウンロードを失敗しないようにするというタスクでした。
具体的にどうやってやったかというと、ダウンロードボタンを押したらCSVファイルの作成を開始。CSVファイルが作成されたらAWSのS3(AWSのデータ保管場所)にアップロード。その間該当ファイルがあるかJS側で定期的にS3にダウンロードするリクエストを行い、該当ファイルがあったらダウンロードするという流れで実装しました。
そこまで大変だったことはなかったのでこの期間での大変だったことは割愛します。
エンジニアに必要な要素とは？
ここまでエンジニアになってからの1年を振り返ってきました。未経験からエンジニアになる上でエンジニアに必要な要素は沢山あるなと思いますが、その中で２つピックアップしました。
- 適切なタイミングでの報連相
- とりあえず形にする能力
適切なタイミングでの報連相
一番はこれに尽きるかなと思います。タスクをスムーズにこなす上で最も大事なことであり、今でも難しいなと感じていることでもあります。
これは自分自身まだ答えが出ていないのですが、意識することはどのタイミングで相談したら大きな出戻りがなくなるかを常に意識することが大事なのかなと思いました。小さな出戻りは全然問題ないと思います。
この能力を仮に転職活動時アピールするのは難しいなと思うんですが、強いて近しいかもなと思うのはQiitaや他技術記事などの定期的なアウトプットや、個人的に日報などを書いているかとかですかねー。
定期的に自分の知識や行動をさらけ出しているともちろん文章能力も上がるだろうし、それによって報連相も自然と苦じゃなくできてくるのかなと思いました。
とりあえず形にする能力
とりあえず60%~70%くらいのクオリティでも形にしてプルリクを上げるのもすごく大事かなと思います。まあやり切れる力ともいうんでしょうか。
一旦形にしたものを修正するのは比較的早いし、レビュー側も形にしていない段階で相談されるよりもより具体的にレビューをすることができます。なので一旦作り切れちゃう能力はタスクをスムーズにこなす上でとても重要な能力かなと思います。
この能力をどうやってアピールするかですが、これは自作のポートフォリオのクオリティになってくるのかなーと思います。
とはいってもそんなに難しいものというよりはまずはエラーの起きないポートフォリオにして最低限ちゃんと動くアプリにする。その上で追加機能を実装していく。クオリティを段階的に上げていくのが良いのかなと思います。
あとがき
さて、ここまで読んでいただいた方は何人いるのでしょうか？笑
最後までご覧いただきありがとうございました！少しでも自社開発企業での働く感じが伝われば幸いです。(企業によって全然働き方、やること違うと思うけども笑)
最近は来月の新サービスの開発に向け急ピッチでフロントのキャッチアップを行なっている最中です。もし振り返りを記事にされるようでしたら2ヶ月おきくらいにやっておくのが良さそうです。マルっと1年は心が折れそうになりました笑
弊社リファラル採用も積極的に行なっているのでぜひ少しでもご興味あればTwitterのDMまでご連絡ください。また、エンジニアに関するご相談でも自分がお役に立てるか分かりませんがウェルカムです。
Twitter：@mokio_50