01フェーズのSaaS開発で意識したことと失敗したこと
こんにちは！Rresilire編集部です。
8月12日に開催された『第4回シード期のプロダクトづくりの進め方（toB SaaS）』にて弊社テックリードエンジニアの大田黒が発表した内容をレポートにしました。
シード期のプロダクト開発に関してやってよかったこと、気をつけるべきところをまとめていますので参考になりますと幸いです。
登壇者プロフィール
大田黒紘之
産業技術高専卒業後、首都大学に編入学。
高専在学中は、超小型人工衛星の開発、医療機器に関する研究に携わる。
理化学研究所で放射線飛跡観測に関する実験システム構築及び中性子イメージングの画像処理に携わる。大学では、量子効果デバイスの数値計算に従事。
その後ABEJAにて小売流通業向け店舗解析SaaSの基盤設計開発を経験。
2020年サプライチェーンリスク管理SaaSであるResilireの立ち上げ期にジョイン。技術戦略の立案及び実行の業務全般を担う。
Resilire（レジリア）の創業背景
Resilire（レジリア）は自然災害による経済損失の大きさを見て、何か被害を予防するイノベーションができないかという思いから始まりました。
経済損失を防ぐやり方は多くありますが、その中でも*サプライチェーンのリスクマネジメントに着目してプロダクトを作っています。
*サプライチェーン
サプライチェーンとは企業が商品を製作するために原材料や部品をサプライヤーより調達し、消費者に届けるまでの流れをいいます。
プロダクト紹介
Resilireは、ツールとして自社のサプライヤー情報をデジタルに管理できる状態を作るものになっています。
災害が発生した際は、一目でリスクの高いサプライヤーを確認しやりとりを円滑にする機能を備えています。
中の人員は社長を含めて数名で行っており、ヒアリング、設計開発、QAのプロセスを回しています。
スタートアップでありつつもエンタープライズ向けのサービスになっているので難易度が高く、「品質・セキュリティ面」で一般的なSaaSよりももう１段階上のレベルで作る必要のある点が特徴です。
Resilireサービスページ
https://www.resilire.jp/
プロダクト設計でやってよかったこと
プロダクト設計で特に意識していたのは「顧客課題に向き合い、解決すべき課題を見定める点」を大事にすることです。
機能開発していくにあたって意味があって必要なものを作る（ソリューションフィット）ことを意識して割と教科書通りやることを大切にしていました。
その中でもやってよかったと思うことは以下の3点です。
①Figmaを基盤に商談プロセスを回した
商談の際にヒアリングをしながらどういうものがあるとお客様の課題を解決できるかをイメージしながらU I/UX Blueprintを起こしていました。
次の商談からはFigmaを見せながら一緒にいじるくらいの勢いで、商談フェーズから一緒に機能改善していこうという空気感を作りながら受注フェーズに持っていったこともいくつかありました。
エンタープライズ向けの事業としてはイレギュラーかなと思いますが、一緒にやっていこうという空気感ができてよかったと感じています。
②CEOがPdm的ロールを積極的に推進していた
CEOがメンバーにお客様の課題を深掘りしたバリューチェーンを積極的に持って帰ってきます。
それまではソリューションを持ち帰り、エンジニアさんにこの改善をお願いしますとお願いをしていましたが旗振りをする人がいないと機能開発が止まってしまうことがありました。
一方で、顧客の課題を持ち帰ってその上で機能設計をしたりしてメンバーがPOのような振る舞いをする体制にするとビジネス・エンジニアもロールに関わりなく同じ視点でプロダクト設計や開発の意思決定ができるようになり良いチームになったと感じています。
③お客様に情報を開示して改善する
Resilireでは企業の中でも強い課題感を持ったお客様を弊社Notionに招待し、機能開発ロードマップをシェアしていました。
Notion上で直接お客様の課題や要望を記入頂く体制にしていました。
その中で、お客様のニーズが最も高いものから優先的に開発していき、早めにできた機能を実際にいじってもらいコメントをいただいき修正後本格リリースするという流れをとっていました。
このプロセスを設けていたお陰で、確度の高いプロダクト開発が短期間でできたなと思う一方で今後は個社対応にならないように気をつけないとなという課題もあります。
システム面で意識したポイント
システム面では事業フェーズの変化を意識した技術選定・システム設計を意識しています。
シード期の作り物は事業フェーズの変化とともに顧客の要望が多様化していったり要件が変わっていったりするためずっと使われるものではないと思っており、その中でも捨てるところと守るところを重視して変化を続けています。
「大事にしたほうがいいもの」
→「技術トレンドや事業が変化しても比較的普遍なもの」
・サービスに関わるデータ（データガバナンス）
・ドメインモデルとロジック、機能使用・非機能仕様
・インフラストラクチャーの管理
「変える前提でいいもの」
→「技術トレンドや事業期の変化によって変わるもの」
・言語設定
・フレームワーク
・アーキテクチャー
必要なフェーズに必要なものがあると思うので、比較的短く事業フェーズと技術トレンドによって変わっていくものは変わる前提を持っています。
捨てるもの捨てないものを意識しつつ方法論に流されず、事業フェーズや組織・人にあったものを選定していくことが大事だなと考えています。
失敗したこと
①マイクロサービスアーキテクチャーに固執しすぎた
マイクロサービスアーキテクチャーに固執しすぎてしまい、シード期のときに大失敗した経験があります。
ビジネスやチームリソースが不安定な状況だったこともあり、相当早いフェーズにサービス分割してしまい失敗してしまいました。
その結果半年やってもリリースできないという大失敗につながってしまいました。
なので、開発プロセスはプロダクトの設計を取り組みながら比較的モノリシックに作り後々サービスとして外に出せるようなことを前提にサービスベースのアーキテクチャーで今回は進めました。
②事業フェーズや組織・人にあわない技術を選定していた
Resilireの開発チームはジュニアな方が多いチームだったのでキラキラとした技術を使いがちでした。
その中で仮説検証のプロトタイピングフェーズからドメインモデルがまだ決まっていないところでクリーンアーキテクチャーを入れようとして失敗した経験があります。
その結果採用もうまくいかなくなり結局やりきれずだめになってしまいました。
方法論に流されず、事業フェーズや組織・人にあったものを選定していくことが大事だなと思いました。
今ResilireはプレシリーズAあたりですが、これから壁にぶつかることもあるかと思います。盛り上げていくための仲間も募集しておりますので気になった方はこちらをご覧ください。ご応募お待ちしております。