FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

【2018年新卒研修】Scalaを通して見えたこと

初めまして、2018年4月に入社した清水です。

新卒研修を終えての振り返りと得た学びについてまとめていこうと思います。Scalaが書けるようになった、Webアプリケーションが作れるようになったということに留まらず、物事の考え方や理解の深め方といった汎用的な価値についても多くの学びがあった研修だったと感じています。

自己紹介

大学では化学を専攻していました。なぜエンジニアを志望したのかとか採用に至るまでに取り組んだことという話はブログがもう1本書けてしまうレベルなのでここでは割愛します。

大学4年の夏ぐらいから卒論執筆の傍らHTML, CSS, JSを触りはじめて、入社前のスキルとしては静的なウェブページをゼロから作れる程度でした。なので、Javaはもちろん知らなくて辛うじて少しかじったRubyで Hello, world! できるくらいだったのですが、セプテーニ・オリジナルにはいろいろあって運よく11月に採用していただけました。

研修内容

研修は毎年アップデートが行われており、今年からの試みとしてメンターがつきっきりで手取り足取りサポートしてくれるという初心者のぺーぺーにも優しい仕様になっていました。気になったこと分からないことはその場ですぐに解決できるので、この研修のスタンスは自分にとって合っていたと思います。

内容として大まかに、ScalaとPlayFrameworkでアプリケーションを作成したり、オブジェクト指向プログラミング(OOP)やドメイン駆動設計(DDD)の研修がありました。文章だと読みづらいので研修のフローをざっくりと図にしてみました。細い線を引っ張ってきて表記しているものは1〜3日で終えた研修の内容を表しています。

f:id:smzst:20180713153041p:plain

Scala研修では、ドワンゴさんのScala研修テキストをベースに読みつつ解きつつ進めていきました。Mac講座ではターミナルの使い方から始まり、SSHキーの生成の仕方などを学びました。Web基礎講座は開発に入るに際して知っておいた方がいい事柄(HTTP, DNS, TCP/IP, DB, Webアプリケーションフレームワークなど)について学びました。DB講座ではDocker上でMySQLサーバーを立て、テーブルを作ったり追加したりと基礎的なことを学びました。OOP講座では、オブジェクト指向入門を読みオブジェクト指向とはなんぞやについて学びました。コンソールアプリ作成では、これまでScala研修で学んだ知識に加えてプロジェクトを分割してアーキテクチャを意識したり、GoogleGuiceを用いた依存性の注入(Dependency Injection; DI)を使ってコンソールアプリを作りました。

Play研修(PlayFramework研修)では、ドワンゴさんのPlayFrameworkのテキストをベースに進めました。WEBアプリ作成では、ScalaとPlay、DockerやMySQLの他にDBマイグレーションツールFlywayを使ってアプリ作成をしました。DDD講座ではドメインを中心とした設計の方法や考え方について学び、それを活かしながらDDDでのWebアプリ作成を行いました。

研修の学びと振り返り

11月まで就活を粘って滑り込んだくらいなので、もともとやる気やモチベーションは高かったのですが、誇張表現無しに3ヶ月でここまでスキルが身につくとは自分でも思っていませんでした。これも指導を担当してくださった池田さんに依るところが大きいと思っています。この場を借りてお礼申し上げます。

ここでは、研修を通しての振り返りと学んだことを自分なりに言語化してみたいと思います。Scalaが書けるようになったよ!ということ以上に学びの多い研修だったことが伝われば幸いです。

手法を学ぶときは、その目的を意識する

振り返ってみるとScala研修を始めたばかりの頃は、ケースクラスやコンパニオンオブジェクトの使いどころ、traitなどの抽象クラスが存在する意味がイマイチ理解できず頭を悩ませたなぁと記憶しています。しかし「形態は機能に従う」という言葉にもあるように、目的があるからそういう書き方や表現の仕方ができるようになっていて、実際これらの表現の仕方は理に叶っているということを後に理解しました。

ケースクラスやコンパニオンオブジェクトは、ドメインの課題を解決するという高レベルの責務に対してDDDやOOPの思想を巧いことコードで表現することができる非常に便利でパワフルな表現方法であり、traitなどの抽象クラスは、インターフェースと詳細な実装を切り分けることで情報隠蔽ができたり、詳細な実装に変更が加わっても変更箇所はそこだけで済むといった疎結合性や保守性の高さに大きく貢献しています。

これらのことはScalaをただ学んで使えるようになっただけでは分からないことでした。OOPやDDDという考え方を学んでからようやく腑に落ちたことをよく覚えています。手法を学ぶときはやり方だけでなく、その目的を意識することが習得への近道であるということを強く実感したいい経験だったと思います。

より少ないことは、より豊かなこと

また、OOP研修ではオブジェクト指向の概念があまりにも抽象的すぎて理解できずに困ったのを思い出します。OOP研修中の自分の思考は、自分の狭く浅い価値観や経験を基に無理に具象化しようとしていました。ですが、オブジェクト指向というのは、ドメインの課題解決といった「銀の弾丸」の存在し得ない複雑難解な課題に対して、よりよい解決手段を提供してくれるものであり、変に具象化してしてしまえば紋切り型になってしまうと考えを改めました。

抽象的だからこそ、幅広い課題に応用が可能であり、今後実務を通してその応用の仕方を学ぶことによってオブジェクト指向的考え方に磨きがかかっていくのではないでしょうか。今はその時が来るまで柔軟な解決策の引き出しとしてストックしておこうと思います。

書く時間より、読む時間

世のエンジニアにとっては至極当然なことかもしれませんが、コードを書いている時間よりもコードを読んでいる時間の方が遥かに長いということを痛感しました。多少改善されたのではないかと思うのですが、研修初期に書いたコードは自分で読んでも何したいのか分からない、変数名から何も情報が伝わってこない、メソッドが色々な責務を負っているというケースが多分にありました。

まだ完全に改善できている訳ではないですが、名前だけで何をしているのかが分かれば低レベルの詳細な実装について遡る必要が減るわけなので、可能な限りこの状況を目指せるよう努めたいと思っています。いい名前、いい実装(読みやすい実装)をするにはかなり頭を使うことだというのは経験しましたが、書く時間が多少伸びたところで、読む時間が短くなったりテストが書きやすかったり保守性が上がったりと、長い目で見たときの時間的コストは抑えられるはずです。実務に入ってからもこのことを第一優先にしていこうと思います。

最後に

新卒で入った会社がここでよかったなと思うばかりです。まだまだ駆け出しなので、これからも学べることしかないと思います。ただコードが書けるだけに留まらず、DDDやOOPの理解を深めたり、人が読みやすいコードが書けるように模索してみたり、挙げるだけキリがないですがまだまだやりたいことがたくさんあるなぁと感じています。

ここまで長々とお付き合いいただきありがとうございました。