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

**タイトル:** 価値検証を加速させるために私たちの開発チームが重視していること **はじめに:** どのスタートアップ企業でも、プロダクトリリースサイクルの高速化・最適化を心がけているかと思います。本記事では、ストックマークのプロダクトであるAnewsの新機能（論文配信）を例に、ストックマークにおける実際の開発の進め方を紹介します。 本記事から学べる点は大きく3点です。 * 高速な価値提供を実現するために意識すべきこと * フロー効率の極大化によりユーザー価値へつなげる方法 * 中期目線で開発速度を保つ方法 それでは、それぞれ個別に見ていきましょう。 **高速な価値提供を実現するために意識すべきこと:** どんなプロダクトであっても、実装しようとしている機能が顧客にとって必要なものかは、何らかの方法で検証してみるまで分かりません。本記事のテーマである論文配信機能についても同様ですが、少なくともユーザーインタビューなどの仮説検証を通じて一定のニーズは確認できていました。 ニーズが確認できたので、実際にミニマムな機能を提供することで仮説検証を進めます。ミニマムといっても、開発着手時点で実装可能な候補はたくさんあります。その中から、いかに「作らずに」仮説検証できるか、そのために検証対象を削ぎ落としていくことが重要です。 今回はその実現のために、「最新データの追従」を最初は盛り込まずに検証するアプローチを取りました。こう書くと簡単なように見えますが、機能追加先のプロダクトであるAnewsは、毎日最新の情報を提供するプロダクトであるため、最新情報が届かないことはユーザーにとって違和感があるかもしれません。しかし、まずユーザーに価値があるかどうかを判断するために、最新データの常時追従は当初から実装しないという意思決定をしました（さらにいえば、最新データをどの程度の頻度で取得・更新すべきかも、検証する必要があります）。 論文データを取得する方法もいくつかありますが、今回はSemantic Scholarに決定しました。Semantic Scholarは、検索による科学文献のデータ提供に加え、APIを通じて2億件以上の論文を含む科学文献データを無料で取得できる機能を提供しています。この決定も、まず仮説検証を迅速に行えることを重視した点にあります。 このように、高速な価値提供を実現するためには、価値の本質を徹底的に見極めることを重視しています。 なお、Semantic Scholarには公開されているスキーマが存在しません。今回調査した情報は弊社公開のNotionページにまとめてありますので、参考にしてください。 **フロー効率の極大化によりユーザー価値へつなげる方法:** 論文配信の提供を始めると、実際にユーザーの行動ログやフィードバックが集まり始めます。まず、当初の狙い通り、論文が実際に読まれていることが検証できました。さらに利用ログを確認していると、一つ興味深いことが分かってきました。 それは、わずかしか存在しない日本語論文が、想定以上に優先して読まれているということです。Semantic Scholarは日本語論文に注力しているわけではないため、全論文の約2%しか日本語論文は含まれていません。その日本語論文が読まれやすいことが分かったのです。 この知見をもとに、日本語論文の強化を検討し始めました。今回は、国立情報学研究所（National Institute of Informatics）が提供するCiNiiについて、CEOの林がコメントしたのをきっかけに、CiNiiからのデータ取り込みから論文提供までを1ヶ月弱で実現しました。 この裏側に意図していたのが、フロー効率重視の考え方です。本機能の価値が高いと判断したため、他の機能開発の仕掛かりを並行して進めるのではなく、むしろ止めて、国内論文の拡充に集中して開発を進めました。 ちなみに、この機能提供により、論文の閲覧数が5倍以上に増加しており、高いニーズがあったことが確認できています。 （論文閲覧数のグラフ） **中期目線で開発速度を保つ方法:** ある程度の開発経験のあるエンジニアであれば、よほど大きな機能でない限り、1人で作り切ってしまった方が早いことがあります。今回の論文配信機能の開発裏側では、まさに開発メンバー1人で実装を進めていました。 一方で、1人で開発を進めていると、中長期的には開発速度が落ちていくリスクがあります。たとえば、開発メンバーが体調不良になった場合、そのメンバーが回復するまで開発が止まってしまうかもしれません。 そこで、論文配信機能が継続的に提供されると分かった段階で、徐々にプロダクト開発に携わるメンバーを増やすように進めてきました。具体的には、新しい機能については、別の開発メンバーと共同で開発するようにします。 そのため、別の開発メンバーが参加しやすいように、「背景」を重点的にドキュメントに残しておきます。機能や処理に関しては、ソースコードからある程度理解できます。一方で、その実装に至った背景については、コメントに詳しく書いておかない限り、ソースコードからは読み取れません。ドキュメントに背景を残しておくことで、長期的に開発速度が落ちにくくなります。 また、今回の実装では全体のインフラ構成も複雑であったため、事前に鳥瞰図を準備しておきました。2023年6月時点の設計・実装とはやや異なりますが、当時準備していたものを参考までに掲載します。 （当時のインフラ構成図） これらの準備によって、途中から開発に参加する場合でも、スムーズに参画できたようです。 **まとめ:** 本記事では、ストックマークの開発で意識していることを重点的に紹介しました。ユーザーに価値をいかに早く届けるか、そして中期目線で開発速度を落とさないための取り組みについてお伝えしました。 本記事では技術的な詳細はあまり触れていませんが、もしご興味があれば、ぜひカジュアル面談でお話しさせてください。こちらからお気軽にお問い合わせください。

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

背景や根拠まで確認しますか？

調べる

選ぶ

サイト