「作る」から「成果を出す」へ意識が変わった話 – Speee DEVELOPER BLOG

※この記事は、2025 Speee Advent Calendar7日目の記事です。
昨日の記事はこちら

こんにちは。24卒エンジニアの木下です。普段はDX事業本部にて、不動産一括査定サービス「イエウール」の開発を担当しています。
イエウールとは、売却を検討しているユーザーと不動産仲介会社をマッチングさせる不動産一括査定サービスです。

この記事では、新卒2年目の私が中規模施策を主導する中で「言われたものを作る」状態だったことで起きた問題と、それを乗り越えるために取ったアクション、そこから得られた学びについてお話しします。

1年目:実装力を磨くことに集中した時期

入社後約一年間は、先輩エンジニアが設計したIssueや比較的工数が小さく不確実性の低い開発を中心に取り組んでいました。
まずは「任されたものを正確に形にできるエンジニア」になることを目指し、実装スキルの習得に注力していた時期でした。

そんな中で2年目に入り、初めて中規模施策の開発を主導する機会をいただきました。
ぶつかった壁
いざ施策を主導する立場になってみると、実装力だけでは乗り越えられない場面が出てきました。大きく分けて2つの壁に直面しました。

1. 設計に対して根拠を持てない

自分の設計に対して、自信を持って根拠を示せない場面も多々ありました。
例えば、先輩エンジニアから「この施策で本当に数値が改善するのか?」「なぜこの設計にしたのか?」と聞かれた際に、事業的な背景まで踏み込んで説明することができませんでした。
目の前の要件だけをみて設計を行った結果、長期的な視点や事業全体の観点が抜け落ちていることに気づきました。

2. プランナーとの認識齟齬と手戻り

1年目と同じように実装に集中して取り組んだ際に、仕様の細部や施策の背景について深い議論ができておらず、プランナーとの間で認識にズレが生じることがありました。
その結果、開発が進んでから「意図していたものと違う」という手戻りが発生したり、スケジュールが遅延することもありました。

壁を越えるためにとったアクション

これらの壁を乗り越えるために、先輩エンジニアやプランナーと相談しながら以下のアクションを取りました。

定期MTGを設定し、議論・会話の量を増やした

週次で数値や施策の背景について議論する場を設け、事前に気になる点を洗い出しその場で解消するようにしました。

以前は、「このIssueをどう実装するか」という目の前のタスクに意識が閉じていました。
しかし、施策の目的を明確に把握しにいくアクションをとることでプランナーと数値を見ながら解釈等を深めるうちに、自分自身からも仕様や要件に対して提案ができるようになりました。
「目の前のタスクを完了させる」から「事業として成果を出す」へ、意識の向け先が変わりました。
また、会話が増えることで自分自身の観点が増え、早期に仕様や細かい箇所について疑問点を持ちプランナーと会話することで手戻りの工数を減らすことができました。

リリース後の確認指標を作成した

施策の水準感を揃えるために、リリース後の確認指標の作成をプランナーに依頼しました。
「何をもって成功とするのか」という認識を揃え、リリース後も定期的に数値を確認しながら解釈を深めることで次の実装方針の精度を上げることを目的としました。

この取り組みを通じて、「ユーザーのどんな行動変化を期待しているのか」「どの数値が動けば事業的に意味があるのか」といった、施策の本質的な狙いがより明確に理解できるようになりました。
結果として、開発中の判断や仕様提案の精度が上がり、リリース後も数値を見ながらエンジニアとして「こういった機能であればこれぐらいの工数で実装できそうです」という提案ができるようになりました。

受け入れ項目の作成を主導した

施策の受け入れ項目をプランナーと一緒に作成し、認識を揃えることを主導しました。
受け入れ項目を作成する過程で、プランナーと施策の目的や背景、重要な観点について議論を深めることができました。
また、受け入れ項目をもとに開発を進めることで、仕様のズレを早期に発見し修正することができ、手戻りを減らすことができました。

学び

今回の経験を通じて得た学びをまとめます。

目的・背景を理解しにいくことで要件や仕様の提案がしやすくなった

背景を深く理解しないまま作ったものは、「作ったけど使われない」「数値が動かない」という結果になりかねません。
どれだけ丁寧に実装しても、事業として成果に繋がらなければエンジニアとしての貢献できる幅は限定的なものにとどまります。

エンジニアが成果を最大化するためには、一次情報(数値や背景)を自ら取りに行き、自分なりに解釈する姿勢が必要です。その解釈をプランナーや先輩にぶつけて、議論の中で精度を上げていくことが重要だと学びました。

水準を知ることで、具体的な勝ち筋が見えるようになった
リリース後の確認指標を定義したことで、「何%改善すれば成功か」という具体的な水準を把握でき、自分自身の解釈を踏まえた機能や仕様の提案ができるようになりました。
例えば「このイベント以降離脱率が上がっているので、ここを改善すれば指標が改善しそう」「この層のユーザーは目標に達する見込みはなさそうなのでこの層以外のユーザーに本番反映したら全体的に改善しそう」といった具体的な勝ち筋を自分自身も見出せるようになりました。

おわりに

Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています!

新卒の方はこちらより本選考に申し込みが可能です!
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます!

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの?」と気になってくれてた方は、こちらチェックしてみてください!
(埋め込み形式でリンクを挿入する)




元の記事を確認する

関連記事