シード期のSaaS開発の失敗と注力すべきこと！

こんにちは。アルプnote編集部です。本日は、mintさん主催で8月12日にオンラインで実施された【第4回 シード期のプロダクトづくりの進め方】のイベントで開発担当取締役の竹尾（@showmant_）が発表した内容をレポートします。

創業期の開発の失敗や、良かったTipsなどを紹介しますので、これからプロダクトの開発を始める方や、今プロトタイプで仮説検証している段階の方の参考になればと幸いです。

ーーー自己紹介

アルプの竹尾と申します。アルプは2018年8月に創業しました。その前はサイバーエージェントに新卒で入社し、アドテクノロジーの事業部に所属していました。DSPと呼ばれる領域のプロダクトで配信サーバーや広告入札ロジックの実装を担当していました。

アルプの創業期では主にバックエンドの開発をしていて、今は開発組織全体のマネージメントや採用を担当しています。

ーーープロダクト紹介

アルプはサブスクリプションビジネスを行う企業向けに、今まで手作業や自社開発だった契約や請求の管理をSaaSとして提供するScalebaseというプロダクトを開発しています。

例えばとあるサービスだと、企業がお客さんごとに交わしている契約があり、契約の内容に基づき毎月請求が発生し、請求に対してクレジットカード決済や請求書で決済します。商品マスターと顧客マスターを持ち、契約から請求に関する一連の業務をSaaSとして提供しているのがScalebaseです。

ーーー開発初期のプロダクト開発の回し方

アルプでは創業期からドメインモデリングに重点を置いた開発をしています。その上でヒアリング、ドメインモデリング、プロトタイピングのループを回すことをやってきました。

ヒアリング
SaaSやサブスクリプションビジネスを提供している企業に対して、契約や請求に関してどのようなオペレーションをしていて、どういった課題があるのかをヒアリングしました。1年で100社程度行いました。
ヒアリングにはビジネスメンバーと私含め、エンジニアも同行していました。企業のオペレーションについて、スプレッドシードで管理しているのか、別の会社が提供しているシステムを使っているのか、契約や請求以外でもそこに至るまでのオペレーションで営業の方が使っているツールなどかなり細かく突き詰めました。

ドメインモデリング
開発初期からドメインモデリングにはかなり注力していました。なぜかというと、設計に注力することが数年単位で見たときに最速にデリバリーできるという仮説を立てているからです。各社で違うと思うのですが、BtoBのSaaSは、BtoCに比べると不確実性がやや低いと思っています。世の中にないものを作ろうとしているわけではなく、実際にそこにオペレーションがあり、企業によって異なるオペレーションを正しく一般化することが重要になります。そういう意味で大きく間違えることは少ない部類です。故にモデリングしたものは捨てないという前提において、設計を重視していました。
ドメインモデリングの初期については、ヒアリングや市場調査を通してモデリングをしていきました。市場調査については、競合のプロダクトを見たり、サブスクリプションを提供している企業のシステムを実際に触ってみて概念のつながりを観察したりしていました。

プロトタイピング
最初の数ヶ月でプロトタイプを作りました。プロトタイプがあった方がヒアリングで具体的なフィードバックを得られやすいからです。企業にプロトタイプをレビューしていただき、この概念の置き方は正しいのかなどフィードバックいただきました。私たちはプロトタイピングという形で実際に動くものを作りましたが、そこは目で見えるものであれば紙芝居のようなものでも良いと思います。

ーーー開発初期で失敗したこと

せっかくなので良かったことではなく、失敗したことやこうしておけばよかったという話だけしたいと思います。

ヒアリング
開発初期にヒアリングするときに、我々はBtoCの方がペインが大きいと思い、BtoCの事業を行っている企業中心にヒアリングをしていました。ただ話を聞いていくとBtoBのお客様の方がペインが大きく解決しやすいということがわかってきました。
ヒアリングしながら開発していたこともあって、BtoC固有の機能を優先して開発してしまい、結果的にその開発が無駄になってしまいました。これ自体は、細かく軌道修正できたという点においては良かったのですが、結果的に作ったものが無駄になってしまったというのが事実ありました。

ドメインモデリング
ドメインモデリングの型を作れず、資産化できなかったというのがあります。ドメインモデリングは概念図やその他の図を利用して議論しながら、全社の人間が理解していく必要があります。全社の人間が理解していくにあたって、過去のあった議論の過程、図などがメンテナンスされておらず、新しいメンバーが入ったときに「なぜこうなったか」の説明に苦心することがあります。

プロトタイプ
プロトタイプを作ったときにはScala、React/TypeScriptを使って開発していましたが、別言語を選択した方がスピードは出せたなと思っています。製品版ではScalaを使うことは確定していて、プロトタイプもできれば資産化したいという気持ちもあってScalaを採用しました。結果、プロトタイプは捨てたこともあって、スピードを重視して他の言語やフレームワークを利用した方が良かった可能性はあったと思います。さきほどお話した通り、toBビジネスで不確実性が低いというところで、その選択をしたのですが、プロトタイプは捨てる前提でスピードのみ重視した選択もあったのかと思っています。
それはとにかくスタートアップはスピードが大事ということと、間違ったときに軌道修正しいやすい方が良いからです。とにかく小さく速くが鉄則だと思っており、そこに反した部分はあったと感じています。結果的に我々はロスが少なかったのですが、真似はしない方が良いと思います。

ーーー開発初期で良かったTips

Jenkinsを使ったCSオペレーション
BtoBのSaaSのオペレーションは多岐に渡り、我々のプロダクトが画面上で提供しているものだけでは解決できないことがたくさんあります。フロントエンドの開発工数は取れないときに、解決できる策の一つしてCS（カスタマーサクセス）がお客様のオペレーションを代行するということがあります。
それをScalebaseではJenkins上で実現しています。バックエンドで操作するバッチを作り、Jenkins上でパラメータを入力し、お客様に変わってCSが実行することでScalebaseの画面上で実装していない機能をまかなっています。
ScalebaseではCleanArchitectureを採用していて、Controller層だけを差し替える、つまりAdapterを差し替えるだけでBatchにしたりAPIにすることができます。最初にBatchで作ったものをAdapterを作るだけでAPIとして提供でき、フロントの工数が取れたタイミングで画面に実装することができます。
開発の無駄が少なく、こういったことを実現できるのでみなさん実践していただくと良いと思います。

アルプのぶんぶん丸
開発が進んでいくとビルド時間は増加していきます。高速にCIできることは生産性もあがり、ストレスが少ない開発ができます。CIのSaaSを使うと月数万〜数十万かかるというのもあり、安く速くやるというソリューションとして、強いマシンを買うことでクリアしました。20万くらいでマシンで、テストを走らせたり、成果物を作ったりしています。今も現役で活躍していて、かなり費用対効果が高いです。
現在はエンジニアが15人居て、ビルドが渋滞することもあるのでマシンを複数台にして並列化したり、渋滞時はEC2を使って並列化したりしています。

ーーーQ&A

当日時間の関係上、解答できなかった質問についても解答させていただいております。

Q: 長期的視野で見るとDDDで設計をすることに力をかける意味を感じますが、設計に時間がかかるとMVPの開発がスタートできないと思います。特に資産にしたいと思うと設計を待つことになるので、どんどん遅くなりますよね。小さく早くに反するDDDをどうやって社内で推進されているのでしょうか？

Q: ドメインモデリングや設計をきちんとやるのはコストがかかると思うんですが、どのようにバランスを取っているんですか？

A: おっしゃるとおり、モデリングや設計に時間をかければ短期での最速ではなくなると思いますが、長期目線では最速になると考えています。あとはどうやって設計の時間を短くするかというところの努力になると思います。Scalebaseでは意識付けと仕組みの両方で設計スピードを担保していました。
意識付けとしては、モデリングするにしてもその概念は「現時点でMust Haveなのか？」「そのモデリングは可逆なのか？」というのを意識するようにしています。
仕組みとしては、一つ目に初期はスクラムのベロシティを使って極端に時間のかかっている設計含めた機能開発がないかを観測していました。その後、より開発速度を意識するためにカンバンを採用し、各工程でかかる時間を測定するようになりました。このあたりの変遷はまた別の機会にお話したいです。
2つ目に各領域におけるドメインマスターにアクセスできる状態をつくり、精度の高い情報を得られやすいようにしています。

Q: まだ不確実性がある中で、Scalaを選択した理由はなぜでしょうか。言語使用者の母数が少ないと採用など苦労するかと思いますが何か工夫してたりしますか

A: Scalaを採用したのは以下の理由があります。

・ドメイン特性上、堅牢性が求められるので静的型付け言語が良い
・初期に居たエンジニアメンバーが得意とする言語のほうが、なにかあったときにカバーが効きやすい
・困ったときに頼れるScalaエンジニアが他言語に比べて自分の周りにたくさんいた

採用については数百人レベルの経験者を採用しようとすると厳しいと思います。現時点においての我々の規模では分母が問題にはならないと考えています。

こちらの記事でもScalebaseの技術選定について語っているので、ぜひご覧ください。

Q: 設計を頑張ったときほど現実と乖離が大きかったというトラウマから、動くものでフィードバックを得る方に気持ちが傾いています。DDDのような概念の世界に留まることにためらいがありますますが、モデリングのためのヒアリングのコツはありますか？アーキテクチャやプロセスの採用の話ももっと聞きたいです。

A: 乖離を小さくするためにも顧客の声を聴くこと、小さく設計すること、小さくリリースすることを心がけるのは前述のとおりです。また、自分たちの思う正しさと実態のオペレーションは、おっしゃるとおり違うことがかなり多いです。特に機能自体が複雑なものになると乖離は顕著です。最近は機能開発のための要件定義書ができ上がるタイミングで開発者含めて、機能を欲しているお客様にヒアリングをさせていただいています。

Q: 分析Dashboardの画面が見えましたが、分析機能って実装する指標が多くて大変ではないですか？実装の優先度はどうやって決めていますか？

A: おっしゃるとおり、サブスクリプションの管理指標は非常に多いです。顧客ヒアリングをもとに、MRRなど主要な指標や、アップセル、クロスセルを可視化できるところなどを優先的にやってきました。

Q: ドメインモデルの分析やモデリング手法等どのように実施していますか

A: 弊社では PRD作成、 概念図作成、 CRC実施、 ユースケース駆動開発を実施しております。それぞれについて今後記事になる予定です！

ーーー発表スライド

ーーー終わりに

アルプでは積極的にメンバーを募集しています。今回の記事を見てご興味を持ちましたら、是非以下の採用ページからご応募お待ちしております！

アルプ株式会社

また今回のイベントで発表した開発担当取締役の竹尾のTwitterのフォローもお願いします！https://twitter.com/showmant_