Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SaaSを作るという仕事について
Search
Fujimura Daisuke
May 21, 2024
Programming
12
5.6k
SaaSを作るという仕事について
Fujimura Daisuke
May 21, 2024
Tweet
Share
More Decks by Fujimura Daisuke
See All by Fujimura Daisuke
AIの時代で我々はどのようにコードを書くのか
fujimura
3
750
一文字エイリアスのすすめ
fujimura
0
300
現役CTOが語る!RubyKaigiの楽しみ方
fujimura
0
1.2k
いかにして文系新卒エンジニアが「大きな問い」を大事にするCTOになったのか
fujimura
2
660
Kaigi on Rails 2022 - 既存Railsアプリ攻略法 CTOが見ること・やること・考えること
fujimura
14
3.8k
SimpleDelegator活用のご提案
fujimura
0
1.5k
入門 名前
fujimura
23
13k
それPostgreSQLでできるよ @ Rails Developer Meetup 2018 Day 1
fujimura
10
3.9k
ストリーム処理ライブラリはなぜ必要なのか
fujimura
2
620
Other Decks in Programming
See All in Programming
シールドクラスをはじめよう / Getting Started with Sealed Classes
mackey0225
3
420
[PyCon Korea 2024 Keynote] 커뮤니티와 파이썬, 그리고 우리
beomi
0
120
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
160
gopls を改造したら開発生産性が高まった
satorunooshie
8
270
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
230
【Kaigi on Rails 2024】YOUTRUST スポンサーLT
krpk1900
1
290
役立つログに取り組もう
irof
28
9.2k
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
490
Quine, Polyglot, 良いコード
qnighy
4
610
Server Driven Compose With Firebase
skydoves
0
430
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
310
イベント駆動で成長して委員会
happymana
1
250
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
40
2.4k
Scaling GitHub
holman
458
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
7
520
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Code Reviewing Like a Champion
maltzj
520
39k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
810
Happy Clients
brianwarren
97
6.7k
GraphQLとの向き合い方2022年版
quramy
43
13k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Fireside Chat
paigeccino
33
3k
Facilitating Awesome Meetings
lara
49
6.1k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Transcript
e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について
自己紹介 - お仕事 2 時期 2008~2012 2013~ 2015~ 2020~ 会社
いろいろ Quipper マチマチ STORES バックエンド Rails Rails Rails Rails, Go, etc. フロントエンド jQuery, Backbone.js etc. Backbone.js etc. React.js React.js, Vue.js 立場 ほぼメンバー いわゆるEM CTO CTO 藤村大介 twitter.com/ffu_ github.com/fujimura note.com/fujimuradaisuke
自己紹介 - 書いたり発表したもの 3 Rails Developer Meetup 2019 入門 名前
WEB+DB PRESSの特集のダイジェスト版 https://speakerdeck.com/fujimura/ru-men-ming-qian WEB+DB PRESS Vol.110 特集 名前付け大全 「よい命名とは」をガチで考えてみたやつ https://gihyo.jp/magazine/wdpress/archive/2019/vol110
自己紹介 - ポッドキャスト 4 論より動くもの.fm 藤村がホストになって、技術や技術にまつわることについてざっくばらんに話す Podcast です。 文字起こしもあるよ! 論より動くもの.fm
カテゴリーの記事一覧 - STORES Product Blog
自己紹介 - 作品 5 Haskellのプロジェクト生 成ツール $ bundle gem みたいな
やつ。当時いいツールが なかったので作った git-grepの結果で置換と リネーム $ git grep | xargs sed -i s/foo/bar/ が 面倒なので作った rspec-railsのHaskell版 RackやWSGIにあたる層 をテストするためのヘル パー。無かったので作っ た
STORES.inc
STORES のミッション こだわりや情熱、たのしみに駆動される経済をつくる 熱中しているひとたちから生み出される、 多様な商品やサービスが街に溢れる世界。 その経済を支える、デジタルインフラを提供する。
STORESのプロダクト お店のデジタル化を支援する、5つのプロダクト。 ネットショップ開設・運営 お店のキャッシュレス オンライン予約システム POSレジ 店舗アプリ作成
自分でつくれる、 本格的なネットショップ むずかしい知識や技術いらずで 自分だけのネットショップをかんたん に。 PRODUCTS
ネットショップとひとつに なった新しいPOSレジアプリ ネットショップとお店の 商品・在庫・売上データをまるっと管 理。 PRODUCTS
お店のキャッシュレスを かんたんに クレジットカード決済も、電子マネー決 済も、 QR決済も、これひとつで。 PRODUCTS
予約・顧客管理が柔軟に。 決済も、これひとつで。 ガイドに沿って設定するだけで、 あっという間に専用の予約サイトを作 成。 PRODUCTS
店舗とECをつなぐ アプリ開発 店舗(POS)やECの顧客情報の取得・統合・ 分析・活用まで、ワンストップで提供。 PRODUCTS
導入事例 STORES さんがやってくれればいいのに、とずっと思ってたと ころに提案がきました。 ネットショップのSTORESを始めたときと同じで、思った通り の機能が思ったところにある。 初めて触る人でもすぐに使え、 かんたんに操作できる STORES レジ
STORES のネットショップに登録していた商品がそのままダイレク トにレジの商品一覧に反映されるので、全くストレスなく始められ てよかったですね。基本的に操作で迷うことはないです。アルバイ トの人が初日に触っても全然問題ないですし、ヘルプで来た奥さん もすぐに使えていたので不安はないです。 ── クリエイティブユニットTENT 治田さま 青木さま 導入事例の詳細はこちら: https://officialmag.stores.jp/entry/ineterview-regi-tentnotempo
導入事例 STORES 予約 で日程調整などの負担が削減! 農作業をしながらもお店との両立が可能 インスタのDMのやりとりで、(焙煎体験会の)予約を受け付けることは できますが、畑の仕事もあるので、すぐ確認することができません。ま た、定型文を用意していないので、打つのが大変です。 STORES 予約
を導入したことで、こちらが対応可能な日時を掲示でき、そ こに入れてもらえます。こちらの都合を考慮できるので、お店を経営する というハードルを下げ、心にゆとりを持つことができました ── ほうじ茶作り体験/販売 たつみ茶園 巽さま 導入事例の詳細はこちら: https://officialmag.stores.jp/entry/interview-reserve-tatsumi-teagarden 予約するお客さま側の立場から STORES 予約 を利用して、自分 のお店に落とし込んだときのイメージをすることができた STORES (EC)を使ってオンラインでも緑茶、ほうじ茶、和紅 茶を販売。
導入事例 Webで予約できることで、電話の混雑も少なく受付開始初日が 無事終わりました。 すぐに予約システムが作れ機能も十分。しかも無料で利用がで きるということで、これはいいとすぐに導入が決定しました。 無料お試しをしてみると、 簡単にすぐに予約を受け付けることができました。 予約システムを検討する際、そもそも予約システムがどのようなものかがわ からなかったため、無料体験できる予約システムを探していました。 1社目は無料体験がうまくいきませんでした。2社目が
STORES 予約 だった のですが、無料体験で予約システムを実際に作って操作してみたところ、素 人の私でも1日もかからないうちにすぐに予約システムが作れてしまい、これ ならワクチン接種予約受付にも対応できると思いました。 ── 北海道 上川町役場 情報防災室 室長 久保さま 導入事例の詳細はこちら: https://officialmag.stores.jp/entry/hokkaido-kamikawa
今日の話:SaaSを作るという仕事について 17 SaaS、つまり、ソフトウェアをサービスとして提供する、という産業はすっか り世界に定着し、もはや人類に必須の存在となりつつあります。また、ソフト ウェア・エンジニアのキャリアとしてもポピュラーなものになりました。私が 働いているSTORESでも広義のSaaSを提供しています。さて、このSaaSを作る こと、また作り続けること(これがキーになるのですが、くわしくは本編で) には、ソフトウェア開発としてどのような特性があり、何が重要なのでしょう か。ここ15年ほど(広義の)SaaSの開発に携わってきた私の知見を有用かつ楽 しい形でまとめてみようと思います。
e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について
商用ソフトウェアの歴史 19 https://www.flickr.com/photos/salesforce/6221128033/in/photostream/
商用ソフトウェアの歴史:パッケージの時代 20 2000年くらいまでは、ソフトウェアは記憶媒体に入れられて、物理的なパッ ケージで販売されていた。これをインストールして使っていた Windows 95(1995) Microsoft Office XP(2000)
商用ソフトウェアの歴史:Software as a Service(SaaS)の登場 21 2000年代から、インターネット経由でソフトウェアが「サービス」として提供 されるようになる。ブラウザ経由で使えるようになった Salesforce(1999) GMail(2004)
商用ソフトウェアの歴史:Software as a Service(SaaS)の普及 22 2024年のいま、SaaSはどこにでもあるあたりまえの存在になっている STORESで利用しているB2B SaaSのごく一部 藤村のiPhone
SaaSの作り方 23
SaaSの作り方:STORESで使われているテクノロジー お店のキャッシュレス オンライン予約システム POSレジ 店舗アプリ作成 ネットショップ開設・運営
SaaSの作り方:WEB+DB 25 - World Wide Web、インターネット - データベース - ブラウザで動くアプリケーション(フロントエンド)
- モバイルアプリケーション(iOS, Android) - クラウドインフラ
SaaSの作り方:WEB+DB 26
SaaSという事業 27 https://www.t2d3.pro/learn/the-5-factors-of-a-b2b-saas-go-to-market-strategy-for-t2d3-growth
(ものすごく簡略化した)SaaSという事業の仕組み 28 例:月額1万円の歯医者向け予約管理システムを運営していて2000アカウントだと、10000円 × 12ヶ月 × 2000アカウント = 2億4000万が年間の収益となる ※
本当はChurn Rateなどを加えてもっと分解して測りますが、今回はわかりやすさのために簡略化して います 年間の収益 = アカウントあたりの平均収益 × アカウント数
例: 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し (ものすごく簡略化した)SaaSという事業の伸ばし方
29 指標 どう増やす? アカウントあたりの平均収益 1: より多くの機能を使ってもらう アカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる
例: 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し (ものすごく簡略化した)SaaSという事業の伸ばすためにやること
30 指標 どう増やす? 何をする? アカウントあたりの平均収益 1: より多くの機能を使ってもらう 機能を増やす アカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる 機能を増やす
- 歴史と現在 - SaaSは当たり前の存在になった - 技術 - WEB+DB - 事業の構造
- アカウントあたりの平均収益 × アカウント数 - 事業の伸ばし方 - アカウントあたりの平均収益 - 機能を増やす - アカウント数 - 機能を増やす 今までのまとめ 31
SaaSを作るという仕事について 32 プラトン
SaaSを作るという仕事について 33 パッケージ SaaS コードベース 毎回変わる 同じ リリース 数年に一度 継続的
機能 増えない 増える 使い方 変わらない 変わる パッケージソフトウェアとの違いでわかることが多いので、この対比から考えていきます
• インターネット越しにソフトウェアの「利用」を提供するのがSaaS • 一つのコードベースで新たに機能を追加し、既存機能を拡張し続ける • 性質上、長期戦になる • 保守性の高いコードは事業成長にとって強力な武器になる SaaSを作るという仕事について:同じコードベースで仕事をすることになる 34
• エンジニアがもっている事業成長の最大のレバーは新機能のリリース • 作ったものをいかに高速・高頻度に安定してリリースしユーザーに届けるか、が重要 ◦ Googleの提唱しているFour Keysはまさにそれ SaaSを作るという仕事について:新機能のリリースが成長のレバーになる 35 DevOps
Research and Assessment(DORA)チームが実施した 6 年間の研究から、ソフ トウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 • 変更のリードタイム - commit から本番環境稼働までの所要時間 • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%) • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
• 会社の経営をとりまく状況は変化する ◦ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普 及、などなど SaaSを作るという仕事について:使い方が変わる 36
• 会社の経営をとりまく状況は変化する ◦ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普 及、などなど • しかし、SaaSにおいて扱うコードベースは同じ ◦ すべて書き直せる、ということはなく、いまここにあるコードベースを資産として事 業を作っていくことになる
• 非常に難しい仕事だが、予想しない変化に耐えるコードベースが必要 ◦ 変化に耐えるコードベースは強力な資産になる ◦ そのために何が大切なのか?設計で考えるべきことは? SaaSを作るという仕事について:使い方が変わる 37
None
普遍
• SaaSは汎用システム ◦ お店によって「注文」や「在庫」、「商品」のあり方は違うかもしれない ◦ しかし、例えばSTORESは一種類の注文・在庫・商品のシステムを提供していて、それ ぞれのお店でちゃんと使えている ◦ STORESを利用しているお店に限って言えば、「普遍」に近い注文・在庫・商品を実装 した、とも言えるのかもしれない
SaaSを作るという仕事について:「普遍」を実装する 40
• SaaSの設計は長期的には一般化される ◦ 企業は基本的には拡大を目指す ◦ SaaSの提供する価値は業務の代替。成長すると用途や対象ユーザーが広がるので、カ バーする業務の範囲や業界が広がる。つまり、適用範囲が広く、一般的な設計が求め られる ▪ たとえばいまのSTORESの「予約」はレストランの予約や航空券の予約では使い
づらい • 目指すべきは普遍的な設計 ◦ 普遍を目指す。用途や外部環境が変わっても、普遍は変わらない ▪ 「予約」のコア、本当に世界で予約と呼ばれているものに共通しているものを、 正しく実装したい SaaSを作るという仕事について:「普遍」を目指す 41
SaaSを作るという仕事について:STORESにおける普遍探しの実例 42
SaaSを作るという仕事について:STORESにおける普遍探しの実例 43
SaaSを作るという仕事について:STORESにおける普遍探しの実例 44
SaaSを作るという仕事について:STORESにおける普遍探しの実例 45
SaaSを作るという仕事について:STORESにおける普遍探しの実例 46
• 再掲:目指すべきは普遍的な設計 ◦ 普遍を目指す。普遍は変わらない。普遍に近ければ近いほど個別化は容易。結果的に 拡張性もある • 具体的にやること ◦ 常に普遍を目指してAPIやデータベースの設計をする。普遍的な設計にするための努力 を不断に行い、そのためのトレードオフを受け入れるための技術的な工夫と努力を惜
しまない ◦ 逆に言うと、個別のケースや現状だけから設計しない。いまの「ユーザー」の設計 は、5年後も「ユーザー」たりうるか?徹底的に(時間の制約のなかで)考える • もっと具体的なTips ◦ そのものを正しく指し示す(普遍に近づける)正確な語彙を選ぶ SaaSを作るという仕事について:普遍を目指してやること 47
普遍のための理論は哲学が専門とする領域。たとえば下記のリストは特定の理論の出来を評価す るにあたっての基準ですが、ソフトウェアの設計でもとても役に立ちます。 • 正確性:主題とする現象や対象に関するデータと合致する度合い • 単純性:基本的な仮定や必要な道具立ての少なさ • 包括性:扱える現象や対象の範囲の広さ • 整合性:理論の内部で矛盾がないこと、また理論の外部で既に確立されている知見や理論と衝突し
ないこと • 一貫性・前進性:理論の修正が場当たり的でないこと、そして問題解決を通じて実質のある新たな 進展が見られること 植原亮『自然主義入門』p. 256 より。ちなみに元ネタは『ワードマップ 現代形而上学』で、更にその元ネタはクーンとのこと 普遍そのものに興味がある方は中世哲学の入門書を読むのがおすすめ。私が最近読んだものだ SaaSを作るという仕事について:普遍のためのヒント 48
SaaSを作るという仕事について:まとめ 49 パッケージ SaaS SaaSでやること コードベース 毎回変わる 同じ 保守性の高いコードを書く リリース
数年に一度 継続的 速く高頻度にリリースする 機能 増えない 増える 普遍を目指して設計する 使い方 変わらない 変わる 普遍を目指して設計する
SaaSを作るという仕事について:メッセージ 50 限られた時間の中で「普遍」を目指して設計し、品質の高いコードを書き、頻繁にリリースす る。このあまりに難しいゲームを解くことが、使ってくださっている方々の仕事を支え、自分の やっている会社の事業を成長させる、というSaaSの開発は、非常にやりがいのある仕事です。常 にベストのものが作れるわけではないですし、失敗もありますが、少しづつうまくできるように なっている実感と、うまくいったときの爽快感と静かな興奮は格別です。 未経験の方は、ぜひいつかこの喜びを体験してもらえると嬉しいです。ソフトウェア・エンジニ アとしての喜びが詰まった仕事だと思います。同業者のみなさんはこれからも一緒に良いコード 書けるように頑張っていきましょう!
おわり 51 普遍の存在を全否定した哲学者、オッカム