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

Transcript

1. e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について
2. 自己紹介 - お仕事 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. 自己紹介 - 書いたり発表したもの 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. 自己紹介 - ポッドキャスト 4 論より動くもの.fm 藤村がホストになって、技術や技術にまつわることについてざっくばらんに話す Podcast です。 文字起こしもあるよ！ 論より動くもの.fm カテゴリーの記事一覧 - STORES Product Blog
5. 自己紹介 - 作品 5 Haskellのプロジェクト生 成ツール $ bundle gem みたいな やつ。当時いいツールが なかったので作った git-grepの結果で置換と リネーム $ git grep | xargs sed -i s/foo/bar/ が 面倒なので作った rspec-railsのHaskell版 RackやWSGIにあたる層 をテストするためのヘル パー。無かったので作っ た
6. STORES.inc
7. STORES のミッション こだわりや情熱、たのしみに駆動される経済をつくる 熱中しているひとたちから生み出される、 多様な商品やサービスが街に溢れる世界。 その経済を支える、デジタルインフラを提供する。
8. STORESのプロダクト お店のデジタル化を支援する、5つのプロダクト。 ネットショップ開設・運営 お店のキャッシュレス オンライン予約システム POSレジ 店舗アプリ作成
9. 自分でつくれる、 本格的なネットショップ むずかしい知識や技術いらずで 自分だけのネットショップをかんたん に。 PRODUCTS
10. ネットショップとひとつに なった新しいPOSレジアプリ ネットショップとお店の 商品・在庫・売上データをまるっと管 理。 PRODUCTS
11. お店のキャッシュレスを かんたんに クレジットカード決済も、電子マネー決 済も、 QR決済も、これひとつで。 PRODUCTS
12. 予約・顧客管理が柔軟に。 決済も、これひとつで。 ガイドに沿って設定するだけで、 あっという間に専用の予約サイトを作 成。 PRODUCTS
13. 店舗とECをつなぐ アプリ開発 店舗（POS）やECの顧客情報の取得・統合・ 分析・活用まで、ワンストップで提供。 PRODUCTS
14. 導入事例 STORES さんがやってくれればいいのに、とずっと思ってたと ころに提案がきました。 ネットショップのSTORESを始めたときと同じで、思った通り の機能が思ったところにある。 初めて触る人でもすぐに使え、 かんたんに操作できる STORES レジ STORES のネットショップに登録していた商品がそのままダイレク トにレジの商品一覧に反映されるので、全くストレスなく始められ てよかったですね。基本的に操作で迷うことはないです。アルバイ トの人が初日に触っても全然問題ないですし、ヘルプで来た奥さん もすぐに使えていたので不安はないです。 ── クリエイティブユニットTENT 治田さま 青木さま 導入事例の詳細はこちら： https://officialmag.stores.jp/entry/ineterview-regi-tentnotempo
15. 導入事例 STORES 予約 で日程調整などの負担が削減！ 農作業をしながらもお店との両立が可能 インスタのDMのやりとりで、（焙煎体験会の）予約を受け付けることは できますが、畑の仕事もあるので、すぐ確認することができません。ま た、定型文を用意していないので、打つのが大変です。 STORES 予約 を導入したことで、こちらが対応可能な日時を掲示でき、そ こに入れてもらえます。こちらの都合を考慮できるので、お店を経営する というハードルを下げ、心にゆとりを持つことができました ── ほうじ茶作り体験/販売 たつみ茶園 巽さま 導入事例の詳細はこちら： https://officialmag.stores.jp/entry/interview-reserve-tatsumi-teagarden 予約するお客さま側の立場から STORES 予約 を利用して、自分 のお店に落とし込んだときのイメージをすることができた STORES （EC）を使ってオンラインでも緑茶、ほうじ茶、和紅 茶を販売。
16. 導入事例 Webで予約できることで、電話の混雑も少なく受付開始初日が 無事終わりました。 すぐに予約システムが作れ機能も十分。しかも無料で利用がで きるということで、これはいいとすぐに導入が決定しました。 無料お試しをしてみると、 簡単にすぐに予約を受け付けることができました。 予約システムを検討する際、そもそも予約システムがどのようなものかがわ からなかったため、無料体験できる予約システムを探していました。 1社目は無料体験がうまくいきませんでした。2社目が STORES 予約 だった のですが、無料体験で予約システムを実際に作って操作してみたところ、素 人の私でも1日もかからないうちにすぐに予約システムが作れてしまい、これ ならワクチン接種予約受付にも対応できると思いました。 ── 北海道 上川町役場 情報防災室 室長 久保さま 導入事例の詳細はこちら： https://officialmag.stores.jp/entry/hokkaido-kamikawa
17. 今日の話：SaaSを作るという仕事について 17 SaaS、つまり、ソフトウェアをサービスとして提供する、という産業はすっか り世界に定着し、もはや人類に必須の存在となりつつあります。また、ソフト ウェア・エンジニアのキャリアとしてもポピュラーなものになりました。私が 働いているSTORESでも広義のSaaSを提供しています。さて、このSaaSを作る こと、また作り続けること（これがキーになるのですが、くわしくは本編で） には、ソフトウェア開発としてどのような特性があり、何が重要なのでしょう か。ここ15年ほど（広義の）SaaSの開発に携わってきた私の知見を有用かつ楽 しい形でまとめてみようと思います。
18. e-ZUKA Tech Night vol.62 2024-05-21 STORES 株式会社 CTO 藤村大介 SaaSを作るという仕事について
19. 商用ソフトウェアの歴史 19 https://www.flickr.com/photos/salesforce/6221128033/in/photostream/
20. 商用ソフトウェアの歴史：パッケージの時代 20 2000年くらいまでは、ソフトウェアは記憶媒体に入れられて、物理的なパッ ケージで販売されていた。これをインストールして使っていた Windows 95(1995) Microsoft Office XP(2000)
21. 商用ソフトウェアの歴史：Software as a Service（SaaS）の登場 21 2000年代から、インターネット経由でソフトウェアが「サービス」として提供 されるようになる。ブラウザ経由で使えるようになった Salesforce(1999) GMail(2004)
22. 商用ソフトウェアの歴史：Software as a Service（SaaS）の普及 22 2024年のいま、SaaSはどこにでもあるあたりまえの存在になっている STORESで利用しているB2B SaaSのごく一部 藤村のiPhone
23. SaaSの作り方 23
24. SaaSの作り方：STORESで使われているテクノロジー お店のキャッシュレス オンライン予約システム POSレジ 店舗アプリ作成 ネットショップ開設・運営
25. SaaSの作り方：WEB+DB 25 - World Wide Web、インターネット - データベース - ブラウザで動くアプリケーション（フロントエンド） - モバイルアプリケーション（iOS, Android） - クラウドインフラ
26. SaaSの作り方：WEB+DB 26
27. SaaSという事業 27 https://www.t2d3.pro/learn/the-5-factors-of-a-b2b-saas-go-to-market-strategy-for-t2d3-growth
28. （ものすごく簡略化した）SaaSという事業の仕組み 28 例：月額1万円の歯医者向け予約管理システムを運営していて2000アカウントだと、10000円 × 12ヶ月 × 2000アカウント = 2億4000万が年間の収益となる ※ 本当はChurn Rateなどを加えてもっと分解して測りますが、今回はわかりやすさのために簡略化して います 年間の収益 = アカウントあたりの平均収益 × アカウント数
29. 例： 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し （ものすごく簡略化した）SaaSという事業の伸ばし方 29 指標 どう増やす？ アカウントあたりの平均収益 1: より多くの機能を使ってもらう アカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる
30. 例： 1. 歯医者向け予約管理システムに従業員のシフト管理機能を追加、オプション料金をいただく 2. もっと多くの歯医者さんに使ってもらえるよう、不足している機能を追加する 3. 美容室でも使えるように全体を改修、不足している機能を追加する ※ 本当は営業やマーケティングなどたくさんの要素が関係していますが、わかりやすさのために簡略化し （ものすごく簡略化した）SaaSという事業の伸ばすためにやること 30 指標 どう増やす？ 何をする？ アカウントあたりの平均収益 1: より多くの機能を使ってもらう 機能を増やす アカウント数 2: より多くのユーザーに使ってもらう 3: ターゲットユーザーの層を広げる 機能を増やす
31. - 歴史と現在 - SaaSは当たり前の存在になった - 技術 - WEB+DB - 事業の構造 - アカウントあたりの平均収益 × アカウント数 - 事業の伸ばし方 - アカウントあたりの平均収益 - 機能を増やす - アカウント数 - 機能を増やす 今までのまとめ 31
32. SaaSを作るという仕事について 32 プラトン
33. SaaSを作るという仕事について 33 パッケージ SaaS コードベース 毎回変わる 同じ リリース 数年に一度 継続的 機能 増えない 増える 使い方 変わらない 変わる パッケージソフトウェアとの違いでわかることが多いので、この対比から考えていきます
34. • インターネット越しにソフトウェアの「利用」を提供するのがSaaS • 一つのコードベースで新たに機能を追加し、既存機能を拡張し続ける • 性質上、長期戦になる • 保守性の高いコードは事業成長にとって強力な武器になる SaaSを作るという仕事について：同じコードベースで仕事をすることになる 34
35. • エンジニアがもっている事業成長の最大のレバーは新機能のリリース • 作ったものをいかに高速・高頻度に安定してリリースしユーザーに届けるか、が重要 ◦ 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
36. • 会社の経営をとりまく状況は変化する ◦ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普 及、などなど SaaSを作るという仕事について：使い方が変わる 36
37. • 会社の経営をとりまく状況は変化する ◦ 事業規模の拡大、M&Aによるサービスの追加、COVID-19でEコマースが急速に普 及、などなど • しかし、SaaSにおいて扱うコードベースは同じ ◦ すべて書き直せる、ということはなく、いまここにあるコードベースを資産として事 業を作っていくことになる • 非常に難しい仕事だが、予想しない変化に耐えるコードベースが必要 ◦ 変化に耐えるコードベースは強力な資産になる ◦ そのために何が大切なのか？設計で考えるべきことは？ SaaSを作るという仕事について：使い方が変わる 37
39. 普遍
40. • SaaSは汎用システム ◦ お店によって「注文」や「在庫」、「商品」のあり方は違うかもしれない ◦ しかし、例えばSTORESは一種類の注文・在庫・商品のシステムを提供していて、それ ぞれのお店でちゃんと使えている ◦ STORESを利用しているお店に限って言えば、「普遍」に近い注文・在庫・商品を実装 した、とも言えるのかもしれない SaaSを作るという仕事について：「普遍」を実装する 40
41. • SaaSの設計は長期的には一般化される ◦ 企業は基本的には拡大を目指す ◦ SaaSの提供する価値は業務の代替。成長すると用途や対象ユーザーが広がるので、カ バーする業務の範囲や業界が広がる。つまり、適用範囲が広く、一般的な設計が求め られる ▪ たとえばいまのSTORESの「予約」はレストランの予約や航空券の予約では使い づらい • 目指すべきは普遍的な設計 ◦ 普遍を目指す。用途や外部環境が変わっても、普遍は変わらない ▪ 「予約」のコア、本当に世界で予約と呼ばれているものに共通しているものを、 正しく実装したい SaaSを作るという仕事について：「普遍」を目指す 41
42. SaaSを作るという仕事について：STORESにおける普遍探しの実例 42
43. SaaSを作るという仕事について：STORESにおける普遍探しの実例 43
44. SaaSを作るという仕事について：STORESにおける普遍探しの実例 44
45. SaaSを作るという仕事について：STORESにおける普遍探しの実例 45
46. SaaSを作るという仕事について：STORESにおける普遍探しの実例 46
47. • 再掲：目指すべきは普遍的な設計 ◦ 普遍を目指す。普遍は変わらない。普遍に近ければ近いほど個別化は容易。結果的に 拡張性もある • 具体的にやること ◦ 常に普遍を目指してAPIやデータベースの設計をする。普遍的な設計にするための努力 を不断に行い、そのためのトレードオフを受け入れるための技術的な工夫と努力を惜 しまない ◦ 逆に言うと、個別のケースや現状だけから設計しない。いまの「ユーザー」の設計 は、5年後も「ユーザー」たりうるか？徹底的に（時間の制約のなかで）考える • もっと具体的なTips ◦ そのものを正しく指し示す（普遍に近づける）正確な語彙を選ぶ SaaSを作るという仕事について：普遍を目指してやること 47
48. 普遍のための理論は哲学が専門とする領域。たとえば下記のリストは特定の理論の出来を評価す るにあたっての基準ですが、ソフトウェアの設計でもとても役に立ちます。 • 正確性：主題とする現象や対象に関するデータと合致する度合い • 単純性：基本的な仮定や必要な道具立ての少なさ • 包括性：扱える現象や対象の範囲の広さ • 整合性：理論の内部で矛盾がないこと、また理論の外部で既に確立されている知見や理論と衝突し ないこと • 一貫性・前進性：理論の修正が場当たり的でないこと、そして問題解決を通じて実質のある新たな 進展が見られること 植原亮『自然主義入門』p. 256 より。ちなみに元ネタは『ワードマップ 現代形而上学』で、更にその元ネタはクーンとのこと 普遍そのものに興味がある方は中世哲学の入門書を読むのがおすすめ。私が最近読んだものだ SaaSを作るという仕事について：普遍のためのヒント 48
49. SaaSを作るという仕事について：まとめ 49 パッケージ SaaS SaaSでやること コードベース 毎回変わる 同じ 保守性の高いコードを書く リリース 数年に一度 継続的 速く高頻度にリリースする 機能 増えない 増える 普遍を目指して設計する 使い方 変わらない 変わる 普遍を目指して設計する
50. SaaSを作るという仕事について：メッセージ 50 限られた時間の中で「普遍」を目指して設計し、品質の高いコードを書き、頻繁にリリースす る。このあまりに難しいゲームを解くことが、使ってくださっている方々の仕事を支え、自分の やっている会社の事業を成長させる、というSaaSの開発は、非常にやりがいのある仕事です。常 にベストのものが作れるわけではないですし、失敗もありますが、少しづつうまくできるように なっている実感と、うまくいったときの爽快感と静かな興奮は格別です。 未経験の方は、ぜひいつかこの喜びを体験してもらえると嬉しいです。ソフトウェア・エンジニ アとしての喜びが詰まった仕事だと思います。同業者のみなさんはこれからも一緒に良いコード 書けるように頑張っていきましょう！
51. おわり 51 普遍の存在を全否定した哲学者、オッカム