※本投稿は10月7日公開のnoteより内容を転載しております。
はじめに
この記事はsmartroundの中心機能「データ共有」を「チームでどのように刷新したのか」をまとめた記事です。
これまでどんな課題があり、なにをきっかけに刷新プロジェクトがはじまり、どのように理想像を現実像に落とし込んだのか。メンバーはどのような思いで開発を行なっていたのか。一連の流れをまとめました。
※この記事では、弊社代表砂川が書いた資金調達マニュアル、PdMが社内ワークショップ用にまとめた内容も参考にしています。
目次
はじめに
1. データ共有の成り立ち
2. これまでの課題
3. 刷新プロジェクトのきっかけ
4. どのように課題を解決したのか
5. 開発の進め方
6. ふりかえり(良かったこと、苦労したこと)
おわりに
1. データ共有の成り立ち
スタートアップは投資家からの依頼を受けて、資料を提出しています。
資料の種類は資金調達前と資金調達後の大きく分けて2つの場面で異なります。
<資金調達前>
投資家からスタートアップに単発で依頼。例が2つあります。
1つ目は、ピッチデッキです。
スタートアップは投資家から投資してもらうために、事業計画書のようなプレゼン資料を作り、「いま当社に投資すれば、数年後に数十倍になって戻ってくる」ことをアピールします。
2つ目は、DD(デューデリジェンス)用資料です。
投資家は投資をする際にさまざまな角度からスタートアップを精査します。事業の成長性や将来性、法令遵守、訴訟リスク、反社会勢力との関係、計算書類の数値、会計基準違反、その他投資をする際に重大な障害はないか、など。スタートアップは定款や株主名簿、その他多数の資料を作成する必要があります。
<資金調達後>
投資家からスタートアップに定期的に依頼。
例は、決算資料、IR資料、株式データ、会社情報などです。
定期的な依頼ですが、毎月、決算月、四半期など資料によって異なります。スタートアップは依頼がきたタイミングで更新し提出します。
このように2つの場面で、やりとりされる資料と頻度は違いますが、そこには共通課題が見えてきます。
![]()
<スタートアップ視点>
・同じ資料を異なる形式で求められる
・投資家ごとにやりとりする経路が違う
・資料作成に時間がかかる
<投資家の視点>
・間違った内容や古い資料を共有される
・投資先ごとにやりとりする経路が違う
・資料収集に時間がかかる
![]()
smartroundは、スタートアップ用のプラットフォーム上に登録されたデータやファイルを共有し、投資家用のプラットフォーム上でも閲覧できる仕組みを作ることで、共通課題を解決することに成功しました。「統一された形式で、正しいデータを、簡単に共有できる世界」の実現です。
2. これまでの課題
プラットフォーム間でデータやファイルを共有できる仕組みは出来たのですが、使いやすさの面では課題が多い状況が続きました。
実は2年ほど前にも刷新プロジェクトを行ったのですが、ユーザーに直感的に使ってもらうには仕様が複雑という課題がありました。
具体的には、データ共有のフローが次の3通りあったからです。
![]()
![]()
![]()
ここまで読んでくれた方は、こんな気持ちになったのではないでしょうか。
「複雑すぎて何回読んでも理解できない」
「つながり、投資関係確認とは?なぜ必要?」
このように、ユーザー視点での使いやすいUXを設計することができなかった背景には、2つの制約の存在がありました。
1つ目は、投資関係確認がプロダクトのデータ構造上、全体の整合をとるために必要だったからです。
2つ目は、データ共有対象をつながりと紐づけることで共有がしやすくなるとの想定から、自分の会社のメンバーと1人でもつながっている投資家をデータ共有対象にする仕様を追加することに決まったからです。
これは「プロダクト仕様の都合と、誤ったメンタルモデルの想定を優先したUX」であり、結果的にユーザー視点での使いやすいUXとは対極にあるものでした。
そのためユーザーも、既存のデータ共有プロセス(例:Googleドライブやメールでの共有)を変えてまで使いたい機能にはならなかったのが実態です。
当時、お問合せの2割がデータ共有関連だったことからも、ユーザーにとって必要な機能にも関わらず、多くの方が使いにくさを感じていたことが分かります。
3. 刷新プロジェクトのきっかけ
ユーザーも開発メンバーも皆が使いにくいと感じている。
使いにくさの根本原因もわかっている。
それなのになぜ今回の刷新プロジェクトまで改善できなかったのか。
それはデータ共有が機能要件を満たしているがゆえ、他の様々な機能の開発が日々必要な中で、改善の優先度が上がらなかったためです。
なにを開発するかは開発ロードマップに沿って行います。開発ロードマップは会社の全体方針に沿って策定されます。そのため、特にプラットフォームを跨ぐ影響範囲の大きな機能は、機能要件を満たしていればOKとされ、なかなか改善のチャンスがありませんでした。
それが今回、開発の優先度が上がったことにより、ようやく刷新できることになったというわけです。
4. どのように課題を解決したのか
データ共有の分かりづらさの根本原因は「つながり、データ共有、投資関係確認」の3つの密接な結びつきです。その結びつきを可能な限り無くすことで、分かりにくさを解消することを目指しました。
進め方としては、「投資家起点」と「スタートアップ起点」の2つのフローに分けて検討しました。
![]()
投資家起点のフローは、投資家側のCSによる説明会を通してフォローできているため優先度を落としています。スタートアップ起点のフローは、smartroundを活用する意思のあるスタートアップが使いにくさを感じて離脱している状態だったため、優先して改善を進めることになりました。
それが「データ共有V1」です。
5. 開発の進め方
smartroundでは、基本的にPdM、デザイナー、エンジニアが1つのチームになって開発を行います。
今回は大規模開発ということもあり、企画段階からメンバー全員が関わることで、背景や要件をきちんと理解し、全ての工程で違和感や疑問点について様々な粒度で活発に議論しながら開発を進めました。
これはプロジェクトのロードマップと関わったメンバーの図です。
![]()
今回の刷新プロジェクトでは、会社都合の仕様や感覚的な想定を可能な限り無くし、ユーザー視点での使いやすいUIUXを目指しました。
前回の刷新プロジェクトにも関わっていたデザイナーとエンジニアが含まれていたので、当時の経緯や課題感を事前に共有できたこと、直接ユーザーの声を聞く機会が皆にあったことなどにより、チーム全体がユーザー視点を常に頭におきながら、同じ方向を向いて開発を進めることができました。
今回の刷新の一番の成果は、「フローからつながりを撤廃したこと」です。
つながりがなくてもデータ共有ができるようになりました。
スタートアップのユーザーは、事前につながり申請を行わなくても、データ共有画面で「新規共有」をクリックし、ステップに沿って進めるだけで簡単に共有できます。
具体的には次の画面のように、
①共有方法と共有先を選び、②閲覧権限を設定し、③完了ボタンを押す、
のたった3ステップです。
投資家はメールやsmartround上の通知から共有されたデータをすぐ閲覧することができます。
![]()
左上から順に、新規作成ボタン、①共有方法と共有先の選択、②閲覧権限の設定、③完了
ちなみに、予定では投資家起点のフローの改善をV2とし、その他の改善もそれ以降のスコープで考えていたのですが、チーム全体であらためて検討したところ、実はこの機能は無くても問題ないのではないかという結論に至り、V2はやらないことになりました。
6. ふりかえり(良かったこと、苦労したこと)
V1完了後、PdM、デザイナー、エンジニアの3名で振り返りを行いました。PdMが社内ワークショップ用にまとめてくれた内容がありますので、ご紹介します。
<良かったこと>
企画段階から複数メンバーを巻き込んだ
- 企画段階からエンジニアも議論に参加したことで、既存仕様や工数も踏まえた議論ができたのが良かった(エンジニア)
- 初期の段階からPdM、エンジニア、デザイナー全員が関わることでもやもやすることなく腹落ちしながら開発が進められた(デザイナー)
- 利用規約の範囲内のユーザーデータ利用で、UXを高められるか、法務にも相談しつつ進められたのが良かった(エンジニア)
- 企画の段階でBizメンバーにも懸念点がないかをみてもらったので既存ユーザーの利用に沿った改善ができた(PdM)
![]()
【企画段階の大量のコメント】ディスカッションしながら方向性を固めていった
ゼロベースで改善案を考えた
- つながりがなくてもデータ共有できるようになったことでUXが良くなったと思う(デザイナー)
- 既存のフローのブラッシュアップではなく、インタビューをもとに理想案を描き、現実的な仕様に落とし込むことができたのでステップを簡素化することができた(PdM)
![]()
理想フローを描き切った上で現実案に落とし込んでいく
同じ視点でユーザーの解像度を上げる
- ユーザーテストにデザイナーとエンジニアも参加したことで、より課題感やつまずきポイントを自分ごととして捉えることができた(デザイナー)
- ユーザーインタビューにリアルタイムに参加することで細かく説明しなくても理想の体験についてエンジニア、デザイナーと議論できた(PdM)
<苦労したこと>
アカウント種別やステータスによってパターンが複雑
- 実装に移ったタイミングで、検討漏れしていたパターンが多く出てきて、都度エンジニアに助けてもらっていた
- パターンがありすぎて仕様背景等を細かく把握することができなかった
過去の経緯から仕様を変えられないなど制約が多い
- 投資関係確認など、smartround側のデータ構造上の都合からUXが複雑化しているケースが多く、理想案の実現が難しいケースも
- 仕様が変更できない中で文言やUIを工夫することでできるだけわかりやすいUXを検討するのが難しかった
直感的な操作性とセキュリティ的な安全性のトレードオフ
- Googleやその他のクラウドツール同様に直感的な操作性を実現したい思いはありつつ、機密データを扱っているので、簡単に共有できたり、データにアクセスできたりするとセキュリティ的にリスクがあるので塩梅が難しい......
おわりに
理想像をすべて実現できる開発は少ないと思います。
しかし、どんなときも理想像は絶対に必要だと思います。
制約が多かったり、開発方針が変わったり、いろんなことがありますが、チーム全体が「理想像にできるだけ近づけるぞ!」という強い気持ちで、その時ベストなものを作っていくことが大事だなとあらためて思いました。
当初想定していたスコープより範囲の狭い刷新になりましたが、大幅に使いやすくなったと感じています。今後は、ユーザーや社内メンバーからのフィードバックを取り入れながら、さらに良い機能に改善し続けていきたいです。
スマートラウンドでは、PdM、デザイナー、エンジニアとも募集中です。
ご興味を持っていただいた方は、ぜひカジュアル面談でお話ししましょう!