※この記事は、2025 Speee Advent Calendar24日目の記事です。昨日の記事はこちら
こんにちは。SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの山本です。 現在Housiiは2つのチームに分かれて開発を進めており、私は片方のチームの開発に取り組みながら、もう片方のチームをリードしています。
この記事では、そんな私がチームをリードするためにこだわっていることを紹介します。 この記事を通して、Speeeには新卒2年目でもこのような内容にチャレンジできる環境があることや、Speeeのエンジニアがプロダクトを作っていく中でどのようなことを考えているのかが伝われば嬉しいです。
1. はじめに：Housiiでの開発について
Housiiは不動産会社から直接物件情報を受け取ることができる完全会員制の家探しサービスです。Housiiの開発チームでは1週間スプリントでアジャイル開発をしていて、それぞれの開発物はストーリーポイントを使用した見積もりをしています。
Housiiの事業フェーズとしては新規事業フェーズです。そのため、開発チームとしてはビジネス的な仮説検証のサイクルをいかに早く回していくかが重要になります。そこで、私は開発プロセスのボトルネック解消と価値を変えずにいかに小さく作るかの2つにこだわっています。
2. 開発プロセスのボトルネック解消にこだわる
2.1 目標達成のための戦略を立てて実行することにこだわる
2.1.1 目標を分解して追える形にする
Housiiの開発チームは全員が実行強度高く毎日の開発に取り組んでいるため、単純に今より頑張るだけでは仮説検証のサイクルが回る速度は変わりません。このような状況で仮説検証のサイクルをより早く回すためには、開発プロセスの中で時間を使っているボトルネックを特定して、それを改善するためのアクションを取っていく必要があります。
そこで、以下のようにそれぞれの開発プロセスごとにどのぐらいの時間になっていれば良いのかという細かい目標を立てることにしています。ベロシティを目標にすると見積もりのインフレなどが起きるため、ベロシティはあくまで開発プロセス改善の結果として安定向上しているかをみるための観察指標として扱っています。
- 仮説検証のサイクルがより早く回るようになっている
- チームベロシティの平均が6.5pt以上で安定している
- 実装：見積もりが1ptの場合、5時間以内で完了するようになっている
- イシューの内容理解と実装方針立て：30分
- プロダクトコードの作成：1時間45分
- テストコードの作成：1時間45分
- 動作確認：0分
- PR作成：30分
- レビュー修正：30分
- イシュー分割：見積もりが2ptの場合、1.5日以内で完了するようになっている
- イシュー作成：イシュー1つあたり30分
- レビュー修正：2時間
- 設計：見積もりが2ptの場合、2日以内で完了するようになっている
- 要件の理解：1時間
- 既存コードのキャッチアップ：3時間
- 設計を考える：7時間
- ドキュメント作成：3時間
- レビュー修正：2時間
- 実装：見積もりが1ptの場合、5時間以内で完了するようになっている
- チームベロシティの平均が6.5pt以上で安定している
2.1.2 実態を把握して戦略を立てる
開発プロセスごとに目標が立てられたら、それに対して実態がどうなっているのかを把握します。ここは実際に開発メンバーにヒアリングしています。この実態がずれていると、改善のアクションを実行したとしてもインパクトが少なくなってしまうと考えているので、ここで1次情報をしっかり取ることが重要だと感じています。また、ヒアリングの中で目標が成立していないことがわかった場合は、目標を変更することもあります。
ここまでやると、それぞれの開発プロセスごとに目標と実態の差分がわかります。それを元に改善したときのインパクトを考えながら、何をどのような順番で倒していくのかという戦略を立てます。そして、直近扱うと決めたものに対して、アクションを設定して実行していきます。このようにやっていくことで、開発プロセスのボトルネックを解消して、仮説検証のサイクルをより早く回せている状態に徐々に近づいていけるということを学びました。
2.2 事前にアウトプットを擦り合わせることにこだわる
仮説検証のサイクルをより早く回せる状態になるために、私は事前にアウトプットを擦り合わせることにもこだわっています。ここではアウトプットを擦り合わせるようにしたことで、以前よりビハインドを抑えられた事例を2つ紹介します。
2.2.1 事例1：何が考えられていたら設計完了なのかの擦り合わせ
Housiiでは実装の前に設計とイシュー分割をしています。既存メンバーの場合は、これまでの経験から設計で何を考えれば良いのかわかっています。しかし、これまでの経験に頼っていたため、新しくジョインしていただいたメンバーの場合はそこがわからず、計画の2倍ほどの時間がかかるということが発生しました。
そこで、私が普段設計で考えていることは何かを整理して、設計ドキュメントのフォーマットを設定しました。具体的には、テーブル設計・クラス設計・それぞれのクラスの責務といったセクションを設計ドキュメントに設けました。このようにアウトプットを定義することで、次回の設計時には計画から半日程度のビハインドで抑えることができました。
2.2.2 事例2：次に何をアウトプットするのかの擦り合わせ
今年新卒入社してくれたメンバーに設計をやってもらうことが最近増えています。その中で相談したいことが出てきたときに壁打ちをしてもらうようにしています。壁打ちにおいて、私は相談された内容をただ解決するだけのコミュニケーションをしていました。しかし、新卒メンバーはまだ設計に慣れていないというのもあり、それでは設計は計画通りに完了できませんでした。
話を聞いてみると、考えるべき論点として何があるのかという洗い出しと、それらをどういう順番で考えるかという優先順位付けがうまくできておらず、考えづらい状態で物事を考えているということがわかりました。そこで、壁打ちのときに次の壁打ちまでに何を考えてどういうアウトプットをするのかというのを擦り合わせるようにしました。新卒メンバーの成長ももちろんあると思いますが、この擦り合わせをすることでほとんど計画通りに設計を完了させられるようになってきています。
3. 価値を変えずにいかに小さく作るかにこだわる
ここまで仮説検証のサイクルをより早く回すために、開発プロセスのボトルネック解消にこだわっていることについて書いてきました。それに加えて、私は価値を変えずにいかに小さく作るかにもこだわっています。ここではただ手なりで開発するのではなく、工夫を入れることで価値を変えずに小さく開発できた事例を2つ紹介します。そして、それらの開発から見えてきた、価値を変えずに小さく作るための考え方を紹介します。
3.1 事例1：物件絞り込み機能の開発における工夫
今年Housiiで扱ったものの中には、ユーザが特定の操作をした物件を絞り込めるようにするというものがありました。Housiiのフロントエンドでは、ユーザが特定の操作をした物件を絞り込むというのはできるようになっておらず、それをそのまま開発するとなると7ポイント程度かかるという見積もりでした。
ただ、その機能は社内のみで使用する想定だったため、フロントエンドで開発するのではなくスプレッドシートのBigQuery連携を使用するという工夫を入れました。その結果、3ポイント程度でやりたいことを実現できました。削減した開発工数は4ポイントですが、これによって目指していたリリース目標に間に合わせることができました。
3.2 事例2：物件情報紐付けの住所突合における工夫
今年Housiiで扱ったものの中には、外部のデータソースの情報をHousiiの物件と紐付けて表示するというものもありました。外部のデータソースの情報を物件と紐付けるためには、その住所とHousiiの住所を突合する必要がありました。それには元々住所文字列をパースして突合するという方法を取っていたのですが、その方法では目検での調査が大量に必要で、特定の地域だけで200時間程度かかるという見積もりでした。
それでは時間がかかりすぎるということで、外部のデータソースの生データを見てみたところ、郵便番号の情報が入っていることがわかりました。今回の場合は、市区町村レベルでの突合ができれば問題なかったため、郵便番号を突合に使用するという工夫を入れました。その結果、目検での調査量を削減でき、100時間程度まで開発工数を圧縮できました。
3.3 価値を変えずに小さく作るための考え方
物件絞り込み機能の開発は、HousiiのフロントエンドでやるというHowに囚われると小さく作れませんでした。物件情報紐付けの住所突合も、住所文字列をパースして突合するというHowに囚われると小さく作れませんでした。どちらの事例も何をやりたいのかというWhatに着目してHowを変化させることで、価値を変えずに小さく作ることができました。
つまり、価値を変えずに小さく作るためには、特定のHowに囚われすぎず、何を作りたいのかというWhatやなぜ作りたいのかというWhyから考えることが重要だと考えています。そして、それをするためには、今考えているもののうち何がHowで何がWhatなのかを切り分けるのが重要だと感じています。
4. まとめ：いかに工夫してやるかにこだわる
この記事では、私がチームをリードするために開発プロセスのボトルネック解消と価値を変えずにいかに小さく作るかにこだわっているということを書いてきました。私はこれらにこだわるということは、結局はやらない理由を探すのではなく、いかに工夫してやるかにこだわるということではないかと考えています。
ベロシティが下がっているときは「こういう理由で下がっていて仕方ない」ということを言いたくなります。また、開発物の見積もりが大きいときも「普通に作ったらこのくらいで仕方ない」ということを言いたくなります。しかし、それは理解したうえで、どうしたらその状況を突破するのかを考えるのが重要なのではないかと思います。
ここまで書いてきたことは私のこの1年間の学びで、まだチャレンジしている領域も多いです。今後も引き続きこだわりを持って、ユーザに価値を届けられるプロダクト作りを続けていきたいと思います。ここまで読んでいただき、ありがとうございました。
Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています！
新卒の方はこちらより本選考に申し込みが可能です！キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！
