ソフトウェア開発において、Developer Experience（開発者体験）は非常に重要な指標です。社内で働くエンジニアたちが快適に生産性高く開発を進められると、プロジェクトの進行やプロダクトの利便性にプラスの影響があり、企業の競争力を高めることにもつながります。

プレイドで、開発者体験の向上やシステムのパフォーマンス向上などのために、全社的な技術基盤の整備やツール作成といったことに取り組むのがDeveloper Experience & Performance Team。今回はTeam Head兼エンジニアの大矢康介とエンジニアの川口和也、石井琢満にインタビューしました。

開発組織全体に影響を与えるような改善施策を担う

――まずは簡単に自己紹介と、チームに参画した経緯やチーム内での役割を教えてください。

大矢：私は2019年の夏からプレイドでインターンとして働き、2020年に社員として入社しました。インターン時代から入社して1年半ほど、プレイドの主要プロダクトである「KARTE」のマイクロサービス化や開発生産性の向上に関わっており、その頃から開発者体験の向上に興味がありました。

そして、KARTEのTalk機能の開発チームに入り、この時代もチーム全体の生産性を向上させるための方法を考え、行動に移していました。その後はDeveloper Experience & Performance Teamの設立に伴ってチームに参画し、2023年11月からTeam Headを務めています。

今はKARTEの認可基盤の刷新やプロダクトで使用されている古いライブラリの置き換え、レガシーなシステムのリファクタリングなど、複数のプロジェクトに携わっています。

石井：私も2019年からインターンとしてプレイドに参画し、2022年4月に新卒入社しました。複数のプロダクト開発に携わる過程で、全社的なインフラ基盤を整備するとか、生産性を向上させるといったことに興味が向いてきたので、このチームに加入しました。

それ以降、KARTEの認可基盤の刷新にずっと携わっています。それ以外にも、社内で使われているインフラ基盤で改善すべき部分があれば、そのための作業を行うこともあります。

川口：川口です、kazuponと呼ばれることが多いですね。私はVue.jsのコアチームメンバーや Nuxtコミュニティメンバーとして活動をしていて、自分でもOSSを開発したり、フロントエンド領域を中心としたOSS開発に携わっています。OSSは基本的にエンジニアの方々が使用するものなので、その活動を通じて自然と「開発者体験をいかにして向上させるか」に関心を抱くようになりました。

そうしたなかで、Vue.jsのコミュニティで一緒に活動していて、今もプレイドでEMとして働く野田さんに誘われて、2019年の4月にプレイドに入社しました。入社後はフロントエンドの国際化対応などに携わり、「自分自身がOSS活動で培った経験を活かして、社内全体のシステム改善に貢献するほうが良さそうだ」と考えるようになって、2024年からDeveloper Experience & Performance Teamに参画しました。

このチームに入ってからは、先ほど話題に上がった認可基盤の刷新に関係する、Expressの設定情報を自動生成するための静的解析ツールを作りました。その後は、複数プロダクトのフロントエンドのバンドラーをwebpackからViteに置き換えるプロジェクトやKARTEのテンプレートの整備をするプロジェクトに携わり、現在はKARTEのデザインシステムの改善をしています。

――Developer Experience & Performance Teamの役割について教えてください。

大矢：Developer Experience & Performance Teamは、社内全体の開発者体験を向上させることと、各種システムのパフォーマンスを安定させることがミッションです。ただ、最近はパフォーマンス面の課題はある程度の改善が進んでいるため、開発者体験向上の役割のほうがメインになっています。

プレイドでは複数のプロダクトが開発・運用されており、さまざまなチームがあります。このような環境のなかで、各チームが開発者体験を良くする活動を個別で行っていては効率が悪いです。そのため、私たちのチームがオーナーシップを持って、全社的な開発者体験を良くする施策を推進したり、各チームの取り組みと連携して全体の生産性向上につなげています。

また、「KARTE」は長く開発・運用が続いてきたため、技術的負債が溜まっている部分があります。各プロダクトを担当するチームは機能改善に注力する必要があり、負債解消になかなか手が回らないことも多いため、そうした作業を私たちが担っています。

石井：「開発組織全体が抱えている課題だけれど、なかなか手を付けられずにいた部分」に切り込んでいくのがチームの特徴です。歴史的な経緯を話すと、かつてKARTEはモノリシックなアプリケーションとして作られていたのですが、その後にマイクロサービス的な構成に変えました。過去の名残で特定システムの変更が全体に影響を及ぼしてしまう場合があるので、そうした箇所を修正・改善する際などには、社内全体のシステムを見る私たちのようなチームがあったほうが良いと思っています。

川口：他の会社では、Frontend Opsのように「○○ Ops」と特定技術の名前を冠したチームが、開発者体験の向上を担うケースが多いと思います。しかし、Developer Experience & Performance Teamはあえて技術領域を限定せず、複数種類の技術を総合的に扱うのが、他の会社にはない特徴だと思います。実際、我々3人も得意とする技術領域が異なっています。

チームが取り組むプロジェクトの事例

――ここまで何度か話に登場した、認可基盤についてのプロジェクトの事例をお聞きしたいです。

石井：先ほどお話ししたようにKARTEはもともとモノリシックなアプリケーションとして作られており、認可のための機能がExpressのミドルウェアとして提供されていました。マイクロサービスに移行してからも、このミドルウェアを各サービス内で共有して使用しています。

この影響で、認可の機能が各システムと密結合になっているという問題があります。そこで、認可の機能をプロダクトから疎結合になるように切り出し、「KARTE Gateway」というシステムとして提供するためのプロジェクトを推進しています。

――プロジェクトを進めるにあたり、どのような点に難しさや面白さを感じていますか？

石井：認可に関わる機能なので、既存の処理との差分を絶対に生み出してはいけないのが大変なところです。たとえば、特定ユーザーがそれまでアクセスできた機能にアクセスできなくなるとか、その逆に不正なアクセスを許してしまうといったセンシティブな問題が発生しないように、検証作業には注意を払っています。

また、このプロジェクトはKARTE Gatewayを導入すればそれで終わりというものではなく、この機能を利用するアプリケーション側のコードも変更する必要があります。全体的にシステムを変更しなければならないプロジェクトなので、大矢さんやkazuponさんにも助けてもらいながら進めています。

川口：KARTE Gatewayへの移行にあたり、私はミドルウェアの設定情報を自動生成するための静的解析ツールを作成しました。そして、この処理を実現するにはアプリケーションに書かれたコードを構文解析してやる必要があり、それを実行するためのパーサーを実装しました。JavaScriptやTypeScriptのコンパイラが処理を行う過程で生まれるAbstract Syntax Treeを使って、解析を実現しています。

この作業で大変だったのが、JavaScriptモジュールのimportパスをうまく解決する必要があったことです。たとえばTypeScriptでは、TSConfigに情報を記述することでパスの設定を変えることができます。各プロダクトで、それらの設定をカスタマイズしているケースがあるんですよ。最初はTSConfigの設定を考慮せずにパスを解決しようとしたんですが、当然ながらうまくいかなくて。そこを、プロダクトごとのカスタマイズをうまく解釈して、どのような設定でも適切に動作する静的解析ツールを作るのがすごく大変でした。

大矢：kazuponさんは「大変だった」と言いましたが、作業をお願いしてからすぐにできていたのが印象的でした。コードも綺麗に書かれていて、追加で修正を加えるのも楽にできました。さすがにツールの作り方がうまいと感じましたね。

石井：kazuponさんに実施してもらった作業は、これまでエンジニアたちが方法について何度か議論したものの、技術的難易度が高過ぎて諦めてきたような課題でした。それをこれだけスピーディーに解決してくれたことに、本当に驚きましたね。

川口：OSS活動に携わる過程で、JavaScriptやTypeScriptのパーサーを使ってバンドラのプラグインや自分のOSSで考えたDSLなどのパーサーを書く機会が何度もありました。その経験がプロジェクトで活きたと思います。また、その後に大矢さんと石井さんが私の書いたコードを読み解いて、ツールのメンテナンスに取り組んでくれたので、学習能力がすごいなと感じました。

技術についての深い知見が、社内のみんなの仕事を支える

――今後のビジョンについてお聞きします。

大矢：Developer Experience & Performance Teamが何かの施策に取り組む際に、その活動によってどれくらい開発生産性が向上したのかを計測できるようにしたいと考えています。この話を各チームのリーダーとしていたんですけれど、あるチームから「具体的にこういうことを可視化してほしい」という依頼がありました。

開発の際にはエンジニアがコードを書いて、Pull Requestを出して、他の人がレビューして、指摘を受けたら修正してマージするという流れになっています。これらの工程のうち、作業を進めるボトルネックになっている箇所を改善したいという話でした。

そのためには、プロダクト開発の各工程でそれぞれどれくらいの時間を要しているのかを計測する必要があり、これをDatadogで計測しています。具体的にどの作業に時間がかかっているのかわからないと、「こういう状態を目指しましょう」という話もできないですからね。

この施策を始めたのが2024年3月の上旬で、徐々に各プロダクトチームのデータが集まっています。データをもとに、たとえば「思っていたよりも、レビューに時間はかかっていない」といったことが可視化の成果としてわかってきました。このデータをもとに、プロダクトチームのリーダーたちとコミュニケーションをとりつつ、開発の課題になっている箇所を特定して、改善のための取り組みを進めていく予定です。

アーキテクチャ改善にも挑戦したいです。先ほど話されたように、「KARTE」はもともとモノリシックだった巨大なシステムを小さいいくつかのサービスに分解したという歴史があります。その小さなシステム同士の依存関係が複雑になっていたり、分解していく際に残されてしまったシステムがあったりと、分離の仕方が適切でない部分があります。適切なアーキテクチャを考えて、それらをあるべき状態にしていきたいです。

また、現在のプレイドではプロダクトチームが開発からリリース、運用までを一貫して担っていますが、どちらかといえば運用よりは開発に比重を置いているチームが多いです。各チームの運用の技術を向上させられるように、私たちが働きかけていきたいと思っています。

他の会社の場合、インフラ構築・運用などを専門で担うチームがあって、そのチームが引き受けてくれるからプロダクトチームが開発に集中できるというケースが多いと思います。もちろん、この体制にも利点があるんですが、プレイドは違う形を目指したいです。

プレイドのエンジニアはみんな、フロントエンドやバックエンド、インフラなどを幅広く担当できますし、技術を学ぶことにも関心のある人が多いです。それを活かして、プロダクトのリリースサイクルを回すうえで必要なすべての業務の責任をプロダクトチームが持つのが、強い開発組織を実現することにつながると思っています。

川口：「KARTE」のサーバーサイドはExpressが使われており、かつNode.jsベースのライブラリが社内ではいくつも作られています。しかし、これらのライブラリがまだJavaScriptモジュールシステムのCommonJSベースでしかサポートされていないという問題があります。

近年、JavaScriptにはES Modulesというモジュールシステムが登場しており、フロントエンドではこの技術が当たり前に使われています。社内のNode.js系ライブラリを、ES ModulesとCommonJSの両方をサポートしつつ、将来はES Modulesベースにように変えていきたいと思っています。

石井：社内全体のリリースサイクルを早めていきたいです。それから、プレイド社内には「適切にリスクを取りつつ、スピーディーに開発していく」という文化があり、これがプロダクトの発展を後押しする要因のひとつになっています。とはいえ、ユーザー数が増加したり、クリティカルなユースケースが増えたりしていくと、トラブル発生時の影響も大きくなっていきます。そこで、たとえば障害発生を早期に検知するなどの仕組みを私たちが作って、それに基づいて各チームが対応できるようになっていくと、理想的だと思います。

――Developer Experience & Performance Teamに所属していることで、みなさんのキャリアにはどのような好影響が出ていると思いますか？

大矢：Developer Experience & Performance Teamには、技術の深い部分を学ぶことに興味のある人が多いです。それに、kazuponさんのように経験が豊富で有名な人とも一緒に仕事ができる、貴重な環境です。また、事業やシステムの規模が大きいプレイドだからこそ経験できることがあります。多くのプロダクトやチームがあり、大量のデータを扱っているからこそ直面する課題があって、それを解決する面白さがあります。

川口：自分がプレイドに入った際のモチベーションの1つとして「OSS活動で得たものを会社に還元したい」という思いがあったので、それをDeveloper Experience & Performance Teamで実現できていることがうれしいです。先ほど話した静的解析ツールについても、石井さんや大矢さんが「勉強になった」と言ってくれて、自分の知識を他のメンバーに伝えられた実感がありました。社外・社内それぞれの活動で、取り組むことの幅をより広げていきたいと思います。

――これは少し穿った意見なのですが、kazuponさんのようにスキルの高いエンジニアがいると、他のエンジニアがkazuponさんを頼り過ぎてしまうようなことはないんですか？

川口：むしろ、逆に自分が他の人から学ぶこともたくさんあります。自分は前職ではCTOをしていて、フロントエンド・バックエンド・インフラなんでも見ていたんですが、プレイドに入社してからはインフラ周りなどの情報はあまり追うことがなくなっています。Developer Experience & Performance Teamに所属する人たちはみんな得意領域が違うので、私が知らないことをみんなから教えてもらっています。

石井：みんなそれぞれに強みを持ちつつ、それらの領域が重複してはいません。だからこそ、頼りになるところはもちろん頼りますけれど、頼りきりという感覚ではないですね。

――理想的なチームですね。

石井：今後の目標に話を戻すと、私はインフラ基盤やシステムのアーキテクチャなど、根幹となる仕組みを考えることに面白さを感じるタイプです。Developer Experience & Performance Teamに所属しているとそうした要素に触れる機会が必然的に多くなるので、自分の志向とマッチしています。これからも、プロダクト開発をしている人たちを支えたり、裏側の仕組みを改善したりといったことに携わりたいです。

――それでは最後に、プレイドで実現したいことやエンジニア個人として実現したいことなどを教えてください。

大矢：私は2023年11月にTeam Headになったばかりなので、これからさらにリーダーとして成長していきたいです。単に目先の課題を解決するのではなく、より中長期的な視点で組織全体を良くしていけたらと思っています。

個人的な目標としては、私たちはプレイド社内の開発者体験を向上させるためのツールやライブラリを作っているわけですが、それらのうち世の中の人たちにも役立ちそうなものは、OSSとして外部に公開していきたいですね。

川口：先ほど大矢さんが話したこととも関連していますが、プレイドは技術的難易度の高い課題を抱えており、それらを解決するために生まれたツールは価値の高いものだと考えています。だからこそ、そのツールをOSSとして社外の方々にも使えるようにしていきたいと思っています。

また個人的な目標としては、私はOSS関連の活動を続けていますが、自分以外にもそういった人が入社してくれるような状態を実現したいです。そのためにも、「OSS開発で得た知見を活かせる環境がプレイドにはありますよ」という情報を、うまく広報していきたいですね。

石井：今回のインタビューで「チームの状況を可視化する」という話がありましたが、いろいろな取り組みに関して、その成果や状況を定量的に測れていない部分はまだまだあると思っています。そうした部分の可視化を進めていくことで、開発者体験の向上に限らず、各種の意思決定にもプラスに働きますし、事業やプロジェクトの推進力も上がります。また、それに加えて全社的なアーキテクチャ改善にも今後は取り組んでいきたいです。

Developer Experience & Performance Teamには真の意味で「技術のスペシャリスト」と言えるメンバーがいます。広く深い知見が社内の人たちの仕事を助けていますし、誰かの課題を解決する力になっていると実感します。私もさらに技術力を高めて、業務を通じて開発組織の人々に貢献していきます。