【エンジニアインタビュー】ユーザーに「価値を返す」ことを徹底して思考する、開発組織のリアル
こんにちは、primeNumber採用担当です。primeNumberの開発する「trocco®」は、データ分析基盤の構築や運用の工数を減らし、現場のデータエンジニアの作業負担を軽減するサービスです。「エンジニアが使うツールだからこそ、私たちエンジニアが一番課題感を分かっている」と話すのは、「trocco®」の開発に携わるエンジニアの中根直孝です。今回は、primeNumberの開発チームがどんなビジョンを持って、どういったプロセスで「世界のエンジニアの右腕となるプロダクト」の開発に向き合っているか、CTOの鈴木健太、エンジニアの中根直孝、岡陽介に聞きました。
——はじめに、みなさんのキャリアやprimeNumberでどんなことをしているか、教えてください。
鈴木：東京大学工学部を卒業後、株式会社リブセンスへWebエンジニアとして入社し、転職口コミサイトの開発、企画、分析などを担当していました。ここで同僚だった小林さんから紹介されてprimeNumberで副業として働き始め、2017年には正式に入社。2018年に自社プロダクト「trocco®」の開発に携わるようになりました。現在はCTOを務めています。
中根：私は新卒で受託系のシステム開発会社に入社して、ECを始めとするWebアプリケーションの開発に携わっていました。その後、退社してフリーランスとして活動しているときに、大学の先輩だったCIOの山本さんから声をかけていただいて、2018年11月に正社員として入社。CPOの小林さんと連携しながら、ワークフロー機能やデータカタログ機能など、新しい機能を0→1で開発してきました。
岡：前職の同僚だった鈴木さんから声をかけられて、primeNumberで副業参画したことがきっかけで、2022年3月に正式に入社しました。普段はRailsやReactでtrocco®を開発しています。primeNumberでは2022年11月からスクラム開発を導入していますが、スクラムマスターとしても活動しています。
「価値を返す」という行動指針のもとに、ユーザーの課題ドリブンでプロダクト作りに向き合う
——開発チームではどういう思想でプロダクト作りに向き合っていますか？
鈴木：primeNumberは「8 Elements」という行動指針を掲げていて、開発チームではその中でも、「価値を返す」を強く意識しています。ユーザーの声や課題に対してプロダクトが価値を返せるようにという思いを持って開発に取り組んでいます。
具体的に「価値を返す」というのは、技術ドリブンではなく、お客様の声を聞いて、課題に対して適切にプロダクトを当てていくことを指します。「価値を返す」は8 Elementsが定義される前から重視されていたバリューで、エンジニアだけでなく社内全体で、お客様のためになることを貫くカルチャーがあります。
trocco®はそもそもエンジニア向けのプロダクトなので、私たち自身もお客様の課題を認識しやすく、お客様の課題を解決することがそのまま自分たちに返ってくると考えていますね。
中根：お客様の課題には、お客様からのフィードバックや要望に基づく顕在的な課題と、お客様から上がってこない潜在的な課題があります。潜在的な課題については開発チームで考え、モックを作ってお客様に見ていただいて、フィードバックをいただいたうえで正式に開発に踏み切るなどのアプローチを取っています。
岡：お客様の顕在的・潜在的な課題に向き合う際には、8 Elementsにある「プロダクトを信じる」という行動指針のもとで、「自分たちがよいと思うものを作る」という点を大事にしていますね。お客様からの要望通りに作るべきか、立ち止まって考える姿勢を持っています。
中根：そうですね。そもそもお客様が「なぜ」その機能を必要としているのかをまず考えます。その「なぜ」を解決するために、本当にその機能が必要なのか、別の手段で解決できないか。そうした視点を常に持つようにしています。
——8 Elementsがプロダクト作りに反映されているんですね。そのうえで、trocco®がどんなプロダクトとなることを目指しているのでしょうか。
鈴木：trocco®が、世界のエンジニアの右腕となるプロダクトとして、世界中のデータエンジニア界隈のデファクトになることを目指しています。
中根：だからこそ自分自身が「使いにくい」と感じるプロダクトは作りたくないですね。お客様は画面のどこを触って、どんなふうに画面遷移をするだろうと常に意識して開発に取り組んでいます。作る側からしたら当たり前のことも、お客様にとっては認識していないことがあるかもしれません。私たちは、初めて触る人にも使いやすいと感じてもらえるプロダクトを目指しています。
岡：お客様に「価値を返す」という意味では、ミニマムな状態でプロダクトを作って、実際にお客様に使っていただきながら、そのフィードバックをもとに改善していくこともよくありますね。
開発の優先度はCSやセールスとも連携して議論。それを「どう作るか」はエンジニアに裁量がある
——現状はどんなチーム構成で、どんな方針のもと開発を進めていますか？
鈴木：まずチーム構成ですが、プロダクト開発チームとSREチームに大きく分かれています。プロダクト開発チームにはソフトウェアエンジニアとデザイナーが所属していて、さらに3つのチームに分かれています。1つはETL系の機能開発を担当するコネクター開発チーム、もう1つはETL以外のデータマネジメントやtrocco®全般の開発を担当するコア機能開発チーム、そして各チームの間に落ちるボールを拾う改善チームがあります。
プロダクト開発チーム内では、お客様からの機能要望をどう解決し、どんな優先順位で取り組むか、プロダクトマネージャーを含めて議論しています。また、SREチームとは、プロダクト開発においてインフラ周りやアーキテクチャについて一緒に考え、機能開発をして、お客様に届けています。
開発方針は中根さんの話にあったように、お客様からの顕在的な課題と、trocco®が実現したい機能、つまり潜在的な課題をそれぞれ並べて、優先順位を決めて開発するスタイルです。
お客様からの顕在的な課題に関しては、直接お客様と接するセールスやカスタマーサクセスのメンバーからも「この機能を開発することでプロダクトの価値がどれだけ向上しそうか」をフィードバックしてもらっています。プロダクト開発チームやエンジニアだけでなく、全体で開発の優先度を決定するところがprimeNumberの特徴ですね。
中根：primeNumberの特徴といえば、上が要件を決めてエンジニアがその通りにただ作るということもないですね。trocco®はエンジニアが使うツールなので、我々自身が一番課題感を分かっています。だから、「どう作るか」というところから裁量を持って開発に参加できます。
——開発環境についても教えてください。
鈴木：開発環境としては、大きめのEC2インスタンスを用意して、各自がそこにSSHで接続して開発を進めています。もともと各自のMac上で開発をしていましたが、MacのDockerで思うようなパフォーマンスが出せなかったりといった問題があって、EC2のLinux環境で開発するようになりました。
技術的には主に、Ruby on RailsとReact、Kubernetes (K8s)を使っています。顧客のジョブを実行していくうえで、リソースを柔軟に設定してジョブを実行したいという話や、セキュリティ上の要求からほかのお客様と混じらないように都度コンテナを立ち上げて、データ転送が終わったら消去するような使い方ができないかという話があって、K8s上でアーキテクチャを構築することになりました。
——具体的な開発プロセスはどのように行っていますか？
岡：スクラム開発をしています。1スプリントは2週間で、各スプリントの初めにプロダクトマネージャーと開発チーム全員で、今回のスプリントでは何を、どこまでやるか定義します。1スプリントが終了したら、要件通りのものができたか、プロダクトマネージャーを含めて振り返ります。
要件通りにできていない場合は、それはどこで、なぜできなかったかを議論しますし、途中で要件が変わった場合はその場で確認をします。また、チームの作業自体を振り返って次のスプリントに活かしていきます。
鈴木：スクラム開発を取り入れたのは2022年11月からですが、それまでは大きめの機能開発はデザイナーとプロダクトマネージャー、エンジニアがそれぞれ1名で、1人1機能開発のような形で進めていました。当時は速度優先で開発していたので、個人の裁量で進めていくのが適したフェーズだったんです。
一方で、この進め方はレビューをする際のレビュアーの負荷が大きい点が課題でした。レビュアー自身も大きめの機能開発を抱えているので、コンテキストスイッチが激しく、すべてを理解するのに時間がかかってしまいます。また、1人1機能開発は、開発した機能が属人化しがちです。こうした点に限界を感じてチーム開発に移行しました。
岡：なぜスクラム開発を選んだのかというと、私自身が前職でスクラム開発を経験して、よい方法だと感じたからです。たとえば、2週間ごとの定期で成果物とチーム課題の振り返りができるところ。スプリントを繰り返すたびに見積り精度が上がったり、課題を解決してより効率的に開発が進められるようになったりと、チームとして成長が実感できます。
スプリントを始めてまだ3〜4ヶ月しか経っていない状況で、課題は日々たくさんあります。たとえば、プロダクトマネージャーとの連携方法でもっといいやり方があるのではないかと思いますし、プロダクトマネージャーとエンジニアの仕事の境界線が曖昧に感じることがあります。タスクの粒度や見積りの精度にしても、今後の課題ですね。
「ユーザーにとって価値のあるプロダクト」であることを前提に要件・仕様・技術選定し、開発に取り組む
——開発組織のカルチャーについて教えてもらえますか？
鈴木：冒頭でも触れた8 Elementsの「価値を返す」を意識するメンバーが多いですね。単に言われた物を作るのではなく、ユーザーのことを想像して、そのユーザーにとって価値があるかどうかを考えながら、要件、仕様、技術選定ができるメンバーが揃っています。
また、8 Elementsの「対話を力に」を意識するメンバーも多いですね。障害やヒヤリハットが発生した際にはポストモーテムを実施して、誰かを責めるのではなく仕組みで防ぐにはどうすればいいか、建設的な議論をするようにしています。
ポストモーテムはSREチームのメンバーが周りを巻き込んで進めてくれたんですが、そんなふうに周りとしっかり対話して建設的に議論をすることでチームを良くしようという意識を持っていますね。
——何度か「顧客に対して価値を返す」というお話が出てきましたが、顧客の声を実際にプロダクトに反映したエピソードがあれば教えてください。
中根：先日対面のユーザー会が開催されたんですが、そこでお客様と直接話す機会がありました。そのときに「ワークフローの複製機能があったら嬉しいです」という声をいただき、実際にその機能を開発してリリースしました。
BtoBのSaaSなので、お客様からフィードバックをもらう機会は多いですね。カスタマーサクセス経由でポジティブなフィードバックをもらうことが多く、日々のモチベーションにつながっています。その延長で、「こんな機能がほしい」といった要望もいただくので、できるだけプロダクトに反映したいと思っています。
——開発チームでは丁寧な開発を大切にしているそうですが、実際にあったエピソードについて聞かせてください。
岡：trocco®にはグループ機能という機能があり、これをリニューアルするプロジェクトを実施しました。この機能はtrocco®全体にまたがるもので、顧客への影響も大きい変更だったので、開発に取り組む際にはプロダクトマネージャーやカスタマーサービス、セールスのメンバーを巻き込んで、ドキュメントベースで議論しました。
実際に仕様を策定するに当たっては、数社の顧客にヒアリングをして最終的な仕様を決めました。リリースの際にはマイグレーションをする必要があったので、セールスと連携しながらお客様への影響を最小限に抑えるよう配慮して対応しました。
鈴木：丁寧な開発はもちろんですが、当社のプロダクトはデータの品質も重要です。現在はQAの専任チームが、リリース前に動作確認を徹底して行っています。以前はエンジニア自身が動作確認をしていましたが、QA専任チームを置くことで品質を担保し、エンジニアは開発に集中できる体制を整えました。
——開発の生産性を高めて組織を良くするために工夫されていることや、取り組まれていることはありますか？
鈴木：直近では技術負債の解消に取り組んでいます。現場DXプラットフォーム『カミナシ』を提供しているカミナシさんが技術負債解消に向けた取り組みを発信しているので、それを参考に進めていますね。具体的には、長期的に見て開発生産性を上げるにはどうすべきかであったり、既存の開発周りの課題を1つずつ解決していくといった内容です。
ほかに、先述したポストモーテムの実施や、GitHub Copilotといった開発ツールの導入をしています。生産性が向上するのであれば、こうしたツールも随時導入していきたいですね。
岡：組織のコミュニケーションという意味では、Slack上の「timesチャンネル」を活用しています。一般的には「分報」と呼ばれるもので、メンバーそれぞれが「#times_oka」という形でチャンネルを持っています。そこに、仕事に関係のない雑談や、開発中に気になったこと、困っていることを書き込んでいます。timeチャンネルはほかの人にもオープンになっているので、困りごとにアドバイスがもらえたり、ちょっとした雑談をしたりといった形でコミュニケーションを取っています。timesチャンネルも生産性向上につながっていると思いますね。
中根：timesチャンネルだけでなく、チームのチャンネルも活用していますよね。チームに共有しておきたいことはチームチャンネルに書き込んでおけば、お互い何をしているか見えるようになります。エンジニアは黙々と仕事しがちなので、コミュニケーションは意識していますね。スクラム開発をするうえでの課題もここで共有されることがあります。
鈴木：primeNumberは緊急事態宣言中はフルリモートだったんですが、コロナ以前から週3日出社、週2日リモートのハイブリッド出社を採用しています。フルリモートだとどうしても、常に一緒に仕事をする人としか関わりがなくなってしまって。出社したタイミングで他チームのメンバーとも会話するようにしています。テキストメッセージだけだと「何か引っかかっている？」と思うようなケースでも、対面で会って話すと印象が違ったりします。対面のコミュニケーションを重視することで、組織のコミュニケーションが円滑になっているように感じますね。
個人の技術的成長と興味深い開発体験が得られる開発組織を作りたい
——みなさんが考える「よい開発組織」はどんな組織ですか？
鈴木：適切な課題が設定されていることと、その課題をどう解決するか開発組織で方針を決められること。そして、それを解決することがお客様への価値提供につながる。そんな開発サイクルがきちんとできている組織が「いい開発組織」だと思っています。
現状はお客様の声を聞いて、機能開発の優先度をつけて、正しいプロダクトを作れるようにプロジェクトチームと一緒に取り組めていると思うので、我々エンジニアが正しいアウトプットを出せれば、それがプロダクトの価値につながるのではないでしょうか。
そんなふうに、全員が自発的にチームをより良くしていこうと取り組んでいますし、チームとしてのアウトプットを上げることでプロダクトの価値を向上させようと考えられる人の集まりでありたいですね。
岡：そうですね。そうした課題解決や新たな機能の実装という場面で新しいチャレンジをしたときに、それが組織全体に伝播するような風通しの良さは大事だと思っています。
——そうした理想に向かって、どんな開発組織を目指していこうと考えていますか？
鈴木：高い市場価値を持った「個」の強いメンバーが集まってほしいですね。そうした人たちがいつでも自由に転職できる状況にも関わらす、敢えてprimeNumberにとどまる選択をしてくれるような組織が理想です。組織に入った人が技術的に成長し、プロダクトとしても興味深いフェーズを経験できる。そんな従業員体験ができる組織を目指しています。
また、ユーザーに対して価値提供をするモチベーションを持った人たちだけが集まれば、コミュニケーションが効率化できます。合理的な思考を持ったメンバー同士、対話を通じて物事を進められるチームができればと思っています。
岡：primeNumberはエンジニアだけでなく、セールスなど異なる職種のメンバーもエンジニアとしての素養を持っているように感じます。みなさんtrocco®というプロダクトが大好きで、プロダクトについて熱心に議論できるメンバーが揃っていますね。
エンジニアも、単にプログラムを書くだけでなく、プロダクト作りに重点を置く人たちが集まる組織が理想です。会社全体としてプロダクトを理解し、開発の方向性を議論し合える組織だといいですね。
中根：組織全体に8 Elementsが浸透していて、同じ目標に向かってプロダクトを作っている雰囲気がありますよね。岡さんが言ったとおり、セールスのメンバーもプロダクトについて理解があるし、カスタマーサクセスからお客様の要望を聞いて、みんなで開発している感覚です。
岡：そのうえで、いい意味で居心地の良い組織を作りあげたいですね。
鈴木：その居心地のよさはあくまで緩さを求めているわけではなく、プロダクトをより良くするために同じ目標を持って、それに対するアクションが評価される。それを邪魔する人がいないという意味での「居心地のよさ」ですよね。もちろん開発過程の中でストレスはある。でもその中で、「プロダクトをより良くする」という方向にひたすら向かっていける居心地のよさを目指したいと思っています。
ここまでインタビューをお読みいただき、ありがとうございました！
もし「ユーザーに価値を届けたい」という想いに共感いただいたり、プロダクトやチームに少しでも興味を持っていただけたら、まずはカジュアルにお話しませんか？
転職を考えていない方でも、ぜひカジュアル面談のお声がけお待ちしております。