Zenn
🚀

パラダイムシフトを1年経験しての振り返りとこれから

2020/10/03に公開1件
ポエム
#
振り返り
#
転職
idea

現職に関わったて1年ほど経つので、やってきたことの振り返りなどなどやろうと思う。パラダイムシフト と書いている理由は転職で現職に来た際に「この会社が使っている技術スタックについて自分は殆ど何も知らなかった」からである。
未知を1年間経験しての振り返りと「俺こんだけ頑張ったよ！」っていうまとめである。

前提

自分は前職で250万MAU規模のtoCサービスの開発と運用をしていたが、転職して全く扱ったことのない技術スタックを使ってる会社で働いている。
転職前の技術スタックとしては以下

  • サーバーサイド
    • Ruby/Rails
  • クラウドインフラ(AWS)
    • EC2
    • Elasticsearch
    • Aurora MySQL
    • Redis
    • Memcached

やってきたこと

2019年11月〜2020年1月

この時点で現職への転職は決まっていたので、実際の転職までの間に副業として参画した。仕事としては主にCI/CD/リモート・ローカル環境周りの整備をした。プロトタイプ版から本格版のアプリケーションへの移行を始めている段階であり、そこにCI/CDなどの基盤を作り込んでいくというものだった。前職に勤めつつ副業で参画していたこともあり、既存のメンバーと連携を取る必要が低そうな分野でお仕事するのが良いだろうとのことで、この分野を担当した。

この際に扱った技術スタックとしては以下

  • CI/CD
    • CircleCI
      • 公式のorbが優秀でそのままECSへのデプロイなどもできるので
  • 開発環境構築
    • ローカル
      • Docker
    • クラウドインフラ(AWS)
      • ECS on Fargate
      • VPCなど各種ネットワーク
      • S3
      • ELB
      • Aurora PostgreSQL

絶賛開発段階であり開発チームが毎日無限にPRを投げる環境だったので、CI/CDの連携の手軽さを最優先に構築した。フロントエンドやサーバーサイドのCIを動かすようにするためにReactやScalaのテスト周りを調べたりもして色々勉強になった。

ちなみにこの頃自分はCircleCIを作り込むのはほぼ初めて（CircleCI自体は使ってたがゼロイチ構築の経験はなし）であり、Docker/ECSに関しては初めてだった。人間とは恐ろしいもので、追い込まれたらなんとかやるもんだなぁというのは思った...。

当時のアウトプットは以下

2020年2月

2月になり無事に予定通り現職に転職した。2月中旬に展示会があったのでそれに向けたて新機能の設計と実装に奔走していた。ざっくりいうと「IoTデータからノイズを整理してリアルタイムに表示する」というものだった。

この際に扱った技術スタック(AWS)としては以下

  • Lambda
  • DynamoDB
  • API Gateway
  • Kinesis

これもまぁどれも初めて使うものだった。その上IoT側の挙動なども理解して実装する必要があったので中々に面白く苦しかったのを覚えている。
また、サーバーレスの手軽さとDynamoDBの柔軟さには心底驚かされた。

展示会が終わった後はIoT周りの環境整備を行うようになった。もう少し具体的に言うとIoTのログやヘルスチェック周りの整備である。AWSのIoT Coreを使ってIoTのヘルスチェック基盤を構築したり、IoT上にDockerでfluentdを建ててslackと連携したログの送信するといったものである。

この際に扱った技術スタックとしては以下

  • Raspiberry Pi 3
  • AWS Iot Core
  • fluentd
  • Docker

Raspberry Pi上にDockerでfluentdを建ててエラーなどを流し込む感じである。外部からもアクセスできるようにAWS IoT Coreとの連携もするという感じだった。始めてRaspberry Piに触れたが、リモートサーバーのノリで面白かった。
*ヘルスチェックやログの管理はDatadogなどに任せるのが遥かに良いことに後に気づいたが、それもまたやってみて体験するものだなぁと思う...。

当時のアウトプットは以下

2020年3月

殆どは体調を崩して入院してた...。皆も健康には気をつけよう。

動けるようになってからはTerraformで既存のクラウドインフラリソースのコード化をした。自分で作ったインフラ構成を改善しつつコード化する感じ。

この際に扱った技術スタックとしては以下

  • Terraform

この際実践Terraform　AWSにおけるシステム設計とベストプラクティスに大変お世話になった。
この時初めてIaCを実践したのだが、コード化による安心感は半端ないものだった。こりゃ革命だ！

当時のアウトプットは以下

2020年4月~6月

4月になりある程度体調も復帰してきたので独りプロジェクトを終えて自社のメインサービスの開発に合流することになった。開発としては主に以下2つをやっていた。

1. 管理機能の開発

ScalaとDomain Driven Design構成のメインサービスに管理機能を設計/実装するものだった。このときの私はScalaについては文法などは多少本を読んだりして覚えていた程度で、仕事で使うのは初めてだった。

ちょうどその頃からCOVID-19対策で全社的にリモート勤務が始まっていたので、ScalaもDDDもロクにわかってない自分にとっては割と地獄だった...。あの頃はFloobitsというペアプロ用のツールをIntelliJと連携してCEOやチームメンバーからペアプロ指導してもらってた。みんなには感謝しかない。
管理機能はバックエンド的にはこのサービスで一番複雑だったこともあり中々に辛かったが、得られるものは多かった。以下はその機能を設計した際のドメインモデル図である。中々育ったものになったのではないかと思う。

2. IoTカメラの録画機能の開発

IoTカメラの録画機能に関しては、メインサービスに直接組み込むには関心事が異なることもあり、Lambdaで構成するようにした。どの方向に向かうかわからないこともあり、ゼロからAPIサーバーを作るよりは1機能1Lambdaで構成するのが良いと判断した。最終的には以下のような構成になっている。

上記2つの開発で扱った技術スタックとしては以下

  • Scala
  • PlayFramework
  • Domain Driven Design
  • AWS
    • Amplify
      • リモート環境のフロントをAmplifyへ移行した
    • Lambda
    • dynamoDB
    • API Gateway
    • CloudFront
    • S3

自分はずっとRuby/Railsを扱ってきていて別パラダイムへの耐性が非常に低かったことに加えて、DDDでは常に議論が発生することもあり、非常に大変な時期だった。その甲斐もあって自分の知らなかったパラダイムを身につけられ、ドメイン知識に関する議論にも多少なりとも参加できるようになったので得られたものは多いと思う。

またこの辺りからチームでスプリント終わりの振り返りなどをするようにして各自の内省（できたこと、もう少しうまくやりたかったこと、課題に感じたことなど）を深めたりして、チームとしても育っていったように思う。

当時のアウトプットは以下
AWS Amplify Consoleと仲良くなれるかもしれないまとめ
DynamoDBにあるデータをnode.js（AWS Lambda）を使って更新する方法
AWS LambdaでFFmpegを使って動画からサムネイルを作成する

2020年7月~9月

この期は前半はメインサービスの改善をして、後半は別サービスの開発に合流した。

1. メインサービスの改善

メインサービスの改善ではフロントエンド中心のタスクだった。フロントエンドはReact x TypeScriptの構成であり、もちろん扱ったことはなかったのでゼロからの挑戦だった。フロントに詳しいメンバーにペアプロをしてもらいつつ、React/Redux/Sagaなどの思想やお作法をキャッチアップしていった。既存の構成を改修するくらいにはなれたかなと思う。

2. 別サービスの開発に合流

8がつ頃から優先度の都合でメインサービスよりも新しい別サービスの開発に合流した。こちらは基盤がAppSyncで構成されていた。合流したメンバーは私も含めてAppSyncが初めてだったこともあり、既存メンバーとともにモブプロを通してキャッチアップをしていった。新しい分野に取り掛かる際にペアプロ/モブプロするのは非常に有効だなというのをチームも私も実感した瞬間だった。

ここでは主にバックエンドとしてLambdaを実装することが多かった。そろそろ別言語に挑戦したかったこともあり、LambdaはすべてGolangで実装した。またベースもServerless Frameworkを使用した。
Golangは関数型でもオブジェクト指向でもなく構造化プログラミングであり、これまた自分にとっては新しいパダライムへの挑戦だった。Scala/DDDの時に全く異なるパラダイムを踏み込んでいたこともあり（またGolang自体シンプルな言語仕様だったこともあり）、キャッチアップは比較的楽にできた。やはり最初（1つしかパラダイムを知らない状態で2つ目に挑戦する際）が一番シンドイんだなぁと思った。

3. サービスのIP固定化

顧客のセキュリティ都合で、顧客先からこちらのサービスをアクセスする際、IPを全部固定する必要が出た。ECSやAPI GatewayなどのIP固定するとか正気の沙汰ではないのだが、割と大口顧客になりそうだったことからなんとか対応できないかを検討した。なおオチから言うと、先方の勘違いだったので最終的には実現する必要はなくなった。

AWSはサービスによってIP固定できそうな物があればでき無さそうなものも有る。その中でどうやって固定するかをひたすら調べて模索した。手段としてはAWS Global Acceleratorというものが解決の糸口になった。一言でいうとこのサービスは固定IPを発行してくれる。通常のElastic IPと違う点はALBなどにアタッチできることである。これをALBにアタッチして特定のIPやパスに応じて既存リソースへルーティングを流してやることでIP固定化が実現できると判断した。

既述の通り最終的には対応する必要はなくなったが、 正解が明確ではない問題への対処 という点では非常に勉強になったタスクである。

4. その他

直接的なタスクではないが、この期間の目標で色々掲げていたこともあり、それらにも挑戦した。

上記3つで扱った技術スタックとしては以下

  • TypeScript
  • React/Redux/Redux Saga
  • Golang
  • AWS
    • AppSync
    • Lambda
    • DynamoDB

当時のアウトプットは以下

振り返りと今後

新規サービスで技術検証的コミコミで設計/実装させてもらえたことで、この1年で自分のできることの幅が格段に広くなり、引き出しも増えた。完全に使いこなせるというわけではないが、未知への抵抗感は随分と減ったのも成果だと思う。
「今すぐにそれはできないけど、まぁ~1ヶ月以内にキャッチアップして皆と同じペースで開発できます」という感じにはなったのかなと思う。また、「その課題は●●を使って構成するのが有効そう」といった技術選定の勘所も以前に比べて付いたと思う。

また、DDDなどで議論ベースの設計/開発にもだいぶ慣れてきたことも重要な資産だと思っている。システム開発にはいんな人（ステークホルダー/PO/デザイナー/フロントエンド/バックエンド/etc）の色々な視点が絡むものであるので、本質的な課題や問題点を探るには議論が欠かせない。テストのように「これが正解！」というものはなく、自分たちで自分たちの正解を見つけていかなければならない。いわゆるコミュニケーションの世界になるが色々な事情が絡んでくることもあり中々に労力を要するものであるが、これをスキップすると本当に解決したい問題を解決しないシステムが出来上がる。この1年で議論をすることのハードルを随分と下げられたのではないかと思う。

今後は自分の得意分野の深堀りをしていこうと思う。特にバックエンドに関しては一通り触ったが、強みとしてのポイントは今ひとつ持っていないのが現状である。「誰しもある程度のレベルにまではなれる」と仮定すると、自分の今の状態は時間が経つと他の人に取って代わられてしまうものであるとも捉えられる。自分の強みとなる点を見つけられるように、今後は特定分野に深く潜っていこうと思う。

最後に、これだけたくさんの経験をさせてくれた現職（経営層/社員全員）には感謝してもしきれない。今後ともよろしく願いたい。

Discussion

gkzgkz

やはり最初（1つしかパラダイムを知らない状態で2つ目に挑戦する際）が一番シンドイんだなぁと思った。
(中略)
「誰しもある程度のレベルにまではなれる」と仮定すると、自分の今の状態は時間が経つと他の人に取って代わられてしまうものであるとも捉えられる。自分の強みとなる点を見つけられるように、今後は特定分野に深く潜っていこうと思う。

新しい視点でした。おつかれささまでした。