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

こんにちは！　2023年に新卒でSpeeeに入社し、イエウールというサービスで開発を行っている林崎と申します。

Speeeに入社するまでは、自分なりにコードを書いて自己満足をする程度の経験しかなかった私ですが、新卒1年目の終わりごろにいきなり大規模リファクタリングに挑戦させてもらえることになりました。

今回は、大規模リファクタリングが失敗に終わってしまうまでの顛末と、そこで得られた「エンジニアとして事業にどのように向き合っていくべきか」に対する学びについて共有します。

特に、「自分なりに技術力は磨いているが、まだ実務経験がなくてイメージがわかない」という大学のときの私と同じような疑問を持っている方がいれば、参考にしていただければと思います！

チャレンジングな目標設定と大規模リファクタリングの意思決定

私たちイエウール開発チームでは、機能をリリースしてそれがどの程度ユーザーのニーズを満たしたかを検証する、というサイクルで開発を行っています。

そんな中で、プロジェクトの特性とフェーズを踏まえて「とにかくたくさんリリースして大量に検証していくことが大事なのではないか」という方針が立ち上がりました。それを実行していくためには、開発チームとしては「2倍の量の機能をリリースするために開発速度を2倍にする」というチャレンジングな目標を追っていくことになります。

2倍というのはちょっと工夫した程度で到達できる水準ではないため、目標達成のためには何か大胆な手段を取る必要がありました。そこで、リードエンジニアの協力を得ながら大規模なリファクタリングを計画しました。

大規模リファクタリングではいくつかの取り組みを行いましたが、メインで進めたのは「モノリシックなRailsアプリケーションからの脱出」になります。

イエウールのシステムは、複数の全く異なる機能が一つのRailsアプリケーションに同居している、いわゆる「モノリシック」なアーキテクチャになっています。私たちが開発している機能群についてもそこに含まれており、以下の理由から開発スピードが出せない状態でした。

管理画面・請求システム・不動産会社向けツールなど、障害が発生したときの事業的インパクトが大きい機能の存在によって、リリースを慎重にならざるをえない
グローバルに適用されているCSS・jQueryの存在によって意図していない挙動が発生する
リポジトリサイズが巨大なので、慣れていないと余計なコンテキストが目に入ってくる

この状況を打開するために、対象の機能群を従来のシステムから分離して新しいRailsアプリケーションとして立ち上げるという意思決定をしました。意思決定プロセスの詳細は省きますが、（上記の1つ1つはこのような手段を取らずとも解決可能ですが）一気にあらゆることを解決するためにはアプリケーションの分離が最適だと考えての結論です。

「2倍」という分かりやすい高い目標に対して、「アプリケーションの分離」という技術的にも難易度の高い方法で解決するというワクワクするような状況だったので、当時は「これはすごい成果が出るのではないか」という期待感の中で取り組んでいました。

しかし、この意思決定は結果として失敗に終わってしまいました。

大規模リファクタリングの失敗

前述したリファクタリングは、普段の機能開発と並行して行いました。

機能開発のアウトプット水準は極力落とさないという制約の中でリファクタリングを進めていたのですが、徐々に開発していて苦しくなる場面が増えてくることになります。

事前に立てていたリファクタリングの実行計画とのギャップ
- 見積もりの甘さに起因する計画の遅延・約10年の歴史があるシステムであるが故の影響範囲の読めなさ（社歴の長いリードエンジニアでも知らない機能がどんどん出てくる）
事前に期待していたアウトカムが得られなかった
- 今回のリファクタリングによって、これまでに実績のあるような機能開発であれば開発スピードを大きく上げられると読んでいた。しかし、プランニングされるIssueが今までとは毛色の違うもので、例えばフロントエンドでJavaScriptで機能を作り込む必要があるなど、今回のリファクタリングでは直接恩恵を受けられないようなものだった。
- 移行を進めることによって開発スピードが上がることを見越してリファクタリングの計画を引いていたので、開発スピードが伸び悩むことでさらに計画が遅れていくという構造になっていた。
事業戦略の見直し
- そもそも開発速度を2倍にしたとしても、それに見合うように2倍の機能のプランニングができる状況ではなかったため、結局のところプランニングがボトルネックになってしまう状況だった
- アプリケーションの分離という大きな意思決定の割には、前提となる戦略の賞味期限が短かった

結果として、リファクタリングは中途半端で止まってしまい、目標に対するFCSTが伸びないまま目標の見直しに入るという、（少なくとも短期的には）失敗と判断せざるを得ない状態になりました。

なぜこのような失敗に陥ってしまったのか

今回の取り組みを振り返って、技術的な反省点や自身の経験の少なさによる実力不足などもありましたが、一番身をもって体感したのは「システムの方針や技術的な戦略を、事業の目指す方向と整合させ続けること」の大切さでした。

冒頭で「2倍の量の機能をリリースするために開発速度を2倍にする」という開発チームの目標を提示しましたが、Bizメンバーが実際に考えている戦略はこの短いステートメントで表現できないほど奥行きのあるものです。

まず最初にやるべきことは「とにかくたくさんの機能をリリース」というわかりやすい部分に飛びつくことではなく、背景にある前提やBizメンバーの持つ理想状態のイメージを丁寧に紐解いていくことでした。

「とにかくたくさんの機能」とはどういう技術特性のある機能なのか（例えば、DBに関連するのか・パフォーマンスに気を配る必要があるかなど）。今まで実績のある機能と同じような取り組み方で開発可能な機能なのか。
（具体的な機能リリースの定量水準が決まっていたのですが）なぜその目標水準を設定したのか。その目標水準で何を検証したいのか（ユーザーに何を届けたいのか）。
開発以外に難所はあるか。この戦略が見直されるリスクはどこにどの程度あるのか。

ただ開発速度を2倍にするだけであれば、大規模リファクタリングは今でも有力な選択肢だと思っています。しかし、事業という複雑なコンテキストの中では、Bizメンバーと歩調を合わせて意思決定の方向をチューニングしていくことが必要不可欠です。

私はこの失敗を通して改めて「事業の目指す場所・その先のユーザー価値にBizメンバーと同じ水準で向き合えていなかった」と感じました。

Speeeのエンジニアには、Bizメンバーと協働してユーザーに価値を届けることに同じ熱量でコミットすることが求められます。私もその環境の中で、一定上手くできているという自信を持っていました。しかし、ちょっとした仕様・デザインの提案など（もちろんそれも大切だが）表層的な部分しか見ておらず、本当に実現したい事業の目標には目を向けられていませんでした。

ユーザーにどんな価値を届けたいか考え抜かれた戦略に対して、これを期待された水準で最後までデリバリーするということには、エンジニアが主体者として責任を持っていかなければなりません。そこに執着することができていれば、前述したような戦略に対する疑問や「本当にその見立てでリリースしていけるのか」といった見積もりに対する不安などは自然に出てくるものだと思います。

事業とシステムの方向性を揃えることの重要性

前提として、設計やアーキテクチャに正解はないと考えています。しかし、事業という制約条件の中では事業の向かう方向と整合した意思決定を積み重ねていく必要があります。そのために大切なことは、短期と長期で事業がどのように進んでいくのかを丁寧に擦り合わせて、限りなく意思決定の確度を上げていくこと、そしてそれを一度ではなく日々の開発プロセスの中で繰り返し行うことではないでしょうか。

そうして事業にピッタリ適合したプロダクトにユニークな設計に作り変えていくことこそ、変化の激しいWebサービスという領域でエンジニアリングすることの一つの醍醐味なのではないかと考えています。

Speeeでは各メンバーが事業とその先にあるユーザー価値に本気で向き合っている環境だからこそ、ときに手痛い失敗をしながらも前向きにプロダクトに向き合うことができています。そういった環境の中で、エンジニアとして技術的な部分に責任を持てるのはとても面白いと改めて感じました。

最後に

Speeeではときに失敗をしながらも、各メンバーがサービスの改善やその先にあるミッションの実現に日々向き合っています。 Speeeのエンジニアの事業への向き合い方について共感していただけた方、Speeeでは一緒にサービス開発を推進してくれる仲間を募集しているので、ぜひ以下のフォームからお申し込みください。