事業の試行錯誤を支えるピボットしやすいシステム設計と工夫 / Easy-to-pivot system design to support trial and error in business

BtoB SaaS企業4社が語る、開発の現場 の登壇資料です。

元ネタ => https://studist.tech/increase-business-agility-by-removing-code-d49066fdeae2

Transcript

1. 事業の試⾏錯誤を⽀える ピボットしやすいシステム設計と⼯夫 2023-07-03 / BtoB SaaS企業4社が語る、開発の現場 @zuckey_17
2. 2 ⾃⼰紹介 • 松村 和輝 @zuckey_17 ◦ 🙅「ざっきー」 🙆「ずっきー」 • スタディスト ◦ 開発本部エンジニアリング部副部⻑ ▪ ⽬標設定、評価、採⽤ ▪ 「ゴキゲン」な開発組織をつくる 💪 ◦ チェーンストア企業向けの新規事業 『ハンクラ』の開発責任者 ▪ プロダクトに関わることはもちろん、直接関わらないことでも⾸を突っ込んでいます ▪ 本⽇はこちらのお話
4. 4 Vision
5. BtoB SaaS プロダクト初期の特徴
6. 良くも悪くも顧客1社1社の重要度が⾼い • BtoBは、1件ごとの⾦額が⼤きくなる分、対象となる顧客の数が少ない ◦ 特にバーティカルSaaSだと対象となる顧客は数え上げられるほどになる • パイロット顧客を⾒つけ、ともにプロダクトをつくりあげるような関係性に ◦ 実業務でプロダクトが使われる → 貴重なフィードバックに ◦ 密なコミュニケーションにより⼀度導⼊されると短期の Churn リスクは少し低め • 1件を失うと事業の存続が危ぶまれるかもしれないという不安 ◦ 特定の顧客の特殊（かもしれない）業務にどこまで寄り添うのか ◦ 実ははじめにあたりをつけた顧客の期待と事業を進めていきたいという⽅向性は違うかもしれない ◦ 初期からともに歩んでいる顧客で、いただいている料⾦がそれが事業の数字の⼤部分を占める場合は... BtoB SaaS プロダクト初期の特徴 特定⽤途への作り込みすぎる⽅向への引⼒が強い
7. 『ハンクラ』史 BtoB SaaS プロダクト初期の特徴 さらなる可能性 他サービスとの シナジー 　価値への自信 試験導入が 進まない！ 本番リリース プロトタイプ ⼩売企業2,3社と提携 プロトタイプを2回 スクラップ & ビルド プロトタイプ利⽤者で契 約いただけたのは⼩売企 業1社... 販促施策を積極的にやり たいメーカー企業を巻き 込む メーカー企業にも課⾦で きるかも... メーカー企業と小売企業と の調整が進まず、試験導 入しても利用頻度が増えず に失注が続く 販促施策ではなく、⽇常 使いされるプロダクトに しよう、という決意 販促クラウド => ハンク ラ プロダクト名変更 想いに賛同いただける企 業さまとの契約 ⼩売企業以外のチェーン ストア企業以外にもアプ ローチできそう！ 潜在市場の広がり 既存プロダクトとの棲み 分けとシナジーへの期待 ~ 2020年 11⽉ 2020年 11⽉~ 2021年秋 2022年秋 2023年夏~
8. 作り込みすぎていたら ⼤⼩のピボットに対応できていなかった、かも... どうしていたのか？
9. コードを捨てやすくし、 システムをシンプルに保つ
10. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 理想的な登り⽅でプロダクトの⽬的は同じでも、実装⽅法も⼤きく変えていくべき コードを捨てやすくし、システムをシンプルに保つ
11. https://twitter.com/lukehannontv/status/794581557357015040 不要だと判断された機能は削除しないと利⽤者の満⾜度は下がる コードを捨てやすくし、システムをシンプルに保つ
12. たくさんのコード⽚ではなく、⼤きな単位で捨てられるようにする • 機能、コードを削除するとき様々なファイルの⼀部を複数箇所に横断して修正する必要があるのはつらい ◦ 影響範囲の考慮漏れ、関係ない場所のテストで落ちる... ◦ ファイル、クラス、何ならディレクトリ単位で削除できるようにしたい • 確度の低い機能は特にDBのテーブルから分ける ◦ テーブルごと削除したら機能削除は終わり ◦ ぱっと⾒は既存のテーブルにカラムを付け⾜したほうが楽そうでもあえてテーブルをつくる • 利⽤者が異なるなら、画⾯も分けておく ◦ パスごと削除できればめちゃくちゃハッピー コードを捨てやすくし、システムをシンプルに保つ 冗⻑な書きっぷりになったとしても、捨てられる安⼼感をとる
13. 事例1 • 顧客の中で新しい部署を巻き込みたい ◦ その利⽤者のための専⽤の画⾯を作る ◦ 部署が違えばほしい情報は異なり、同じモデルを⾒ていてもそこから得たい⽰唆 が異なる ◦ 既存の画⾯に詰め込むよりも新しい画⾯を作ったほうがよく、思ったように利⽤ してもらえなければ捨てれば良い コードを捨てやすくし、システムをシンプルに保つ
14. 事例2 • サマリの機能には1つのテーブルを⽤意 ◦ データが溜まるとそれをイイ感じにサマって⾒たいという要望はよく出る ◦ 1つのモデルに対していくつかのサマリViewがあれば、テーブルを使い回すので はなくViewに対してテーブルを作る ◦ Viewが不要になった時にテーブルごと削除 ◦ サマリをアップデートするための⾮同期ジョブも同時に消すことができる コードを捨てやすくし、システムをシンプルに保つ
15. 利⽤状況をウォッチして削除の意思決定を後押しする • システムが複雑になる⼤変さを⼀番知っているのは開発者 ◦ たとえ機能や画⾯が使われていなさそうな雰囲気でも せっかく⼯数をかけて作り、まだ⾒ぬ顧客が使う可能性があるものを削除する意思決定をすることは難しい • 客観的事実を集めて削除の納得感を⾼める ◦ ログを簡単に閲覧できるようにして、特定機能の利⽤状況を把握できるようにする ◦ 顧客との打ち合わせで活⽤⽅法について定期的に聞いてみる ▪ 客観的な数字よりも説得⼒が⾼い場合もあり ▪ 想定の運⽤ではなかったり、機能を求めていた⼈は別の部署にいるが知らないだけかも ▪ 利⽤者ごとのログをサマって⾒せられると企業内のサービス活⽤推進に繋がったりする コードを捨てやすくし、システムをシンプルに保つ 開発者がやりたいだけではコード‧機能の削除は進まない
16. まとめ 1 BtoB SaaS 初期は”特に”プロダクトに作り込みの⽅向に引⼒が働く 2 事業の状態が変われば、ほしい機能や仕様も変わる 開発のスピード感を保つためにはシステムをシンプルに保つ必要がある 3 コードを捨てやすくする 捨てやすい設計と意思決定のための情報収集の両輪で攻める
17. システムをシンプルに保って ゴキゲンな開発を
18. https://studist.jp/