taiyoh's memorandum

@ttaiyoh が、技術ネタで気づいたことを書き溜めておきます。

2018年を振り返る

この記事はカヤックOBが綴るアドベントカレンダー「ex-KAYAC Advent Calendar 2018」の11日目の記事となります。

qiita.com

この一年何してたか

  • Lobi Tournament @ KAYAC(〜7月)
  • IoT device platform @ SmartDrive(9月〜)

本記事は技術エントリではなく、一年の振り返りと今更転職報告を兼ねたものです。

Lobi Tournament @ KAYAC

前職で最後に関わっていたのは、PvPタイトルでの大会作成・運営を支援するLobi Tournamentというプロダクトでした。このプロダクトでは2017年3月頃から僕の鶴の一声でドメイン駆動設計の勉強と実践に取り組むことを決め、開発メンバーで当時思いつく限りの手法を試しまくるDDDの大実験場と化していました。

敢えて機能単位でサブコンテキストの分割を行い、コンテキスト間の繋ぎ込みのためのACLの実装方法を試したり、集約を跨ぐが結果整合性が伴えばよい処理はドメインイベントとしてアーキテクティングしてみるとか、IDDD本内の付録以外のことは曲りなりにも手を出してみたつもりです。
プロダクトはLL言語Perl!)なのに同じチームの後輩がinterface的な役割を持ったクラスを定義したことがあり、流石にそれはtoo matchだとは思ったんですが、おかげでオニオンアーキテクチャについて理解が深まったという一面もあります。

あとLobi Tournamentは前年からGraphQLの採用も始め、GraphQLのtype定義とDDDにおける集約はだいぶ親和性高いなぁ、と使いながら思ってました。GraphQLはqueryだけでなくmutationも使っていて、普通にRPC的に使ってました。subscriptionは構想まであったけど手が出せなかった(その前に僕が転職した)です。

何故か最終出社後に「最後に何か話してくれ」と言われたので、Lobi TournamentでDDDやGraphQLを採用した経緯なんかを話しつつ「まず先人たちのレールに乗っかって、その上で自分たちなりの手法や取捨選択をすればいいのでは」という話をしました。
僕自身、DDDに触れるまでソフトウェア設計の守破離の「守」すら知らなかったようなものなので、DDDやClean Architectureのような「前提知識」があると、アーキテクティングや設計時に何かを判断する時に本当に助けになる、ということを身を持って知ることができました。

ただ、何でもかんでもうまくいってたなんてことはなかったです。特にレイヤードアーキテクチャはある程度事前知識がないとキャッチアップが難しく、いくら「ここでこう書いてるようにやればいいよ」と言ってもなかなか思うように進まなかったということは何度もありました。また、僕と周囲のDDDに対する温度感も違っていたりして、独りよがりだということを指摘を受けて今では反省しています。

なお余談ですが、DDDの勉強を始めて半年くらいの時点の知識というか思いの丈を以前エントリにまとめてました。

taiyoh.hatenablog.com

この記事で触れてる某Mカリに行った後輩(というか自分にとっては先生ですね)には今でも感謝してます。
DDDを勉強してある程度自信がついたことで、「この会社でまだ学ぶことがある」から「学びたいことはどこでも学べる」という気持ちに切り替わったというのは、転職に至る大きな原動力になりました。
(転職活動中にとあるDDDを実践してる会社さんに伺って話をしていて「DDDのこと、結構分かってそうですね」と言ってもらえたり、4月に開催されたDDD交流会にて、結構いい感じで他の参加者と話が出来たのが自信になった)

IoT device platform @ SmartDrive

何年か前くらいからぼんやりとゲームや広告とは無縁の事業に関わることに関心を持ち始めていて、IoTもそうした「別の関心ごと」の一つでした。
カヤックだったら何でもできるじゃん」みたいな意見はあるとは思いますが、そろそろ事業部間異動はいいかなー、外の世界も見てみたいなー、という思いが強くなって転職するという道を選びました。去年末からいくつかの転職サイトでの活動を少しずつ始め、お声がけいただいた会社の中から興味の湧いた会社何社かに話を聞きに行き、そのなかで一番お互いに手応えが良く9月に転職したのがSmartDriveでした。

smartdrive.co.jp

SmartDriveではGo(Gin)とRuby(Rails)で事業が展開されています。が、僕はどちらも業務でまともに書いたことがなかったので、正直よく入社できたよな、と我ながら関心してしまっています。

使える言語はマジでこんな感じだったけど見送られなくてよかった〜〜〜〜😂
面接等は終始和やかだったと思っています!

実際のところはオファーを提示される前に体験入社を一日行っていて、そこで実際に動いているコードを触らせてもらってました。そこで出されたお題に対してPRを作るというものだったので、実際のコーディング能力も採用時に把握されています。
体験入社の制度はいいですね。採用側が相手の能力を見ることができるだけでなく、エントリーした側もどういうコードで実装されているのかを確認できるので、入社後に初めてコードを見て「なんじゃこりゃあ!」という事態を避けることができると僕は思っています。そういえば、SmartHRさんでも体験入社の制度が整備されているそうですね。
エンジニア向けの体験入社制度ができました - SmartHR Tech Blog
現職は正直なところ、ここまで至れり尽くせりではないですね。。。ただ、「体験入社」という仕組み自体はもっと広まってもいいのかな、と思っています。

因みに、カヤック時代と比べて生活がどう変わったかと言うと。。。

  • 通勤時間
    • めっちゃ伸びた(1時間半〜2時間弱)
    • 暇なので本読んだりポッドキャスト聞いたりする時間にあててる
    • 早く帰ろうと思ったら満員電車に重なり、遅く帰ると妻にも迷惑がかかるというちょっと板挟み的な状況
  • オフィスアメニティ
    • WeWorkさまさまです!
      • 空調はちょっと残念かも
      • ドリップコーヒー、ティーパックが(ほぼ)飲み放題
      • 蛇口から出る水が恐らく浄水
      • 昼になったらビールサーバーが解禁になる
        • 帰り際に一杯飲んでから、なんてことができる
  • 飯事情
    • そこそこ美味く、そこそこ安い店が多い
    • ただ、僕は普段は弁当。。。
    • 弊社では毎週水曜日はケータリングサービス使って社員数人でのグループランチを美味しく戴いてます
  • 周辺環境
    • 自然が少ないのはもう目を瞑る
    • 会社最寄り駅の御成門駅から見える東京タワーはキレイ
    • 高度成長期以降に建てられた建物が多く、正直あまり面白くない
    • 歩いて10分かからないところにボルダリングジムがあるので、忙しくなければ夜立ち寄ってる
  • 職場の空気
    • 口調が穏やかな人が多いからか、近くで会話しててもそんなに気が散らない
      • 多分、僕はうるさい。。。
    • times文化が強い

いつぞやのグループランチ www.instagram.com

現職でもDDD関連の勉強というか情報収集や実践は続けています。
最近新機能開発に携わっていたのですが、既存実装に影響がないことを条件にClean Architectureの採用をシニアエンジニアに許可もらったので、ドメイン層はDDDを意識してモデリングを行い、RepositoryやUseCase等の層はClean Architectureをだいぶ意識して実装しました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

この新機能実装については、折を見てどこかで触れる予定です。
また、とりあえずこれでGoでドメインモデリングを伴う実装に対して実績が出来たので、まず社内で知見を共有していきたいと思います。