2022 / 6 / 13

個別最適でプロダクトを作り続けたスタートアップがデータ専任部隊を作ることにした話

ストックマークのプロダクトはデータに支えられている

まず前提として、ストックマークのプロダクトである Anews と Astrategy はどちらも、国内外で公開されている膨大なデータを利用しています。

上図のデータはWebクローラーによって毎日収集され蓄積されています。実装としては、大量のAWS lambdaによる汎用的な収集・抽出処理が内部で動作しています。Webクローラーときくと、「え、データを取ってくるだけでしょ？」と思われるかもしれませんが、そんなに単純ではなく非常に厄介な問題があります。

「何もしてないのに壊れる」のではなく「何もしてないと壊れる」

Webというのは常に動的に変化するものです。Webクローリングを実施する場合、ある程度のHTML構造をベースにデータを抽出していきます。たとえば、このタグのここには必要となる情報が存在している、このタグは不要な情報である、といったように判断しながら情報を収集しているということです。

HTML構造が変化しなければ問題ないのですが、Webは常に進化していきます。したがって、更新に追従し続けなければ、クローリングの失敗数が漸進的に増えてしまうのです。結果として、データに支えられるはずのプロダクトの価値が低下することになります。

Phase0: どちらのプロダクトが対応する？

歴史的に、Anews と Astrategy の2つのプロダクトはコアな価値探索にフォーカスするため、別にチームで開発されてきました。Webクローラーの開発は、下図のとおりでプロダクト間の隙間に落ちているような状態になっていました。

Phase1: 役割の一部を明確化

ここで、まず取り組んだのはそれぞれのチームの適任メンバー数人が掛け持ちで分担するスタイルへの変更です。Anews のチームも Astrategy のチームのどちらも、クローラー開発の役割の一部を担うように変更しています。

もちろん、いきなりクローラーのチームを切り出した方がよいのでは、という考えもあります。しかし、まずは顧客価値創出を優先するためにチームを大きく変更するのではなく、徐々に変化していく方式で進めています。

この結果として、Webクローラーの改善が常時進むようになりました。ストックマークの開発チームでは、この状態を半年間維持してきました。その次のステップでデータチームの切り出しへ着手しています。

Phase2: データチームの切り出しへ

簡単にいえば、「プロダクトとデータはデータベースを介してやりとりする」方式です。

マイクロサービスアーキテクチャを学んだことがある方が上図をみると、すぐに気づく問題があります。それは共有データベース問題です。これは、開発チームでも認識していますが、次のSTEPへの過渡期として採用しています。

過渡期とはいえ、一定の成果が出ています。たとえば、プロダクトで配信できるWebサイト数が3.2倍・LeanとDevOpsで定義される4つのキーメトリクスの改善が得られています。また実際にお客様からも驚きの声を頂きました。

一方でまだまだシステムとして伸びしろが多くあります。ストックマークのプロダクトは構造化データを利用して、お客様に価値提供しています。構造化データは各プロダクトごとに作り込みされており、互いに流用し合うのが困難という課題がありました。

Phase3: データプラットフォームの構築へ

これらの課題に対して、現在進行系で進めているのがデータプラットフォームの構築です。あくまで、顧客への価値提供を最優先としているため、安易に今回もチーム自体に大きな変更は加えず、最適な摂理面を探し続けるアプローチを取っています。

ストックマークの開発チーム・システムは、ここまで述べたように常に最適な体制へ変化しています。

なぜ上手く変化できているのか？

ここまで、ストックマークにおけるデータを取り巻く進化をお伝えしてきました。ここまでは上手く進化できているように考えており、今ふりかえると、そこには大きく2つの理由があったかと考えています。

逆コンウェイ戦略によってチームインタラクションをソフトウェアに寄せたため
アジャイルに開発する土台があったため

これら2点が組み合わさったことにより、開発パフォーマンスを高め続けられています。

未来へ

ここまでご紹介した内容は、2022年6月時点のスナップショットではなく、未来に向けて引き続き最適な開発チーム・システムアーキテクチャへ変化させていく予定です。もし、未来の姿にご興味があれば是非お話しましょう！