入社から2年間で、ダイレクトリクルーティングとSaaSの業務支援クラウドの2つのプロダクトを立ち上げ、エンジニアの組織づくりにも取り組んできたCTOの石塚に、プレックスのエンジニア組織や開発環境の特徴、現状の課題や今後の展望について話を聞きました。

石塚 淳（いしつか じゅん）
CTO
1992年茨城県常総市生まれ。茨城県在住。東京大学卒。ソーシャルゲームやニュースアプリを運営する企業において、開発や分析、新規事業の立ち上げを経験。フリーランスとしてさまざまなスタートアップの開発、分析の支援をおこなったのちに、2021年6月にプレックスにジョイン。CTOとして開発組織全体を統括。

１）開発以外にも事業成長に必要な経験を積んだCTOのキャリア

ー現在のプレックスでの役割について教えてください。

2年前にプレックスに入社し、現在はCTOとしてエンジニア組織全体を統括しています。当社には「PLEXJOB」というダイレクトリクルーティングのプロダクトと、「サクミル」というSaaSのプロダクトがあり、さらにコーポレートエンジニアリングチームが営業を支援する社内システムの開発と管理を担っています。

「サクミル」は設備工事・メンテナンスに特化した業務支援クラウドで、事業者がどこでも簡単に報告書を作成したり、顧客や案件管理をしたりすることができ、社内外の情報連携を円滑におこなうことができます。2023年7月に大幅なリニューアルと価格改定をおこない、設備工事・メンテナンス以外にも、建設領域の様々な業種のお客様から支持を集めて急拡大している事業です。

この2年間で、2つのプロダクトの立ち上げと、コーポレートエンジニアリングチームの体制構築、エンジニア組織全体の採用や組織づくりなど、全方位的に取り組んできました。

ープレックスに入社するまではどのような経験をされてきたのですか？

私は新卒で、ソーシャルゲームの開発をおこなう会社に入社しました。学生時代からプロダクトづくりに携わりたいという想いがあり、サーバーサイドエンジニアとして、複数のゲームを横断した分析基盤や社内向けツールの開発など、ゲームに限らず様々な開発に関わっていました。

こうした経験によってプロダクトを独力で開発できる自信を得たため、今度はサービスを成長させる経験を積むために、メディア事業を手掛ける事業会社に転職しました。データを重視し、数値に基づく意思決定がなされる環境に魅力を感じたため、一旦開発を離れ、データ分析に取り組みながらサービスを成長させるためのアプリ施策の実行や効果検証をおこなっていました。

しばらくはデータ分析を中心に仕事をしていましたが、定量データの分析と改善による効果には限界があるため、ゼロから事業やサービス作りに携わりたいと考え、新規事業開発の部署に異動しました。定量データの分析だけでなく、ユーザーインタビューなどの手法も試しながら、新規事業やプロダクトの立ち上げを経験できたのは良かったですが、既存ビジネスとのシナジーがあるプロダクト開発が優先されるあまり、経営と現場で意見の食い違いが生まれるなど、新規事業の難しさも実感しました。

PdMや企画のメンバーと数値を元に議論しつつ開発を進める機会も多く、テックサイドとビジネスサイドを繋いでいく経験ができたことは、CTOとして組織づくりをおこなう上で、大いに役立っています。

２）一人目のエンジニアとして、同時並行で進めた開発と組織づくり

ープレックスにはどのような経緯で入社されたのですか？

前職を退職し、フリーランスで複数のスタートアップのデータ分析の支援をしていた際に、大学時代からの知り合いだった黒﨑さんからダイレクトリクルーティング事業の構想を聞き、その立ち上げのためにプレックスに入社しました。

2年前はまだ30名くらいの組織規模で、エンジニアは私とインターン生だけでした。自分だけでは動ける範囲が限られますし、開発スピードもあがらないので、インターン生を採用して育成したり、新卒時代の同期をリファラル採用したりしながら、開発と組織づくりに取り組み、エンジニア組織を立ち上げました。

ー1人目のエンジニアとして入社されて、かなりのスピードで開発や組織づくりを進める中で、苦労はありませんでしたか？

まだダイレクトリクルーティングのプロダクトや開発体制が整っていない段階で、黒﨑さんからSaaSの事業構想について話があり、気付いたらプロダクトの開発がスタートしていました（笑）。ダイレクトリクルーティングのチームでは、当時、スプリント開発を導入するなどチーム体制を整えながら開発を進めていたのですが、同時並行でSaaSのプロダクト開発にも携わることになったのは大変でしたね。

この2年間でようやく社内のエンジニアが10名、インターン生や業務委託のメンバーを含めて25名程の規模になり、組織的な動きができるようになってきました。最近は様々な仕組みを整えたり、エンジニアの評価制度を見直し、給与テーブルを改訂してベースラインの引き上げをおこなったりもしています。

ーどのようなエンジニアの方が多く集まっているのでしょうか？

通常はPdMなど仕様を決める役割と、それを実装する役割とではっきり分かれていることが一般的ですが、プレックスではその境界線がより曖昧で、エンジニアが柔軟に対応する部分も多いです。プロダクト開発全体のプロセスに関わりたいという思考性を持ち、ビジネスサイドとも積極的にコミュニケーションを図りながら仕事を進めていくような、いい意味でエンジニアらしくない人も多く集まっています。

３）事業の急成長フェーズにおける開発課題

ー現状、組織として直面している課題があれば教えてください。

PLEXJOBとサクミルという2つのプロダクトに加え、営業の効率化をサポートするための社内システムも構築しているため、とにかく人員が不足しています。現在、社員数は全体で約240名ほどですが、そのうち多くのメンバーが人材紹介事業に携わっているため、社内システムの整備やツールの改善は営業活動の効率化や、売上、事業の拡大に直結します。お客様からの引き合いも増えているので、メンバーが顧客への価値提供やフォローアップなどの仕事に専念できるようにするためにも、社内システムの開発やツールの改善は非常に重要です。

これまで社内システムの開発は専任チームを設けず、エンジニアのリソースの大部分をプロダクト開発に割り当て、空いた時間でその都度対応する形で取り組んでいました。ただ、そのためにメンバーのリソースを振り分けてしまうと、当然ながらプロダクト開発に影響が生じるため、コーポレートエンジニアチームの強化は急務であり、事業拡大においても極めて大事な位置付けです。

想像を上回る速さで組織が拡大しているので、コーポレートエンジニアチームの体制構築の優先度を高めておくべきだったというのは一つの反省ですね

ー今後もかなりのスピードで組織が拡大していくと思いますが、それによる懸念はありますか？

プロダクト開発のチームが複数に分かれていった時に、プレックスのエンジニアらしさをどう定義して、共通認識を持つことができるかが鍵になると考えています。

現在働いているメンバーの中では「プロダクトや事業の成長に貢献するエンジニアを目指す」という共通認識はあるものの、全員が同じような思考性でも組織として上手くいくかどうかはわかりません。必ずしも、そういうエンジニアの方ばかりではないと思うので、今後の組織の拡大や事業の成長に合わせて、採用する人物像や組織体制を見直していく必要も感じています。

４）少数精鋭で開発を進める組織の特徴

ー現在のエンジニア組織の開発体制について教えてください。

週に1度スプリントミーティングを実施しています。PdMが事前に仕様をまとめてタスク化して優先順位を立てたものに対し、エンジニアが見積もりをおこない、一週間で消化できるポイントを割り振る形で進めています。また、毎日の進捗を確認しながら、優先的に実施することや困っていることをシェアするなど、スタンダードな開発スタイルです。

組織図上は開発組織が一つにまとまっていますが、実務では事業部毎にチームを組んで動いているため、隔週でエンジニア全体での定例会や、各々が取り組んできたことの学びをシェアする機会も設けています。

ー開発において重視していることや工夫されていることはありますか？

私たちが事業を展開するインフラ産業においては、お客様がサービスを導入したとしても、現場の仕組みを変えていくには時間が必要です。そのためプロダクトを作って終わりではなく、長期的にメンテナンスしながら改善していくことを念頭において開発に取り組んでいます。

また、エンジニアの数が限られる中で、複数のプロダクトを動かしていくために、サーバーサイド、フロントサイドそれぞれで、出来る限り言語を統一しています。

他にも、PaaS（Platform as a Serviceの略）と呼ばれる、クラウド上のサービスとしてアプリケーション実行用のプラットフォーム機能が提供されているものを活用し、社内ではインフラを構築しないようにして、エンジニアがアプリケーション開発に注力できるような工夫もしています。

ー他にも、開発環境における特徴的な取り組みがあれば教えてください。

当社の開発環境で特徴的なのが、10%-20%ルールです。開発を進める中で、機能開発ではなくエンジニアが技術的負債を返済できるようにしたり、ライブラリのアップデートをしたり、生産性の改善に繋がることに時間を当てられるようにしています。

また、構想段階ではありますが、事業部ごとに分かれているチームを横串で補完する役割を設けようと考えています。具体的には、例えば各事業部のフロントエンドエンジニアの中から、フロント全体に対して責任を持つテックリードを任命し、その人が全体の統制や技術の向上を促進するような役割を担います。それにより、各事業部と横串の技術組織が連携し、より効果的な情報共有や技術開発が可能になると期待しています。

５）開発力や設計力が問われる事業拡張フェーズ

ーこれからのプレックスでは、どのような面白みを味わうことができますか？

開発に携わるプロダクトや事業のフェーズによって異なりますが、例えばSaaSであれば立ち上げフェーズなので、色々な人を巻き込みながら新しい機能を実装していく経験ができます。また、開発体制を構築している段階なので、効率的な開発体制を作っていく動きも経験できると思います。

一方のダイレクトリクルーティングは、テクノロジーと人的リソースの両方を組み合わせながら効率的なオペレーション構築を進めています。現場に入り込んで、メンバーとコミュニケーションを取りながら、業務オペレーションを深く理解し、プロダクトを改善していくような動きが好きな人は楽しめる環境です。

コーポレートエンジニアは先ほどお話しした通り全社的なインパクトが非常に大きいですし、様々な部門とコミュニケーションを取りながら開発を進められることは大きな魅力ではないかと思います。

ー今後、事業を展開する領域や職種が広がると、それに応じてプロダクトや機能の拡張が必要になりますね。

プロダクトをそのまま他の領域や職種に横展開できれば簡単なのですが、それだけでは幅広い顧客の課題を解決することはできません。一方で、領域や職種ごとに全てを個別化してしまうと無駄が多くなるので、どこまで個別化したり、最適化したりしていくかは難しい判断が必要です。まさにそこを試行錯誤している段階なので、大変ではありますが、エンジニアとしての開発力、設計力が問われるのも面白いところだと思います。

６）目指すのはプロダクトや事業の成長を加速させるエンジニア組織

ーエンジニア採用の方針や、採用像について教えてください。

引き続きSaaSやダイレクトリクルーティングを中心に組織を拡大していく方針で、半年で5、6名のエンジニアを採用する予定です。ベンチャーなどで数年の経験を積み、マルチに開発に取り組んできたような人が当社のプロダクト開発には向いていると思います。また、一連のプロセスや全体像を理解した上で、事業の状況に応じて何が大事なのかを判断し、自立して開発を進めて成果をあげられる人が理想です。開発という役割に縛られず、どうすれば成果が出るのかを考えながら、アウトプットベースで仕事を進められる人だといいですね。

ー今後、プレックスのエンジニア組織をどのようにしていきたいと考えていますか？

エンジニアがプロダクト開発に関わることで、事業成長をより加速させることができるような組織にしていきたいと思っています。例えば、エンジニア界隈で、Rubyに強い会社と言えばクックパッドという共通の認識があるように、「プレックス出身のエンジニアに開発をお願いすれば、プロダクトの改善が進み事業成長が加速する」と言われるような認知を獲得していきたいです。そのために、事業を推進したりバックアップしたりできる体制を構築し、運営していけるようにするというのが一つの目標です。

私個人としては、開発だけではなく採用や組織づくりに時間を当て、エンジニア組織の基盤を盤石にして、将来的には自分が関わらなくても開発が回る状態にしていき、より潜在的な課題や探索的な業務に時間を割いていきたいと思っています。