初期プロダクト検討において、"良かった判断"と、"ちょっと後悔した判断"
ourly代表の坂本(@sakamoto_ourly)です。社員持ち回りnoteリレーの第3弾は「ourlyや自身だからうまくできたこと」をテーマに記事を書きます。
前回はHR相原さん(@aiharamana1)がリファラル採用比率を20→55%に爆上げした秘訣を書いてくれました！
ourlyは2020年に株式会社ビットエーの新規事業として検討が始まりました。ビットエーは主に大手企業のtoC向けwebサービスのグロース支援を行っており、特に設計・デザインやフロントエンド開発に長けたメンバーが多い会社です。
そのビットエーの開発知見を用いてourlyのプロダクト検討を進めたのですが、いま振り返っても良かった判断と、いまなら違う判断をするなということがあります。
僕は非エンジニアなので、非エンジニアが押さえるべきポイントを理解してエンジニアと会話できるよう、ourlyでの事例を交えながら学びを共有できればと思います。
良かった判断(1) サービスの核となるデータは、後々、活用しやすい形で保存する
ポイント：後からデータ構造を変えるのはめちゃくちゃ困難、かつ最初からデータ活用の理想形は見えない。なので、サービスの根幹に関わるデータはできるだけあとから利活用しやすい、"クリーン"な形で保持するのが吉。
↓ ourlyでの事例
ourlyは社内報機能からスタートしているのですが、社内報=記事投稿できることが必須であり、そのためにはエディタ（noteの記事作成に使うやつみたいなもの）と呼ばれる機能を使って、記事を作る必要があります。
このときに、どういうエディタを採用するかで保存されるデータ形式が変わってくるわけですが、この選定によって、その後におけるUI変更の容易さ、データの活用のしやすさが決定されてしまいます。
イメージを掴んでもらうため、超簡単な例を挟みます。
🙅将来に負債を残しがちな例：HTMLと記事文章が分離されず保管される
<p> Hello World！ </p>webページを作るときに、
・"ここ文章要素だよ"を示すコードが<p>～</p>
・その間にあるのが文章データ
だと思ってください。
これは古いエディタだとよくあるのですが、この形で保存されると、コードと文章データが一緒に保存されるので、文章データを抽出してなんかしたいときにコード部分を取り除く処理が必要だったり、（詳細は割愛しますが）UI変えるときにだいぶと面倒なことになります。
ついつい売上見ている側からすると「最速リリースで後から直そう！」と言っちゃいがちなのですが、SaaSはデータの積み上がり方が非線形なのと、特にクライアント影響があるデータの場合は簡単に手出しができない。
（ourlyのようなサービスで、記事データ変換ちょっとミスりました…😅とはなかなか言えないので、やるにしてもチェック工数が跳ね上がるし、チェックしている間に記事がどんどん増えていく。またその負債解消の時間を提供価値向上に使えないもどかしさから、着手がどんどん遅れていく。）
何がサービスの核となるデータかはサービスによって変わりますが、核となるデータだけは後々の展開を考えて、できるだけ再利用しやすい形で保存することをエンジニアと議論したほうが賢明かと思います。
良かった判断(2) とにかく利用データを残しておく
ポイント：後々、データ活用をして機能改善したり、サービス提供価値を向上させるためには、とにかく利用データを残しておくのが吉。
↓ ourlyでの事例
残したいデータ例1：サービス利用データ
ourlyは分析機能を売りにしていたので、記事の閲覧状況などは最初から取得していたのですが、サービス主機能の活用状況がわかると、顧客への活用提案レベルがあがるだけでなく、CSでチェックすべき活用度が低い顧客も簡単に抽出できるようになります。
残したいデータ例2：エラーログ
エラーログをちゃんと取って可視化/通知できるようにしておくと、顧客から問い合わせがある前にエラー検知して能動的にサポートができますし、よくエラーが発生している箇所は修正することで満足度を高められます。
ourlyのように、管理者と利用者(社員)が分かれる場合、管理者から声をきくだけでは利用者の困ってることが拾えない場合もあるので、顧客ヒアリングと利用データの両面から解像度を上げようという話を良くしています。
残したいデータ例3：操作ログ
大手になればなるほど、セキュリティチェックで管理画面の操作ログ追えることなどが求められたりもしますので、サービスのターゲット規模によって取得データを考えると良いかなと思います。
LayerXの福島さんも以下動画で仰ってましたが、後々これみたいとなってもデータが無いとどうしようもないので、とにかく改善に使えそうなサービス利用データは取っておくのが良いんじゃないでしょうか。
良かった判断(3) 外部の有識者に入ってもらう
ポイント：自社内で知見が薄い部分は積極的に外部の有識者に入ってもらうのが吉。たとえレビューだけでも。
↓ ourlyでの事例
ビットエーでは、大手企業のwebサービス開発支援をしていましたが、自社でSaaSを作った経験はなかったので、インフラや基盤技術の選定を手探りで進めているタイミングもありました。
またサービスリリース後も追加開発をするにあたって、なかなか外部に知見が出回っていない領域などもありました。
その時に過去の取引先、社内の人脈、時にはSNS上の発信から繋がりを手繰り寄せて、有識者の方に入ってもらうことで、自分たちの技術選定に自信を深められることができました。
経験豊富なエンジニアリングチームを抱える場合は置いておき、そうでない場合は外部の有識者の方を探して、せめてレビューだけでもしてもらうことで前進速度は大きく変わると思います。
ちょっと後悔した判断：最初から自前で作り込みすぎない
ポイント：サービスの提供価値は変わっていくし、そもそも提供してみないと見えないものもある。自前主義で最初から作り込みすぎずに検証を優先する。
↓ ourlyの事例
先ほど、ourlyでは分析機能が売りと書きましたが、そのために初期開発において結構な工数をかけて管理画面に分析画面を作りました。デザインにもこだわり、他社が提供しているライブラリなどは使用せず、自前で表などの機能を用意しています。
が、、いざ提供しだすと、もうちょっと違う角度からデータを見たほうが、より踏み込んで顧客支援ができそうなことがわかって、管理画面ではなく、別方法で集計したデータをもとに支援するようになり、最終的には分析画面をフルリニューアルすることになります。
フルリニューアル時には自前で表を作るのではなく、機能性などを踏まえて外部の有償ライブラリを使うことにしましたのですが、最初からあそこまで自前で作り込みすぎなくても良かったなという反省があります。
もちろん外部ライブラリを使う時は気をつける観点もありますが（サポート切れたときの考慮とか、使い続けるに足る信頼があるのかとか）、前述したデータ構造など後戻りが困難なものはコストをちゃんと掛けて、後から変えやすいものや変わりうるものはコストを掛けすぎないのが良いと思います。
ちょっと長くなってしまいましたが、初期検討を振り返って、非エンジニア観点で押さえておくと良い学びでした。
カルチャー・マネジメントから、顧客の組織課題解決をしていく仲間を募集しています
最後までご覧いただきありがとうございました。ourlyに少しでも興味を持った方は、まずは人事とのカジュアル面談から。気軽にお話ししましょう！