事業の試行錯誤を支える、システムをシンプルに保つための設計と工夫
2023年6月スタディスト「テックブログ月間」の6月29日の記事です。新規事業「ハンクラ」のプロダクト開発責任者をしている zuckey が担当します。
はじめに
「ハンクラ」プロダクトの立ち上げ時にプロトタイピングをしたり、ドメインについてチームで詳しくなったりという取り組みについては以前ブログに書きました。
一方で、プロダクトをリリースした後すぐに、意図通りに市場に受け入れられるとは限りません。
本エントリでは、BtoB SaaS プロダクトのリリース後に事業としてどのような試行錯誤があり、その中でプロダクト開発として工夫できるポイントについて紹介します。
B to B SaaS プロダクト初期について
顧客1社ごとの重要度が高い
BtoCと比べてBtoBのサービスでは、1つの案件ごとの金額が大きくなりやすく、対象となる市場の顧客の数は少なくなります。特に業界・業種に特化したバーティカルSaaSだと対象となる顧客は数え上げられるほどになる場合もあります。
パイロット顧客を見つけ、ともにプロダクトをつくりあげるような関係性になる
プロダクトがはじめから完璧であることはありません。それでも実業務で使ってくださるようなパイロット顧客を見つけ、フィードバックをいただくことにより、よりよいプロダクトに近づけていきます。
こういった顧客は、 伸びしろがあることを理解いただきつつ、事業の思想に共感してくださっています。また、事業としても密なコミュニケーションをする余裕もあるため、短期の Churn リスクは少し低めになります。
1件を失うと事業が危ぶまれるかもしれないという不安もある
顧客の特殊（かもしれない）業務に寄り添うことになるわけですが、それが新規の顧客や自分たちが進めていきたい方向性と必ずしも合うわけではありません。
将来の可能性を狭める可能性があるため、あまり作り込みすぎるのは避けたいところです。しかし、初期からともに歩んでいる顧客で、いただいている料金がそれが事業の数字の大部分を占める。そういう場合に特定用途について作り込みを許容するほかない状況もあります。
一方で、このような動きをして、序盤から事業数字を作っていけることもBtoB SaaSの強みの一つでもあります。
売り込み先や課題を、状況に応じて設定し直し続ける
ハンクラにおいて、立ち上げ時期のプロトタイプでの検証に協力頂いた顧客3社中、本契約まで利用いただいているのは1社でした。
- 市場規模が思っていたよりも大きくなく、ほかの業種や部署にもアプローチする必要があることがわかった
- 初手から（顧客や関連会社などの）登場人物が多すぎて思うように事業にスピードが出なかった
など、日々学びがあり事業としてはそれに応じて打ち手を変える必要があります。
プロダクトも影響を受けますが、前述のようにある程度の作り込みを許容しながらこの変化に追従し、更には加速させるためには工夫が必要です。
システムをシンプルに保つための設計と工夫
プロダクト開発のスピード感を維持、加速するためにはシステムが理解しやすく、変更を加えやすい必要があります。つまり、シンプルなシステムであることが大事です。
そのために、わたしたちが意識してきたことは、コードを可能な限り捨てやすくする ということです。
作り込んだコードも不要になった時に捨てることができればよいわけです。
たくさんのコード片ではなく、大きな単位で捨てられるようにする
機能やコードを削除するとき、様々なファイルの複数箇所を横断して修正する必要があるケースは、影響範囲の考慮漏れの結果、予期せぬ不具合につながりやすくなります。
なるべくファイルやクラス、ディレクトリ、ネームスペースの単位で削除できるようになるのが理想です。
使い続けられる自信が持てない機能はデータベースのテーブルから分ける。テーブルごと削除できればスッキリになります。ぱっと見は既存のテーブルにカラムを付け足したほうが楽そうでもあえてテーブルをつくるのが良さそうです。
新規の機能で画面を分けておくのもよいです。URLのパスごと削除できればすごくハッピーです。
冗長な書きっぷりに見えることがありますが、簡単に捨てられる安心感をとることが重要なこともあります。
例えば、わたしたちは以下のような工夫をしています。
- 顧客の中で新しい部署を巻き込みたい場合、その利用者のための専用の画面を作ります。部署が違えばほしい情報は異なり、同じモデルを見ていてもそこから得たい示唆が異なります。それを既存の画面に詰め込むよりも新しい画面を作ったほうがよい場合があります。もし、思ったように利用してもらえなければ捨てれば良いです。
- サマリの機能には1つのテーブルをつくります。プロダクトが利用され、データが溜まるとそれをイイ感じにサマって見たいという要望はよく出てきます。1つのモデルに対していくつかのサマリViewがあることもあり、そのときはテーブルを使い回すのではなく、Viewに対してテーブルを作っておくようにします。そのViewが不要になった時にテーブルごと削除すればよいですし、サマリをアップデートするための非同期ジョブも同時に消すことができます。
利用状況をウォッチして、削除の意思決定を後押しする
システムが複雑になった時の大変さを一番理解しているのは開発者といっていいでしょう。しかし、開発者だけが機能やコードを削除したいと言っても、物事は進みません。
たとえ機能や画面が利用されていなさそうでも、せっかく工数をかけて作ったもので、まだ見ぬ顧客が使う可能性があるものを削除すると決めることは難しいものです。
そのため、削除しやすい設計にするだけでなく、情報を集めて削除の納得感を高めるということも必要です。
まずは、プロダクトのログを簡単に閲覧できるようにして、特定機能の利用状況を客観的に把握できるようにしましょう。
私達の場合は、本番のDBとユーザーIDの入ったWebサーバーのアクセスログを併せてRedash上で見られるようにし、誰がどの画面、機能を利用したのかを確認することができるようにしています。
また、顧客からヒアリングすることも大事です。客観的な数字よりも説得力が高い場合もあります。
一方で、顧客に話を聞いてみると機能が使われていないのは単に機能の存在や使い方を知らないだけ、ということもあります。せっかく作ったものを捨てないという意思決定をするためにも情報収集は必要です。
まとめ
システムをシンプルに保つことにより、事業を身軽にし、スピードをあげることを助けることができます。
また、スタディスト開発本部は「ゴキゲンに働くこと」を大切にしていますが、システムがシンプルだと普段の開発も「ゴキゲン」になります。
設計だけではなく、コードの積極的な削除が許容される雰囲気をつくることも技術者の腕の見せどころです。
さいごに
スタディストでは、“伝えることを、もっと簡単に” するために、一緒に働く仲間を探しています。
少しでも気になった方はお気軽にご連絡ください！
ブログ月間は明日で最終日！CTOの佐橘が締めくくります。
このイベントが終わっても開発ブログを積極的に更新して行きますので、是非 Twitter @studist_tech もフォローしてみてください。
いきなりカジュアル面談するにはまだスタディストのこと知らないよ…という方は、Entrance Bookもあるのでぜひ見に来てください◎
