投稿者「hirano.tatsuya」のアーカイブ

01のプロダクト開発を振り返ってみる

hirano.tatsuya｜2021年12月13日

開発よもやま

この記事はランサーズの AdventClender2021 の13日目の記事です。

開発部新卒エンジニアの平野(@44511336tatuya)です。今回は新規開発で得た学びや失敗を振り返って行こうと思います。

初めての新規開発
開発メンバーが業務委託中心
開発リーダー不在

という条件の中、試行錯誤しながら今回のプロジェクトを進めてきました。

1. チーム全員が常に共通認識を持つこと

開発初期段階では社内側のメンバーと社外の開発メンバーでアプリの完成象、描いている世界観の乖離が起きていたことによって手戻りが発生した部分がありましたので、業務委託の垣根を超えてチームとして密なコミニケーションを初めから取っておけばよかったなと思いました。口頭での認識合わせだけでなくアップデートした情報を仕様書に紐付けてストックしていくことも大事です。
この経験から、チーム全員が共通の認識を持って開発をすることがプロジェクトをスムーズに進める上でいかに重要なことか知りました。

2. プロジェクトに関連する情報は1つに集約する

本プロジェクトではGoogleDriveを使って情報を管理していたのですが、

プロジェクトに関連する資料が1つのドライブにまとめられていない
進捗管理や仕様書はスプレッドシートに纏められていたので視覚的に現状を把握しづらい、読み辛い

等の問題がありました。それに付随してプロジェクトが進行するにつれてタスク管理や進捗管理が煩雑になってしまったので、次回新規開発をする時は backlogやtrelloなどを使って全ての情報を1つのアプリで管理したいなと思いました。

3. スケジュール通りに実装しなくても良い

各機能ごとのスケジュールを引いてそれに合わせるように開発していましたが、コンフリクトや仕様漏れによる修正作業などでスケジュールをビハインドしてしまいました。
今回の経験からスケジュールはあくまで目安であって前倒しで実装できそうならどんどん進めても良いのではないかと思いました。開発期間の半分の日程で7割以上を終わらせるぐらいの気持ちで開発をすればテストを書く時間やより詳細な動作検証に時間を注ぎ込めたのかなと思います。

4. 開発機能の優先順位を明確にしておく

開発を始めた当初、機能の優先付をせずに、取り掛かりやすそうなissueから手をつけていました。結果として、業務委託の方に優先度の低いissueを振って時間を溶かしてしまったりと今考えても勿体なかったなと思います。
また優先順位を付けれていなかった背景として、システムの概要やニーズが不明瞭な部分が多々ありましたので、実際にシステムを利用する方々に早い段階で要望等をヒアリングできていればある程度の優先順位や方針を立てやすかったかなのかなと思います。
ここでの学びは

早い段階で優先順位を付けるためにシステムを利用する方々にヒアリングをしておく
「リリースに際して絶対必要」という機能と「欲しい機能だがリリース後でも大丈夫」という機能のように優先順位をつけておく

こうすることで業務委託の方に適切に仕事を振ることができたのかなと思います。

5. 選択した技術に責任を持つ。技術的挑戦をしてみる

フロントの技術スタックにvue3、vuexという選択をしたのですが、開発メンバーのほとんどがvueの知識が無い状態での選択でしたので開発を進めながら個人でモダンなフロントエンドをキャチアップしていく必要がありました。
この経験から技術を選択したら人任せではなく、責任を持ってキャッチアップから実装まで先導していく必要があるのだなと思いました。

まとめ

初めてチームでの新規開発を経験して初歩的な内容ではありますが、良い学びになったと思います。既存のアプリの保守開発をしているだけでは経験できないような出来事、様々な壁に直面しました。この経験を自分の中に落とし込んで次回の新規開発に役立てて行きたいと思います。

Railsのメール送信をSendGridに移行しました

hirano.tatsuya｜2021年09月01日

Rails

開発部の平野(@44511336tatuya)です。今回はRuby on Rails製のLancers Creative(以下LCC)のメールサーバーをsmtpからSendGridに移行しました。その際、課題や実装した内容などご紹介させて頂こうと思います！

なぜsmtpからSendGridに移行したのか

今まではgmailのアカウントを使ってsmtp経由でメールを送信していたのですが、いくつかの問題を抱えていました。

存在しないメールアドレスにメール送信をするとスパム認定されメール送信が一時的にストップしてしまう
一日のメール送信上限が限られている

このような問題が起こっていましたので、今回の移行に踏み切りました。

Railsアプリからメール送信

SendGridを使ったメール送信には「Web API」と「SMTP」の2種類の方法がありますが、今回はランサーズ本家でも使用しているWeb APIでの実装にしました。また今までのActionMailerの各メーラーでの処理はそのまま流用し、ActionMailerの配信方法(deliver_method)をSendGrid Web API用に新しく追加する形を取りました。

公式でgem sendgrid-rubyが用意されているのでこちらを使用して実装していきます。

実装内容

ディレクトリ構成

config
├── initializers
│ ├── mail.rb
│ ├── sendgird.rb
├── mail.yml
├── mail.yml.example
lib
├── mail
│ └── send_grid.rb

1. SendGridアカウント及びAPI Keyの作成

まずはSendGridのアカウントとAPI Keyの作成を公式の手順通り行います。

https://sendgrid.kke.co.jp/docs/Tutorials/A_Transaction_Mail/manage_api_key.html

2. Gemfileにsendgrid-rubyを追加

Gemfile

gem 'sendgrid-ruby'

3. initialize時にActionMailerのdelivery_methodを拡張

ActionMailerがdefaultで用意している配信方法(deliver_method)は以下の4つとなります。詳細はRailsガイドを参照下さい。

:smtp
:sendmail
:file
:test

これらの配信方法以外にも独自の配信方法を追加することができ、ActionMailerが用意しているadd_deliver_method というメソッドを使用して、以下の様なで:sendgridという配信方法を新たに追加します。

config/initializers/sendgird.rb

Rails.configuration.to_prepare do
  ActionMailer::Base.add_delivery_method :sendgrid, Mail::SendGrid, api_key: ENV['SENDGRID_API_KEY']
end

上記のファイルが initialize時に呼ばれ、deliver_methodに:sendgridが追加されます。第2引数で渡しているclassは、後述する5の lib/mail/sendgrid.rbで作成するMail::SendGridクラスになります。

また、この際に1で作成し環境変数化したAPI Keyも引数として渡しておきます。

4. mail.ymlを書き換える

LCCのメール設定はmail.ymlという1つのファイルで各環境毎の設定を管理しております。このファイルをinitialize時に呼ばれるmail.rbで読み込むことで、環境に応じた配信方法等のメール設定をしています。今回の実装では、:smtpを指定していたところを3で追加した:sendgridに書き換えました。

mail.yml

development:
  delivery_method: sendgrid
  raise_delivery_errors: true
  default_url_options:
    host: localhost:3000

test:
  delivery_method: test
  raise_delivery_errors: true
  default_url_options:
    host: localhost:3000

production:
  delivery_method: sendgrid
  raise_delivery_errors: true
  default_url_options:
    host: "本番環境ホストURL"

pre:
  delivery_method: sendgrid
  raise_delivery_errors: true
  default_url_options:
    host: "pre環境ホストURL"

mail.rb

MAIL_CONFIG = YAML.load_file(File.expand_path(Rails.root.join("config", "mail.yml"), __FILE__))[Rails.env]
Rails.application.config.action_mailer.delivery_method = MAIL_CONFIG['delivery_method'].to_sym
Rails.application.config.action_mailer.raise_delivery_errors = MAIL_CONFIG['raise_delivery_errors']
Rails.application.config.action_mailer.default_url_options = MAIL_CONFIG['default_url_options']

これでtest環境以外の環境では:sendgridのdelivery_methodが適用され、add_delivery_method時に引数で渡していたMail::SendGridクラスがメール送信時に呼ばれます。

5.deliver!メソッドをオーバーライド

deliver!メソッドをオーバーライドすることで、既存の各メーラーで作成されたメールオブジェクトが実行されたタイミングでこちらのクラスが呼ばれます。このクラス内での処理としては、以下の3点になります。

既存の各メーラーで作成されたメールオブジェクトをSendGrid用のメールオブジェクトに置き換えていく
API呼び出し
API呼び出し時の接続先ホスト(エンドポイントのホスト部)の切り替え(こちらについては後ほど説明します)

sendgrid-rubyが用意するヘルパークラスを用いて以下の様に記述していきます。

lib/mail/send_grid.rb

class Mail::SendGrid
  # settingsにはsendgrid.rbで渡したapi_keyが格納されている
  # 下記プライベートメソッドのset_api_hostで取得した値も追加しておき、API呼び出し時に引数として渡す
  def initialize(settings)
    settings[:api_host] = set_api_host
    @settings = settings
  end

  def deliver!(mail)
    # ActionMailerのメイラー内で作成したメールオブジェクトの詳細情報をSendGrid用のメールオブジェクトに置き換えていく
    # personalizationでto, cc, bccを設定
    personalization = ::SendGrid::Personalization.new
    personalization.subject = mail.subject

    Array(mail.to).each do |email|
      personalization.add_to(::SendGrid::Email.new(email: email))
    end

    Array(mail.cc).each do |email|
      personalization.add_cc(::SendGrid::Email.new(email: email))
    end

    Array(mail.bcc).each do |email|
      personalization.add_bcc(::SendGrid::Email.new(email: email))
    end

    # from, subject, content, personalizationを設定しSendGrid用のメールオブジェクト完成
    sg_mail = ::SendGrid::Mail.new
    sg_mail.from = ::SendGrid::Email.new(email: mail.from.first)
    sg_mail.subject = mail.subject
    sg_mail.add_content(::SendGrid::Content.new(type: 'text/plain', value: mail.body.raw_source))
    sg_mail.add_personalization(personalization)

    # API呼び出し
    sg = ::SendGrid::API.new(api_key: @settings[:api_key], host: @settings[:api_host])
    response = sg.client.mail._('send').post(request_body: sg_mail.to_json)
    puts response.status_code
    puts response.headers
  end

  private

  # pre及びdevelopment環境では各環境のモックコンテナへリクエストを送りたいので、環境毎にAPI接続先のホストを取得する(後ほど説明)
  def set_api_host
    return 'https://api.sendgrid.com' if Rails.env == "production"
    return 'https://pre-sendgrid-creativecloud.lancers.jp' if Rails.env == "pre"
    return 'https://localhost:3030' if Rails.env == "development"
  end
end

deliver!の引数であるmailには、ActionMalerの各メーラーで作成されたメールオブジェクトが渡ってきます。各メーラーでは下記の様にmailにtoやsubjectが設定されますが、その設定情報を上記でSendGrid用のメールオブジェクトに置き換えています。

Class UserMailer < ApplicationMailer
  default from: 'hoge@example.com'

  def foo
    @user = params[:user]
    mail(to: @user.email,
         subject: '件名')
  end
end

メール送信テスト

開発環境及びStg環境(Pre環境)では実際にSendGridのAPIにリクエストは送らず、モックコンテナを用いてテストを行います。モックコンテナで用意したモックAPIにリクエストを送ると、上図のsendgrid-devからmaildevへsmtpでメール配信され、http://xxx.xxx.xxx.xxx:1080/(開発環境)にアクセスすることで、maildevへメールが送信されていることがブラウザ上から確認できます。

モックコンテナについての詳細は SendGrid用のMailモックコンテナを作りましたでエンジニアブログに記載しておりますので、ご参照下さい。

アプリ側の実装として、API接続先の切り替えは以下の手順となります。

lib/mail/send_grid.rb

環境毎にAPI接続先のホスト情報を取得します。

 private

  # pre及びdevelopment環境では各環境のモックコンテナへリクエストを送りたいので、環境毎にAPI接続先のホストを取得する
  def set_api_host
    return 'https://api.sendgrid.com' if Rails.env == "production"
    return 'https://pre-sendgrid-creativecloud.lancers.jp' if Rails.env == "pre"
    return 'http://localhost:3030' if Rails.env == "development"
  end

set_api_hostで取得した値を@settingsに渡しておきます。

  # settingsにはsendgrid.rbで渡したapi_keyが格納されている
  # 下記プライベートメソッドのset_api_hostで取得した値も追加しておき、API呼び出し時に引数として渡す
  def initialize(settings)
    settings[:api_host] = set_api_host
    @settings = settings
  end

API呼び出し時に引数として渡します。

  sg = ::SendGrid::API.new(api_key: @settings[:api_key], host: @settings[:api_host])

まとめ

今回はsmtpからSendGrid Web APIへの移行が中心となりましたが、SendGrid Web APIを使用することにより、各メールへのカテゴリー設定やEvent Webhookとの連携ができる様になります。これらの便利な機能の導入も進めていきたいと思います！

お知らせ

2021/9/8日に【Lancers x SUPER STUDIO】Engineer Meetup #1を開催します。今回実装したSendGridへの移行の話や、ランサーズの新卒エンジニアがインターン入社してからどのようなタスクに取り組んできたかについて、お話する予定ですので是非興味を持たれた方はご参加ください！

RailsプロジェクトのDocker開発環境の改善に取り組んだこと

hirano.tatsuya｜2020年12月20日

Docker

この記事はランサーズ Advent Calendar 2020 20日目の記事になります。

皆様こんにちは！開発部インターンの@44511336tatuyaです！
私は11月の頭から開発部のインターンとしてLancers Creativeという月額定額制のクリエイティブサービスの開発をしています。こちら開発言語・フレームワークにRuby on Railsを採用し、開発環境はDockerで構築しております。今回はDocker × Ruby on Rails で快適に開発できるために取り組んだことをまとめてみました。

当初の課題

DockerとMacOSの共有ファイルシステムの差異により、オーバーヘッドが発生して遅い
コンテナを再起動しないとソースコードがリアルタイムで反映されない時がある
デバックツールのpry-rails(gem)がNginxの設定によりタイムアウトして使えない

課題解決に取り組んだこと

ホストのディレクトリをマウントするのではなく一旦コピーしてみる（原因調査）
docker-syncを導入してみる（速度改善）
Dockerの設定のUse gRPC FUSE for file sharingをOFFにする/mount時にdelegatedの追加（速度改善）
Railsのアプリケーションファイルのconfig/environments/development.rbを一部変更する（ソースコード反映）
デバックにweb-consoleを導入する（デバックツール適用）

構成

├── dev
│   ├── README.md
│   ├── app
│   │   ├── Dockerfile
│   │   ├── common
│   │   ├── gemrc
│   │   ├── nginx
│   │   │   ├── app.conf
│   │   │   ├── domain.conf
│   │   │   └── nginx.conf
│   │   └── supervisor
│   │   ├── app.conf
│   │   └── delayed_job.sh
│   ├── docker-compose.yml
│   ├── elb
│   │   ├── Dockerfile
│   │   ├── h2o
│   │   │   ├── conf.d
│   │   │   │   ├── domain.conf
│   │   │   └── h2o.conf
│   │   └── service.sh
│   └── mysql
│   ├── Dockerfile
│   ├── mysql_init.sh
│   ├── mysqld.cnf
│   └── service.sh

本番環境とより近い構成にするため、ELB、App、MySQL、の3つのコンテナから構成されております。

環境

MacOS Catalina バージョン10.15.7
Ruby 2.7.1
Rails 6.0.3
MySQL 5.7

1. ホストのディレクトリをマウントするのではなくソースコードをコピーしてみる。(原因の切り分け)

まずアプリ側なのかMacの共有ファイルシステムに問題があるのか原因の切り分けを行いました。といっても本番環境はECS/Fargateで運用しており、問題なくレスポンスは早いので、Macのファイルシステムが問題なのは間違いないと予想できます。

docker-cp ~/www/app <コンテナID> : /var/www/app

リロード時間は10秒→2秒台後半に短縮！これにより、App側に問題は無く、Macの共有ファイルシステムが問題だと判明しました。

2. docker-syncを導入してみる(速度改善)

docer-syncの使う理由と仕組みは下記の記事を参考にしました。

参考: docker-syncでホスト-コンテナ間を爆速で同期する

docker-syncの仕組みとしては、 docker の -v で直接ホスト側のディレクトリをマウントするのではなく、rsyncやunisonの仕組みでホスト側のファイルをコンテナ側に転送しよう、というものです。

(詳細はわかりませんが、実際には、シンク用の名前付きボリュームを作成し、そこにホスト側のファイルを同期した上でそのボリュームをコンテナにマウントすることで実現しているようです）

早速検証してみました。

gem install docker-sync

brew install fswatch

brew install unison

docker-sync.yml

version: '2'

syncs:
　sync-volume:
　　src: ~/www/app
　　sync_strategy: native_osx

docker-compose-dev.yml

version: '2'

volumes:
　sync-volume:
　　external: true

services:
　app:
　　volumes:
　　　- sync-volume:/var/www/app/

docker-sync start # docker-syncで同期開始
docker-compose -f docker-compose.yml -f docker-compose-dev.yml up

こちらもリロード時間を2秒代前半まで短縮できました！しかしこれだと開発環境の構築手順が増えてしまい、Windowsでも開発している方もいるので動作確認などの手間が増えてしまいます。

3. Dockerの設定のUse gRPC FUSE for file sharingをOFFにする(速度改善)

こちらの設定は前回のブログでも@adachin0817さんが紹介してくれたので詳細は割愛します。
以下参考
https://engineer.blog.lancers.jp/2020/12/replace-ecs-fargate-lancers/

https://blog.hanhans.net/2020/11/28/docker-for-mac-slow-again/

こちら適用してみたところリロード時間が1/2に短縮されました！Dockerの設定を一つ変えるだけでこれは素晴らしい！たた、これをオフにしてしまうとrails cにログインできなくなります。なので基本はオンにするべきです。

mountの部分にdelegatedを追加する

書き込みと読み込みの一貫性を担保しない代わりにパフォーマンスが向上されるものです。基本こちらは追加するべきでしょう。

volumes:
- ~/www/hoge:/var/www/hoge/:delegated

4. Railsのアプリケーションファイルの`config/environments/development.rb`を一部変更する(ソースコードが反映されない問題)

こちらの設定はソースコードがリアルタイムで反映されない問題の解決策になります。
参考: 【Rails6】Dockerコンテナを再起動しないとソースコードが反映されない

ファイルの変更を検知しているのはconfig/environments/development.rbのfile_watcherという部分です。
この設定ファイル内でconfig.file_watcher = ActiveSupport::EventedFileUpdateCheckerによって変更イベントを検知しています。（名前にもEventedとありますね。）

しかし、Dcokerによる環境構築ではvolumeで共有ファイルとしてホスト側のディレクトリを仮想環境にマウントしており、この方式だと変更イベントが発生しないようです。故にファイルの変更を検知することができず、コンテナを再起動しないとソースコードの変更がされないという事態になります。

config.file_watcher = ActiveSupport::FileUpdateCheckerはソースコードの更新をサーバー起動中にチェックする機能なのでこれでviewだけでなくController処理の変更も再起動せずによくなります。

なるほど!当初ソースコードが反映されないのは前述のファイルシステムの差異によるものだと思っていましたが問題は別にあったみたいです。

development.rb

config.file_watcher = ActiveSupport::EventedFileUpdateChecker

以下に変更。

config.file_watcher = ActiveSupport::FileUpdateChecker

しっかりソースコードがリアルタイムで反映されるようになりました！

5. デバックツールにweb-consoleを導入する

やはりRailsプロジェクト開発にはpry-railsによるデバッグが欠かせません。しかし、当プロジェクトはNginxとunicornをリバースプロキシしていることによりタイムアウトになってしまうことからpry-railsがDocker開発環境で使えないことが判明しました。@adachin0817さんに相談していたところ、web-consoleでデバッグすることができました。

早速使ってみる

console を立ち上げたい View または、Controller で console メソッドを呼び出します。
projects_controller.rb

def index
    service = Projects::SearchService.new(search_params: params.permit(:page, :type, :search_type, q: {})).authorized_by(current_user).invoke
    @search = service.search
    @projects = service.projects
    @selected_tab = service.selected_tab
    console
  end

これで以下のような画面が立ち上がります。

あとはrails consoleと同じように欲しい値を入力すると値の中身が取れます。

Docker x Nginx x Unicornでbinding.pryを利用したい場合

NginxでUnicornをリバースプロキシしてbinding.pryでデバッグするとサイトがタイムアウトされてしまいます。binding.pryはrais sで起動するため、unix socketsドメインだと不可能です。なので開発環境ではUnicornのportで起動するようにし、supervisorでunicornを停止後に bundle exec rails sで起動すればデバッグ可能になります。

まとめ

結果的に速度改善に関してはDockerの設定であるmountの部分でdelegatedを追加することでストレスなく開発ができるようになりましたので、docker-syncの導入は無くなりましたがdocker-syncを導入する過程でMacとDockerのファイルシステムの違いなどを詳しく調べたことは良い勉強になりました。また、会社全体のインフラや環境構築などの課題を一手に引き受けてくれているSREチームの皆様は本当に凄いなと思い、尊敬の念に堪えません。
私もバックエンドの開発だけでなく、インフラも含めたプロダクト管理ができるようになりたいと強く思いました。

明日はSREチームのyKanazawaさんです！

元料理人が入社してからの1ヶ月を振り返る

hirano.tatsuya｜2020年12月04日

インターンシップ

ランサーズ Advent Calendar 2020 4日目の記事です。

皆様はじめまして！今年の11月からインターンとしてジョインした平野達也と申します！
ランサーズに入社する前は5年ほどフレンチの料理人をしていました。今回は入社に至る経緯と実務未経験で現場に配属された際のリアルを綴って行きたいと思います。

バックグラウンド

高校在学中にフランス料理の道に進むことを決意し、辻調理師専門学校フランス校に進学。在仏時にミシュランの星付き店で半年間フランス人と一緒に仕事をしていました。
帰国後は大阪の星付きレストランやホテルで四年間研鑽を積み、更なる飛躍を目指して今年の3月から上京し新規店舗の立ち上げに参画しようとしていた矢先にコロナウイルスの影響でオープンを断念しなくてはいけない状況になりました。そこで私は料理人として再起するより自分の可能性を探究したいと思い料理とは全く別ジャンルのエンジニアを目指すことを決めました。

大阪のレストラン時代

入社の経緯

2020年の5月末からプログラミングスクールに通い、エンジニア転職を目指してプログラミングを勉強していました。

卒業してから転職活動するためのポートフォリオをRuby on Railsで作成し、インフラ、本番環境にはECS, CircleCi, Dockerなどの今流行のナウい技術を取り入れようと考え、Qiitaの記事や諸先輩方々のポートフォリオをソースコードを読み漁って何がどうなっているのかよくわからないまま構築を進めていました。
そしてデプロイ途中で完全に迷子になってしまい、そんなニッチもサッチもいかない状況で弊社サービスである MENTA を使ってインフラを教えてくれるメンターさんを探す事にしました。

そこで私はランサーズSREチームの安達(adachin)さんにメンターをして貰うことになります。
Linuxの基礎から始まりDockerによる開発環境の構築、ECS/Fargateにチャレンジしようと思いましたが、短期間で実現できずAnsibleを使ったEC2での本番環境コード化、CircleCiによる自動デプロイなど一ヶ月の間にかなり色々な知識を教えて頂き、濃厚な日々を過ごさせて頂きました。技術だけでなく、エンジニアとしての姿勢も教えてくださり、TeamGeekも読んだことで、現場での振る舞い方なども学ばさせていただきました。そして最後にはランサーズに紹介してくださりその面接のための履歴書添削、wantedly添削などもして頂きました。

安達さんにメンターをして頂いて本当に良かったと思っています。入社してからもチームは違いますが、インフラ系の相談や改善を一緒に取り組み、メンターをしてもらっていた頃の様に頻繁にコミュニケーションをとっています。

実際の現場に入ってみて

入社してからは、Lancers Creativeという月額定額制のクリエイティブサービスの開発にアサインされました。技術スタックにはRuby on Railsが採用され、インフラはECS/Fargateで本番運用されています。
LCCをECS/Fargateに移行した際の記事

正直自分が現場では色々な壁にぶち当たる覚悟はある程度していましたのでギャップというギャップは感じなかったのですが、些細なことでも真剣に議論される先輩エンジニアの方々がかっこいいな~なんて思ったりしていました。
例えば、Gitの運用上のコミットの粒度、メソッドや変数などの命名、ロジックの置き場所など自分が個人開発している時には全く気にならなかったことでした。開発の規模が大きくなりソースコードも複雑になるにつれて如何に保守性の高いコードを書くかというところにエンジニアとしてのプロフェッショナルが垣間見えました。

また、ランサーズは新卒やインターンのフォロー体制も万全で実装で詰まっていたら社内slackの中で個人の分報部屋(分報とは日報の分バージョンで、日に1回の日報とは違い、自分の作業内容をSlack上で逐一報告していくという進捗共有方法です)に「〇〇で詰まっているのでフォローお願いします」みたいな感じで書き込めばすぐに先輩エンジニアがフォローしてくれる体制が整っています。新卒であろうと、インターンであろうと、ランサーズの社員として働く以上はスピードと結果が求められます。
ランサーズのチームメンバー全員がLancersWay(行動指針)の最高か最速を体現されていると感じました。

実際の分報部屋の様子

まとめ

入社して1ヶ月が経ち成長を実感していますがそれ以上に自分にできないことが多くもどかしく感じています。今の目標は携わっているサービスのワークフローを理解しビジネスサイドの要望を開発に落とし込めて、自ら率先して提案できるエンジニアになりたいです。
また様々な技術に興味を持ってキャッチアップしていきたいと思っております。

最後にここまで読んで下さってありがとうございました！

Wantedlでもインタビューされたのでぜひ！

https://www.wantedly.com/companies/lancers/post_articles/297210