Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

査定依頼のマッチングシミュレーションをチーム開発で作成した話

※この記事は、2024 Speee Advent Calendar15日目の記事です。 昨日の記事はこちら tech.speee.jp

2024年に新卒としてSpeeeに入社しました、中島です。すまいステップというサービスのエンジニアとして開発にあたっています。今回は、査定依頼のマッチングシミュレーションをチーム開発で作っていく過程で得た学びを書こうと思います。チームでの開発経験がまだなくこれから始めるという方に、チーム開発はこういうものだというイメージをつけていただけるとありがたいです。

マッチングとは

すまいステップのマッチング
 すまいステップは、不動産会社が設定した条件に基づき、家を売りたい「ユーザー」と「不動産会社」をマッチングするサービスです。ユーザーと不動産会社に対して、より多くマッチングを行える方法を開発することで、すまいステップのサービスの価値を引き上げられることになります。

 とはいえ、仮説段階の方法を検証せず実際にリリースしてしまうと、かえってマッチングできる数が少なくなりサービスの価値を落としてしまう可能性があります。そのため、最適なマッチング方法を選択するために実際の査定依頼のデータを用いて様々なシミュレーションを行うことでサービスとしての価値を高めることに繋がります。すまいステップには、このシミュレーションの仕組みがなかったため、このタイミングで私が主体となって事業上重要度の高い開発を行うことになりました。

序盤、自分で開発した時に感じた成長、課題感

 入社して半年ほどで、このような事業上重要度の高い開発に挑戦できることになりました。正直、取りかかる前には途方もない話のように感じられて緊張したのですが、振り返ると成長が垣間見える場面がありました。

 半年前と比べると、いただいた要件を理解し、実装を進めることができるようになってきました。シミュレーションについてはゼロから仕組みを作る必要があり、実際にマッチングしている部分のコードも複雑ではあったのですが、かなりの部分を自力で実装することができたと思います。

 一方で作業を進めていくと、課題感もいくつか見えてきました。その日に修正の要件を受け、それを日中実装して夕方にシミュレーションを渡すというようなことが増え、なぜそれを行うのか、というような背景を理解しないままコードの修正のみ行い続けることが発生しました。このような状況では、正しい実装なのか検討できなかったり、改善に向かっていない開発を乱発することになり、非常に効率が悪かったと思います。

ぶつかった壁

 課題感はあれど、開発自体はある程度順調に進んでいたのですが、シミュレーションの要件が複雑になったところで壁にぶつかりました。いままで1時間弱で終わっていたシミュレーションが突如30時間かかるようになってしまいました。シミュレーションは1時間で終わるという前提で計画を組んでいたほか、そもそもこれではシミュレーションとして実用に耐えません。

 ここにきて気づいたのは、シミュレーションがどのくらいの時間で回せればよいかを考えていなかったということです。今まで「要件」としていたのは主にどのようにシミュレーションするかのような機能要件であり、パフォーマンスなどの非機能要件が入っていませんでした。

チームに頼る選択とその難しさ

 突然パフォーマンスが悪化し、次のシミュレーションがいつ終わるか分からないという苦しい状況に陥ってしまいました。ここで、「チームに頼って解決しよう」と助言をいただいたこともあり、チームに頼る選択をしました。

 学生時代は、なんとしても自分で解決しようという意識のもとで、なるべく一人で進めていく形をとることが多かったです。これでうまくいくこともある一方、難しい問題に直面すると時間がかかってしまったり、頼らないうちに問題が大きくなりがちでした。さらに、一人で進めていける問題しか解くことができず、今思えば成長を望みにくくなっていました。この場面では、「一人で取り組んでいては前進が望めず、チームとして取り組んだほうが早く終わり、早く価値を届けられる」と判断しました。学生時代にはこのような観点はあまりなく、これも入社から半年で培われたのだと思います。

 チームに頼ることでできることが増えるのは確かなのですが、一方で一人で進めていたものについてチームの力を頼るということの難しさもあります。コードの知識をインプットしてもらったり、今やっていることの背景を共有したりする必要があります。作業してもらう部分もどう分割するか考える必要があり、コミュニケーションコストもかかります。勘違いされがちなのですが、単純に人数を倍にすれば倍のスピードで物事が終わるわけではありません。

チームに頼って壁を乗り越えられた

 それでも、今振り返るとチームに頼る選択をしてよかったと思います。前述のように単純にできることが増えるため、一人がパフォーマンスの向上、もう一人が新しいシミュレーションのコードの記載、というように同時に作業を進められます。さらに、自分が持っていなかった観点からアイデアが出ることで、事態を打開できる可能性が上がります。今回の例でいうと、シミュレーションのパフォーマンスを上げつつ、シミュレーションを同時にいくつも回せるようにすればよいのではないかというアイデアがあがりました。最終的にシミュレーションは1回あたり4時間ほどで、3つのシミュレーションを並行して回すことができるようになり、ほぼ期限内でシミュレーションをやりきることができました。

 また、チームに頼るということには、開発チーム以外の人に頼るということも含まれています。このシミュレーションは別の職種の方からの依頼なのですが、その方により簡単な実装でやりたいことができているかを考えてもらったり、「設けられた期限を満たすために要件をいつまでにほしい」などとこちらからも依頼しました。他職種の方にも頼ったり、時に要求したりすることで、自分の目標を達成し、さらに事業的な目標を満たすことにもつながります。

最後に

 開発チームが成果を出すためには、個人が成果を出していくことが必要であり、そのためにはチームに頼るということが必要になってくると思います。自分の力で追っていき、一つ一つ身に着けていくというアプローチもありますが、学習に時間がかかり、成果が出るのにどうしても時間がかかってしまいます。事業上重要度の高い開発に早くから取り組む場合、新卒のエンジニアとして、まずは何としても成果を出すという考えから、遠慮せずチームに頼るということが効果的です。このようなチーム開発をすることで、成果の出し方が徐々にわかってきて、成長角度も大きくなりました。

 Speeeのエンジニアは、決められた要件のものをただ作るというものではなく、背景を見つめて、やりたいことをどう最短で実現するかを新卒の時から考えます。こうすることによって、作ったものが効率的・効果的に価値を生み出すようなエンジニアになることができるというメリットがあります。私もこの考え方を忘れずにエンジニアとして成長していきたいです。

 Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています。新卒の方はこちらより本選考に申し込みが可能です。 キャリア採用の方はこちらのフォームよりカジュアル面談も気軽にお申し込みいただけます。Speeeでは様々なポジションで募集中なので「どんなポジションがあるの?」と気になってくれてた方は、こちらをチェックしてみてください。