入社4ヶ月で感じたプレイドエンジニアの組織文化

こんにちは！エンジニアの@g0eです。4月1日にPLAIDに入社して、約4ヶ月が経過しました。
まだまだ勉強することだらけですが、ようやくKARTEの開発環境にも慣れてきました。

本記事ではプレイドエンジニアの組織文化について、入社4ヶ月目のフレッシュな目線で書いてみようと思います。
転職活動中でプレイドに興味がある、KARTEというプロダクトの裏にあるエンジニア文化に興味ある、といった人にとってなにかの参考になれば、と思います。

入社直後にもこの記事でもプレイドという組織について少し話をさせてもらっているので、もし興味がある方はこちらも合わせて読んでみて頂けると嬉しいです。

プロダクトファースト

プレイドではKARTEというマーケティングツールの開発を行っています。自分が転職活動をする時にまず第一条件としてあげていたのが、自社開発の強いプロダクトを持っているという点だったのですが、やはりエンジニア文化を語るにあたっても、このKARTEというプロダクトを中心にエンジニア文化が形成されているという点は外せないかと思っています。

入社後の研修プログラムでも、まずはKARTEについての理解を深めるところから始まります。
また、社内ではガチャと呼んでいる仕組みがあって、プロダクトに関する不具合が見つかった場合や、エンジニア側での調査が必要な問い合わせがあった際に、その担当をエンジニアにランダムに割り当てる仕組み（厳密には順番なのでランダムではないのですが）があります。

普通に開発をしていると自分自身が書いたコードやその周辺領域以外はブラックボックスということが多いと思うのですが、それを意識的にバラしにいくという仕組みになっています。
以下はガチャの担当が回ってきた時に自動的に割り当てられるissueにかかれているメッセージの一部です。

bugfixを実際開発した人に回すのは基本的に最小限にする。キャッチアップも兼ねてbugfixは受け取った人がやること。分からない場合、どうしても時間がない場合はしょうがない

自分も入社してしばらくしてこのガチャの担当に入れてもらったのですが、最初は初見のコードになかなか苦戦したものの、以下のようなメリットを感じています。（この仕組みは自社プロダクトを開発している会社では導入を検討する価値のある仕組みだと思います）

• 自社プロダクトの（実装面だけではなく）仕様や使い方に対する理解が促進される
• 普段自分が担当している領域以外も含めたシステム全体像の理解が促進される
• 最初の実装を担当していたエンジニアへの確認などエンジニア間でのコミュニケーションが促進される
• （クライアントからの調査依頼も含まれるので）、クライアントからの声に直接触れる機会を持てる

変化に対する柔軟性

マーケティングの世界はとにかく変化が激しい世界で、KARTEを取り巻く外部環境の変化も激しく、市場に合ったプロダクト開発を進めていくためには柔軟性やスピード感が非常に重要になってきます。プレイドでは、その変化に柔軟に対応できるようにいくつかの仕組みがあります。

まず最初に挙げられるのが、開発を行う際のサイクルについてです。社内では開発期間を2ヶ月毎に区切ってその1区切りをフォーカスと呼んで、フォーカス毎に各チームで達成したい目標を設定して、開発に取り組んでいます。2ヶ月という比較的短いサイクルで区切ることによって、短期間のうちに成果を出せるように意識的に動くことになります。
当然、2ヶ月では終わらないような開発を行うこともあるのですが、その場合はフェーズを切る形で対応するなどして、短期・長期のバランスをとっています。

フォーカスは2〜5人程度で担当する機能毎にチームを組んで進めていくのですが、チームの組み換えもフォーカス毎に行うこととなり、人によっては2ヶ月で新しい機能開発を終えて、次の新規機能の開発に着手していくことになります。一部高い専門性が必要となる領域ではある程度メンバーが固定化されている部分もありますが、それでも一部のメンバーを入れ替えることで変化やチーム間での交流を促すような仕組みになっています。
（席替えも月1回の頻度であり、基本的にはチームごとに近い席に座ることが多いのですが、毎月周りの景色が変わるというのもなかなか新鮮でした。）

次に挙げられるのが、創造のための破壊という点です。どのような会社やプロダクトであっても、技術トレンドの変化によって技術的負債の返済とは付き合い続けるものだと思います。特に技術的負債によって苦労したことがある人は、なるべく負債にならないようにと、技術選定にかなり時間をかけてしまうのではないでしょうか。

プレイドのエンジニア文化として強く感じたのは、『とりあえずやってみる』からの、『違うと思ったら作り直す』という文化です。同期入社の@kazuponさんのエントリーでもあったような、大規模な変更についても、かなりアグレッシブに取り組んでいます。
これまで作ってきたものを躊躇なく破壊（作り直すことが）することができ、それを『承認より謝罪』の文化に則って進めることができることは、変化に対応し続けるためにも、スピード感を持ち続けるためにも、非常に重要な役割を担っているように感じます。
（影響範囲の大きい変更を加えることは、なかなか大変で責任も伴うことですが、変え続けていくことを是として、失敗してもフォローし合える空気感を作ることが重要なのだと再認識しました。）

生産性を高め続けること

最後に、入社して感じたこととして、生産性を高めることへの意識が（これはエンジニアに限らず）全社的に非常に高いということです。

自社で（マーケティング）のツールを開発しているだけあって、世の中のSaaSサービスに対するアンテナが非常に高いというのもあると思うのですが、とにかく社内で色々なサービスを使って、色々な業務を自動化したり効率化したりという取り組みが行われています。（入社して一番最初の仕事がPCと社内で使っているサービスのセットアップなのですが、ここでまず社内で使っているサービスの豊富さに驚きました）

また、既存のサービスをうまく利用するだけでなく、無いものは自社で開発してしまったり、会社の制度も含めていかに効率化するか、というのが非常によく考えられています。
一例にはなりますが、社内で生産性を高めるために行われている取り組みや制度を次に挙げてみました。リモートワークについては、突発的な問題への対応に限らず、集中作業日としてうまく活用している人も多いように感じます。（心なしか大雨の日はオフィスに人が少ないような気も…）

• 毎日勤怠をつけるのが大変
  • →　会社のNWに繋ぐと自動的に勤怠を記録するシステムを自社開発
• 毎月の経費精算が大変
  • →　前もって手当として定額を支給する制度を運用
• 家庭の事情や天候不順で通勤が困難
  • →　リモートワークの制度をうまく活用

エンジニア(プログラマ)の美徳として『怠惰』であること、がよく挙げられ、自分自身もルーチンワークは苦手な方なのですが、いまのところ不満を感じずにエンジニアの美徳を貫いて作業に集中できる環境になっているように感じます。

やや働き方や働く環境的な話に寄ってしまったのですが、エンジニアとしての業務の進め方に関しても、上記の様な生産性を強く意識した環境になっています。最初の項目で挙げたガチャの仕組みはslack上のボットにより自動化されていたり、ビジネス職の方からの依頼や相談もすべてgithub上のissueに集約される形になっていて、基本的にはコードとgithubとslackがあれば通常の業務は回せるようになっています。

良い側面ばかりを書いてきたのですが、当然、これらの生産性を高めるための取り組みの裏側には、それだけのアウトプットが求められ続けていることや、そのためのセルフマネージメントが要求されるということを、忘れてはいけないな、とも思います。

最後に

最後まで読んで頂いてありがとうございます！
いかがでしたでしょうか？プレイドのエンジニア文化に興味を持って頂けたでしょうか？

CX（顧客体験）プラットフォーム「KARTE」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。
詳しくは弊社採用ページまたはWantedlyをご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！