コンパウンドスタートアップを作るエンジニア像

自分たちのプロダクト上で行われる意思決定の大きさに武者震いしている松本 (@matsu7874) です。代表の平井が会社規模でのコンパウンドスタートアップとしての戦い方を書いているので、私は自分たちが目指す姿がコンパウンドスタートアップだと自覚し、コンパウンドスタートアップを実現するにあたっての難しさと、そのチームに必要なエンジニア像について書きたいと思います。

開発しているプロダクトとチーム紹介

私たちのチームはestieの看板プロダクトestie マーケット調査ではなく、別のバリュー・プロポジションを提供する2つのプロダクトを作っています。まだお客さんに使っていただきながらPMFを目指しているフェーズです。

この2つのプロダクトは独立して導入いただけるプロダクトとして開発されていましたが、相互に連携することで単体で使っていただく以上に顧客に価値を提供できるものです。また2つのプロダクトが連携するだけではなく、コンパウンドスタートアップを目指す estie のデータ基盤の現状 - estie inside blogで触れられているデータ基盤からデータをもらっています。

私たちのチームにはフルタイム換算で7名のSWEがいます。

とある競技プログラマーの 1 年 - estie inside blogを書いた riano_さん、吉原さんをリードとして2つのサブチームを運用しています。2つのサブチームは得意なプロダクトはあるもののもう一つのプロダクトも開発できるチームです。ユーザーに価値を届けたいという思いが強い開発チームです。

勝田さんが事業責任者、Kioさんがデザイナー兼PdMをしている事業部です。

コンパウンド化を進める難しさ

私たちが開発するプロダクトは最初からプロダクト間の連携を最優先に設計されたわけではなく、それぞれが別々に開発された上で、データ連携で顧客に提供できる価値を高めようとしています。

さらに新しいデータが必要であれば、別のチームが開発しているデータ基盤やデータ加工のプロセスと調整する必要があります。

こういった状況で感じている2つの難しさについて説明します。

他のプロダクトの文脈

私たちのプロダクト群のようなデータの生成元が1箇所ではないプロダクトの場合、同じように見えるが微妙に異なるデータがあります。estieではまだ標準化が完全に終わっているわけではないため、カラムの意味がばらついていることもあります。

例えばプロダクトAで入力したデータをプロダクトBでも使える場合、金額の税込・税別は統一されていますか。時刻はUTC・JSTどちらでしょうか。歴史的経緯でプロダクトごとに使っている言葉が違うこともあります。必須・任意の設定が異なっていたり、プロダクトAの「不明」とBの「不明」は同じ状態を表していますか？など確認が必要な事があります。

当然ソースコードを追ったり、PdMやドメインエキスパートに確認しながら連携を進めています。連携の過程で統一したり、ドキュメントを整備することも進めていますが、まだプロダクトに詳しいエンジニアに頼ってしまっている部分があります。標準化とインターフェイスのドキュメンテーションを進めていきたいと考えています。

問い合わせ窓口

また、逆にユーザーに一番近いカスタマーサクセスの側から見ると問い合わせ先が分かりにくくなる状況が発生しました。別プロダクトから流れてきたデータが原因か、このプロダクトに問題があるのか分かりにくいのです。

こちらはfirst responderが一元的に一次対応として切り分けるようにしました。なんとか回るようになったという状態ですが、調査を自動化するなど改善を進めていきたい部分です。

それでもプロダクト間の連携をしたい

最初から連携しながら開発していくのではなく、複数のプロダクトをコンパウンド化する難しさはありますが、コンパウンドスタートアップとして「産業の真価を、さらに拓」かねばならないestieでユーザーが触るプロダクト同士の連携を強化する前例を作っている意義のある仕事です。

実際、私たちのプロダクトでは連携を始めてから使ってくださるユーザーが増加しているだけでなく、日々の業務オペレーションに組み込んで使われています。これは連携によって、両方のプロダクトを持っているestieにしか提供できない価値を提供できている証です。これは単なる効率化ではなく質的な変化を提供できていると感じます。