ビッグリライトでシステム刷新した秘訣 ~ Anewsの成功事例から ~

はじめに

ストックマークが提供するプロダクトであるAnewsにおいて、ビッグリライトによるフロントエンド・バックエンドの両方を含むアーキテクチャ刷新を成功させました。一般にビッグリライトは、ハイリスク・ハイリターンであり、難易度も高いと言われていますが、大きなトラブルもなく、かつお客様評価も高い状態を実現しています。

本記事では、なぜビッグリライトを選択したのか、何が要因となって成功に至ったのか、といった事項について、開発チームで振り返りした中からいくつかの要因を紹介いたします。

アーキテクチャ刷新の背景

Anewsは、新規Feedを最適化して提供するプロダクトで、2020/8時点では累計1500社のお客様に利用されています。(参考：導入事例)

スタートアップのプロダクトでは、顧客の声に耳を傾けながら、大小あるピボットを積み重ねて、洗練されたプロダクトを開発・提供していきます。Anewsも例にもれず、細かな変更の積み重ねを繰り返してきました。幸いなことに多くのお客様に利用いただいておりましたが、より高い価値を提供するためには、プロダクトを大きく変更する必要がでてきました。

そこで、2020/1に大規模なシステムリニューアルを決断しました。

なぜビッグリライトの選択したのか？

基本的なプロダクトのベース機能は、リニューアル前後で同一です。ベース機能は同一ですが、今回のリニューアルでは、ニュースフィード画面の大きな変更を加えます。

このような状況下でのベースアーキテクチャ刷新の方法には、ビッグリライト・リアーキテクティング・リファクタリングなどいくつかのアプローチがあります。（参考：レガシーソフトウェア改善ガイド）

Anewsでは前述の通り、ハイリスク・ハイリターンであるビッグリライトを選択しました。一般に、ビッグリライトは、既存プロダクトと並行開発・運用する必要もあるため、リソース的な制約もあり、難易度があがります。しかし、成功した場合には、顧客向けの提供したい価値の最大化に加えて、これまでの技術的負債の解消も狙えます。

そこで、Anewsではビッグリライトを選択しました。もちろん、単に選択したのではなく、いくつかの工夫を加えることによって、成功確度を戦略的に高めています。以下ではそのアプローチについて紹介いたします。

ビッグリライトの成功確度を上げた工夫

ビッグリライトの成功確率を上げた工夫のうち、代表的なものは次のとおりです。

• 難易度の高いところから着手・実験する
• スコープをコントロールする
• 旧プロダクトのアーキテクチャをベースに、かつデータストアにRedisを使って仮説検証する
• 本番を見据えてしっかり作るというよりはとにかく動くことを優先して作る

以下でそれぞれを解説します。

難易度の高いところから着手・実験する

Anewsの最大の価値は、機械学習から生成するコンテンツ品質です。コンテンツ品質が悪ければ、プロダクト価値は非常に低下します。

今回のリニューアルでは、機械学習のモデル作り直しをスコープに入れており、かつその作成難易度は非常に高いものでした。仮にモデル作成と、同時並行で他の開発も進めて、モデル作成で失敗してしまうと、並行開発分が無駄になる可能性があります。

そのため、まずは難易度の高いモデル作成の部分に開発リソースを投下して検証しました。結果的に、非常に高いレベルのMLエンジニアの力もあり、検証で良い結果が出たため、サンクコストが大きくなるリスクを最小限に抑えて開発をすすめることができました。

スコープをコントロールする

システム開発における概念に、鉄の三角形という概念があります。鉄の三角形では、Scope/Time/Costの三要素のうち2つまでを固定可能です。

Anewsの開発チームは、開発プロセスとしてアジャイル開発を採用しており、上記三要素のうちScopeのコントロールによって、開発チームに負荷のかかりすぎない開発をすすめることができました。（負荷がかかりすぎると、バーンアウトしてしまう）

旧プロダクトのアーキテクチャをベースに、かつデータストアにRedisを使って仮説検証する

開発をミニマムに抑えた状態でユーザ検証することで、迅速なフィードバックサイクルを実現できます。もし、アーキテクチャを細部まで作り込んだあとに、ユーザ検証で価値がないことがわかると、サンクコストが発生します。そのため、いかにシステムを作らずに、価値検証するかが重要となります。

Anewsのリニューアルにおいて、作り込みすぎないという点で工夫した点は、旧プロダクトのアーキテクチャをベースにしつつ、データストアにRedisのみを用いた点です。

従来、Webアプリケーションを作る場合にはRDBを用いるのが基本的なパターンかと思います。RDBはACID属性を持っており、堅牢なデータストアとして利用可能です。しかし、ちょっとしたデータ構造の変更を加えようとすると、テーブル定義を変更する必要があります¹。

そこで、今回はRedisのみをデータストアとして利用しています。RedisはシンプルはKVSを提供しており、かつスキーマを容易に変更できるため、ちょっとした変更にも柔軟に対応できます。また、今回は、データ永続化の要件などもないため、AOFなどの設定も不要です。

結果的に、Redisを利用したプロトタイプでユーザ価値を検証できました。続いて、RDBも利用する本格的な開発へ進んでいきます。

本番を見据えてしっかり作るというよりはとにかく動くことを優先して作る

前述のRedisをメインデータストアとしたプロトタイプは、本番を見据えてしっかり作るのではなく、とにかく動くことを優先して開発を進めました。データストアとしてRedis単体をそのまま使う想定ではありませんでしたが、本番でも使える部分は使う、ぐらいの想定です。

システム開発において、一度目からクリーンな設計ができるわけではなく、実際にコードをある程度書き進めてから、課題などに気づくことは多くあります。実際に今回のリニューアルにおいても気づきが多く、本番向けの開発ではより洗練された設計・実装を実現しています。

また副次的な効果として、チームにいるエンジニアの成長につながっています。捨てるつもりのプロトタイプとはいえ、0からシステムをチームで作り上げる経験、また得意でない分野にもチャレンジできる機会が得られるためです。次の画像は、実際にRetrospectiveで上がった声です。

その他の成功要因

ここまでは、開発プロセスにおいて工夫した点を述べてきました。開発プロセスにおける要因以外で、成功に寄与した最大の要因は人だったと思います。

運の良かったことに、スキルが高く開発経験の多いメンバもストックマークにJoinしてくれています。このようなチームメンバに恵まれたからこそ、ビッグリライトが成功できたと考えております。

上手くいかなかったこと

ここまでの記事で、全てが上手くいったように見えておりますが、もちろんそんなことはなく、課題も多くありました。一例を紹介すると、

• コロナでフルリモートになった時期だったので、コミュニケーションが難しかった
• 新しいアーキテクチャで作ったこともあり見積もりが難しく、実際にかかった工数と乖離してしまった
• スコープ調整を行うのが遅く、着手したが結局リリースに含めなかった機能もあった

といった内容になります。この辺りは、今後の開発に向けて課題として解決していきます。

さいごに

ストックマークでは、スキルの高い開発チームで一緒に働いてみたい方を募集しております。Wantedlyに募集職種を載せておりますので、ぜひご覧いただいてまずはカジュアル面談からでもお話しましょう！