SaaSを作るという仕事について

by Fujimura Daisuke

Slide 1

Slide 1 text

e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について

Slide 2

Slide 2 text

自己紹介 - お仕事 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/ﬀu_ github.com/fujimura note.com/fujimuradaisuke

Slide 3

Slide 3 text

自己紹介 - 書いたり発表したもの 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

Slide 4

Slide 4 text

自己紹介 - ポッドキャスト 4 論より動くもの.fm 藤村がホストになって、技術や技術にまつわることについてざっくばらんに話す Podcast です。文字起こしもあるよ！論より動くもの.fm カテゴリーの記事一覧 - STORES Product Blog

Slide 5

Slide 5 text

自己紹介 - 作品 5 Haskellのプロジェクト生成ツール $ bundle gem みたいなやつ。当時いいツールがなかったので作った git-grepの結果で置換とリネーム $ git grep | xargs sed -i s/foo/bar/ が面倒なので作った rspec-railsのHaskell版 RackやWSGIにあたる層をテストするためのヘルパー。無かったので作った

Slide 6

Slide 6 text

STORES.inc

Slide 7

Slide 7 text

STORES のミッションこだわりや情熱、たのしみに駆動される経済をつくる熱中しているひとたちから生み出される、多様な商品やサービスが街に溢れる世界。その経済を支える、デジタルインフラを提供する。

Slide 8

Slide 8 text

STORESのプロダクトお店のデジタル化を支援する、5つのプロダクト。ネットショップ開設・運営お店のキャッシュレスオンライン予約システム POSレジ店舗アプリ作成

Slide 9

Slide 9 text

自分でつくれる、本格的なネットショップむずかしい知識や技術いらずで自分だけのネットショップをかんたんに。 PRODUCTS

Slide 10

Slide 10 text

ネットショップとひとつになった新しいPOSレジアプリネットショップとお店の商品・在庫・売上データをまるっと管理。 PRODUCTS

Slide 11

Slide 11 text

お店のキャッシュレスをかんたんにクレジットカード決済も、電子マネー決済も、 QR決済も、これひとつで。 PRODUCTS

Slide 12

Slide 12 text

予約・顧客管理が柔軟に。決済も、これひとつで。ガイドに沿って設定するだけで、あっという間に専用の予約サイトを作成。 PRODUCTS

Slide 13

Slide 13 text

店舗とECをつなぐアプリ開発店舗（POS）やECの顧客情報の取得・統合・分析・活用まで、ワンストップで提供。 PRODUCTS

Slide 14

Slide 14 text

導入事例 STORES さんがやってくれればいいのに、とずっと思ってたところに提案がきました。ネットショップのSTORESを始めたときと同じで、思った通りの機能が思ったところにある。初めて触る人でもすぐに使え、かんたんに操作できる STORES レジ STORES のネットショップに登録していた商品がそのままダイレクトにレジの商品一覧に反映されるので、全くストレスなく始められてよかったですね。基本的に操作で迷うことはないです。アルバイトの人が初日に触っても全然問題ないですし、ヘルプで来た奥さんもすぐに使えていたので不安はないです。 ── クリエイティブユニットTENT 治田さま青木さま導入事例の詳細はこちら： https://oﬃcialmag.stores.jp/entry/ineterview-regi-tentnotempo

Slide 15

Slide 15 text

導入事例 STORES 予約で日程調整などの負担が削減！農作業をしながらもお店との両立が可能インスタのDMのやりとりで、（焙煎体験会の）予約を受け付けることはできますが、畑の仕事もあるので、すぐ確認することができません。また、定型文を用意していないので、打つのが大変です。 STORES 予約を導入したことで、こちらが対応可能な日時を掲示でき、そこに入れてもらえます。こちらの都合を考慮できるので、お店を経営するというハードルを下げ、心にゆとりを持つことができました ── ほうじ茶作り体験/販売たつみ茶園巽さま導入事例の詳細はこちら： https://oﬃcialmag.stores.jp/entry/interview-reserve-tatsumi-teagarden 予約するお客さま側の立場から STORES 予約を利用して、自分のお店に落とし込んだときのイメージをすることができた STORES （EC）を使ってオンラインでも緑茶、ほうじ茶、和紅茶を販売。

Slide 16

Slide 16 text

導入事例 Webで予約できることで、電話の混雑も少なく受付開始初日が無事終わりました。すぐに予約システムが作れ機能も十分。しかも無料で利用ができるということで、これはいいとすぐに導入が決定しました。無料お試しをしてみると、簡単にすぐに予約を受け付けることができました。予約システムを検討する際、そもそも予約システムがどのようなものかがわからなかったため、無料体験できる予約システムを探していました。 1社目は無料体験がうまくいきませんでした。2社目が STORES 予約だったのですが、無料体験で予約システムを実際に作って操作してみたところ、素人の私でも1日もかからないうちにすぐに予約システムが作れてしまい、これならワクチン接種予約受付にも対応できると思いました。 ── 北海道上川町役場情報防災室室長久保さま導入事例の詳細はこちら： https://oﬃcialmag.stores.jp/entry/hokkaido-kamikawa

Slide 17

Slide 17 text

今日の話：SaaSを作るという仕事について 17 SaaS、つまり、ソフトウェアをサービスとして提供する、という産業はすっかり世界に定着し、もはや人類に必須の存在となりつつあります。また、ソフトウェア・エンジニアのキャリアとしてもポピュラーなものになりました。私が働いているSTORESでも広義のSaaSを提供しています。さて、このSaaSを作ること、また作り続けること（これがキーになるのですが、くわしくは本編で）には、ソフトウェア開発としてどのような特性があり、何が重要なのでしょうか。ここ15年ほど（広義の）SaaSの開発に携わってきた私の知見を有用かつ楽しい形でまとめてみようと思います。

Slide 18

Slide 18 text

e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について

Slide 19

Slide 19 text

商用ソフトウェアの歴史 19 https://www.ﬂickr.com/photos/salesforce/6221128033/in/photostream/

Slide 20

Slide 20 text

商用ソフトウェアの歴史：パッケージの時代 20 2000年くらいまでは、ソフトウェアは記憶媒体に入れられて、物理的なパッケージで販売されていた。これをインストールして使っていた Windows 95(1995) Microsoft Oﬃce XP(2000)

Slide 21

Slide 21 text

商用ソフトウェアの歴史：Software as a Service（SaaS）の登場 21 2000年代から、インターネット経由でソフトウェアが「サービス」として提供されるようになる。ブラウザ経由で使えるようになった Salesforce(1999) GMail(2004)

Slide 22

Slide 22 text

商用ソフトウェアの歴史：Software as a Service（SaaS）の普及 22 2024年のいま、SaaSはどこにでもあるあたりまえの存在になっている STORESで利用しているB2B SaaSのごく一部藤村のiPhone

Slide 23

Slide 23 text

SaaSの作り方 23

Slide 24

Slide 24 text

SaaSの作り方：STORESで使われているテクノロジーお店のキャッシュレスオンライン予約システム POSレジ店舗アプリ作成ネットショップ開設・運営

Slide 25

Slide 25 text

SaaSの作り方：WEB+DB 25 - World Wide Web、インターネット - データベース - ブラウザで動くアプリケーション（フロントエンド） - モバイルアプリケーション（iOS, Android） - クラウドインフラ

Slide 26

Slide 26 text

SaaSの作り方：WEB+DB 26

Slide 27

Slide 27 text

SaaSという事業 27 https://www.t2d3.pro/learn/the-5-factors-of-a-b2b-saas-go-to-market-strategy-for-t2d3-growth

Slide 28

Slide 28 text

（ものすごく簡略化した）SaaSという事業の仕組み 28 例：月額1万円の歯医者向け予約管理システムを運営していて2000アカウントだと、10000円 × 12ヶ月 × 2000アカウント = 2億4000万が年間の収益となる ※ 本当はChurn Rateなどを加えてもっと分解して測りますが、今回はわかりやすさのために簡略化しています年間の収益 = アカウントあたりの平均収益 × アカウント数

Slide 29

Slide 29 text

例： 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し（ものすごく簡略化した）SaaSという事業の伸ばし方 29 指標どう増やす？アカウントあたりの平均収益 1: より多くの機能を使ってもらうアカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる

Slide 30

Slide 30 text

例： 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し（ものすごく簡略化した）SaaSという事業の伸ばすためにやること 30 指標どう増やす？何をする？アカウントあたりの平均収益 1: より多くの機能を使ってもらう機能を増やすアカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる機能を増やす

Slide 31

Slide 31 text

- 歴史と現在 - SaaSは当たり前の存在になった - 技術 - WEB+DB - 事業の構造 - アカウントあたりの平均収益 × アカウント数 - 事業の伸ばし方 - アカウントあたりの平均収益 - 機能を増やす - アカウント数 - 機能を増やす今までのまとめ 31

Slide 32

Slide 32 text

SaaSを作るという仕事について 32 プラトン

Slide 33

Slide 33 text

SaaSを作るという仕事について 33 パッケージ SaaS コードベース毎回変わる同じリリース数年に一度継続的機能増えない増える使い方変わらない変わるパッケージソフトウェアとの違いでわかることが多いので、この対比から考えていきます

Slide 34

Slide 34 text

● インターネット越しにソフトウェアの「利用」を提供するのがSaaS ● 一つのコードベースで新たに機能を追加し、既存機能を拡張し続ける ● 性質上、長期戦になる ● 保守性の高いコードは事業成長にとって強力な武器になる SaaSを作るという仕事について：同じコードベースで仕事をすることになる 34

Slide 35

Slide 35 text

● エンジニアがもっている事業成長の最大のレバーは新機能のリリース ● 作ったものをいかに高速・高頻度に安定してリリースしユーザーに届けるか、が重要 ○ 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

Slide 36

Slide 36 text

● 会社の経営をとりまく状況は変化する ○ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普及、などなど SaaSを作るという仕事について：使い方が変わる 36

Slide 37

Slide 37 text

● 会社の経営をとりまく状況は変化する ○ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普及、などなど ● しかし、SaaSにおいて扱うコードベースは同じ ○ すべて書き直せる、ということはなく、いまここにあるコードベースを資産として事業を作っていくことになる ● 非常に難しい仕事だが、予想しない変化に耐えるコードベースが必要 ○ 変化に耐えるコードベースは強力な資産になる ○ そのために何が大切なのか？設計で考えるべきことは？ SaaSを作るという仕事について：使い方が変わる 37

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

普遍

Slide 40

Slide 40 text

● SaaSは汎用システム ○ お店によって「注文」や「在庫」、「商品」のあり方は違うかもしれない ○ しかし、例えばSTORESは一種類の注文・在庫・商品のシステムを提供していて、それぞれのお店でちゃんと使えている ○ STORESを利用しているお店に限って言えば、「普遍」に近い注文・在庫・商品を実装した、とも言えるのかもしれない SaaSを作るという仕事について：「普遍」を実装する 40

Slide 41

Slide 41 text

● SaaSの設計は長期的には一般化される ○ 企業は基本的には拡大を目指す ○ SaaSの提供する価値は業務の代替。成長すると用途や対象ユーザーが広がるので、カバーする業務の範囲や業界が広がる。つまり、適用範囲が広く、一般的な設計が求められる ■ たとえばいまのSTORESの「予約」はレストランの予約や航空券の予約では使いづらい ● 目指すべきは普遍的な設計 ○ 普遍を目指す。用途や外部環境が変わっても、普遍は変わらない ■ 「予約」のコア、本当に世界で予約と呼ばれているものに共通しているものを、正しく実装したい SaaSを作るという仕事について：「普遍」を目指す 41

Slide 42

Slide 42 text

SaaSを作るという仕事について：STORESにおける普遍探しの実例 42

Slide 43

Slide 43 text

SaaSを作るという仕事について：STORESにおける普遍探しの実例 43

Slide 44

Slide 44 text

SaaSを作るという仕事について：STORESにおける普遍探しの実例 44

Slide 45

Slide 45 text

SaaSを作るという仕事について：STORESにおける普遍探しの実例 45

Slide 46

Slide 46 text

SaaSを作るという仕事について：STORESにおける普遍探しの実例 46

Slide 47

Slide 47 text

● 再掲：目指すべきは普遍的な設計 ○ 普遍を目指す。普遍は変わらない。普遍に近ければ近いほど個別化は容易。結果的に拡張性もある ● 具体的にやること ○ 常に普遍を目指してAPIやデータベースの設計をする。普遍的な設計にするための努力を不断に行い、そのためのトレードオフを受け入れるための技術的な工夫と努力を惜しまない ○ 逆に言うと、個別のケースや現状だけから設計しない。いまの「ユーザー」の設計は、5年後も「ユーザー」たりうるか？徹底的に（時間の制約のなかで）考える ● もっと具体的なTips ○ そのものを正しく指し示す（普遍に近づける）正確な語彙を選ぶ SaaSを作るという仕事について：普遍を目指してやること 47

Slide 48

Slide 48 text

普遍のための理論は哲学が専門とする領域。たとえば下記のリストは特定の理論の出来を評価するにあたっての基準ですが、ソフトウェアの設計でもとても役に立ちます。 ● 正確性：主題とする現象や対象に関するデータと合致する度合い ● 単純性：基本的な仮定や必要な道具立ての少なさ ● 包括性：扱える現象や対象の範囲の広さ ● 整合性：理論の内部で矛盾がないこと、また理論の外部で既に確立されている知見や理論と衝突しないこと ● 一貫性・前進性：理論の修正が場当たり的でないこと、そして問題解決を通じて実質のある新たな進展が見られること植原亮『自然主義入門』p. 256 より。ちなみに元ネタは『ワードマップ現代形而上学』で、更にその元ネタはクーンとのこと普遍そのものに興味がある方は中世哲学の入門書を読むのがおすすめ。私が最近読んだものだ SaaSを作るという仕事について：普遍のためのヒント 48

Slide 49

Slide 49 text

SaaSを作るという仕事について：まとめ 49 パッケージ SaaS SaaSでやることコードベース毎回変わる同じ保守性の高いコードを書くリリース数年に一度継続的速く高頻度にリリースする機能増えない増える普遍を目指して設計する使い方変わらない変わる普遍を目指して設計する

Slide 50

Slide 50 text

SaaSを作るという仕事について：メッセージ 50 限られた時間の中で「普遍」を目指して設計し、品質の高いコードを書き、頻繁にリリースする。このあまりに難しいゲームを解くことが、使ってくださっている方々の仕事を支え、自分のやっている会社の事業を成長させる、というSaaSの開発は、非常にやりがいのある仕事です。常にベストのものが作れるわけではないですし、失敗もありますが、少しづつうまくできるようになっている実感と、うまくいったときの爽快感と静かな興奮は格別です。未経験の方は、ぜひいつかこの喜びを体験してもらえると嬉しいです。ソフトウェア・エンジニアとしての喜びが詰まった仕事だと思います。同業者のみなさんはこれからも一緒に良いコード書けるように頑張っていきましょう！

Slide 51

Slide 51 text

おわり 51 普遍の存在を全否定した哲学者、オッカム