シード期のSaaS開発はどう進める？〜SIer出身エンジニアが陥った失敗と教訓

■ イベントページ
https://blog.allstarsaas.com/posts/ascend-saas-engineering
■ YouTube
https://youtu.be/owPnuFLv3_Q

Transcript

1. シード期の SaaS 開発はどう進める？ SIer 出身エンジニアが陥った失敗と教訓 2022/06/28 創業者/フルサイクルエンジニア 増谷 侑一 取締役 CTO 丹羽 健
2. シード期のスタートアップにおける SaaS 開発の失敗と教訓についてお話します • 運送管理 SaaS 「アセンド・ロジ」のα版構築と破棄 ◦ 体制・プロダクト両面で課題が大きく、事業推進が困難であると判断 ◦ 0からのプロダクトの作り直しを実行 • スタートアップのサービス立ち上げに関する見解 ◦ 不確実性が高く、最初からベストな選択肢を取ることは困難 ◦ 故に、失敗を経つつもそこから学び、プロダクト、ひいてはチーム・組織をも 再定義していくプロセスがシード期のスタートアップにとって重要ではないか 本日のお話の要旨 本日のお話における「失敗と教訓」は、 アセンドが失敗から学び、再出発を果たした軌跡とご理解下さい
3. 前編 アセンド・ロジ α版の構築 失敗に至るダイジェスト
4. • フルコミットの創業メンバー3人（ビジネス2名、エンジニア1名) • 業務委託の副業メンバー6人（エンジニア5人、デザイナー1名） ヒト、カネ、モノのいずれも余裕が無いシード期のスタートアップ 当時の弊社の状況（2020/11ごろ）: 概況 体制 • 創業メンバーは社長の自宅をオフィスにして膝詰めで業務推進 • 副業メンバーとはリモートでコミュニケーション 環境
5. コンサルおよびSIer出身の「堅め」なメンバーが集まるも、 サービスやプロダクトを0から1に立ち上げた経験のあるメンバーは不在 • 会社創設時のメンバーは以下3名 ◦ 日下（シンクタンク・コンサル出身） ◦ 森居（コンサル出身） ◦ 増谷（SIer 出身） • 体制上の課題 ◦ サービスやプロダクトを0から1に立ち上げた経験のあるメンバーが不在 ◦ 唯一のエンジニアである増谷のスキルセット不足 ▪ 得意領域がIT基盤（インフラ）寄り。SaaSを含む業務アプリケーションの設計・実装経験なし • 課題への打ち手 ◦ 副業エンジニアに参画していただくことで、足りない知見やマンパワーを補おうとした 当時の弊社の状況（2020/11ごろ）: 創業メンバー詳細
6. 2021年02月 アセンド・ロジ α版 破棄の意思決定 プロダクトの状態が今後の 事業展開に耐えないと判断（後述） プロダクト開発をめぐるタイムライン 2021年05月 初契約が決定 α版での実証実験にご協力いただいた 会社様にて正式に導入判断を頂く。 他数社でも契約に向けた前向きな検討が進む 2019年08月 事業検討・開発開始 創業メンバーが週末に集まり 事業について検討を進め アセンド・ロジの開発を開始 2020年11月 実証実験を開始 プロダクト検証のパートナーを獲得し 価値検証を開始 2020年03年 ascend株式会社創業 2021年08年 製品版の構築完了 製品版として最低限の価値提供が 可能なプロダクトが構築完了
7. • 持続的でない体制・プロセス ◦ プロダクトにもチームにも思想がなく、開発の方向性が見えない ◦ プロダクトについても、開発プロセスそのものについても、継続的な改善のサイクルが根付いておらず CSからの要望を只管製造するのみ • 積み上がった技術的負債 ◦ 「ツギハギ」の改修がパッチワークのようにまとわりついたことで、 中核を担う機能は大量の if文やfor文を含む巨大なメソッド・クラスで実現されており、改善不可能 ◦ 利用されていないソースコードが残置されており、仕様を理解しづらい（「割れ窓」だらけ） ◦ テストが殆ど書かれておらず、改修後に既存機能が正常に動作することが保証されない 導入決定当時のプロダクトの状況 このままでは事業を前に進めることは出来ないと判断。 結果として、0から再度プロダクトを作り直す意思決定。
8. 前編 α版破棄の失敗と教訓
9. 失敗の構造 プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション 「組織を思想に基づき設計していくこと」に対する意識の希薄さ
10. 失敗の構造 「組織を思想に基づき設計していくこと」に対する意識の希薄さ プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション
11. • プロダクト事業の推進にあたって 遭遇した具体的な状況に相当 • 単なる知見の不足のみならず、 自らのビジネスを合わせて知見・知識を 取捨選択出来なかった点も失敗の根幹 • 思想を持てないに至った マインドセットに相当 • Unlearn とは、 自身の資産である知識と経験を 棄却して学び直すプロセス • 大企業出身ばかりの創業メンバーにとって Unlearn 不足は失敗の根幹の一つ 失敗の根幹と、その先にあるもの 「組織を思想に基づき設計していくこと」に対する意識の希薄さは大きく 2つに分解される 既存価値観からのUnlearn 不足 SaaS 開発知見の不足
12. 失敗の構造 プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション 「組織を思想に基づき設計していくこと」に対する意識の希薄さ
13. • 大企業出身のみの創業メンバー ◦ コンサル出身2名、SI出身1名 • プロジェクト型な進め方への慣れ ◦ やって終わりなプロジェクト、 不確実性を前提に学ぶの実経験不足 大企業的発想 + 不確実性への軽視 • 人的・時間的リソースが 豊富な状況を前提とした思考 • 「行動に対して得られる結果が 確定的であること」を期待した行動 • カルチャーマッチ軽視の採用 ◦ 稼働時間・スキルセットを重視 • 協働なきコミュニケーション ◦ 縦割り意識 ◦ 守備範囲を定めるような 振る舞い・コミュニケーション • 内省・振り返り文化の欠如 ◦ 課題認知の機会不足から 学ばない・改善しない 失敗の概要 失敗の背景 アセンドで顕在化した事例
14. 大企業的発想 + 不確実性への軽視 • 教訓 失敗に対する考察 教訓 • 不適切な行動様式や、思考の癖を Unlearn するためには、まずはバイアスに気づくこと が重要 ◦ 内部で率直で相互フィードバック ◦ 外部からの目線を入れる • 一定の不確実性の存在を前提とする。 どのように不確実性を取り扱うか （減らす or 受容する）、許容可能な 不確実性の量を越えていないかを確認 • 社会人キャリア観点での創業メンバーの同 質性に起因して事業推進が阻害されている ことに気づくことは難しかった • そもそもプロジェクト型以外での仕事の進め 方を知らず、唯一経験のある型で仕事を進 めざるを得なかったとも言える
15. 失敗の構造 プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション 「組織を思想に基づき設計していくこと」に対する意識の希薄さ
16. • マクロな業界課題への精通がある故に ミクロなSaaS適合の難易度を軽視 • 運送会社にSaaSを適合させる タイムスパンを短く見積もった ビジネスモデルの認識不足（Vertical SaaS） 失敗の概要 • 浅い顧客課題設定 & 安易な機能開発 ◦ 顧客の課題を矮小化・狭く捉える ◦ 価値ではなく機能にフォーカス • 学びながら作り続ける姿勢の欠如 ◦ 真に業務適合を目指し、 改善を続ける動きの鈍さ • 内省・振り返り文化の欠如 ◦ 顧客課題と向き合い、 課題を問い続ける姿勢の欠如 失敗の背景 アセンドで顕在化した事例 • 社長がシンクタンク出身で 高い業界解像度を持っていたが故 • 作って学ぶ期間を計画に織り込まず ◦ システムを作って納品する一過性の ビジネスからの Unlearn 不足
17. • 一言で言えば「あたまでっかち」。 SaaSという事業モデル、B2C / B2B、 Vertical / Horizontal に関する教科書的知 識のみをしてビジネスモデルを理解した気に なり、向こう見ずに突き進んだ ビジネスモデルの認識不足（Vertical SaaS） • 教訓 失敗に対する考察 教訓 • まずは自らのビジネスについて深く知ること。 そして B2B Vertical SaaS の解像度を高め 続けること。これらを踏まえて必要な知識を 取捨選択・カスタマイズし、開発を推進してい く ◦ 我々の場合、想定より顧客の業務課題 と深く・長く向き合い続ける必要性に気 づいた
18. 失敗の構造 プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション 「組織を思想に基づき設計していくこと」に対する意識の希薄さ
19. • 事業特性の無視と、世に広く知られた プラクティスの安易な適用 • 適用したプラクティスの機能不全 プラクティスを集めただけの思想なきエンジニアリング • 安易な技術選定 ◦ 消極的な意思のこもった選定 • 場当たり的開発プロセス ◦ 技術レイヤでの盲目的チーム分割 ◦ 根拠なきTry&Error • 負債コントロールのない設計 ◦ 技術的負債の利用・返済計画の不在 失敗の概要 失敗の背景 アセンドで顕在化した事例 • プロダクト事業を持たない コンサル/SI 出身の創業者 • プラクティスの運用に対する 知識不足・経験不足
20. • 事業とエンジニアリングを強くアラインさせて いく議論は世に少なく、 その重要性を認知できず • プラクティスの捉え方が依存的。 プラクティスとは、特定の課題設定と、その解 決に対するアプローチの一つでしかなく、む しろ生まれた背景に重心をおいて捉えるべき だが、漠然と銀の弾丸のように捉えていた プラクティスを集めただけの思想なきエンジニアリング • 教訓 失敗に対する考察 教訓 • エンジニアリングは事業を成り立たせる手段 の一つではあるが、独立したものではない。 事業目的とアラインしたエンジニアリングの 方針が必要。 • プラクティスの適用にあたってはその背景こ そを理解するべき。表面的な適用では恩恵を 受けることは出来ない。
21. 失敗の構造（再掲） プラクティスを集めただけの 思想なきエンジニアリング 学びながら 作り続ける 姿勢の欠如 既存価値観からの Unlearn 不足 ビジネスモデルの認識不足 （Vertical SaaS） SaaS 開発知見の不足 負債 コントロール のない設計 安易な 技術選定 内省 振り返り 文化の欠如 大企業的発想 不確実性 への軽視 浅い顧客課題設定 安易な機能開発 場当たり的 開発 プロセス カルチャー マッチ軽視 スキル軸での メンバー選定 協働なき コミュニ ケーション 「組織を思想に基づき設計していくこと」に対する意識の希薄さ
22. 後編 α版破棄提言と意思決定 現在のプロダクトチーム
23. 当時よりアセンドは「物流業界を主語」としており 社会に必要な会社だろうと丹羽が考え 勝手なプロダクト破棄の提言に至った。 α版破棄の提言と意思決定 • 当時副業で外部から関わっていた丹羽が α版の負債の多さ・組織設計の無さを 危ぶみ正社員メンバーに指摘 • ToBeの形が無ければ破壊的な提言は 受け入れられないだろうと考え 勝手にToBeを描き提言をする • 教訓 破棄の提言 意思決定 • 2020年12月 初期はフロントエンドが刷新スコープ • 2021年01月 プロダクトの思想・構想を練る中で 全体を改めるべきと相談しスコープ変更 • 2021年02月 全体思想を元に製品版の最終提言＆決定 セールス＆CSは動きを停止
24. 同じ釜の飯を食う文化 社員全員で日常的に夕食を 共にすることで関係を構築 仕事仲間以上の 心理的安全性で議論を深める Unlearn が生まれるカルチャーを形成する Unlearn とは自身の資産である知識と経験を棄却して学び直すプロセス 高い心理的安全性を基に日常的に Unlearn が起きるカルチャーを形成する アセンド食堂 内省・振り返り文化 #アセンド食堂 定例会で記入時間を確保 内省を中心とした振り返り オープンな振り返りの共有 共感による信頼関係の構築 １年半の運用で 2854 件
25. 自身のビジネスモデルを再解釈し、思想として言語化する 数多あるベストプラクティスの誘惑に対して強い意思を持って取捨選択し統合する Vertical SaaSという認識 • レガシーな現場業務のデジタル化 • 多様なモノを運ぶ運送会社 SaaSという認識 • 持続可能なプロダクトの開発 思想を養う（自身のビジネスモデルを再解釈する） アセンドでの例 持つべき特性 Vertical SaaS として • 顧客業務・業界の理解の深さを作る • 業務装着性の高い機能＆UX • 標準データモデル探究の為の暫定モデル SaaS として • 継続的に価値を積み上げる開発
26. プロダクト立て直し時に、まず最初に作ったものが技術思想のドキュメント。 思想の体現を目的としてアーキテクチャを構築した。 • 最も重視する点を明確にする • 短く端的な表現で思想の精度を上げる • 一人で思想のドラフトを作成したが 最後は全員で思想の一致を確認する 思想を養う：事例（自身のビジネスモデルを再解釈する） 思想のポイント 実際に作成した ドキュメント
27. 以下の３要素に対して 思想を基にシステム思考で全体を設計する 組織を設計する（エンジニアリング） Vertical SaaS として • 顧客業務・業界の理解の深さを作る • 業務装着性の高い機能＆UX • 標準データモデル探究の為の暫定モデル SaaS として • 継続的に価値を積み上げる開発 持つべき特性 特性に対する設計 開発 プロセス 技術 選定 組織 設計
28. フルサイクルエンジニアによる Vertical SaaS 開発 Full Cycle Developers at Netflix — Operate What You Build https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 １エンジニアの担当領域が広いため自動化・効率化に投資 運送会社の複雑な業務・業界知識を学び、 価値あるプロダクトを迅速に開発するために フルサイクルエンジニアでの開発スタイルを選択 • Netflix における開発スタイル • ソフトウェアライフサイクル全体に対して エンジニアがオーナーシップを持って取り組む • エンジニア個人の中に学習のループを作る 学習 と フィードバック 設計 リリース テスト 運用 開発 サポート
29. 継続的価値創出の為に「Lean と DevOps の科学」を参考 １日に何度もリリースできる水準を目標に技術選定 • Full TypeScript Architecture ◦ 言語統一による開発中の認識負荷を軽減 • GitOps x ArgoCD ◦ 開発プロセスの流れにリリース作業を組み込み自動化 • MongoDB ◦ 学びながらモデルを容易に変更できることを目的 高い生産性を実現する技術選定 リリース / 日 4.2
30. • フルサイクルエンジニア • スペシャリスト フルサイクルエンジニアは１領域を持ち 深く自律的に学習サイクルを回す。 専門知識が必要な部分に対しては スペシャリストにより個人の成長をサポート メンバーの成長と Unlearn を支える組織設計 運行 管理領域 Site Reliability Engineering UX/UI デザイナー 物流業界ドメインエキスパート CS サポート マスター 管理領域 データ 分析領域 プロダクトマネジャー 請求 管理領域 ロール定義
31. 組織を思想に基づき設計していくこと ゼロから会社もプロダクトも創れることがスタートアップの競争優位性 自身のビジネスを解釈し、強い思想を養い、設計し実行する。 • そのプラクティスは思想に合致するか？ 全ての施策を思想にアライメントする • 思想ベースで考えることで １段飛躍した相乗効果を実現する 思想に基づく取捨選択 • 自身の知識・知見を常に疑い 自身を否定して学び直すこと • 組織として学習する為に 内省・振り返りの文化を持つ • 仕事仲間以上の関係を持って 高い心理的安全性で不確実性を御す Unlearn
32. @niwa_takeru We’re hiring!!! アセンド株式会社は 共に社会課題を解決する仲間を探しています。 アセンドに少しでも興味が出ましたら 丹羽・増谷までDMでご連絡ください！ アセンド食堂でぜひお会いしましょう！！！ @ymasstani Meety Twitter