estie で一年働いてみて感じたこと

はじめに

こんにちは、徳永です。7月1日で、estie に入社して一年経ちました。この一年で(何故か)3チームで仕事をして様々なメンバーと仕事をしてきたので、この機会に日々感じていたことをお話しできればと思います。

【プロフィール】徳永 裕介（とくなが　ゆうすけ）楽天市場のbookmark team、アカデミストでの決済周りの機能開発と主に toC の EC での保守・運用・開発を経験。その後、estie へ入社しデータパイプライン → 新規サービス立ち上げ → estie pro の開発、とチームを転々としている。

1年で3つのプロジェクトを経験

自分は、estieに入ってからチーム移動を2回していて計3チームで開発をしてきました。それぞれのチームで事業における立ち位置やサービスのフェイズの違いもあり、様々な経験が出来たので各チームで印象に残ったことをお話ししようと思います。

高速にヘビーユーザー(“user6”)とのフィードバックループを回しながらの社内ツール開発

前職で働いていた頃から業務委託としてお手伝いをしていて、2021年7月の入社直後はデータパイプライン（データソースから受け取った情報をサービスに出せるようにきれいにする作業をしているモジュール群）チームにいました。

データパイプラインには色々な卵料理の名を冠したサービスがあるのですが、medamayaki と呼ばれる社内ユーザー向けのサービスを作っていました。medamayaki は estie の不動産データベースを管理・メンテナンスする中で、自動化が難しい(目視でのチェックが必要な)部分をオペレーショナルに解決するための社内用データ管理サービスです。サービスに当時求められていたことは、よくあるアドミンツールと同様に認証・認可、操作の記録(復元可能性)辺りのミニマムなものでした。

medamayaki の開発で面白かったのは、同時期に estie のデータクオリティを担っていたヘビーユーザー (“user6”)の存在です。

自分が今まで行ってきた toC サービスの開発では、一定のユーザー層(数)に機能を提供するため、特定セグメントのペルソナなどを立て、(ヒアリング等はするとはいえ)仮想的なユーザーに向けたものでした。しかし、medamayaki では特定のユーザー(“user6”)、しかも尋常ではない速度でブラウザ上で操作を行うユーザー(社内では estie のデータ上でビルを建てたり解体したりしているのでゼネコンと呼ばれています)が、当時 〜 それ以降も一定期間そのデータの品質をメンテナンスすることが確定していました。作業イベント比率を見ても圧倒的だったため、「”user6”の使いにくい部分を直す」「”user6”が不安にならないような fool proof ・ fail safe な操作である」ことがそのサービスのスループットを最大にする打ち手になりました。

1年で40万件近くデータの追加・修正を行い圧倒的なインパクトを示す “user6”

新たな機能を開発した際や仕組みを導入した際に、サービス上でのインパクトが出るまでにはそれを運用に載せるまでの文化醸成のラグがあると思います。「こういう機能をマージしました」と言って次の日にダッシュボードを見たら何百件レベルで実データが改善されているのを見た時は、驚いたと同時にとても開発し甲斐があるなと感じました。

当時は medamayaki に限らないデータパイプラインの業務を他にも抱えてはいたのですが、”user6” と sync する週次の定例までに必ず一つは機能要望、修正要望を対応して臨むという裏目標を勝手に立てて仕事をしていました。どんな機能をリリースしても使われなかったら(使われなかったことがわかる以上の)価値がないと思っているので、実際に使われていることがこんなにダイレクトに感じられる環境で、開発者体験が非常によかったですね。

事業開発、デザイナーと組んでミニマムチームでの新規事業立ち上げ

データパイプラインでのまとまった機能開発を終えたあと、新規事業立ち上げのプロジェクトに途中合流しました。
このプロジェクトは自分がアサインされてから3ヶ月で凍結になっていて、現在大枠のコンセプトは変えずに別の進入角度でのアプローチで絶賛立ち上げ中です。社内向けには、ちょうど今月の全社定例で「しくじり先生」というセッションがあったので、「どう失敗したのか」「どうしたらもっと早く失敗して次の手を打てたのか」などを共有する機会がありました。プロジェクトの当事者としてはプロジェクトを成功させられなかったのは悔しいですが、ちゃんと会社として失敗できる組織なのは強みだと感じます。

当時は、

• 事業開発: 1
• デザイナー: 1
• ソフトウェアエンジニア: 2~3 (業務委託や他ユニットとの兼務などで1人前後増減)

にインターン生1人を加えた5人前後のチームでした。toBの新規開発ならでは(?)の難しさがあり、顧客の事業での既存フローの理解と、弊社サービスの導入・移行期間における情報のダブルメンテナンスという部分をいかに乗り越え価値を感じてもらうかというところに苦心していました。

残念ながらこのプロジェクト自体は前述のとおり凍結しているので、プロダクトでユーザーに価値を届ける部分を達成できずソフトウェアエンジニアとしての力不足を痛感しましたが、ここでは顧客との定例で事業開発とデザイナーのメンバーの仕事、特にその成果物が機能する場を直に見ることが出来たのが個人的にはとても印象に残っています。

顧客との定例はデザイナー主導で以下のような流れで業務フローをヒアリングします。

• 課題に感じている部分を質問する
• confluence + figma で業務フローを視覚的にまとめる
• フローを流れるアウトプット(excel)を特定する
• excel を読み解く

上記を繰り返し、我々が confluence + figma 上にある情報で顧客の業務フローを説明できるようになるまで認識をすり合わせペインを感じている領域がどこなのかプロダクトで価値を出せる領域を特定していきました。口頭ではなんとなく認識が揃っていたように感じていた部分も、図や表として整理されたものが目の前にあると、顧客から「ここ実は、〇〇で…」といった詳細の情報を教えてもらいやすくなるんだなと実感しました。

上記の ASIS の整理に加えて、TOBE での やる/やら の提示も図や表、モックを使うことで顧客との認識のずれを素早く検知し、顧客とのフィードバックサイクルの加速に明確に機能している瞬間を実際に目にすることが出来ました。

また事業開発のメンバーは、 estie としてのプロダクトの方向性を示しつつ着実に期待値を調整しながら、プロダクトに実装する以外での価値提供方法でも顧客に価値を提供していました。顧客の excel を紐解きながら顧客よりそのデータに詳しい状態になり、「これから作るプロダクトがあればこういう意思決定ができるようになります」といった業務整理ができるインサイトを絞り出していました。

顧客とのやり取りの合意結果だけでなく、その合意までの過程で他の職種のメンバーの”機能している”仕事(成果物としての資料とその交渉過程のやり取り)を体験できたのはこれからの社会人生活にも活きてくると感じました。

アカウントマネージャーと2人組での顧客への価値提供機能の模索

上述の新規事業サービスが凍結後は、同じ技術スタックを使っていた estie pro という estie の基幹事業の開発チームに移りました。ちょうど今年(2022年)に入ったくらいですね。

新規開発だった前チームと違い既に顧客が利用しているサービスなのでVoC(Voice of Customer) を参考に、日々サービスの改善を行っています。チーム全体としてはざっくりいうとVoCで要望が多く上がっているもの、顧客へのインパクトが大きいものを優先して開発しています。

この方針はチーム全体としての大玉の機能開発の方針としては適切ですが、自分は前のチームでの経験によるものか、ユーザーと小さいフィードバックサイクルを回せることに意義を感じていました。同じく顧客とのライトサクセスを重ねたいという課題意識を持つアカウントマネージャー（AM）とバディを組み、VoC が多くなくてもAMが当たりが良さそうに感じている新規機能仮説のベータ版を作って、実際に使えるかご意見を伺っています。新規機能としてリリースしなくても、redash などでサクッと資料を用意できると顧客とのフィードバックループが回せるような小さいこともいっぱいあるなと感じています。

estie では顧客のセグメント毎に担当するAMがいるのですが、バディ制によって必然的にコミュニケーション頻度・量ともに多くなり、AMのセグメントの理解の深さ・感覚の鋭さを感じるようになりました。最近はAMがさらっと言っていた「不動産業界の人たちは地図で情報を整理して理解している」という観点から、より魅力的な情報の提示方法がないか考えています。

おわりに

ここまで書いてきたように、estie では同職種に限らず、タテ・ヨコ・ナナメ、全方位の人の仕事から刺激をもらいながら働ける環境です。別のチームの仕事に関してもその週に達成したことを華金に共有し合うWinning Sessionやチーム横断的なメンバーでの values(ランチ)会など隣の人の仕事(の成果)が見える環境が整っていて、「どこがどう面白いか」「顧客の価値になるか」を楽しそうに話す人が多いのが estie らしいなと思います。

また、ソフトウェアエンジニアの環境としては、入社前の副業期間からバリバリアウトプットを出していた優秀な方々が続々と入社を決めていて、エンジニアに求められるレベル感も自分が入社した時(当時はコーディング面接もなかった)と比較して一段と上がってきていると感じます。そんな中でもまだまだ、小さな単位で動けているので自身のアウトプットがそのままユニット・会社のインパクトにつながると感じられる刺激的な環境だと思います。

顧客と近く、色んな職種のメンバーから刺激をもらえる環境でサービスを作りたい方はぜひ以下を覗いてみてください！