価値検証を高速化するために開発チームで意識していること

はじめに

どのスタートアップ企業でも、プロダクトリリースサイクルの高速化・最適化を心がけているかと思います。本記事では、ストックマークのプロダクトである Anews の新機能（論文配信）を例にとって、ストックマークの開発の実際について紹介いたします。

本記事から学べる点は大きく 3 点です。

• 高速な価値提供を実現するために意識すべきこと
• フロー効率の極大化によりユーザー価値へつなげる方法
• 中期目線で開発速度を保つ方法

それでは、それぞれ個別に 1 つ見ていきましょう。

高速な価値提供を実現するために意識すべきこと

どんなプロダクトであっても、実装しようとしている機能は、何らかの方法で検証してみるまで顧客にとって必要なものか分かりません。本記事のテーマである論文配信機能についても同様ですが、少なくともユーザーインタビューなどの仮説検証で一定のニーズは確認できていました。

ニーズまでは確認できているので、実際にミニマムな機能を提供することで、仮説検証を進めます。ミニマムといっても、開発着手時点で実装可能な候補がたくさんあります。その候補の中から、いかに何も作らずに仮説検証できるか、そのために仮説検証対象を削ぎ落としていくのが重要です。

今回はその実現のために、”最新データの追従” を最初は盛り込まずに検証する、というアプローチを取りました。こう書くと簡単なように見えますが、機能追加先のプロダクトである Anews は、毎日最新の情報を提供するプロダクトであるため、最新情報が届かないことはユーザーにとって違和感があるかもしれません。しかし、まずユーザーに価値があるかどうか判断するために、最新データを常に追従を当初から実装しないという意思決定をしています。（さらにいえば、最新データをどの程度の頻度で取得・更新すべきか、も検証する必要があります）

論文データを取得する方法もいくつかありますが、今回は SemanticScholar に決定しました。SemanticScholar は検索による科学文献のデータ提供および、API により 2 億件以上の論文を含む科学文献のデータを無料で取得可能な機能を提供しています。こちらの決定要因も、まず仮説検証が迅速にできることを重要視した点にあります。

このように、高速な価値提供を実現するために徹底的に価値の本質を見極めることを重視しています。

なお、SemanticScholar には公開されているスキーマが存在しません。今回調査した情報は弊社公開 Notion ページにまとめておりますので、参考にご活用ください。

フロー効率の極大化によりユーザー価値へつなげる方法

論文配信の提供を始めると実際にユーザーの行動ログやユーザーのフィードバックが集まり始めます。まず、当初の狙い通り、実際に論文が読まれることがまず検証できました。さらに利用ログを確認していると面白いことが 1 つ分かってきました。

それは、わずかしかない日本語の論文が想定されるより優先して読まれているということです。SemanticScholar は日本語の論文に注力しているわけではないため、全論文量の 2%程度しか日本語論文が含まれていません。その日本語論文が読まれやすいことがわかったわけです。

この知見をもとに、日本語論文の強化を検討しはじめます。今回は、国立情報学研究所が提供する CiNii について、CEO の林がコメントしたのをきっかけに、CiNii のデータ取り込み・論文提供まで 1 ヶ月弱で実現しました。

この裏側で意図していたのがフロー効率重視の考えです。本機能の価値が高いと判断したため、他の機能開発のし掛かりを並行して進めるのではなくむしろ止めて、国内論文の拡充に集中して開発を進めました。

ちなみに、こちらの機能提供により、論文の閲覧数が 5 倍以上に増加しており高いニーズがあったことが確認できています。

中期目線で開発速度を保つ方法

ある程度の開発経験のあるエンジニアであれば、よほど大きな機能でない限り、1 人で作り切ってしまった方が早いことがあります。今回の論文配信機能の開発裏側では、まさに開発メンバー 1 人で実装を進めていました。

一方で、1 人で開発を進めていると中長期的に見て開発速度が落ちていくリスクがあります。たとえば、開発メンバーが体調不良になった場合、そのメンバーが回復するまでに開発が止まりかねません。

そこで、論文配信の機能が継続的に提供されるとわかった段階で、徐々にプロダクト開発に携わるメンバーを増やすように進めてきました。具体的には、新しい機能については、別の開発メンバーと共同で開発するようにします。

そのため、別の開発メンバーが参加しやすいように、「背景」を重点的にドキュメントに起こしておきます。機能や処理に関してであれば、ソースコードから一定理解できます。一方で、その実装に至っている背景については、コメントに手厚く書いておかない限りソースコードからは読み取れません。ドキュメントに背景を残しておくと、長期的に開発速度が落ちにくくなります

また、今回の実装では全体のインフラ構成も複雑であったため、事前に鳥瞰図を準備しておきました。2023/6 時点の設計・実装はやや異なりますが、当時準備していたものを参考までに掲載いたします。

これらの準備によって、途中から開発に参加する場合であってもスムースに入れたようです。

まとめ

本記事では、ストックマークの開発で意識していることを重点的に紹介しました。ユーザーに価値をいかに早く届けられるか、そして中期目線で開発速度を落とさないための取り組みを紹介しました。

本記事では技術的な詳細はそこまで触れておりませんが、 もしご興味あれば是非カジュアル面談でお話させてください。こちらより気軽にお問い合わせください！