プロダクトの未来に責任を持ち、プロダクト開発の面白さを解放する

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

こんにちは！イエウールというプロダクトでエンジニアをしている林崎です。

新卒でSpeeeに入社して今年で3年目になりますが、役割が広がって事業戦略を主体的に獲得する必要性を理解し、長期的な視点を持てるようになったことで、開発に対する向き合い方が大きく変わり、プロダクト開発の面白さを再発見することができました。

業務に少しずつ慣れて、日々の開発業務にどこか物足りなさを感じている方がいれば、この経験が少しでも参考になれば幸いです。

短期だけを見ていたことで開発がつまらなくなった

入社して2年ほど経った頃、私は開発業務に対して少し停滞感を感じていました。

このとき考えていたのは、せいぜい1ヶ月先の開発をどう終わらせるかということだけでした。バックログに積まれているアイテムをできるだけ早く終わらせることだけに集中し、Bizメンバーから与えられたロードマップを固定されたものとして、言われた通りに開発するという状態になっていました。

2年ほど一貫して同じプロダクトを開発していたため、ある程度の慣れによってどんな機能が来てもそれなりのスピードで開発できるようになっていました。それ自体は良いことなのですが、いつも決まったパターンで「（短期的に）最短でやるのでこういう方針で設計しました」という毎回同じ意思決定を繰り返していました。

もちろん、ロードマップ通りに開発していくこと自体が難しく奥行きのあるテーマです。しかし、当時はエンジニアとして引けるレバーが「ある程度やり尽くした感のある工数削減の工夫」だけしかないように感じられ、前向きに開発に関わることができませんでした。

また、戦略や成果は定期的に共有されていましたが、私はそれを目の前の開発業務と結びつけることができませんでした。「エンジニアも事業を理解することは良いことだ」という一般論として受け止め、ただ「知る権利」として情報を消費するだけで、事業に実際に関わっている実感は持てずにいました。

プロジェクトをきっかけにプロダクトの将来に目を向けられるようになった

そんな中、2ヶ月以上かけて内部品質改善を行うプロジェクトを主導することになりました。今後も開発投資を続けていくにあたって、人の手で行わなくていい雑多なタスクに時間を取られないようにし、本来投資したい機能開発に集中できるような環境を作るための基盤開発を行います。

このプロジェクトを主導するためには、1年以上先を想定してプロダクトのあるべき姿を定義し、今後どのような開発が行われるかを理解する必要がありました。2ヶ月分の開発工数をどのように回収していくのか説明しなければなりませんし、複数ある選択肢の中から1年後の開発を最適化できる方法を選ぶ責任もありました。

自分なりに解決の手段を探しましたが、どの選択肢にもメリット・デメリットがあり、絶対的な正解がない中で未来を予測しながら判断を下すことはこれまでにないプレッシャーでした。

このような局面にあたって、これまで遠い存在だった事業戦略が急に自分にとって意味のある、必要不可欠な情報に変わりました。

今後の事業展開や、それに伴ってどのような開発が必要になるのか。まだ見えていない市場の変化や投資の可能性といった不確実な情報まで含めて、プロダクトの未来に対する解像度を必死に上げようと努めました。

最初は「今後どのような開発をする予定か」というシンプルなところから会話を行いましたが、得られた情報で自分が納得いっていない部分を言語化して「状況がこのように変わったらxxxxのような開発が必要になりそうだが、そのような変化はどれくらい起こりそうなのか」や「将来の戦略は不確定だが、プロダクトの性質を考えるとどこかのタイミングではxxxxの開発が必要になるのではないか」など、自分でも将来像を描きながら議論を重ねました。

最終的には、今後2年間でどのような開発がどのくらいの確度で発生するのかをタイムラインとして並べ、改善を行った場合と行わなかった場合でどのように開発工数が変わるか・どこで損益が分岐するのかを示して関係者と合意し、全員が自信を持って投資判断を行うことができました。

長期でプロダクトに責任を持つことで、目の前の開発で引けるレバーが増える

内部品質改善プロジェクトを経験して気づいたことは、長期的な視点を持つと目の前の開発で引けるレバーが一気に増えるということです。

これはただ選択肢が増えたというだけでなく、事業の実現したいことが捉えられていれば開発の前提も一緒に作っていけるということでもあります。

以前は、Bizメンバーはとにかく最速で機能をリリースすることを常に優先しているのだと勝手に思っていました。しかし、「目先で最短の手段を取る代わりに、この基盤を整えることも同時に行えば、この時間軸では工数や品質を最適化できる」のような提案も、長期的にどのような事業の前提でどのように成果として回収できるかを率直に会話することで、制約だと思っていた部分を自ら作り変えることができるという実体験を得ることができました。

これらは大きな内部品質改善プロジェクトに限った話ではなく、日々の機能開発においても長期的な視点があれば、検討すべき手段の幅が広がります。

例えば、以下のような問いに向き合えるようになりました。