はじめまして、エンジニアの新妻(にいつま。"づ"じゃない点に注意！)です。 @doriven_tech
MOSHアドベントカレンダーの6日目ということで何を書こうか悩みましたが、入社エントリーを書いてみることにしました。
どういう経緯でMOSHを知ったのか
私は積極的に自分から転職活動を行っていた訳ではなく転職求人サイトに登録をし、声が掛かったところにカジュアル面談を受けていました。
前職はWeb広告の会社でフルサイクルな開発行っていてそれに面白さを感じていたこともあり、それらが出来る環境であり私に声を掛けてくれたのがMOSHでした。
それまではMOSHという会社を知らなかったのですが、面談を受ける中でMOSHの事業内容やエンジニアの働き方を知り、自分に合っていると感じたことが入社のきっかけです。
どのような点が入社の決め手になったのか
以下の3点が入社の決め手になっています。
これらの調査や検証はカジュアル面談・会食・面接・1Day体験入社を通して行いました。
議論を出来る土壌があること
エンジニアは成果物（PullRequest、DesignDoc、ADRなど）を通して議論を行って、自分だけではなくチーム全体で様々な意見を出し合うことで成果をブラッシュアップできると信じています。
議論が生まれないということは成果物の質が個人のスキルキャップになってしまい、プロダクトがより良くなることを阻害してしまうのが嫌なので議論を出来る土壌があることが重要だと感じています。
MOSHでは自分のような畑違いのエンジニアでもしっかりと意見を聞き入れてくれる文化・環境があります。
ホスピタリティが大切にされていること
私がこれを大事にしている理由は、どんなに面白い技術を触りどんなに面白いプロダクトを作ることが出来ても一緒に働く人と仕事を楽しめないと続かないと感じているからです。
ホスピタリティがない人(強い言葉を使う、人格否定をする、すぐに感情的になる人など)と一緒に働くことはメンタルに影響を受けるだけでなく、その人の影響を受けて自分・チームが萎縮してアウトプットの量や質が下がってしまい、結果的にプロダクトの成長を阻害してしまうので一緒に働く人のホスピタリティが重要だと感じています。
MOSHではホスピタリティが大切にされている文化があり、エンジニア・営業などの職種に関わらず全員がお互いにリスペクトを持ち、感謝の言葉をしっかりと伝えたり、他人の成果を称賛し合う文化があり非常に気持ちよく働ける環境だと感じています。
フルサイクルな開発を行える環境であること
私はフルサイクルな開発が好きで、プロダクトの企画から一緒に考えて価値を創造したいし、そのプロダクトの体験を守るために運用も含めて関わりたいと考えています。
私が所属しているプロダクティビティチームは基盤改善だけでなくミッションの1つにイネイブリングチームとしてを他チームを技術で牽引する過程で機能開発にも関われる環境があります。
MOSHでは色々な議事録やドキュメントが公開・共有されており、どのチームがどのようなプロダクトを作っているのか、どのような課題を抱えているのかが分かりやすく基盤チームであってもそこのキャッチアップが可能で、他チームから提案をしたり質問を聞いてくれる文化や環境が整っているため組織を越境して影響力を出しやすいです。
また触るレイヤー(フロントエンド・バックエンド・インフラ)をチームや職種(インフラエンジニアなどの区分けはない)で制限を受けていないので、自分がやりたいことを出来る環境がMOSHにはあります。
それらの土壌があるので技術的な課題に限らず組織的な課題も含めフレキシブルに対応することが出来ています。
現在進めていることと今後の展望
Lambda-lith
MOSHではAPIの実行基盤はServerlessFramework(APIGateway + Lambda + DynamoDB)を使って創業当初から構築されています。
Lambdaの数は創業当初から増え続け今では300以上のLambdaが稼働するような状況になっています。
その結果以下のような問題が出てきました。
- Lambdaのコールドスタートによりレイテンシが増大
- ServerlessFrameworkが吐き出すCloudFormationのスタックが膨大になっていき1スタックあたりに作成できる上限を迎える
- zipの200MBの制限に引っかかる
Lambda固有の問題や尖った技術スタックにより運用が難しくなっていたので、APIの実行基盤をECSに移行させる展望があります。
その前段としてLambdaでWebフレームワーク(FastAPIを選定)を稼働させて1つのLambdaが複数のエンドポイントを処理できるようにするために着々とエンドポイントをLambda-lithに移行させているのが今です。
Lambda-lithが完了した後はECS FargateにAPIの実行基盤を移行させていく予定です。
ECS Fargateにすることで様々な恩恵を得ることが出来ます。
- FargateSpotでコスト削減をする余地が生まれる
- サイドカーなどを利用したコンテナ間の連携(各種監視サービスとの連携がしやすくなる等)
- 長時間のバッチ処理を行うことが出来るようになる等々
モダンでデファクトスタンダードな技術スタックを選定することで、MOSHのエンジニアの開発体験を向上しより多くのエンジニアがMOSHに興味を持ってもらえるようになることを期待しています。
アプリケーションエラーのアラートを見る文化の醸成
MOSHではアプリケーションエラーをSentryで収集しているが私が入社した直後、エラーが多すぎて一部の人を除いてSentryのエラー(特にフロントエンド)がまったく見れていない状況でした。
またSentryのエラーのissueがArchiveされていたのですが、どういった判断基準でArchiveされているかも分からずトリアージの判断の妥当性を検証することも出来ない状況でした。
アプリケーションのアラートが狼少年化してしまうことで潜在的な不具合が見逃されてしまうことがあったり、プロダクトの改善をするサイクルが回せないことに危機感を覚えました。
そこで段階的にSentryのエラーを見る文化を醸成することを行いました。
Sentryのエラーissueをエンジニア全員で見る時間を作成し、今までエラートリアージを行っていた人がどのような判断基準でトリアージを行っているかを共有する場を用意しました。
それらを通してそもそもSentryの画面の見方、Sentryのエラーをどのような観点で見ればいいのかなどの知見が共有されてチームの理解度を底上げすることを目指しました。
この取り組みにより以前よりも多くのエンジニアがエラーのトリアージを行えるようになりました。
現在の取り組みとして、トリアージを持ち回りで行うことでエラーのトリアージを行う文化を醸成することを行っています。
将来的には持ち回りなどの当番制を敷かずに能動的に各チームがエラーのトリアージを行い、エラーの優先度を判断して必要があれば改善のサイクルを回せるようにしていきたいと考えています。
仲間を募集しています
上に記載している通り、MOSHにはまだまだ技術的な課題・組織的な課題がありますが、それらを解決していくためにはエンジニアが必要です。
MOSHではエンジニアが自らの意見を持ち、それを実現するための提案を行い、それを実現するための行動を起こすことが求められています。
もしもMOSHに興味を持っていただけた方がいらっしゃいましたら、ぜひ下のリンクからカジュアル面談をぜひお願いします！
Discussion