はじめに

こんにちは。divxエンジニアの内炭です。僕は今年の9月でエンジニアになってちょうど2年が経ちました。

エンジニア歴2年というと新人エンジニアから中堅エンジニアになってくる頃ではないでしょうか。僕もエンジニアの仕事に慣れてきて自分1人の力で開発業務ができるようになってきたのを感じています。

しかし最初はコードを書くこともエラーを解決することもまったくできずに悩むことが多かったものです。エンジニアになったばかりの時に研修として簡単なチャットアプリを制作するという課題があったのですが、他の人が1~2週間で終わらせているところを自分は1ヶ月かけてなんとか終わらせたのも今ではいい思い出です。

今ではある程度1人で機能を実装したりエラーを解決したりできるようになりましたが、それはただエンジニアになって2年経ったから慣れてできるようになったというわけではありません。もちろん慣れもありますがそれ以上にエンジニアとして成長するためにはどうすべきか考えて色々試したことが一番の要因だと思っています。

そこで今回はエンジニアとして成長するために僕なりにやってよかったと思うことをお話しできればと思います。

成長するためにやってよかったこと

技術力を上げるためにやってよかったと思うことは大きく2つあります。

• 先輩から学べることを自分で見つける
• 分からないことを自力で解決する

先輩から学べることを自分で見つけること

先輩から学べることを自分で見つけて取り入れることで、教えてもらってないことでも学びを得ることができます。逆に言うと教えてもらったことだけ学ぶということは教えてもらってないことは学べないということにもなります。

教えてもらったことはもちろん学びとしてキャッチアップし、教えてもらってないことでも学べることはないか自分で探して主体的に取り入れるという姿勢はとても大事です。

分からないことを自力で解決すること

自力で解決することのメリットは問題解決能力が身に付くことです。

僕が今まで所属してきたチームではありがたいことに分からないことはすぐに質問して教えてもらえる環境でした。

しかし僕の場合は質問できる環境に甘えすぎてしまい自分で考えることが足りていなかったと今になって反省しています。分からないことをその場凌ぎで先輩に解決してもらうような形になっていました。

しかしエンジニアであれば実装に行き詰まった時やエラーの解決など問題を解決しなければならない場面は多々あります。

分からないことを自力で解決することはこの問題解決能力を鍛えるのにとても有効な手段です。

次にこの2つを実際に僕が実践したエピソードについてもお話ししようと思います。

先輩から学べることを自分で見つける

先輩の調査ログが分かりやすい

不具合の原因調査

同じチームの先輩が不具合の原因調査のタスクを担当していたのですが、この原因調査はかなり難易度の高いタスクでした。不具合とは具体的にはデータの不整合が発生するという内容です。
データの不整合とは簡単に言うとデータAの値が1ならデータBの値は2になっていないといけないところが、データBの値が3になってしまっているというものです。
データの組み合わせが誤った状態で保存されてしまう不具合の原因調査を先輩が行っていました。

タスクの引き継ぎ

その先輩が退職することになってしまい自分が不具合の原因調査のタスクを引き継ぐことになりました。このタスクは難しいことが分かっていたので内容を理解するのに時間がかかるだろうなと思っていました。

最初に引き継ぎ資料としてその先輩が調査した内容をまとめた調査ログを共有してもらいました。調査ログには今まで調査の経緯や詳細が記載されておりそれなりにボリュームのある内容でした。

ボリュームはありましたが必要な情報がきれいに整理されていてタスクの内容をすぐに把握することができました。これだけの量の情報を正確にまとめられる先輩はさすがでした。

先輩の資料作りのスキルがすごいというのがありますが、とくに分かりやすかったのがSQLを使って説明されていたことです。不整合になるパターンのデータをSQLで実際に取得して説明されていたので具体的で分かりやすくなっていました。

SQLを使って説明する

データの説明をするのにSQLを使って実際にそのデータを取得して説明するというのはとてもよい方法だと思いました。多分僕だったら直接文章で書いて説明していたことでしょう。

この方法のよいところは人が手書きで書いて説明するのではなく実際に取得したデータで説明するので正確性が高いことです。

この方法について先輩から直接教えてもらったわけではありませんが、個人的にデータの説明にはとてもいい方法だと思ったのですぐ自分のプルリクエストにも取り入れました。

分からないことを自力で解決する

質問することをやめる

チームメンバーが3人

以前僕が所属していたチームではまだ人が少なくメンバーは上司を含めて3人でした。上司と自分、そしてもう1人はまだ入社して間もないメンバーだったので自分が先輩になります。

また、技術的に上司にしかできない仕事が多くあり上司の負担が大きくなってしまっている状態でした。

チームに貢献するためには

この状況の中でチームへ貢献するために自分がすべきことは以下の2つだと考えました。

1. チームメンバーのサポートをする
2. 上司から仕事を巻き取って負担を減らす

しかしこの2つは今の自分では難しくさらに成長する必要がありました。

この時はまだ1人で開発業務を十分にこなせていなかったため、自力で業務をこなせるようになる必要があると考えました。自分の仕事ができていない状態で他の人に教えたり仕事を巻き取ったりすることはできないからです。

成長にするためには

今まで分からないことがあった時は質問して解決してもらうことが多く、先輩に頼るばかりで自分で解決するということができていませんでした。

なので質問することをやめ分からないことを自力で解決できるようになることを目指しました。

どうしても分からない時だけ上司からヒントをもらい基本的には自力でなんとかするというようにしました。

自力で解決するためにやったこと

自力で解決できるようになるためにやったことは大きく2つあります。

1. 自分が苦手なことを知る
2. 仮設を立てる

何ができないのかを明確にする

まずは自分ができていないことが何なのかを明確にするところから始めました。そのために今まで先輩に質問していた時に何が分からなくて質問していたのかを振り返りました。

すると質問していたことは主にこの2つであることが分かりました。

1. コードが理解できない
2. エラーが解決できない

なぜこの2つができていないのかそれぞれ原因を分析してみました。

まずコードが理解できないについて。

僕はコード読む時に一行ずつ順番にコードを読んでどういう処理をしているのか理解しようとしていました。短いコードならそのやり方でも大丈夫でしたが長いコードの場合だんだんコードを読むことに疲れてきて訳がわからなくなるというのが僕のいつものパターンでした。

次にエラーが解決できないについて。

エラーが出た時はまずエラー文をコピーしてそのエラー文でググって出てきた記事の解決法を片っ端から試していくということをしていました。出てきた記事の解決法で解決できればよいですがだいたいは解決できずそのまま先輩に質問していました。

2つの原因の共通点として仮設を立てずに闇雲に解決しようとしていることに気づきました。

次にこの2つを仮設を立てて考えてみます。

仮設を立ててコードを読む

コードが読めないのは最初から順番に一行ずつコードを読んでいることが原因でした。なので最初にどういう処理をしているのか予測してからコードを読むようにしました。

たとえば関数の場合以下の順番で処理の内容を予測します。

1. その関数が何の処理をしているのか予測する
2. 関数内の処理をいくつかのまとまりに分けて、そのまとまりごとに何の処理をしているのか予測する
3. まとまりの中のコードを一行ずつ読んでいく

つまり最初にある程度こういう処理をしていそうだと仮設を立ててから最後に一行ずつ読んでいくというやり方です。個人的にこのコードの読み方はめちゃくちゃ効果がありました。

どういう処理をしているのか当たりをつけてそれを確認するような形でコードを読むことで格段にコードが読みやすくなりました。

エラーが起きている原因の仮設を立てる

エラーが起きた時にエラー文でググって出てきた記事の内容を試すというやり方をしていましたが、これだと解決できる記事が出てくるかどうかの運任せになってしまい自力で解決とは程遠いやり方です。

なので段階を踏んで仮設を立ててエラー解決をするようにしました。

1. エラーの原因の仮設を立てる
2. エラーの原因を探る
3. エラーの解決方法の仮設を立てる
4. エラーを解決する

おおまかに原因の特定と解決の2つの工程に分けており、それぞれ仮設を立てています。

また、原因の特定に関しては1回の仮設で特定しようとするのではなく「仮設を立ててその仮設が合っているか確認する」というサイクルを繰り返すことで少しずつ原因の可能性を絞っていき原因を特定するようにします。

こうすることで運任せではなく根拠を持って原因を特定しエラー解決ができるようになりました。

おわりに

今回はエンジニアとして成長するために必要なことについてお話させて頂きました。

今回このテーマを選んだのは「エンジニアとして成長するために一番大事なのは主体的に行動すること」だということを伝えたかったからです。これは裏を返せば「ただ歴が長くなるだけで自動的に成長することはできない」ということです。

僕自身どこかでエンジニア歴が長くなれば勝手にできるようになってくるだろうと思っていました。そのせいで受け身になってしまいいつまで経っても先輩の助けを必要とする状態から抜け出せないでいました。

教えられたことだけを学び、分からないことは先輩に解決してもらうという他人まかせのマインドをやめることがエンジニアとしての成長につながりました。

もちろん成長するために必要なことは人それぞれだと思いますが、1人のエンジニアが成長するためにどのように思考して行動したのかという一例として参考になれば幸いです。

divxでは一緒に働ける仲間を募集しています。
​​​​​​​興味があるかたはぜひ採用ページを御覧ください。