estieの開発手法の歩みを赤裸々に語ってみた

estie VPoEの青木です。
前回の記事では、「ハリネズミを飼おうかと検討しています」と書いたのですが、晴れて生後2ヶ月のハリネズミを家に迎えました。
世話の仕方に苦戦しながら(慣れるまでなかなか針を立てずに持たせてもらえない...)楽しい日々を過ごしています。

データドリブンな意思決定を支援する社内データ分析基盤 - estie inside blog

さて、今日は”estie”(オフィス探しプラットフォーム)開発チームの開発手法の歩みについて、これまでの経験を書きます。
まだまだ改善したいことがたくさんあり文章に残すのも恥ずかしいなと感じますが、ここまで開発チームとして、事業にどれだけ高速に貢献するかを考えて試行錯誤してきたそのプロセスが、この記事を読んでいる方の少しでも参考となればと思います。

そもそもestieって何しているの?

事業用不動産(オフィスや店舗など)を主なドメインとする"不動産テック企業"です。
現在、以下2つのプロダクトを様々な領域のオフィス不動産に関わるユーザに提供しています。

estie pro

全国7万件以上、都心5区90%を網羅しオフィス賃貸に必要なあらゆるデータを蓄積してそれを解析する、日本最大級のオフィスデータプラットフォームです。
不動産デベロッパーをはじめとした「オーナー」から「仲介会社」まで、オフィス不動産に関わるプロのユーザーに利用していただいています。

leasing.estiepro.jp

estie

オフィス探しをシンプルにするための賃貸オフィスマッチングサービスです。
オフィスを探している企業の方が登録するだけで、複数の優良エージェントからまとめて物件提案を受けることが出来ます。
また、自分で条件を指定して物件を検索することや、独自開発したアルゴリズムによるAI自動提案を受けることも可能です。

www.estie.jp

この記事では、特にestieの開発チームにフォーカスして、ここまでの開発手法の変遷をご紹介できればと思います。

開発したいことがありすぎる!

estieは正式にリリースされてから1年も経っていないプロダクトです。まだまだ開発したいことが山ほどあります。
例えば、

  • 早くプロダクトに反映して試したいビジネス仮説
  • ユーザインタビューで得られた示唆に基づいた改善
  • CVR改善のために実施したいABテスト
  • SEOなど多くのユーザに利用していもらうために必要な着実な改善
  • 細かいバグ/表記の修正
  • 技術的負債の解消

などなど。上げだせばキリがないくらい、本当にたくさんの「開発したいこと」があり、当たり前ですがすべてをすぐに開発することは難しいです。

これまでの歩み

このような「開発したいことがありすぎる」”estie”の開発チームが、アウトプットを最速で出すために試行錯誤しながら変更してきた開発手法の歩みをご紹介します。

step1: スプリントを決めて開発チームごとのKPIを決めた(2019/10)

私が”estie”に関わり始めたころは、正式版のリリース(2019/9/20)が完了したころです。
β版リリースを通じて見えた「最低限ユーザに価値を届けるために必要な機能」の公開が完了して、ここからどんな機能を追加していけばよいのか、どんな順番で手を付けたらいいのか、それらをいつリリースしたらいいのかといったロードマップが計画できていなかった時期でした。
また、ユーザからのフィードバックやユーザのことを考える中でふわふわとしたアイデアはたくさん浮かんでくるものの、それらはslack上で流れていき、「あれあの話どうなったんだっけ?」といった会話もよく繰り広げられていました。
また、業務委託という形で関わってもらうメンバも増え、そもそもこの改修って何のためにやるんだっけという話を共有することも難しくなっていました。

より効率的な開発をするために、大きく3点、開発手法を改善しました。

  • スクラムを導入し、2週間のスプリントを決めてそれぞれのスプリントで開発する内容を議論した
  • ガンガン改善案を流せるSlack channelを作って、定期的にgithubのissueを作成するようにした(フローではなくストック情報に変更するようにした)
  • 開発チームを2つに分けて(みんなが大好きなお酒にちなんで、"黒霧島"と"金宮"チームと名付けられました)、それぞれ特にフォーカスするべきKPIを決定し、文脈の共有をクイックに実施できるようにした

step2: githubのkanban管理に移行してOKRを導入した(2020/03)

上記の改善でかなりテンポをつかめるようになった開発チームは、いくつかの山場のリリース(検索機能提供に合わせたDB構成のリプレースなど)を超えながら着実に機能を追加していきました。
ただ、徐々に関わるチームメンバの人数・時間が増えた割に、開発速度も、開発することでユーザに提供できている価値も、あまり上がらないと感じるようになってきました。

その理由として、GitHubのissueの形で貯めるように変更した対応したいタスクの量も増えていくなかで、より一番フォーカスするべき開発内容が見えづらくなったことが挙げられると思います。
また、2週間単位で開発する中で、なかなか緊急度は低いけど優先度が高い開発内容を考慮する時間を取れなくなっていましたし、コードベースに技術的負債が蓄積されていくことで、新しいメンバがすぐに貢献しづらいコードベースへと徐々に変化していってしまっていました。

slackへの投稿

それらへの対応として、以下のような改善案を実施しました

  • githubのprojects機能を利用して、開発バックログとスプリント内の開発状況をkanban形式で確認できるようにした
  • 技術的負債レーンを作ってスプリントで一定割合対応することで、スプリントあたり提供できる価値を上げた
  • プロダクト単位のOKRを作成することで、緊急度は低いけど優先度が高いタスクにフォーカスできるようにした

OKRについては、以下の本がわかりやすくておすすめです(estieのメンバはこれを元に導入しました)
https://www.amazon.co.jp/OKR%EF%BC%88%E3%82%AA%E3%83%BC%E3%82%B1%E3%83%BC%E3%82%A2%E3%83%BC%E3%83%AB%EF%BC%89-%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%8A%E3%83%BB%E3%82%A6%E3%82%A9%E3%83%89%E3%82%AD%E3%83%BC-ebook/dp/B07B2R1ZDL/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=okr&qid=1598899313&sr=8-2www.amazon.co.jp

step3:バックログ部分をexcelにした(2020/08)

上記の対応で、OKRを導入して優先度が高いタスクにフォーカスできるようになり、かなり洗練されたスクラムmtgをできるようになってプロダクトが提供できる価値にフォーカスできるようになったものの、
暫く経つとまた新しい問題が見えてきました。
一つは、タスクのバックログとしてgithubのprojects機能にバックログレーンを作って優先度付けしていたのですが、issueが増える中で「どのような理由でその順番なのか」が見えなくなってきてしまうことです。
特に、SEOやUXなど各方面でアドバイザーの方にアドバイスをもらうようになると、それらの優先度付けが難しくなってきました。
また、”estie”のサービスに表示するためにビルや募集区画の情報を取得してくるデータチームと関連する開発内容も増えてくるにつれて、それらを共有できる形で保持したいと思うようになってきました。
これらの課題を改善するべく、8月からは以下のように新しい仕組みを入れました。

  • 大きな仮説に基づくバックログは、他チームと共有のエクセルファイルに移行して、想定インパクトと開発コストを踏まえて優先順を決めるように変更した
  • 開発スクラムに先立って、バックログ内容の最新化、想定インパクトと開発コストのすり合わせを関係者で行い、開発メンバに背景含めて記載されたタスクを渡せるようにした

excel移行したプロダクトバックログ

  • 現時点では、タスクの種類に応じてexcelのプロダクトバックログと、github projects内のレーンを使い分けるようにした

タスクアサインまでの流れ

おわりに

まだまだestieはプロダクトと合わせて開発チームのプロジェクト管理手法も磨き上げているようなフェーズですが、これまでの試行錯誤が同じような課題に悩む方の参考に少しでもなれば、と思いあえて赤裸々にプロセスを書いてみました。

プロダクトの性質やそのフェーズ、そこで活躍するメンバの経験や関わり方によって最適な管理手法は異なると思います。
実際、estie内でも、プロジェクトの性質によってはWBSを作成してプロジェクト管理していることもあります。

WBSを作って計画しているプロジェクトの例

ここまでの経験を踏まえると、変化が激しいスタートアップにとって一つの開発手法で進み続けることは難しいと感じます。
大切なことはチームの課題に向きあい、新しい管理手法を感度高く吸収し、試行錯誤を繰り返しながら、よりアウトプットを早く出すことができるよう開発のプロセスを変化させ続けることなのでしょう。

そんなestieでは、プロダクトだけでなく、チーム・プロジェクトそのものを牽引する仲間を求めています!少しでも興味がある方は気軽にお話ししましょう!


hrmos.co

hrmos.co


【9/8(火)本日イベント開催のお知らせ】
「エンジニアのキャリアパス、難しくない?
~BtoB SaaSの創業期で活躍するエンジニア達のぶっちゃけトーク~」
急成長 B2B スタートアップのestieとhokanの合同イベントを開催します。
各社のCTOとテックリードがパネルディスカッション形式でお話ししますが、全員大手企業からスタートアップへ転向した30代前後のエンジニアです。
また、元ヤフーの黒帯エンジニアで、JavaScriptのエバンジェリストとして活躍された、浜辺将太さんもゲストにお呼びします!
みなさまのご参加を心よりお待ちしております。
estie-hokan.connpass.com

© 2019- estie, inc.