プレックスジョブチームの技術スタックと開発フローの紹介

組織 技術 開発環境 企業文化

はじめに

こんにちは。

株式会社プレックスでWebエンジニアをしている池川です。

弊社では現在、複数の事業を展開しており、それぞれの事業部にエンジニアが所属しています。 チームによっては異なる技術スタックや開発フローを採用しているため、今回チームごとの特徴や取り組みをまとめることにしました。

本記事はその第一弾で、プレックスジョブの開発チームにおける技術スタックや開発フローを紹介します！

チーム紹介

プレックスジョブについて

プレックスジョブは、物流・建設・製造業界など生活インフラを支えるエッセンシャルワーカーの方に特化した人材プラットフォームです。 2018年のリリース後扱う業種も拡大し、現在では転職希望の登録者数は100万人、導入事業所数は27,000社を突破するなど、これまでに多くのユーザーの転職をご支援させていただいています。

www.plex-job.com

チームの構成

プレックスジョブは2025年8月時点で、プロダクトマネージャ（以下、PdM）: 1名、エンジニア: 6名の合計7名で開発・運用を行っています。 各メンバーの紹介は弊社の採用ページに載せてありますので、そちらも合わせてご覧ください！

dev.plex.co.jp

メンバー全員で集まって MTG したときの写真↓

技術スタック

チームの技術方針

チームの技術スタックについて紹介する前に、技術方針について紹介します。 弊社では言語やインフラなど全社共通で採用している技術もありますが、事業部によって扱っているドメインも異なるので各々のチーム独自で採用している技術もあります。

プレックスジョブだと、

  • 人材プラットフォームというサービスの特性上、検索流入が重要になってくるため、SEO を意識した技術選定を行う
  • 人材プラットフォーム以外にも、クライアント向けの管理画面、社内管理画面の合計3つのプロダクトがあるため、プロダクトの特性に合った技術や設計を選択する
    • エンジニアは全てのプロダクトでフロントエンド、バックエンド両方の開発に関わるため、言語やフレームワークなどはプロダクト間で共通
  • 車輪の再発明をしない

といった方針をもとに技術選定を行っています。

技術スタック

2025年8月現在の技術スタックは下記です。直近だとプレックスジョブマガジンリニューアル時に microCMS や、 Devin などの AI ツールを新しく採用しました。

カテゴリー 技術・サービス
1. プログラミング言語 Ruby, TypeScript
2. フレームワーク、ライブラリ Ruby on Rails, React.js, Next.js
3. API／通信 GraphQL, Apollo Client
4. データベース PostgreSQL
5. インフラ／クラウド基盤 Google Cloud
6. コンテナ基盤 Docker, Google Kubernetes Engine
7. PaaS Vercel
8. SaaS microCMS, GitHub, Notion, Slack, Figma, Google Workspace
9. データ基盤／分析基盤 BigQuery, Redash
10. モニタリング／運用ツール Datadog
11. AIツール Claude Code, GitHub Copilot, Devin, ChatGPT

開発フロー

次に開発フローについて紹介します！

プレックスジョブはアジャイルで開発を行っており、スクラムを採用しています。スプリントの期間は一週間と短く設定した上で、毎週金曜日に、①前スプリントの成果の共有、②次スプリントの開発タスクの決定と見積もり、③前スプリントの振り返りを行っています。

スプリントの10〜20％は、技術的負債の解消や開発ブログの執筆といったタスクに充てるルールにしています。 また、リリースは曜日を固定せず、必要に応じて随時行うことで、ユーザーにいち早く新機能を届けられる体制を整えています。

次に、チームでも力を入れている「技術的負債への取り組み」と「振り返り」について紹介します！

技術的負債への取り組み

チーム紹介の欄にも書きましたが、プレックスジョブは2018年にリリースして約7年が経過しているプロダクトです。

7年が経ちサービスがスケールする中で様々な技術課題が出てきています。 それらの技術課題は GitHub にIssueとして起票し、GitHub Projects で管理をしています。 また、起票は誰でもできるようにしておき、クォーター、スプリント単位で棚卸しつつ、優先度の高いものからスプリントで取り組んでいます。

振り返り

振り返りはクォーター、月次、スプリント単位で行っています。 スプリントの振り返りでは、KPT を使って個人・チーム間での課題を共有したり、Four Keys の指標をもとにチームのパフォーマンスを振り返っています。 また、月次の振り返りでは、クォーター単位で決めた OKR の進捗を確認しつつ、OKR の優先度に沿った開発ができているか、問い合わせが増えていないかなどの確認を行っています。

振り返りについては少し前の記事にはなりますが、開発ブログに詳細を記載しているのでよかったら見てみてください！

product.plex.co.jp

その他の取り組み

ここからはチームで最近取り組んできることを3つピックアップして紹介します！

AI 活用

チームとして AI を活用している2つの事例を紹介します。

一つ目は Devin による Renovate の対応の自動化で、2025年8月から本格運用を開始しました。 導入の経緯や検証内容の詳細は弊社の開発ブログに記事がありますのでそちらを参照ください！

product.plex.co.jp

product.plex.co.jp

二つ目は Copilot Review を使ったコードレビューです。 チームでは以前から開発のガイドラインをドキュメント化する文化が根付いていたこともあり、導入はスムーズに行うことができました。

具体的にはガイドラインの内容を instructions に落とし込んだ上で、メンバーにコードレビューを依頼する前に、Copilot Review を通す運用を行っています。 ガイドラインに沿った実装ができているかだけでなく、タイポのチェックなども行ってくれるため、レビュワーの負担が減ったと感じています。

例）RSpec のガイドラインの一部

OKR（Objectives and Key Results）

プレックスジョブのプロダクトチームではクォーター単位で OKR を決めて、その達成に向けた取り組みを行っています。 OKR にはビジネス側で PdM が作成するものもありますが、開発側でも必ず一つは策定するようにしています。

以下、開発で直近取り組んだ OKR の例です！

  • Next.js の App Router 移行
  • Devin の活用
  • パフォーマンスチューニング

一定の時間がかかる課題は後回しになりがちですが、OKR として取り上げることでチーム内で課題を共有し計画的に取り組むことができるのでおすすめです！

勉強会

現在は毎週金曜日にチーム内で勉強会を実施しています。 LT形式でテーマは業務に関することなら何でもOKとしており、自分が実装した機能の紹介やAI活用事例などテーマは様々です。 もともとは輪読会の形をとっていたのですが、メンバーも増えお互いが何をしているのか分かりづらいといった課題感があったため今の形に変更しました。 発表は任意なため、適度に緩くやれているのもチームに合っていているのかなと思います。

実際に勉強会で使った資料の一部です。

あと、今年の5月に開催された TSKaigi 2025 に一名登壇したほか、9月に開催される Kaigi on Rails 2025 にも一名登壇するなど、チーム内でカンファレンスや外部勉強会への登壇熱が高まっており、登壇の練習の場としても活用できればと考えています！

product.plex.co.jp

さいごに

プレックスジョブではエンジニア、PdM のポジションも絶賛募集中です！ 気になる方はぜひ下記のポジション一覧をご覧ください。

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

インフラ産業の課題を解決するプロダクトマネージャー - 株式会社プレックス

インフラ業界の課題を解決するSRE - 株式会社プレックス

Rake タスクの Unhandled Exception を Rails.logger でログ出力する方法

はじめに

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

これまで、Railsアプリケーションから構造化ログを出力する上でいくつか試行錯誤を行ってきました。 今回は、その中で行った「Rakeタスクで発生した例外をRails.loggerとしてログ出力する」取り組みについて紹介したいと思います。

構造化ログに関連する取り組みについては、よければ過去の記事もご覧ください。

課題

Plex Job開発チームでは、構造化ログの出力にSemantic Loggerを活用しています。 Railsアプリケーションで利用する場合は、rails_semantic_logger gemを導入することにより、Rails.loggerが拡張されます。これにより基本的なRailsアプリケーションからのログ出力は自動的に構造化されます。

導入時は気づきませんでしたが、運用をはじめてからRakeタスクで発生した例外のみ構造化されないままログ出力されていることに気づきました。

以下は出力の例

bin/rails aborted!

/workspaces/sample/lib/tasks/hoge.rake:3:in 'block (2 levels) in <main>'
Tasks: TOP => hoge:fuga
(See full trace by running task with --trace)

というのも、Rakeタスクで発生した例外はtaskブロック内で捕捉しない限り、Rakeのログ出力機能によってエラー出力されてしまいます。

以下は、rakeの該当箇所のコードになります。

...

# Provide standard exception handling for the given block.
def standard_exception_handling # :nodoc:
  yield
rescue SystemExit
  # Exit silently with current status
  raise
rescue OptionParser::InvalidOption => ex
  $stderr.puts ex.message
  exit(false)
rescue Exception => ex
  # Exit with error message
  display_error_message(ex)
  exit_because_of_exception(ex)
end

...

# Display the error message that caused the exception.
def display_error_message(ex) # :nodoc:
  trace "#{name} aborted!"
  display_exception_details(ex)
  trace "Tasks: #{ex.chain}" if has_chain?(ex)
  trace "(See full trace by running task with --trace)" unless
      options.backtrace
end

RakeタスクはRailsコマンドで実行することが可能ですが、タスクの実行についてはRailsのエコシステムで実行されるわけではありません。例外についても独自の機能traceメソッドでエラー出力されます。

Plex JobではRakeタスクで定期バッチを実装しています。

その他のログと同様に監視ツールからモニタリングしたいので、Rails.loggerを経由してUnhandled Exceptionをfatalやerrorレベルの構造化ログとして出力する必要がありました。

Rakeの挙動

そのため、RakeタスクからRails.loggerを経由してログを出力する方法を検討してみることにしました。

実現方法の検討

調査・検討してみたところ、いくつか方法がありました。

  1. begin ... rescue ... end で処理を囲う
  2. Rake にパッチをあてる
  3. at_exit を使用する

それぞれの方法について見ていきたいと思います。

1. begin ... rescue ... end で処理を囲う

  • task ブロックの処理をすべて begin ...rescue ... end で囲う
  • 例外が発生した場合は、Rails.logger でログを出力する

以下は実装例です。

namespace :hoge do
  desc "実装例"
  task fuga: :environment do
    begin
      # do something
    rescue => e
      Rails.logger.fatal(e)
      raise e
    end
  end
end
  • メリット
    • シンプルで理解しやすい
  • デメリット
    • 毎回書くのが面倒
    • 実装漏れが発生する可能性が高い

2. Rake にパッチをあてる

  • Rake にモンキーパッチをあてる
  • Rake タスク実行時にかならず例外をキャッチし、Rails.loggerでログを出力する

以下は実装例です。

module Rake
  class Task
    alias_method :invoke_without_loggable, :invoke

    def invoke(*args)
      begin
        invoke_without_loggable(*args)
      rescue StandardError => e
        Rails.logger.fatal(e)
        raise e
      end
    end
  end
end
  • メリット
    • タスクの実装時にunhandled errorのハンドリングを意識する必要がない
  • デメリット
    • Rake の内部実装が変わると壊れる可能性がある

参考

3. at_exit を使う

以下は実装例です。

namespace :db do
  desc "This task does nothing"
  task nothing: :environment do
    at_exit do
      exception = $ERROR_INFO
      Rails.logger.fatal(exception)
    end
    ...
  end
end
  • メリット
    • 導入が簡単
    • タスクの実装時にunhandled errorのハンドリングを意識する必要がない
  • デメリット
    • 副作用に注意する必要がある(前後関係で処理が上書きされたり、したりしてしまう)

参考

どの方法で実装するか？

begin ... rescue ... end で処理を囲う方法は、完全に実装漏れを防ぎきることが難しい。

at_exitを使う方法については、

  • 登録した処理の実行順番を意識する必要がある
  • よく使うgemにも組み込まれていることが多い

こともあり、アプリケーションコードに組み込む上で、副作用を考慮しながら保守し続けるのはコストが高くつきそうでした。

今回は保守性を考慮して、Rake にパッチをあてる方法が落とし所としてはよさそうだという判断となりました。

観点としては以下となります。

  • 例外時のログ出力について、実装の漏れが発生しない
  • パッチをあてる対象が限定的で、将来Rakeのインターフェースが多少変更されても修正が容易であること
  • 処理がRakeだけに依存していること(その他のgemやアプリケーションコードへの影響を考慮する必要がない)

Rakeにパッチをあてる

方針が決まったので、実際にRakeにパッチをあてることにします。

https://github.com/ruby/rake/blob/79bf96f9aa3219ce87a4979e78fb206a29d18dac/lib/rake/application.rb#L235を参考にdisplay_error_messageメソッドにモンキーパッチを当てることで実装を行いました。

以下は実装例です。

Rakefile

# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.

require_relative "config/application"

# RakeExtensionモジュールを作成して、パッチ処理を実装する
module RakeExtension
  def display_error_message(ex)
    # Semantic Loggerでログ出力する
    logs_error_for_semantic_logger(ex)

    super(ex)
  end

  def logs_error_for_semantic_logger(ex)
    task_name = ex.chain if has_chain?(ex)
    Rails.logger.fatal("#{name} aborted! Tasks: #{task_name}", ex)
  end
end

Rails.application.load_tasks

# Railsの初期化後にRake::Applicationを拡張する
Rake::Application.prepend(RakeExtension)

上記のようなパッチをあてることで、以下のようにtaskブロックで発生した例外がRails.logger(Semantic Loggger)により構造化されてログが出力されるようになりました。

以下は出力の例

{"host":"004c21fd7993","application":"Semantic Logger","timestamp":"2025-07-24T06:23:03.354088Z","level":"fatal","level_index":5,"pid":6481,"thread":"1816","file":"/workspaces/sample/rakefile","line":17,"name":"Rails","message":"bin/rails aborted! Tasks: TOP =\u003e hoge:fuga","exception":{"name":"RuntimeError","message":"","stack_trace":["/workspaces/sample/lib/tasks/hoge.rake:3:in 'block (2 levels) in ..."]}}

おわりに

弊社では各事業部でエンジニアを募集しております！ 気になるポジションあればお気軽にお問い合わせください。一緒に働きましょう。

弊社の各事業部でエンジニアを求めています！

SaaS

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

PLEX JOB

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

コーポレート

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

参考

初めてのdbt開発、あの時の自分に伝えたいこと

コーポレートエンジニア データ基盤 dbt

はじめに

株式会社PLEXでコーポレートエンジニアをしている石川です！
社内で使われている業務用システムの開発など、社内業務の改善に取り組んでいます。

この記事では、初めてdbtの開発を任された私が、どのようにアプローチしたか・つまずいたか・改善したかについて共有します。

対象読者

以下の項目に関心・該当する方におすすめの記事です！

  • 自社でdbtを導入予定で、dbt開発を任されたが何をすべきかわからない方

背景

社内業務の一貫として、社内のさまざまなデータソースに存在する企業情報を元に、BigQueryに企業テーブルを作成する必要性が生じました。

BIツール越しにSQLを書くことも考えましたが、下記の要件を満たすためにdbtを導入することになりました。

  • カオスなSQLの爆誕を回避する
  • 今後の保守業務の負担の高さ
  • 他の社内ツールからも生成した企業テーブルを利用したい

課題

  • SQLは何となく書けるが、dbtは完全初見の私が1人で開発をする

実践、アプローチと改善について

1. ローカルでいじってみよう

dbtをまずはローカル環境で動かしてみることで、“触って学ぶ”アプローチが有効だった話です。
手を動かしながら概念を理解していくことが、自分にとって最も定着につながると実感しました。

良かったポイント

dbtで始めるデータパイプライン構築〜入門から実践〜を一番最初に読み、試したことです。

dbtとは? から始まり、dbtの概要をざっと理解できます。
ざっくりdbtについて記載すると、ELTのアプローチにおける「T」層の部分を担います。すなわち、データの変換が責務です。

当時の私もたまたまこの記事と巡り会い、ローカルで手を動かしたのはとても良い選択でした。
公式ドキュメントをもとに作成されたこの記事は、「dbtとは何か?」の手助けとなり初手やるべきこととしてベストだと思います。

今思うと改善できたポイント

dbtで始めるデータパイプライン構築〜入門から実践〜を一度試して、後半の紹介をさらっと目を通して終わらせてしまったことです。

後半部分のdbt向けPythonライブラリのご紹介にライブラリの紹介などが記載されています。
ブログ後半にも記載していますが、言わずもがなdbtでもライブラリ利用が開発効率性を大幅にあげます。

なのでdbtとは何か?のイメージを掴むだけで終わらせるのではなく、「〇〇できるライブラリあるんだー」と雰囲気を知るためにも、一度は目を通すべきでした。

2. dbtベストプラクティスに目を通そう

「公式が言っている正解」を先に知ることで、設計や命名での迷いがぐっと減ります。
やみくもに試すのではなく、ベストプラクティスを押さえた上で判断できるようになったのは大きな収穫でした。

良かったポイント

ローカルで手を動かした後、dbt公式のベストプラクティスガイドを読んだことです。
先ほどの記事を見たからと言って、dbtを全て理解できるわけではありません。

「staging・marts層のSQLファイル名は何がよくて、何が悪いのか?」であったり、「baseフォルダはいつ作るべきなのか?」など深掘り知識を付けるには、公式ドキュメントを読み込むしかないです。

特にフォルダ構成のあるべき姿を、最初のうちに見てイメージをさらに固められたのが良かったです。
また、staging層やmarts層に求められている責務や、joinはどの層でやるべきなども書いてあるため、初見のdbt開発でもレールに従って開発ができます。

今思うと改善できたポイント

dbtのフォルダ構成・命名規則に問題はないが(運用上支障は出てない)、ymlファイル周りのコードが膨れ上がった際にどういうアプローチを取れば良いか、事前に公式ドキュメントを読み込んでイメージを作っておくべきでした。

弊社のstaging層の一部抜粋ですが、_{source}__{entity}s.sqlの公式ルールに従って設計いたしました。

bqやgcsでフォルダ分けしてますが、ファイル名にそもそもソース元を記載してるので、なくても良いのかなと運用してから気づきました。

models/staging
├── bq
│   ├── _bq__models.yml
│   ├── _bq__sources.yml
│   ├── stg_bq__dm_logs.sql
│   └── stg_bq__zip_codes.sql
│
│
└── gcs
    ├── _gcs__models.yml
    ├── _gcs__sources.yml
    ├── stg_gcs__companies.sql
    └── stg_gcs__geographical_coordinates.sql

一部抜粋なので、sqlファイルが少ないですが、本来は数倍以上あります。 実装当初の名残で各ymlファイルに全てメタ情報を詰め込んでいるため、800行近くあります。

とはいえ社内でのdbt知識に差があるため、1つの箇所に情報がある方がたどりやすいかと思い、当初の設計のままになっています。
いつかリファクタリングを行いたいと思ってます。

3. dbt Packagesの存在を知ろう

便利なライブラリを知らなかったせいで、手作業・重複コードが増えてしまった話です。
スター数が少ないからといって信用しないのはもったいないです。

良かったポイント

反省点多数。最低限dbt-utilsを導入していたのは良かったです。

今思うと改善できたポイント

当時の私は、dbt関連のライブラリのスター数が基本低いため(1000以下が多かった)、あまり利用しない方が良いのかと考えてました。

ですが、dbtの開発を進めていく中で、色々なブログでよく聞くpackage(dbt-external-tablesやdbt-osmosis)も、スター数が少ないものが多く、無駄な重複するコードをたくさん量産してしまったのが失敗点です。

なので、一から始める場合は、下記のライブラリには最低限目を通して、導入するか検討すべきだったと思います。

  1. dbtモデル開発時の便利関数やテストが豊富
    dbt-utils

  2. expect_column_to_exist など、データ品質チェックに特化した豊富なGenericテストが多数
    dbt-expectations

  3. モデル定義(ymlなど)を自動生成・保守できるツール。手動管理の負担を大幅に軽減
    dbt-osmosis

  4. dbt Labsのベストプラクティスに基づいて、命名や構成をチェックし、ソースコードの品質を担保
    dbt-project-evaluator

  5. dbtプロジェクトのデータの可視化・アラート・監視などを可能に
    elementary-data/elementary

  6. GCS・S2など外部データをテーブルとして定義可能
    dbt-external-tables

4. メタデータを管理しよう

メタ情報の整備は地味だけど重要です。手動管理は非効率なので自動化できるとすごく楽になります。
ymlファイルの記述を毎回手でやっていた当初の自分に「自動生成できるぞ」と教えてあげたいです。

良かったポイント

手間ではあるが、sources,modelsのymlを毎回定義していたのはよかったです。

今思うと改善できたポイント

手間な作業をもっと効率的にできないか? の視点が抜けていたことです。
dbt開発当初、コピペの連続でymlファイルを定義してました。
ですがdbt-osmosisという、とても便利なライブラリがあります。(プロジェクト後半で存在を知りました。)

dbt-osmosisについての説明は記事が多く存在するため割愛します。
いくらdbtの設計が綺麗でも使われるテーブルを生成しなければビジネスに何も影響がありません。
利用者を増やすためにもメタデータの豊富さは必要不可欠です。

特にdbt LabsがSDF Labs を買収したことにより、dbt-osmosisの必要性は今以上に上がると考えます。
カラムリネームはもう怖くない！dbt‑osmosisを超えるSDFの挑戦 の記事が大変参考になります。

5. awesomeを見よう

他のdbtプロジェクトを見ると、自分たちの設計や実装に活かせるヒントが山ほどあります。
特にmacroの実装例やフォルダ構成は、ベストプラクティスと合わせて学ぶと設計の視野が広がります。

良かったポイント

dbt公式でjaffle-shopのディレクトリ構成以外にも、他のdbtプロジェクトの事例がないか検索しawesome-public-dbt-projectsとawesome-dbtに辿り着き、どのような実装を行っているのかを知れたのは良かったです。

dbt公式のベストプラクティスに基づいてないような場合もありますが、フォルダやファイル名の切り方など色々な角度から学習できます。
macro層や実装方法では、mattermost-data-warehouseの書き方を参考にしたりしました。

Jinja自体初見だったため、dbtの文法なのかJinjaの文法なのかわからず何も分からなかったので、helpers.sqlのSQLコードを見たりして、書き方の一例としてインプットしてました。

今思うと改善できたポイント

特段ないです。良い視点で情報収集できたかと思います。

6. テストを書こう

dbtにも“制約に近い”テストが存在し、使うことでデータ品質を担保できます。
SingularテストとGenericテストの違いを理解しておくと、最小工数で最大の保守性を得られます。

良かったポイント

改善点多数あり。テストの認識を間違えていました。

今思うと改善できたポイント

Singularテストのような、一種のDB制約のようなものが機能として存在していたことを見落としていました。　　

dbtのtestには大きく分けて、SingularテストとGenericテストがあります。
Singularテストはtestsディレクトリ配下に定義する下記のようなものです。
一例ですが、法人番号(corporate_number)がnullのレコードが存在してると落ちるテストです。

## tests/test_companies_corporate_number_not_null.sql

select
  id,
  corporate_number
from {{ ref('companies')}
where 
  corporate_number is null

私がdbt開発を行ってる際、知識不足で「テスト = 上記のようなSQLを毎回書くもの」と勘違いしており、dbt自体開発が完成して、運用した後に書く判断をしてしまいました。 これは大きな反省点です。
本来ならば、作成したテーブルで確実にnullを許容しないカラムには絶対テストを書くべきでした。

ここでGenericテストが登場です。

  • unique
  • not_null
  • accepted_values
  • relationships

の4つがあり、「ymlの定義だけで」テストを実装できます。
先ほどのSingularテストを書き換えると下記のようになります。

version: 2

models:
  - name: companies
    columns:
      - name: corporate_number
        tests:
          - not_null
          - unique // 一意であることも確認したいなら

当時の実装では、テストを一切書いていなかったため、nullを許容すべきではない箇所にnullが入ったりと、開発以上に調査時間が増えてしまいました。
なので、最低限Genericテストは書きましょう。時間がなくても。

参考: dbt公式-テストについて

最後に

弊社では各事業部でエンジニアを募集しております！ 気になるポジションあればお気軽にお問い合わせください。一緒に働きましょう。

弊社の各事業部でエンジニアを求めています！

SaaS

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

PLEX JOB

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

コーポレート

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

Devin × Renovate 運用効率化の第一歩 : 一次レビューをAIに任せてみた話

AIエージェント ツール 組織 技術 AI プログラミング

はじめに

こんにちは。PLEXでPLEX JOBの開発を行っている田中です。
前回は、同じ開発メンバーの小松さんが「DevinにE2Eテストさせてみる」という記事を執筆しましたが、今回はその続編として、Devin活用シリーズ第2弾をお届けします！

概要

Devinの導入を検討した背景としては、チーム内で開発効率を高める手段として、Devinを活用したいという声があったためです。
私の所属しているPLEX JOBチームでは、1スプリント(1週間)の中で約10%程度を技術的負債の解消に割り当てています。
また、弊社ではライブラリの依存関係の更新にRenovateを採用しており、対応もその一環になっています！

Renovateをマージする際には、一般的には以下のようなプロセスを踏む必要があります。

①自動更新対象のパッケージに関して、該当バージョンのリリースノートを確認し、破壊的変更が含まれていないかを確認する
②破壊的変更がある場合は、プロジェクトのコードに影響があるかどうかを調査する
③影響があると判断した場合には、既存の動作を維持するためにソースコードの修正や対応を行う

①の破壊的変更がなければ、それほど時間は掛からずにマージが可能と判断できますが、③まで作業を行った場合は、影響範囲によってはかなりの工数がかかることになります。
そこで今回、Devinに一次レビューを依頼し、「マージしても問題ないか」の判断材料を挙げてもらうことで、開発者の負担を軽減できるのではないかと考え、試してみることにしました。

対象読者

  • Devinを使ったことはないが、実際にどこまで使えるのか興味がある方
  • AIを活用して日々の業務の時短を行いたい方
  • Renovateをチーム開発に導入しているが、PRのレビュー対応が負担になっていると感じている方

DevinにPRレビューを任せてみた結果

プロンプトや具体的な指示の出し方については、以下の記事を参考にしつつ、今回の用途や対象となるリポジトリに合わせて、個別にカスタマイズを行いました。

developers.freee.co.jp

drbアップデートのRenovate対応
drbのマイナーアップデートになりますが、Devinの一次レビューをRenovateのPRにコメントさせてみました。 次の観点で、十分な精度のあるアウトプットが得られたと感じています。

  • 視覚的にレビュー内容が見やすい
  • テストの実行結果が対象の件数を明記した上で、全テストが成功していることが分かる
  • リリースノートやCHANGELOGの破壊的変更を確認し、分析した上でマージ可能なことが分かる

Devinでレビューさせる対象PRの選定基準

対象となるPRの条件

  • 比較的ボリュームの小さいライブラリかマイナーアップデートのライブラリを対象

対象のPRに対するDevinの役割

  • フロントエンド
    • 破壊的変更の調査
  • バックエンド
    • 破壊的変更の調査
    • アップデート後のローカル環境RSpecが通るかの確認
      • テストが通らない場合は、失敗しているテストケースと修正案まで提示

担当者の対応事項 / マージOKかの判断基準

プロンプト設定

Devinの回答精度を向上させるには、何よりプロンプトのチューニングが一番重要です。
DevinはOpenAIのGPT-4をベースに設計されています。
そのため、Open AIが出しているベストプラクティスをもとにプロンプトのチューニングを行いました。

どれも重要ですが、私が特に気を付けていたのは下記になります。

  • 構造を理解しやすいように、コンテキストを明確に区切る
  • 具体的なすべきことや例を提供する
  • 欲しい出力形式を明確にする

これらのポイントを意識することで、回答精度は大きく向上しました！

プロンプト定義

Devinに的確な一次レビューを行ってもらうため、以下のようなバックエンド用のプロンプトを用意しました。

## 対象PR

(URLを入力する)

## 注意事項

- 回答はすべて日本語で行う
- 実際の実装に影響がなければ破壊的変更への対応が不要な分、レポートは簡潔に表現する
- あらゆる一次情報源（コード、コミット履歴、変更履歴等）を参照する
- 全ての引用・参照には必ず元のURLを添付する
- コミットとマージは行わない
- 最後に「対象PR」のコメントとして、以下のようにまとめる
  - (Devinが過去に書いたコメントの中で見本となるリンクを追加)


## 依頼内容

- 「対象PR」の依存関係更新に問題がないかの確認を行う
- 「対象PR」のタイトルからでなく、ファイルの更新内容を元に調査を行う
- 現在のバージョンと更新後のバージョン間の破壊的変更(breaking changes)を確認する
- CIが失敗している場合は、CIを直すためにローカルで検証し、コミットは行わず修正案の提出だけをする
- バージョン更新後の動作確認を行う
- バージョン更新後docker compose run --rm web bundle exec rspecを実行してRSpecのテストが問題ないかの確認を行う

## 破壊的変更への対応
破壊的変更が見つかった場合：

- 具体的な実装パターンへの影響例（ある場合は実際のコード例）
- 互換性維持のための具体的なコード修正案
- プロジェクト全体への影響度合い
- ただし、ライブラリのバージョンアップデートだけで問題が解決する場合は修正案不要

## レビュー結果の提示

- 必ず単一のコメントにまとめて提供
- 結論を最初に明示（承認または修正必要）
- 調査に使用した全てのドキュメント・ソースへの直接リンク
- コード例はマークダウン形式で、行番号参照付きで
- 分析は事実に基づき、重要な問題に集中

## 調査結果 : 

- 下記の観点で最後にまとめる
    - 結論
    - 脆弱性の詳細
    - パッケージ更新の適切性評価
    - プロジェクトへの影響
    - 調査方法
    - 参考リンク
- 調査結果は「対象のPR」コメントする

フロントエンド側のプロンプトは、破壊的変更の調査のみに限定しているため、RSpecのテスト確認の一文を削除して使用しております。

Devinの2パターンの運用

  • Slackに直接プロンプトを入力して実行
  • Playbooksからマクロを呼び出して実行

Slackから実行

Slack上で「@Devin」を入力した上で「プロンプト定義」のプロンプトを入力します。
「対象PR」のURLだけはそれぞれのリンクを貼り付けて実行するようなイメージになります。

Playbooksから実行

Playbooksとは、繰り返し実行されるタスクのプロンプトを定義するための機能になります。
作成したPlaybooksには「プロンプト定義」のプロンプトと同じものを貼り付けします。

「対象PR」

{{ pr_url }}

「対象PR」のURLを貼り付けるところだけ動的にしますので、この部分だけ修正が必要です。

その上でPlaybooksから「Use Playbooks」ボタンを押下し、以下のような画面で入力を行うことで実行できます。

Playbooks実行画面

好みになりますが、Slackから実行する時の方が、直に貼っている分、プロンプトの内容をより網羅的に回答している印象です。 Playbooksはコピペのミスがなくなったり、入力のテキストが少ないという利点があるので、両方試してみて使い勝手が良い方法を導入して頂ければと思います。

コスト

Devinを使う上でACUでどれくらい一つのタスクで金額が消費されたかの目安を知ることが重要です。
ACUとは、Devinが作業を行う際に消費する計算リソースの単位になります。

実際にどれくらい使ったかはDevinのUsage Historyでセッションごとに確認することができます。
弊社ではTeamプランを契約しており、1ACUあたり2ドルかかります。
おおよそ軽いRenovateなら1〜2ACU(300円~600円)ぐらいに収まります。
この程度のコストであれば、試してみる価値は十分にあると感じています。

Devinは実務で使えるか

結論としては、範囲を限定的にすれば実務で使えるかなと思いました。
例えば画面のUIの確認はDevinの苦手な分野かなと考えています。
Material UIのメジャーアップデートでプレビュー環境でアイコンの表示崩れや画面の動作確認などもさせてみましたが、網羅性にはやや疑問が残る印象でした。
結果としてフロントエンドは、作業者が実際にリグレッションテストを行うべきかなと思い、破壊的変更のレビューのみに絞りました。

とはいえ、Devinの一次レビュー活用は、Renovateの対応工数を削減する選択肢としてはかなりアリかなと思いました！

今後の運用方針

今回は私が中心となって検証を行いましたが、来月からは運用ルールを整備し、Renovate対応に関してはDevinによる一次レビューを必須とする試験運用をPLEX JOBチーム内で開始する予定です。

具体的には、各メンバーに検証対象とするRenovateをアサインし、スプレッドシートにDevinの検証結果を記入してもらいます。
メンバーからの評価や所感を聞くことで更に改善できることも見えてくると思います。
後々はしっかり本格的な運用まで結びつけたいと考えています！

最後に

弊社では各事業部でエンジニアを募集しております！ 気になるポジションあればお気軽にお問い合わせください。一緒に働きましょう。

弊社の各事業部でエンジニアを求めています！

SaaS

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

PLEX JOB

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

コーポレート

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

DevinにE2Eテストさせてみる

ツール AIエージェント

はじめに

こんにちは。PLEXでPLEX JOBの開発を行っている小松です。

E2E テストのつらさ

E2E テストってみなさまどのように行っているでしょうか。なんだかんだ人力に落ち着いた、というチームも少なくはないのかなとも思います。
E2E テストにおいて人力の優れている点は何と言っても UI への適応力です。既存のテストツールは UI の入力フォームに必須項目が一つ増えればたちまちテストシナリオが壊れてしまいますが、人は「ん？こんな入力項目あったけな？こんな感じでいい？」といい感じに入力してくれます。人ってすごい…。

今回の目論見

今回は弊社でも検証導入中の Devinくんにブラウザを操作してもらい、WEB アプリの E2E テスト（UI テスト）を行います。
今回の E2E テストの目的というか目論見は

  • E2E テストの工数を減らしたい（人間はサボる！）
  • E2E テストツールのメンテナンス工数を減らしたい

あたりになります。
また Devin というキーワードでいうと、割と初学者向けの話になるかなと思います。

  • Devin で何ができるか情報収集中の方
  • 導入したけど ACU が余っている

みたいな方ですと、何かの参考になるやもしれません…！

我々のDevin 開発環境について簡単に

Devin マシンもメンバーの開発環境とほぼ同じ

実行環境の構成

今回 Devinくんには弊社の PLEX JOB というサービスの E2E テストを行ってもらいます。

簡単に Devinくんの開発環境の構成は以下のような形です。

repos/
├── plexjob_api/   # Ruby on Rails の API
└── plexjob_web/   # Next.js のフロントエンド

API は Docker compose で立ち上げ、フロントエンドは Devin マシンの node.js に直接立てています。これは我々エンジニアの開発環境の構成と全く同じで、docker-compose.yml も社内のエンジニアたちが利用しているものをそのまま利用しています。
また、テスト結果を確認できるようにpostgresql-clientをインストールしています。

今回のテストはここで立ち上げたローカルホストに Devin の持っているブラウザからアクセスしてもらい、実際にブラウザを操作してもらって行います。

Devin実行環境の様子

実践、Devinくん に E2E テストはできるのか

結論

ジュニア以上(？！)にはやってくれる。
課題はありつつも(後述)、個人的には期待以上の働きを見せてもらいました。いや、むしろ、君、ジュニアってレベルじゃないんじゃない？

検証方法

テストシナリオ

今回テストシナリオは人にとっての読み易さと Git での管理のし易さからマークダウン形式で記述しました。
元々社内でリグレッション用に持っていたテストシナリオはスプレットシートだったのですが、それを ChatGPT くんにざっとマークダウンに直してもらい、最後は私の方で調整しました。

できたものの抜粋が以下。
何度か検証してみて、Devinくんは手前に置いた内容に重きを置いてくれそうだった為、最終提出物として欲しいエビデンスに関しては冒頭で述べる事にしています。ただし、今回のテストケースではエビデンスの指示はしたものの報告フォーマットの指示までは行っていません。

## 前提

http://localhost:3000/
へアクセスしてWEB画面を検証

## 会員登録＋応募フロー（ドライバー）

### No.1 会員登録＋応募（ドライバー）

#### 前提条件

- ログイン済の場合はログアウトしておく

#### エビデンス

テスト結果として以下を提出すること

- 今回の処理で登録されたusersレコードの内容
- 【期待結果】とされている画面のキャプチャ

#### 操作手順

1. **ドライバーの求人情報一覧(driver/)から任意の求人を選択する**
    -  選択「詳しくみる」ボタンをクリック
    - **期待結果:** 求人詳細画面へ遷移する

以下略

会員登録＋応募を行い、「電話番号登録済みのエラーの確認」と「応募完了の確認」と2つの結果を確認してもらいます。
今回はこちらをソースコードと同じリポジトリに同梱してテストを行います。

テスト開始

まず Devin くんには以下のような指示をしてみました。(今回 Slack のメンションをトリガーにテストを開始しています)

①plexjob_apiのブランチをfeature/data-maintenance-for-devinを変更して作業を始めて
②setup-pj-webの手順でplexjob_webのローカルホストを上げて
③docs/test_case/basics/01-01_job_entry.md
このファイルを確認してテストを実行してみてほしい。
③-1. まず一度テストケースを確認したら実行計画を教えて。（報告だけで承認は不要）
③-2. テストを実行して。

という指示を出します。
①でまず検証用のブランチに切り替えてもらいます。（Seedデータのメンテナンス、テストシナリオの配置を行いました）
②のsetup-pj-webはDevinのKnowledge機能に設定しているマクロです。ローカルマシンの立ち上げ方が記載されています。なくてもDevinくんはよしなにやってくれると思いますが、再現性の向上や消費ACU1の削減等が期待できます。
③テストシナリオファイルはGitでソースコードと一緒に置いて検証しました。

するとDevinくんからはまだできるか分からないけどとりあえずテストケースを読んでみるねという旨の返事がありました。

そしてテストケースを確認するとまあまあな確度でできるかも！と返事が来ました。
（私が「gogo」と茶々を入れてますが別に何も言わなくても続けてくれます）

この間WEBからはDevinくんの作業プロセスを除き見る事ができます。Devinくんのブラウザで実際にカーソルが動く姿を確認できます。
更に待つとテストが完了したようです。

画像からはカットしてしまいましたがテスト結果として求めているレコードの検索結果と期待した画面キャプチャを添付してくれました。
画面テストしての信頼性は申し分ないなと感じました。

課題点

今回完璧な仕事をしてくれたDevinくんですが課題点もなくはないです。

運用コストは組織の価値観次第かも

今回のテストシナリオは1つの求人に会員登録を伴った応募をするというものでしたが、これにかかったACUは2.5です。 現在PLEXではDevinをTeamプランで契約しており、その場合1ACUは2ドルで換算できます。なので応募テストにかかった費用はだいたい5ドル程度となります。
実運用で回すテストシナリオは簡易な求人応募シナリオに絞ってもこの5~6倍の規模になります。もちろん、会員登録を伴わないケースもあり費用が純粋に5~6倍になるわけではないですが、日常的にテストを回していく事を考えると費用対効果はもう少し検証が必要そうです。

逆に今回の検証では費用感以外は大きな課題も感じなかった為、ここが見合いそうな組織には現実的な選択肢になってくるかもしれません。

Tips

最後にこの検証で得られたTips的なものを共有します。
どれも人にテストを依頼したとしても通じるような話ばかりかもしれませんが。

ステップを踏んで実行させる、しかし実行許可は不要であることを明言

AIエージェントを使う際は共通することかもしれませんが、Devinくんもテストシナリオを読み込んだ後、実行計画を提出させた方がその後の実行制度が高くなるように感じます（大抵は言わなくても出てきますが）。
ただし、実行計画を提出した後、Devinくんが「この実行計画で実行して良いかな？」という許可待ち状態になることがある為、事前にユーザーの実行許可を待つ必要がない事を明言した方がよさそうでした。

テストする画面のURL、フォームの入力内容はなるべく具体的に指示をする

Devinくんの良さとしてファジーな指示でもテストシナリオが崩壊しないという点を冒頭で述べましたが、それでも指示はなるべく具体的な方がスムーズです。例えば「画面のフォームをすべて入力して」という指示でもどうにかなる時はなりますが、テストの精度やコストは具体値を指定した方が結果が良くなります。

エビデンスのデータフォーマットは具体的なSQLで指示する

画面テストを行う上でDevinくんにデータ構造を意識させるコストは勿体ないので、DBの登録値を提出させたい場合は提出用のSQLを用意すると期待値に近いテスト報告を受けることができそうでした。

複雑なHTML構造の操作は苦手

今回のテストで実行コストが嵩んでしまった要因であると感じているのですが、例えばラジオボタンやセレクトボックスを人間向けにカスタマイズしているような画面（素直なフォームと構造が異なる）の操作はDevinくんは若干苦手なのかなという印象でした。
逆にプレーンなフォームの入力、ボタンの押下などはあっさりこなしているように見えました。

最後に

弊社では各事業部でエンジニアを募集しております！ 気になるポジションあればお気軽にお問い合わせください。一緒に働きましょう。

弊社の各事業部でエンジニアを求めています！

SaaS

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

PLEX JOB

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

コーポレート

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

  1. ACU...（Agent Compute Unit）Devinの実行コストを数値的に表現した指標↩

【TSKaigi2025】TypeScriptが苦手な私を登壇へと導いた「たった1つの習慣」

勉強会 イベント

はじめに

こんにちは。

株式会社PLEXでWebエンジニアをしている栃川です。

このたび、TSKaigi2025で「型推論の扉を開く―集合論と構造的型制約で理解する中級へのステップ」というタイトルで登壇いたしました。

この記事では、TypeScriptが苦手な私でも登壇者としてステージに立つことができた「たった1つの習慣」についてお伝えします。

※ 発表資料は記事の末尾にてご覧いただけます。

前提

私はTypeScriptに対する強い苦手意識があります。

というのも、これまで私はRuby（動的型付け言語）を得意としてきました。

TypeScriptは入社後に学び始めたものの、動的なJavaScriptの世界観に慣れた私には、TypeScriptはまるで異世界の言語に感じられました。

型エラーに遭遇するたびに調べものが増え、学習が停滞。小さなプロジェクトで何度もコンパイルエラーに泣かされ、「なぜ動かないのか」を腹落ちさせるまでに時間がかかり、自信を失う日々を過ごしていました。

その結果、TypeScriptの奥深さを知ることなくエラーを潰しては、そのまま業務をこなすだけ。 苦手意識ゆえにTypeScriptそのものが好きになれませんでした。

自分を変えた「たった1つの習慣」

では、どうしてプロポーザルを通し、ついには登壇できるようになったのか―― それは「日報をつける」というたった1つの習慣を継続したことです。

曽根さんの「強いエンジニアのなり方」という資料に出会い、私は日々の業務に自ら日報をつけることで、自分自身でフィードバックサイクルを回す習慣を取り入れました。

speakerdeck.com

この習慣を身につけてからというもの、ただエラーを潰すだけの日々から、そのエラーはなぜ起き、それが何を防ぎ、どんな思想に基づく設計なのかまで深掘りすることを、自然とできるようになりました。

毎日知識を消化せずにストックしていくことで、次第に「今の自分に何が足りないか」や「次もっとよくするために何ができるか」が見えてきて、自らフィードバックサイクルを回せるようになるのです。

参考: **強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day - Speaker Deck

結果として、単なる知識が経験に紐づいた知識へと変わり、自らの血肉になっていきました。

なお、今回通過したプロポーザルの内容も、まさに日報で蓄積した気づきや考察をまとめただけのものです。

日報を書き続けておけば、登壇のようなチャンスが来たときに、すでに整理された材料をもとに初動を素早く進められるのも大きなメリットです。

日報はどう書くのか？

私の日報はシンプルに「起きたこと」と「考察」を記すだけです。

ポイントは、形式にこだわらず思いの丈をとにかく吐き出すことが大切だと考えています。

例えば、以下のように書き連ねます。（社内でも初公開のため非常に恥ずかしい笑）

誰にも見られない前提なので、支離滅裂でも間違っていても問題ありません。 重要なのは、書くことで思考が整理され、自然に内省・Nextアクションへつながっていくことです。

また、毎日書くことにこだわりすぎないほうがいいです。

毎日必ず深い学びが得られるわけではありませんし、あまりに「毎日書かねば」と意気込みすぎると、一度書けなかっただけで「もうダメだ…やめよう！」となりかねません。完璧を目指さず、まずは小さな一歩から始めて、自分のペースでゆるく継続していくことが大切だと私は思っています。

週報じゃダメか？

個人的にはおすすめしません。

（実際にやってみましたが）週報は進捗共有になりがちで、私のように忘れがちな人間には、大した内省につながらないことが多いです。

1日ごとに、その日の出来事や感じたことが鮮明なうちに日報を残すほうが、振り返りの精度は段違いに高まります。また、そうした振り返りを続けることで、成長のスピードが著しく上がるのもいうまでもありません。

さらに、日報という粒度の小さい記録のほうがサッと書きやすく、習慣化しやすいメリットがあります。週報だと情報量が多くなりがちで、書くハードルが一気に上がってしまいます。

こうした理由から、週報より日報のほうが継続しやすく、得られるメリットも大きいと言えます。

最後に

今回の登壇はわずか5分という短い時間でしたが、本当に楽しい経験でした。

Xで反応をいただいたり、元同僚から連絡をもらったり、「集合で捉えるという考え方を知らなかった！参考になった」と感想を聞けたことが嬉しかったです。

また登壇をきっかけに、休憩室で他社DevRelの方々から声をかけていただき、「技術広報のキャリア」や「他社のエンジニア採用事情」、さらには「ブログ運営のコツ」など、普段は聞けない貴重なお話を伺うことができました。こうした交流から新たな視点やインスピレーションを得られたのも、何よりの収穫です。

エンジニアイベントはやはり刺激と学びに溢れていますね！

次回はKaigi on Rails2025に参加しようよ思います！さらなる挑戦に向けて準備を進めいきます！

登壇資料

speakerdeck.com

宣伝💡

弊社では各事業部でエンジニアリングのポジションを募集しておりますので、気になる方はぜひ下記のポジション一覧をご覧ください。

私宛にでももちろんOKです！Xなどでぜひお声がけください！（転職を考えていない方でも歓迎します）

弊社の各事業部でエンジニアを求めています！

SaaS

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

PlexJob

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

コーポレート

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

私の連絡先はこちら

https://x.com/Web_TochiTech

【入社エントリ】成長のレバレッジと人生の揺らぎを求めて by tetty

入社エントリ フロントエンド 組織 企業文化

【入社エントリ】成長のレバレッジと人生の揺らぎを求めて by tetty

転職しました

はじめまして！こんにちはこんばんは！フロントエンドエンジニアのtettyです。

株式会社プレックスに転職してから半年と少しが経過したので入社エントリを公開します！

また、転職前に相談やお誘いいただいた皆様にはこの場を借りて改めて感謝申し上げます。

本当にありがとうございました！

株式会社プレックスについて

弊社は2018年に創業した現在8期目のスタートアップで、日本を動かす仕組み作るというミッションを掲げている企業となります。

事業においてはエッセンシャルワーカーの人材紹介や採用支援に加え、SaaS事業やM&A仲介事業など複数の新規事業を展開しています。

概要だけではよくわからないかもしれませんので、ほんの一部ですが弊社のすごいポイントを紹介させてください！！！

2024年度（7期目）の売上総利益（粗利）60億円突破！㊗️㊗️㊗️

2024年度の売上総利益60億突破

日本最大級の運送｜建設｜技術職の求人サイト「プレックスジョブ」 累計登録者数が100万人を突破

prtimes.jp

建設業に特化したクラウドサービス「サクミル」、リリース1年9ヶ月で正式利用企業数が1,000社を突破

prtimes.jp

M&A支援機構が成約事例・実績を初公開 ー 吉野家ホールディングス × キラメキノ未来の対談も掲載

prtimes.jp

"組織の壁"を越えて、気づいたら420人規模になっていたベンチャーが、秘かに大事にしていること

note.com

いいですか？この会社は8期目ですよ？8期目。

しかも、ファイナンスもノンエクイティのモデルを取っている上で毎年度、各事業部が、超超飛躍的に成長しています。 めちゃくちゃすごいです。

はて、ノンエクイティとは？という方はぜひ弊社代表の記事をご覧ください。

comemo.nikkei.com

経歴

弊社の紹介は置いて、簡単ですが私の経歴をご紹介します。

  • 2016年: 日本工学院八王子専門学校のITスペシャリスト科入学
  • 2017年: 開業し個人事業主としてWeb制作やWebサービスの受託開発を行う
  • 2018年: Kakedasの共同創業者兼CTOとしてプロダクト開発から開発組織の組成（現在MA済）
  • 2020年: 合同会社DMM.comに20新卒で入社
    • 動画事業全体のTechnicalSEOのディレクションと開発を担当
    • DMMTV フロントエンド領域の立ち上げメンバーとして参画
    • 上記プロダクトにおいてテレビ・ゲーム機向けのアプリの開発からローンチ、その後の改善・機能拡充をTech Leadとして従事（一部マネジメントを担当）
  • 2024年9月: 株式会社プレックスに転職

転職経緯

前職での葛藤

もっとハードな環境かつハイコミットなメンバーがたくさんいる高い基準値の環境で、いち技術者として事業開発を楽しみたいという思いが常にあったことが葛藤としてありました。

しかし、次なるキャリアとしてより大きなスケールでエンジニアリング領域を強くしていく必要性があり、自身がプレイヤーから離れた状態でスケーラブルなチームを組成をすることや開発メンバーに対して今以上のフィードバッグをすることが困難になっていくと感じていました。

現場への未練もあったのだと思います。

（※前職は良い仲間や仕事にも恵まれていたのでとても働きやすい良い環境でした！）

転職を決意

そんなこんなでプロジェクトが落ち着き、当時担っていたマネジメントやテックリードの委譲・引き継ぎが完了したタイミングで転職をしました。

理想的なリーダー像とは何か、事業の開発組織においてよい環境や自分にとってのマクロな楽しさとは何かを自身に問うためにも、人生で最も苦しみ楽しんだスタートアップという環境に戻ってきたというわけです。

戻ってきた企業がプレックスだったのですが、創業時からプロダクト開発のお手伝いをさせていただいておりました。

圧倒的な企業の成長と若手を中心とするハイコミットな仲間たち、そしてそれらが醸成される再現性の高い環境が生まれ大きくなっていくのを肌身に感じ、開発本部の立ち上げと新規事業への参画を機会に転職を決意しました。

プレックスでやっていること

主にサクミルのフロントエンドのリードおよび開発を行っております。

sakumiru.jp

サクミルとは

サクミルは建設業に特化したクラウドサービスとして、現場・管理・経営層が一体となって生産性の向上や負担を軽減を目的に開発されたサービスです。

このサービスは案件管理をはじめとしてスケジュール・日報の管理だけでなく、見積書や請求書の作成/原価管理・入金管理など、管理者と現場間で情報を分断することなく一元管理できます。

建設業に特化したクラウドサービス「サクミル」

私がこの半年で主に担当したものでいうと、フロントエンド領域を中心にサービス全体の権限管理機構やメンバーの予定を管理・閲覧するカレンダー機能（例えばGoogleカレンダーのような粒度をまるっと作るイメージ）、その他に開発基盤周りやDatadogRUMを用いたモニタリング環境の構築・改善などを行いました。

技術者としての面白ポイント

プレックスで半年働いた上で私が面白く魅力だと感じたポイントを一部紹介します。

その① オールインワンSaaSをつくっているよ！

世の中には様々な業務効率特化型のSaaSが生まれていますが、サクミルは特化型ではなくオールインワンSaaSを目指しています。

よって、開発する機能群が単体でサービスとしてマネタイズできるような機能となっており、機能開発のタスク1つ1つが非常にハードかつ技術者としても事業ドメインを作る人間としても成長やこだわり・やりきるためのディスカッションとチャレンジを求められるようになっています。

つまり、1つ1つが持ちうるスキルの切り売りではできないものばかりなのです。

その② 技術者として純粋なフィードバックを受けられるよ！

また、弊社が毎年度成長をしている大きな要因としてビジネスチームがめちゃくちゃ強いんですよ。

定量定性をやりきり事業と売上を毎年度大きく伸ばしているビジネスチームやマネージャーの存在によって、我々技術者の作ったものがそのまま定量定性の結果に現れるという純粋なフィードバックを得られることが我々をより成長させる確実な材料であると感じています。

その③ 打席がめちゃくちゃ多いよ！

弊社は各事業が圧倒的にスケールをしているだけではなく、新規事業もメガベンチャーにいた時とは非にならない頻度で生まれます。

技術者にとっては0から100までの機会があり打席があるということになるので、経験したことのないフェーズや練度を高めたいフェーズの開発に携わることのできる打席が比較的多くあります。

そのため、色々な景色をみて経験をしたいというモチベーションのある方は面白く感じるポイントだと感じますね。

これから転職を考えている人や今の環境に悩んでいる人へ

まずは数ある記事の中からここまで読んでくださりありがとうございます。

最後に、入社エントリではありますが私から1つお伝えたいことがあります。

皆さんは自身の成長要因はどのようなものだと考えているでしょうか。

実際、様々な要因がありますが私は一番の理由として”仕事をやりきった先に得られる成功失敗の体験が純粋な結果として示され、次のモチベーションや打席につながるプロセスを構築できること”が成長のレバレッジとして最も大きいと考えています。

これはサラリーマンとして企業で働く身としては個人で継続・完結することが非常に困難であるものです。 つまり、自身がどの環境でどういう基準値を持った仲間とどういうスタンスで働くかは非常に重要です。

人生において多くの時間を有する仕事という時間をより楽しく、より熱を持って、自身の基準値をアップデートしてもらえる確信が弊社にはあります。

安定こそすばらしいものですが、自身の成長にレバレッジをかけてみたいという方はぜひ弊社で揺らぎを感じてみませんか？

おわりに

弊社では各事業部でエンジニアリングのポジションを募集しておりますので、気になる方はぜひ下記のポジション一覧をご覧ください。

私宛にでももちろんOKです！WantedlyやXでぜひお声がけください！（転職を考えていない方でも歓迎します）

弊社の各事業部でエンジニアを求めています！

100兆円規模のインフラ産業の課題解決に挑戦｜業務支援SaaSのテックリード - 株式会社プレックス

急成長する業務支援SaaSのソフトウェアエンジニア・リードエンジニア - 株式会社プレックス

インフラ産業の人材課題を解決 | フロントエンドの技術を牽引するテックリード - 株式会社プレックス

インフラ領域で日本を動かす仕組みを作るスタートアップのエンジニア - 株式会社プレックス

オペレーションの効率化によって事業成長に貢献するコーポレートエンジニア - 株式会社プレックス

私の連絡先はこちら

https://www.wantedly.com/id/tetty

https://x.com/tetty0217