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