この記事はクラウドワークスグループ Advent Calendar 2024 シリーズ1の9日目の記事です。

クラウドソーシングサービス「クラウドワークス（crowdworks.jp）」で24新卒のエンジニアとして働いている原です。

未経験で開発を始めてからもうすぐ1年になるので、「1年で自分の意識が変わったと思う3つのこと」について書こうと思います。

自己紹介

大学では文学部でドイツ語を専攻していました。当時は自分がエンジニアになるなんて考えてもみていませんでしたが、IT系ベンチャー企業でのインターンを通して開発の仕事に興味を持ちました。

大学卒業後はドイツに渡り、大学でコンピュータサイエンスを専攻。2年間の留学を経て2023年に帰国し、2024年4月に新卒枠で株式会社クラウドワークスに入社しました。

この1年で自分の意識が変わったと思う3つのこと

クラウドワークスへの正式な入社は2024年4月ですが、入社前の2024年1月からインターンをしていたので、開発らしいことを始めてもうすぐ1年になります。

インターン開始時は、プログラミング自体は大学でやったことがあるけれどもウェブ開発はまったく未経験、という状態でした。

インターンの内容は、Ruby on Railsを使った開発の入門として、簡単なブログ投稿サイトを構築するというもの。その時は完全に個人開発で、チーム開発を始めたのは正式入社後からでした。

3か月の個人開発と9か月のチーム開発を経て、自分の意識が変わったと思うことは以下の3つです。

コミット履歴をきれいにするようになった
公式ドキュメントを読むようになった
"早くやればいい"というものではないと気づいた

それぞれ詳しく書いていきます。

1. コミット履歴をきれいにするようになった

1つ目は、コミット履歴をきれいにするようになったこと。

インターン時代の個人開発では、そもそもコミットを分けるということをしていませんでした。

1機能につき1プルリクエスト、1コミット。
どんなに変更行数やファイル数が多くても1コミット。

今思うとどんなにレビューしにくいプルリクエストを作ってしまっていたんだと、申し訳なくなります。

しかし、チーム開発を始める前後くらいで、コミット履歴について書かれたQiita記事「コミット履歴が " きれい " なPRはすごく助かる。ありがたい。好き。¹」を読みました。

当時私はまだコードレビューに参加していなかったこともあり、レビュワーの負担について考えたことがなかったのですが、この記事を読んで「コミット履歴がきれいなことって大事なんだ！」と思うようになりました。

それからというものの、コミットを適切に分けたり、コミットする順番を考えたりするようにしています。

また最近では、コミット履歴を書き換えることのできるGitコマンド git rebase -i HEAD~X（※XはHEADから遡って何個のコミットを対象にするか） を先輩社員から教えてもらったので、これを使用してプルリクエストを出す前にコミット履歴をきれいにするようにしています。

例えば、コミットをいくつか積んだ後に、些細なコードの間違いに気づいた時。

以前は、後から「◯◯の微修正」「◯◯の対応漏れを修正」といった内容のコミットをいくつも積んでそのままにしていましたが、git rebase -i HEAD~X を覚えてからは、そういったコミットは本来それが含まれるべきコミットに統合するようにしています。

まだまだコミットの切り分け方やコミットメッセージの文言等々で悩むことも多いですが、意識し続けて慣れていきたいです。

2. 公式ドキュメントを読むようになった

2つ目は、プログラミング言語やフレームワーク等の公式ドキュメントを読むようになったことです。

新人あるあるな気がしますが、公式ドキュメントは英語で書いてあることも多いので、以前はなんとなくとっつきづらくて避けていました。

特にインターン時代は1回も公式ドキュメントを読んだことがなかったかもしれません。

ですが、公式ではないネット記事に載っている情報やAIに聞いて得た情報は信頼性が定かでなく、厳密性にも欠けることがあるため、それらを確たる根拠として実装したりレビューしたりすることはできないなと思うようになりました。

それからはCSSのプロパティでもRuby on Railsのメソッドでも、使い方に自信のないものはなんでも公式ドキュメントで調べるようにしています。

ただし、ネット記事やAIは信頼できる根拠として扱えないだけで、実装方法を知りたい時など、逆引きが必要になる場面ではとても役立つと思っています。見つけた方法で本当によいかどうかは別途確認する必要がありますが、こちらもうまく利用していきたいです。

3. "早くやればいい"というものではないと気づいた

3つ目は、仕事は"早くやればいい"ものではないと気づいたことです。これについては、周囲の環境や所属する開発組織の考え方によるところも大きいのかもしれません。

入社当時、私は仕事は"とにかく早くやればいい"と思っていました。

この考え方は、学生時代のインターンで身についたものです。

私は約3年ほどBtoBのウェブメディアでインターンをしていました。当時の私の仕事内容は、開発ではなく記事の編集・校正・執筆・挿図作成などがメインでした。

まず、ウェブメディアでは毎日何本もの記事を公開しなければならないので、"仕事が早いこと"が重要でした。ただ、記事中になんらかの間違いがあった場合、メディア全体の信用にも関わるので、もちろん品質もとても重要視していました。

雇用形態はアルバイトで、時給で働いていたこともあり、時間あたりにこなせる仕事が多いほうがよいというのは当然といえば当然です。

この仕事の仕方が悪いということではまったくなく、同じようなやり方が求められるところもたくさんあると思います。

問題なのは、そういった別業界の別職種で行っていた仕事の仕方を私が間違った方法で持ち込もうとしたこと。

「とにかく書いたプログラムが動けばそれでいい」というような考え方をしてしまっていたのです。

例えば次のようなこと。

開発中にエラーが出たときに、ネットで調べたコードを追加したらなんかうまくいったけど、なんでうまくいったのかは調べない
自己流でもコードを書いてみて期待通りに動いたのでヨシ！もっとわかりやすく、もしくは簡潔に書けるかということは追求しない

なぜそんなスタンスだったのかというと、「今作っているプログラムが期待通りに動くことがゴールなので、それ以外の"今やらなくても困らない作業"に時間を費やしてはいけない」と思っていたからです。

ただ、この時に"今やらなくても困らない作業"だと思っていたことは、実は大事なことばかりだったと気づきました。

例えば以下のようなことです。

今後同じエラーに遭遇した時にスムーズに解決できる
あとからコードを読んだ人がすぐにコードを理解できる
プログラムの挙動は変わらないがランタイムの処理時間を短縮できる

仕事をしていく中でこのようなことに気づくとともに、上長や先輩社員との1on1を通して、それまでの自分とは別の価値観があることを知りました。

それは、「仕事が早ければそれに越したことはないが、よりよいプログラムないしプロダクトを作るために必要な調査や知見の収集には時間をかけてよい」ということ。

当初は、自分の成長のために時間を使うなんていいのだろうか、と思っていました。しかし、それは多かれ少なかれ仕事と関連した内容であるはずだし、加えて自分の成長がプロダクトや組織への貢献につながるのだということが段々と理解できてきました。

そのため、今では実装中に疑問に思ったことはきちんと調べ、わからないまま実装することがないよう気をつけています。また、コードを書く時も長期的な視点で考え、わかりやすい書き方を意識しています。

とはいえ、そのわかりやすいコードを書くための技量がまだ足りていないのと、どんなコードであれば長期的な運用に耐えうるのかということもまだあまりわかっていないので、これからもっと経験を積んで、学んでいきたいです。

2年目に向けて

1年目はまだまだ自分のことに精一杯で、自分に与えられたタスクをひたすらこなすことを使命としていました。

ですが、先輩社員の姿を見ていると、チームのプロダクトオーナーから降りてきた仕事をこなすだけでなく、自ら仕事を見つけて動いていることも多いと感じています。それはチームで行っている施策に関するものもあれば、チーム外のこともあり。

特に、施策を進めていて予定外に必要な調査や作業が発生した時など、率先して動いている方が多い印象です。

また予定外のことだけでなく、プルリクエストのレビューを日常的に積極的に行う、チームでの話し合いに積極的に参加する、などもその一つだと思います。

1年目は自分のことばかりになってしまっていたので、2年目はそういった周りへの貢献がもっとできるようになりたいなと思います。

おわりに

いつもレビューやモブ作業を通してたくさんのことを教えてくださるチームの先輩方、またチームは別でも事あるごとに手を差し伸べてくださる先輩方には、感謝してもしきれません。また、先輩方の開発に対する姿勢や仕事の仕方からは、いつも多くのことを学ばせていただいています。

もっと周りに貢献できるエンジニア2年生を目指して、これからも精進していきます！

https://qiita.com/_mi/items/f477e95a864474187e3d ↩