Developer eXperience Day 2024 参加レポート

こんにちは、プレックスの石塚です。

今回は、7月16日から17日の2日間にわたって開催されたDeveloper eXperience Day 2024に参加してきたので、その感想をまとめたいと思います! Developer eXpericence DayはCTO協会が主催するイベントで、その名の通りテーマは開発者体験となっています

cto-a.org

印象に残ったセッションとその感想

簡単ではありますが、印象に残ったセッションを紹介して、感想をまとめたいと思います。

チーム安野が目指すデジタル民主主義

東京都知事選に出馬し、無所属・初出馬で5位の15万票を獲得された安野さんの発表です。都知事選が終わったばかりのこのタイミングでのイベント登壇ということで、安野さんの選挙で得た知見を世の中に還元したいという思いと主催者の本気度が伝わってきました。

発表では安野さんが15万票という成果を上げることができた仮説について、「デジタルテクノロジーを使って、双方向の選挙をできたからではないか」というお話がありました。多くの人から意見を吸い上げる仕組みやそれを議論して、取り入れて、反映するという作業を繰り返すことは政治のみならず組織運営でも通じるものがあると感じました。

またこのセッション以外でもプロダクト開発のエッセンスを組織作りに取り入れる発表などもあり、テクノロジーを使ったソフトウェアエンジニアリングのアプローチはさまざまな分野で通用するということを証明した出来事だったのではないかと思います。

さらに興味のある方は下記のnoteもぜひ読んでいただきたいです。 note.com

生成AI関連の発表

特定の発表ではなく恐縮ですが、今年の発表タイトルを見ても、生成AI系の発表が多く、自分が参加したセッションも14個中6個が生成AI関連のものでした。

以下は、自分が参加した生成AIに関連するセッションの一覧です。

  • エンジニアの才能を最大限に引き出す Googleの生成AIが実現する開発生産性の向上
  • 最先端の生成AIトレンドから先読みする これからの生成AIエンジニアに求められるスキルセット大解剖
  • 脳力とAIのアラインメント
  • Software EngineerのためのPrompt活用
  • 生成AIと自動運転開発の舞台裏
  • 生成AIに振り回された3か月間の成功と失敗

上記のセッションの中では、Googleのプロダクションコードの半分以上が生成AIによって書かれているという話や、生成AIによってライブラリを自動でアップデートしたりESLintのIgnoreを自動で解消するタスクに取り組んでいるといった話がありました。

ソフトウェアエンジニアとしていかにAIと付き合っていくかは改めて避けては通れないテーマだということ、組織としても個人としてもより真剣に生成AIに取り組んでいかなければならないということを実感しました。

まとめ

2日という短い期間でしたが、日頃の業務を離れて広く日本のソフトウェア業界全体を見渡すことができてとても有意義な2日間でした。

特にイベントを通じて最も実感できたことは、 「Software is eating the world」 の波が予想以上に大きく広がっていることでした。純粋なソフトウェアの開発から始まったIT産業ですが、ハードウェアや非IT産業のDXに広がり、今では政治や行政といった領域にも広がっていることを身を持って体感することができました。

我々プレックスもSaaSというソフトウェアを提供していますが、同時に人材紹介事業やM&A仲介事業といった非IT産業のDXにも取り組んでいます。宮坂副都知事の基調講演で行政は市場規模が大きく、まだまだITが未開拓の領域というお話がありましたが、それはプレックスが取り組むDXも同様です。

一見純粋なソフトウェア系のプロダクトと比較して面白みがないと思われてしまいがちな領域ですが、テクノロジーを活用して圧倒的に生産性の高い事業を生み出すというチャレンジは面白く、価値があると感じています。まだまだ日本ではそうした非ITの領域が巨大であり、プレックスの成功が日本の産業に対して大きなインパクトを与えられるようなモデルケースにしていきたいと思っています。

最後に、プレックスでは開発者体験を改善するソフトウェアエンジニアを募集しています。少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp

【インターン記録】技術と事業の両軸を目指して

はじめに

はじめまして、豊田と申します。

約半年間、エンジニアインターンとしてサクミルという建設業界向けのSaaSプロダクトの開発に携わりました。

事業が急成長する中で、様々な経験をしたので、振り返りを兼ねてブログを書くことにしました。

インターンに参加をしたきっかけ

Xでインターン募集の投稿を見て、興味を持ちました。

当時は事情があり、選考を受けませんでした。

それにもかかわらず、就活やキャリアの相談に真摯に向き合っていただきました。

お話させていただく中で、技術と事業に対する熱い思いを感じ、この方と一緒に働けたら絶対に楽しいだろうと思いました。

その後、改めて連絡をしてインターンに参加させていただくことになりました。

魅力的だった点

1. ビジネスと開発の距離の近さ

ビジネスと開発の距離間が近く、事業にも興味がある私にとって、サクミルでの開発は非常に楽しいものでした。

サクミルでは、エンジニアが技術的な観点から事業・企画・仕様に対して責任を持ちます。

そのため、企画・仕様・設計・実装の全てにおいてエンジニアが関わります。

もちろん、インターン生も同様です。

新しい開発要件が出てきた際には、お客様のユースケースを踏まえて、PdMやビジネスサイドの方と議論し、それをどのような概念としてサービスに落とし込んでいくかを考えます。

2. 事業が急成長する中での開発

インターンを始めた当初と比べて、半年間で事業も組織もプロダクトも大きく変化しました。

事業立ち上げの0から1のフェーズにおいて「0が確かな1になる」そういう期間だったと思います。

また、プロダクトが成長するにつれて、開発の内容もより面白く変化していきました。

事業が伸びているからこそ、このような刺激的な経験ができたのだと思います。

半年間で得たもの

プロとしての自覚

全てを理解しなくても良いけど、既存実装と関連する公式ドキュメントは全て読んでからがスタート」。

メンターであるテックリードの方からいただいた忘れられない言葉です。

既存実装を一通り読み、何度も公式ドキュメントを読み込むことを徹底しました。

また、メンターの方が非常にプロフェッショナルであり、その姿勢を見ているうちに「自分もプロでありたい」と思うようになりました。

フィードバック

既存実装と公式ドキュメントを読み込むことを徹底したおかげか、現状を正しく理解しようとする姿勢を評価していただけました。

一方で、新しい概念など既存の仕組みを超える必要がある際に、現状の仕組みや枠組みに囚われすぎてしまうというフィードバックをいただきました。

半年間で変わったこと

今回のインターンで得られたものとして、大きくスタンスとスキルの部分があります。

スタンス

プロとしてのエンジニアの基準を知ったことで「ここまでやらなければならない」「これくらいやらないと、プロとしてのスタートラインにすら立てない」という自覚と覚悟が芽生えました。

スキル

企画から関わり、技術と事業に向き合うことを通じてソフトウェアを捉える力が向上したと感じています。

具体的には、組織とプロダクトの変化の中で現状がどのような前提に依存しているか、その前提が崩れる境界は何か、機能をどう仕様と設計に落とし込むか、なにを意識させたくてこのインターフェースにするかなどを、考えられるようになりました。

自分の中で、良いコードとは何か、良いアーキテクチャとは何かをある程度は言語化できるようになりました。

「技術的な視点から事業を伸ばせるエンジニア」になる

今回のインターンを通じて、事業が急激に成長していくフェーズを経験することができました。

立ち上げ期においても品質と開発速度の両立が出来ることを実感し、ここまでやりきることが出来ると学びました。

メンターであるテックリードの方のように、自分も技術的な視点から事業を伸ばせるエンジニアになりたいと強く思いました。

最後に

インターン期間中にお世話になったメンターをはじめ、関わっていただいた皆様に改めてお礼を申し上げます。

技術と事業の両軸を目指しているエンジニアにとって、サクミルはこの上ない環境です。

興味を持った方は、ぜひ応募してみてください!

dev.plex.co.jp

【入社エントリ】休養を経てプレックスに入社した理由

はじめに

初めまして、エンジニアの中西と申します。
2024年1月に株式会社プレックス(以下、プレックス)にマーケティングチームのエンジニアとして入社致しました。
入社してから今日までの時間の中で感じたプレックスの良さや業務内容などをお伝えできたらと思います。

簡単な自己紹介

  • 2019年に新卒で受託,派遣(SES)の会社に入社し、web開発に従事。
  • 2020年2月ごろに転職し、受託,派遣(SES)の会社に入社。web開発に従事。
  • 2022年5月退職
  • 2024年1月プレックスに入社

2022年5月~プレックスへ入社するまでの間、詳細は割愛しますが鬱病のため療養しておりました。

プレックスへの入社理由

これまで受託や派遣(SES)が主の会社に勤めていましたので、成果物に対して明確なフィードバックがある環境に居ませんでした。
そのため、制作物へのフィードバックがCVRなどの数値となって明確に返ってくるというお話に魅力を感じました。
また、自社サービスを開発できる点にも魅力を感じたのが理由です。

所属しているマーケティングチームについて

当初は私と業務委託の方数人の体制でしたが、現在は社内エンジニア2人+業務委託の方という体制となり、主にランディングページ(以下LP)を制作しております。
またLP以外の業務であっても、やりたいことがあればやらせてもらえる環境となっています。
主にフロントエンドですが、勿論バックエンドを触ることも可能です。

入社後に感じたプレックスの魅力

妥協しないデザイン・レイアウト

1pxを妥協せず調整を行う、そのような環境に身を置けます。
例えば、css上中央であっても見た目でずれていれば1px単位で調整を行います。 時に大変ですが、出来上がりは素晴らしいものになること間違いありません。

エンジニア以外との関わり

主にマーケティングの方々と関わることが多いです。
CPC(Cost Per Click: クリック単価)*1やCVR(Conversion Rate: 獲得率)*2など、エンジニア業務だけでは聞くことのないような単語を意識して仕事に当たることができます。
またエンジニアかどうか関係なく、理解することを諦めてる方はいないので、同じ温度感で開発の相談ができます。

当事者意識

自身の業務上のことであり相手には関係なくとも、当事者であるかのように相談にのって頂けます。
解決するために何が必要かなど、一緒に考えていただける素晴らしい環境が整っています。
相談しても放置されるなんてことはまずないです。

最後に

プレックスはとても成長を促される環境だと思います。
また、休養期間がある方でも臆することなく働ける環境となっています。
随時エンジニアを募集しておりますので、ご興味持っていただけたら幸いです。

dev.plex.co.jp

*1:ユーザーによる広告のクリック1回当りに掛かる費用

*2:広告のリンクをクリックした数のうち、何割がコンバージョン(商品購入や資料請求などの最終成果)に至ったかの割合を示す指標

Firebase Authenticationにおける分散トランザクション

はじめに

2024年4月に株式会社プレックスにエンジニアとして新卒入社した佐藤祐飛と申します。現在はサクミルという建設業界向けのSaaSプロダクト開発を行っています。

sakumiru.jp

Firebase Authentication(以下Firebaseと略します)を利用した認証において、ユーザー作成時に分散トランザクションによってデータの整合性を担保する実装をRuby on Railsで行ったのでその知見について共有したいと思います。

firebase.google.com

背景

サクミルにおけるユーザー認証について

サクミルではFirebaseを活用したJWTによるユーザー認証を行なっています。ユーザー認証完了後、FirebaseのユーザーUIDを元にサクミルはDB上にあるユーザーデータを提供し、各ユーザーはサクミルにログインすることができます。

ユーザー作成方法について

サクミル管理画面ではアカウント発行機能としてFirebase上へのユーザー作成とサクミルのDB上へのユーザー作成を同時に行う機能を提供しています。サクミル管理画面のAPIにおけるユーザー作成手順を以下に示します。

ユーザー作成手順

サクミル管理画面のAPIRuby on Railsで書かれているのですが、Firebase公式からはRubySDKが提供されていないので、google-api-ruby-clientというgemを活用して、Firebase上へのユーザー作成を行なっております。

github.com

課題

ユーザーデータの不整合が生じる可能性がある

ユーザーデータがDBとFirebaseという異なる2つのノードに保存されるので、データの不整合が生じる可能性があります。

例えば、Aさんのユーザーデータを作成することを考えます。Firebase上へAさんのユーザーデータを保存することに成功したものの、その後のサクミルのDB上への保存が何らかの原因で失敗した場合、「サクミルDBにはAさんのデータがなく、FirebaseにはAさんのデータがある」という不整合が発生します。

ユーザーデータの不整合が生じる例

この不整合の状態で、再度サクミル管理画面からAさんのアカウント発行を実行するとFirebase上の一意制約によってアカウント発行の処理が失敗してしまいます。

Firebaseのコミット制御やロールバックができない

いわゆるIDaaSであるFirebaseを利用すると、認証サービスの実装コストや監視コストが下がるというメリットがある反面、デメリットとして認証サービスのカスタマイズ性が低下します。

FirebaseはFirebase内部のDBについて、コミットのタイミング制御やロールバックを行う機能を提供していないので、分散トランザクションの代表的手法である2フェーズコミット(2PC)を行うことができません。

サーガパターンによる整合性担保

上記の課題を解決するために、サーガパターンによる分散トランザクション管理を実装しました。

サーガパターンとは

サーガパターンとは、複数のサービスにまたがるビジネスプロセスを管理し、データの整合性を担保する分散トランザクション手法です。サーガパターンは、各サービスのローカルトランザクションのシーケンスであり、ローカルトランザクションはDBを更新して、次のローカルトランザクションをトリガーします。

ロールバックを実行する場合は、各ローカルトランザクションを取り消す操作として補償トランザクションを実行します。

サクミル管理画面 APIの実装

Firebaseへの操作を管理するFirebaseAdminクラスを以下に示します。

工夫したポイントは2点あります。 1点目はFirebaseへの操作を行うメソッド(今回はsign_up_user)内で補償トランザクションをスタックに積んだことです。 2点目は、補償トランザクションの処理をproc インスタンスとしてスタックに保持させ、rollbackメソッドによってロールバックを行えるようにしたことです。

これらの工夫によって、動的にUIDが変化するロールバックの処理を実現することができます。

class FirebaseAdmin
  def initialize
    # HTTP通信のclientを初期化する
    @client = Google::Apis::IdentitytoolkitV3::IdentityToolkitService.new
    
     # 認証
    ...
    # 補償トランザクションの処理を保持するスタック
    @revert_proc_stack = []
  end

  def sign_up_user(email:, password:)
    # Firebaseへユーザー作成のリクエストを送信
    request = Google::Apis::IdentitytoolkitV3::SignupNewUserRequest.new(email:, password:)
    response = @client.signup_new_user(request)

    uid = response.local_id

    # ユーザー削除の処理(補償トランザクション)をスタックにプッシュする
    @revert_proc_stack.push(proc { delete_user(uid:) })

    uid
  end

  def delete_user(uid:)
    request = Google::Apis::IdentitytoolkitV3::DeleteAccountRequest.new(local_id: uid)
    @client.delete_account(request)
  end
  ...

  def rollback
    # スタックが空になるまで補償トランザクションを実行する
    until @revert_proc_stack.empty?
      proc = @revert_proc_stack.pop
      proc.call
    end
  end

  def cleanup
    @revert_proc_stack.clear
  end
end

以下に、アカウント発行を実行した際に叩かれるcreate_user!メソッドを示します。

工夫したポイントはActiveRecordトランザクション内でFirebaseへの操作とDBへの操作を実行し、例外処理でロールバックを行ったことです。例外(FirebaseまたはDBに対する処理の失敗を想定)が発生するとFirebase上のロールバック処理とDBのロールバック処理が実行されることが保証されるため、ユーザーデータの整合性が担保されます。

def create_user!(email:, password:)
  # FirebaseAdminインスタンスを作成
  client = FirebaseAdmin.new

  begin
    User.transaction do
      # Firebase上にユーザーを作成する
      uid = client.sign_up_user(email:, password:)

      # DB上にユーザーを作成する
      user_record = User.create!(..., email:, uid:)
      ...
      save!
    end
  rescue StandardError => e
    # 例外をキャッチし、ロールバックを実行する
    client.rollback
    raise(e)
  ensure
    # スタックのクリーンナップを必ず実行する
    client.cleanup
  end
  ...
end

最後に

プレックスではエンジニアを募集しております。ご興味ある方がいらっしゃれば是非連絡をください! dev.plex.co.jp

また、入社エントリを執筆いたしましたのでご覧いただけるととても嬉しいです!

product.plex.co.jp

【入社エントリ】効率化大好きなエンジニアがプレックスに入社した理由

はじめに

初めまして、エンジニアの山崎と申します。

2024年1月に株式会社プレックス(以下、プレックス)にコーポレートエンジニアとして中途入社いたしました。

入社してから半年弱経過した上で感じたプレックスの良さや業務内容をお伝えできたらと思います。

自己紹介

2020年に新卒で Amazon Web Service に入社し、CSE(クラウドサポートエンジニア)に従事しました。
しかし、人生の深み(ドラマでよく見る、あの頃は大変だったなあというやつ)を出すために、過酷な状況に身を置き、何かにチャレンジしてみたいという謎の好奇心に駆られ2年半で退職しました。

ほぼ無計画で退職後、本気を出せば勝てると信じてYouTubeを始め、1年で7万人ほどのチャンネル登録者数を獲得しました。
しかし、諸事情で効率化大好きなエンジニアがプレックスに入社した理由 のみの活動が難しくなり、再就職を決意し今に至ります。

約1年半で社会復帰したため、深みが出たかと言われると微妙ですが、ボロ家で貧乏飯を喰らいながら必死に作業し続けた経験は、大きな財産になると思っています。
いやあ、あの頃は大変だったなぁ...(伏線回収)

プレックスへの入社理由

就職活動中に感じたプレックスの魅力は以下の通りです。

  1. モダンな技術スタック
  2. テックブログから感じたエンジニアの質の高さ
  3. コーポレートエンジニアという役職

募集要項やテックブログを拝見し、エンジニア組織の質の高さや、雰囲気の良さを感じました。 しかし、一番の志望理由はコーポレートエンジアという役職です。

私は物事を効率化させることが大好きです。
個人で沢山のツールやWebアプリを作りましたが、大半のものは効率化を目的とするためのものでした。

  • 就活中に「モチベーショングラフを作って自己分析した方が良い」と人事の方に言われた際に、紙に書くのが嫌すぎてWebで作成できるアプリを作った.
  • YouTube用の動画作成時に字幕をつけるのが面倒だったので自動生成&配置ツールを作った.
  • 新海誠監督が感情曲線を用いて脚本を書いていると知り、感情曲線グラフをプロットしながら脚本を書けるVSCode拡張を作った.

他にも様々なものを作ってきましたが、効率化を目的とした開発が一番モチベーションを持って取り組めるんだと感じていました。

そして、プレックスにおけるコーポレートチームは 「オペレーションの効率化によって事業成長に貢献する」 をミッションとしており、私にピッタリのチームなのです!

入社して半年弱経過しましたが、期待していた以上に自分の価値を発揮できる職種だと感じています。

コーポレートチームについて更に知りたい方へ product.plex.co.jp

入社後に感じたプレックスの魅力

ビジネスサイドとの連携が刺激的

コーポレートエンジニアはビジネスサイドと連携をすることが多いです。業務プロセスの自動化や効率化を行うツールやアプリケーションの作成を通して、会社へ貢献していることを体感できます。

  • LP の開発、Kintoneとの連携
  • 手動で行われていたタスクを Cloud Functions, Cloud Scheduler で自動化
  • etc...

依頼通りに実装するだけでなく、問題の根本的な原因を調査して、より良い方法で解決できた時は、エンジニア冥利に尽きる瞬間です。

さらに、エンジニアとしてだけでは得られない知識や考え方、ビジネスについて触れることができる点も魅力的です。これにより、視野が広がり、新たな発見や学びが日々あります。

なにより、ビジネスサイドとの連携は非常に刺激的です。新しいアイデアやプロジェクトに取り組む際の熱意や創造力は、日々の仕事に大きなモチベーションをもたらしてくれます。

会社の成長を肌で感じることができる

10月のカジュアル面談時には社員数が約150人でしたが、1月の入社時には200人近くまで増え、現在では300人を超えています。

急速な成長を肌で感じることができる環境で、自分の貢献が会社の成長に直結していることを実感しながら働くことができるのは、大きなやりがいとなっています。

裁量がとても大きい

会社にとってメリットがある場合、大抵のことは希望すればやらせてもらえます。

  • Kintone カスタマイズ開発環境の刷新(Turborepo や Typescript の導入)
  • 社内チャットツールのコンポーネントライブラリを Material UI にリプレイス(進行中)
  • etc...

改善点を提案し、自ら解決することができるので、社員一人一人が会社をより良い方向に成長させることができる環境であると感じています。

さらに、エンジニア業務以外のタスクにも携わることができる点も魅力です。様々な業務に関与することで、多角的な視点を持つことができるようになり、開発をしているだけでは得られない経験を積むことができます。

私は入社して半年弱ですが、カジュアル面談を担当させてもらっています。
もし、面談の担当になった際にはよろしくお願いします。

最後に

プレックスではエンジニアを募集しております。
上述の通り、プレックスは現在急成長を続けており、その速度は数字だけでなく日々の業務の中で体感できるほどです。
本記事を読み少しでも共感する点があれば、是非ご連絡ください!
この記事では伝えきれなかったプレックスの魅力を語らせていただきたいので、とりあえず私とカジュアル面談しましょう。

dev.plex.co.jp

プレックス、社内勉強会やってます!!

こんにちは、Plex Job 開発チームの池川です。

エンジニアといえば勉強会、ということで今回の記事ではプレックスでこれまで実施した社内勉強会を紹介したいと思います!

社内勉強会とは

プレックスでは週一の頻度で、エンジニア対象の社内勉強会を行なっています。 そこまでカチッとしたものではなく、お昼の時間にランチがてらエンジニアが集まって雑談する延長、みたいな感じで開催しています。 勉強会のテーマは技術に関することなら何でもOKで、下記のような感じでカジュアルに決めています↓

【Slack】勉強会のテーマ決めのスレッド

今回の記事を書くにあたり、過去のSlackや勉強会資料を振り返っていたところ、約2年前から社内勉強会は行われていたようでした。 ここからはこれまでに開催した勉強会について、内容や教材・目的を簡単に紹介していきます! (第1回〜第3回までは私が入社前の話なので伝聞形式でお届けします…)

社内勉強会の紹介

1. DDD勉強会(2021/12~2022/2)

記念すべき勉強会、第1回のテーマは、DDD(Domain-Driven Design)でした。 初学者が多かったこともあり、教材は「ドメイン駆動設計 モデリング/実装ガイド」を使いました。

DDD をテーマとして選んだ理由としては、

  1. 弊社のプロダクト開発において、事業間の連携が存在し、複雑なドメイン知識を必要とするようになったため
  2. 新しいメンバーがジョインしてドメイン知識の共有に課題があったため

の2つがあったようです。

DDD勉強会を通じて得た知見については、別の記事に詳細をまとめていますのでそちらも参照ください。

product.plex.co.jp

2. TypeScript勉強会(2022/3~2022/6)

第2回は「プログラミング TypeScript」を教材に、TypeScript をテーマとしました。

勉強会は、

  1. あらかじめ決めておいた章を読んでおく
  2. 勉強会の冒頭で Google Jambord に重要だと思った点や、質問・業務に取り入れたいところ、などを貼っていく
  3. その後、付箋をグルーピングして各トピックについて話す

といった流れで進めていきました。

勉強会をする前から TypeScript は使用していましたが、体系的に勉強することで、型宣言の切り分けのベストプラクティスやエラー処理などが理解でき、実務に活かすことができました。

勉強会で使用したJambord

3. RSpec勉強会(2022/7~2022/10)

第3回のテーマは RSpec でした。 弊社ではバックエンドに Rails を採用していることが多いので、教材は「Everyday Rails - RSpecによるRailsテスト入門」を使いました。 この勉強会では本を輪読するだけでなく、より実践的な勉強を行うために下記の手順で勉強会を行いました。

  1. GitHubに専用のリポジトリを作成
  2. 参加者はあらかじめ、対象の章のテストを書いておいてプルリクを出しておく(下記画像参照)
  3. 勉強会では誰かのプルリクを見ながら議論を行う

レビュー形式で勉強会を進めることでより理解が深まったと思います!

勉強会で使用したプルリクのコメント

4. SRE本の輪読会(2023/3~2023/7)

第4回のテーマは、SRE(Site Reliability Engineering)でした。 教材はSRE本「Site Reliability Engineering」で、初めて英語の本を教材としました。(英語だと無料で読めます) 当時、Plex Jobのサービスがスケールする中で、プロダクトをいかに安定稼働させるかが重要なテーマになっていたこともあり、SRE をテーマに選びました。

勉強会後には、Plex Job 開発チームで運用しているOKRに「プロダクトの安定稼働」を設定し、「SLO: 99.9% (時間ベース)」をKRとして、スロークエリの改善や障害発生時に気付ける仕組みづくりなどの改善を行いました。 また、2024年1月にはその延長で Heroku から GCP へのインフラ移行も移行し、一定の効果を実感しています。

product.plex.co.jp

5. 単体テストの考え方/使い方」の輪読会(2023/10~2024/2)

第5回のテーマは単体テストで当時、話題となっていた「単体テストの考え方/使い方」を教材に選びました。

勉強会は

  1. 各章ごとに担当者を決めて、Notion に内容をまとめる
  2. 担当者は事前にまとめたページを共有して、参加者は気になる点や疑問点があればコメントする
  3. 勉強会ではまとめた内容を説明しつつ、適宜、質疑応答を行う

下記のような流れで行いました。

この頃にはPlex Job以外にもSaasやコーポレート、マーケといった事業部ができていたので、各事業部のプロダクトでどのような運用をしているかなど、意見交換できたのも良かったです!

Notionにまとめた勉強会資料

6. 「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」の輪読会(2024/2~実施中)

第6回のテーマはアーキテクチャで、現在もこのテーマで勉強会を行なっています。 教材は「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」を使っています。 直近だと10章のレイヤードアーキテクチャについて勉強会を行いました。

以上がこれまでプレックスで行なってきた勉強会です。

勉強会あれこれ

せっかくなので勉強会を定期的に開催するにあたり、気をつけていることや今後やっていきたいことも簡単に共有したいと思います!

発表者は持ち回りにする

発表者は毎回持ち回りの交代制にしており、特定の人に負荷がかからないようにしています。 現状だと、2,3ヶ月に一回、発表者の役割が回ってくるペースです。

有志が集まって開催する

勉強会は強制ではなく、参加したい人・できる人が集まって開催しています。 また、メンバーによってはリモートワークしている人もいるので、オフライン+オンラインで勉強会を行なっています。

ワークショップの様子

輪読会では必ずしも一冊全てを行わない

教材とした本の内容について全てを勉強会で取り上げるのではなく、業務に関連する箇所や興味のある箇所に絞って取り上げています。 勉強会は大体2,3ヶ月のスパンで扱うテーマを入れ替えており、これくらいの期間で行なっていくのがモチベーションを維持して継続的に勉強会を開催する意味でも良いのではと感じています。

今後やっていきたいこと

ここ数回は輪読会が続いているので、LT会など別の勉強会の形式も取り入れていきたいです。 また、ほとんどの時間を発表者が一人で話して終わり、といった形になってしまったこともあったので、事前に質問を集めたりプロダクトのコードを題材にするなど、発表者以外のメンバーも積極的に勉強会に参加できる仕組みづくりも行なっていきたいと考えています。

さいごに

プレックスでは今回の記事で紹介した社内勉強会の他にも下記のような勉強会やイベントを開催しています。

コンテンツ 概要
社外勉強会 LT会*1
株式会社プレックス 社内ISUCON ISUCON*2 の社内版
開発本部定例 隔週で開催、業務で得たTipsなどを持ち回りで共有

※1 LT会の詳細はこちらの記事を参照ください

※2「ISUCON」は、LINEヤフー株式会社の商標または登録商標です

また、今年初の社外オフライン勉強会として2024年6月にLT会を開催する予定です! 詳細が決まり次第、connpass でイベントを公開しますので、興味がある方はぜひ参加いただけると嬉しいです。

plex.connpass.com

最後に、弊社では全ての事業部でエンジニア採用を積極的に行なっています。少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募ください!

dev.plex.co.jp

【入社エントリ】 プレックスに入社しました!

はじめに

初めまして、エンジニアの石川と申します。

2023年9月に株式会社プレックス(以下、プレックス)に中途入社いたしました。

入社して半年以上経ち、入社エントリーを投稿するには少し遅れてしまいましたが、半年以上経った上で見えてきた、会社の良さや日々の業務内容をお伝えできたらと思います。

簡単な自己紹介

簡単に私の経歴をお伝えすると、プログラミングスクール黎明期に仮想通貨で獲得したお金を元にプログラミングスクールに通い、そこから渋谷のベンチャー企業にて毎日プログラムを書きながら、時には1年放浪し紆余曲折ありながら今に至ります。

2018年 短期集中プログラミングスクール TECH::EXPERT(株式会社div) 入学
2019年 ~ 2022年4月 株式会社テモナ入社
2022年4月 ~ 2022年10月 株式会社speee入社
2022年10月~2023年9月 放浪
2023年9月~ 株式会社プレックス入社

小学4年生からPCのFPSなどはやっていたものの、プログラミング自体は社会人になる直前にスクールで学習したぐらいでしたので、かれこれ4年もプログラミングをしている自分にびっくりしてます。

プレックスへの入社理由

人として良いエンジニアが多いと感じたのが一番です。

僕自身「価値のあるサービスを作る」「保守性の高いソースコードを書き続けたい」などの思いももちろんありますが、休みの日も楽しくソースコードを毎週かけるかと言われたら、ゲームを友達とやる方がおそらく楽しいと内心は思ってます。

ですが、働く上でエンジニアのメンバー達と技術の話をしたり、良いサービスを作ろうと団結する一種の文化祭みたいな雰囲気はとても好きなので、一緒に働くエンジニアの方々を一番重視しておりました。

また、サービスを作るにあたっても一緒に働きたいと思える人たちと作れなければ、良いサービスを生むことは難しいと思っています。1人でできることには人間限界が絶対にあるので。

エンジニアとしてこのような考えが正しいかどうかはわかりませんが、僕自身はプレックスに入社して大変よかったなと半年間を通して改めて実感しております。

所属しているコーポレートチームについて

入社して現在に至り、コーポレートチームにてエンジニアをしております。コーポレートチームは2023年9月に誕生し、主な業務は下記になります。

  • 社内で利用されているkintoneのプラグイン開発
  • 営業の方の業務改善のためのGAS作成
  • 社内システムの0からの開発
  • 社内データをまとめ意思決定・施策を考えるためのDWH・BigQuery開発・運用

私自身がコーポレートチーム1人目の正社員エンジニアで、CTOの石塚さんと2人で開発を行っておりました。今では正社員のメンバーが2人増え、計4人のチームで日々開発・保守しております!!

コーポレートチームについて更に知りたい方へ product.plex.co.jp

入社してからの感想

課題解決のためのプログラミング

私自身Ruby on Railsでの開発経験が多く、自分の技術スタックベースで課題解決を考えていましたが、「この課題を解決するためにはPythonのライブラリを利用した方がいいよね」のような会話が日常的にあります。

Python未経験でしたがキャッチアップしながらソースコードを書き課題を解決し、改めて課題を解決するために技術があることを感じました。

当たり前と言えば当たり前ですが、自分が触れてきた技術ベースで考えてしまう癖は、気付かぬうちに自分の可能性を狭めているんだなと業務を通して感じられて大変よかったです。

非エンジニアの方の技術に対する理解度が高い

コーポレートチームで働くと、営業・マーケティングなどエンジニア以外の方とコミュニケーションを取ることが多いのです。

その際、「〇〇のデータが欲しいからSQLを△△の条件で書いて」のような依頼ではなく、「SQL書いたんだけど、JOIN周り非効率的で処理が遅いんだよね」のようなSQLなど書いたことなくても、自分で一旦挑戦した上で質問を頂くことがとても多いです。

このような「一旦挑戦してみて無理だったら質問してみる」のスタンスの方が多くて大変驚きました。

改めて前向きなエンジニアが多い

こちらは入社理由でもお話しいたしましたが、良い意味でギャップがなく前向きなエンジニアが多いです。

自分のメイン業務があるにも関わらず、Slackにて技術的疑問や悩みを書き込めば、部署問わずみなさんコメントを書き込んでくれますし、サービスをよくするために自分の開発力を毎日磨いてる方がいたり、自分から提案して開発環境を整備する方もいます。

タスクがあるから仕方なく仕事をするのではなく、自分から能動的に働きかける人が多く、自分ももっと能動的に動けるようになりたいと日々感じております。

最後に

私自身、かれこれ4年ほどプログラミングを行っていますが、漠然とバックエンドが好きなのかなと思う程度です。

先人の強いエンジニアの方と比べて自分の専門領域は何なのか日々向かい合っていますが、こういう方にこそコーポレートチームは合っているのかなと思います。

考えているだけだと悩みますが、一緒に手を動かしながら色々な業務を通じて切磋琢磨できるメンバーを募集しております。

もしこの記事を読んで、興味を持って頂けましたら、是非ともご連絡頂けるとうれしいです!!

dev.plex.co.jp