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