Leverages Tech Blog

Leveragesの技術ブログ

未経験エンジニアがプロジェクトに参画して学び得たこと

はじめに

メディカル事業部のKTです。

今回は入社2年目の私がレバレジーズのエンジニアとして、 この1年間どのような経験をしたのかということをご紹介できたらと思います。

開発歴が浅い私のようなエンジニアが壁にぶつかった時、少しでも参考になるものがあれば嬉しいです。

目次

  • 背景
    • 事業フェーズについて
    • 入社当時の自分について
  • プロジェクトに参画して学び得たもの
    • エンジニアがやるべきこと
    • プロジェクト理解の大切さ
  • まとめ

背景

事業フェーズについて

私たちのチームについては、こちらを参照ください。

tech.leverages.jp

配属された当時、メディカルチームは社内システムとオウンド側の大規模なリプレイス中でした。 私がプロジェクトに参画したのは、約2年のプロジェクトの残り半年くらいのフェーズで、 仕様書を見ながら(たまに仕様から考えて)ひたすらページの作成を行うのが主な業務内容でした。

チームの編成としては、エンジニア、デザイナーとマーケをあわせてが30数名といったようなチーム編成です。

入社当時の自分について

入社時の私のプログラミング歴は1年ほどでした。 一通り言語に関する本を読み(たのしいRuby)、チュートリアルを元にシステムの理解はできており、記事などを見ながらとりあえず動くものが作れるといった程度の技術力を持っていました。

インターンで(主にフロント側)チーム開発も行っていたのと、研究ではとりあえず動くものを1から作成しAWSを利用してデプロイも行っていたので、アプリケーション開発に関しては一通り学んでいました。

プロジェクトに参画して学び得たもの

私がプロジェクトを通して学んだ、非常に大事なポイントを2つ紹介したいと思います。

エンジニアがやるべきこと

f:id:l-taniai:20180704092302j:plain

1つ目は、「エンジニアがやるべきこと」とは問題解決であるということです。

ただ、当時の私はそんなことも考えずに、とにかくコードを書くことに必死でした。 作業ゲームのように修正やリファクタを行い、 プロジェクトにとってその改修が何になるかを全く考えない無責任な実装をしてしまっていました。 (もちろんリファクタ自体は大切な作業だと思います。)

気づいたときには、「きれいにコードを書くこと」 が目的になっていました。 それでいて結果が出ていないのにも関わらず、コードを書く量は多いので仕事をした感だけが蓄積されていくのが怖いところです😰。。。

そんなときに先輩から、「エンジニアがやるべきことはコードを書くことではなく、課題を解決することだ。」と指摘されたのを覚えています。

それからは、

  • (実装する前に)この実装は本当に必要なのか。代替えはないか
  • 目的に対しての解決策になっているか
  • 本当に「今」やらないといけないことなのか

などを意識するようになり、結果として無駄なコードが減り、実装の優先度を考えた作業ができるようになりました。 また、やらないことを決めたおかげで自由に使える時間も増えました。

ぜひ、その行動が問題解決に繋がっているか ということを意識してみてください。 やらなくてもいいような仕事が削られて、やるべきことに時間が回せるようになると思います。

プロジェクト理解の大切さ

f:id:l-taniai:20180704092332j:plain

2つ目は、プロジェクト理解の大切さです。

チュートリアルや、個人開発しかやったことのないエンジニアにとって最初の難関は、 社内の複雑なプロジェクトの関係性を理解することにあるかなと私は思います。(体験談)

  • 今までのアセットをどう活かして実装するか
  • 自分の書いたコードが極端に目立っていないか

など個人開発とは違い、より長期的な運用を見越した、汎用的な実装が求められます。

私は、プロジェクトに馴染むコーディングが苦手でした。どうしても自分の書いたコードだけ目立ってしまってそれを何度か指摘されたことがあります。(一概に個性を出すことがすべて悪いこととは言い切れませんが、規約やロジックの組方があまりにも違っていていると、他のメンバーの理解にコストが掛かってしまいます。そのため、チーム開発においてあまり個性を出しすぎることは非推奨のようです。)

そのため技術の勉強に加えて、プロジェクトのソースコードを読み込んで

  • コーディング規約は何をベースにしているのか
  • ロジックはどこに書いたらいいのか
  • 変数のスコープは適切なのか
  • 細かいところだと、クラスやメソッドにはどういったネーミングが推奨されているのか

などを理解する事に時間設けるよう調整しました。

それらを理解することで、

  • 実装時に思考時間が減り、作業量・作業スピードが向上した
  • 設計から行う実装も既存のリソースを参考にし、検討できるようになった
  • 携わったことのないライブラリの改修もある程度理解できるようになった

など、メリットは数知れずです。 もちろん既存の実装をそのまま鵜呑みにする必要はありませんが、 思うように仕事が進まない🤦。。。

と思ったらまずは自社のプロジェクトのソースコードを読み、 それを参考にコードを書いてみるといいかもしれません。

おわりに

今回は、1年目に携わったプロジェクトの経験から、2年目の私の振り返りをまとめさせていただきました。 大きく2つ「エンジニアが本当にやるべきこと」と「プロジェクト理解の大切さ」を得られたことについてご紹介しました。

最初の1年でこれからエンジニアとして生きていく上で必要な心構えを理解できたいい機会だったと思います。

次回からは、今年度入社の新卒のメンバーのアウトプットや取り組みにについてもご紹介できたらと思います。

最後までお読みいただき、ありがとうございました。 以上、KTがお送りいたしました🙇。