SaaSスタートアップのプロダクト開発（シード〜シリーズA編）
カミナシでCOOをしている河内です。
カミナシでは、現場で働くノンデスクワーカー向けにSaaSプロダクトを提供しています。
2020年6月にリリースしたプロダクトの導入社数は右肩上がりで伸び続けており、毎日数十万件のデータが紙の代わりにモバイルで提出されるまでに成長しました。
SaaSスタートアップの成長ステージを
1. Product-Market-Fit期（プロダクト価値の検証）
2. Go-To-Market-Fit期（ビジネス戦略の検証）
3. Growth & Moat期（事業スケールと参入障壁の構築）
の3つに分類すると、カミナシは「3」のステージに入りつつあります。
今回は、SaaSスタートアップであるカミナシのプロダクト開発をテーマに
・3つの成長ステージに応じて、どのように体制が変遷したか
・いま具体的にどんなことに取り組んでいるか
を書いていきたいと思います。
こんな方の参考になればうれしいです。
・PM/エンジニア/デザイナーなどプロダクト開発に携わっている人
・アーリーフェーズのSaaSスタートアップに関わっている人
・現場で使われるデスクレスSaaSに興味がある人
1. Product-Market-Fit期（社員数：〜10名）
プロダクトリリース前後で利用ユーザー数も少なく、生き残りをかけてプロダクトを開発していた時期です。
事業のグロースに取り組む余裕はありません。とにかくユーザーと向き合いながら、どうすればお金を払っていただける価値を感じてもらえるかに全社員がフォーカスしていたように思います。
プロダクト開発は、創業者の代表諸岡が営業・カスタマーサクセスなど顧客接点の中で直接フィードバックを得て、そのまま仕様に反映するという進め方をしていました。デザイナーが不在だったので、創業者・エンジニアチームがFigmaでデザインをしています。
利用ユーザー数が少なくプロダクトの利用状況も様々だったので、定量的にデータを見て改善をまわすよりも、定性的にN1のユーザーの声と向き合いながら仮説を立てて検証していくことが多かったように思います。この時期のプロダクト開発はアートの世界に近いです。
創業者がプロダクトマネジャー（以下PM)を兼務しながら、ビジネス・プロダクトを属人的に同期させて、トップダウンでプロダクト開発を推進する体制だったといえます。
2. Go-To-Market-Fit期（社員数：〜30名）
プロダクトの価値提供に再現性が生まれてきた頃から、創業者から専任PMへの権限移譲が本格的に進みました。
1人目のプロダクトデザイナーも入社し、主要画面のUIリニューアルを行いました。エンジニアチームでもスクラム開発のイベントを部分的に取り入れたSprintがまわりはじめます。
ユーザー数の増加に伴い、プロダクトの利用状況を定量的にデータで確認する取り組みが増えたのもこの頃です。具体的には、解約率（Churn Rate）の先行指標となる主要機能の利用率を測定しながら改善を重ねました。
PMFが見え始めた比較的早いタイミングで創業者から専任PMへの権限移譲を進め、プロダクト開発のプロセスを整備しはじめた時期だったといえます。
3. Growth & Moat期（社員数：31〜60名）
社員数が30名を超え、エンジニアチームも複数に分かれる中で、より組織的にプロダクト開発を進めていく必要性が増してきました。UXリサーチャーも加わり、職種ごとにプロダクト開発の専門性も高まります。
ここからは約1年前から現在進行中の取り組みを紹介していきます。
デザインシステムの構築
プロダクト開発に関わる人数が増えると、個々人の力量や実装方法によってユーザー体験にバラつきが出ないように工夫する必要があります。
カミナシではプロダクト間のユーザー体験を統一することを目的に全社基盤としてデザインシステムの整備を進めています。
デザインシステムにはプロダクトデザインの原則やルール、共通コンポーネントなどが含まれており、カミナシではデザインチームがオーナーシップを持って構築を進めています。
ユーザー体験に一貫性を持たせるだけではなく、再利用できるUIコンポーネントがコードも含めてツール化されることで、開発効率の観点でもさまざまな利点があります。
（余談ですが、最近ではデジタル庁でも将来的な各省庁サイトのデザイン統一を視野にデザインシステムの構築を進めているそうです）
デザインシステムは、プロダクト開発と同様に一度作ったら終わりではなく、継続して開発〜改善をしていく必要があります。現状は既存メンバーが兼務して作っていますが、将来的にはデザインシステムの専任チームを作って改善サイクルをまわせるのが理想と考えています。
「価値探索」のサイクルを体系化
工場や店舗など様々な「現場」で使われるカミナシは、デスクリサーチだけではユーザーの業務フローやペインを理解するのが難しいという特徴があります。そのため、価値探索のための様々な取り組みをおこなってきました。
検証可能な最小限の製品を「MVP（Minimum Viable Product)」といいますが、小さく作ってリリースしてから改善するマインドセットは重要です。
一方で、toBプロダクトでは、法人の購買プロセスを経て製品を使われることから、売ることができる最小限の製品「MSP（Minimum Sellable Product）」を作らなければ、使ってもらうことができません。その結果、有用なフィードバックも得られないのです。
また、すでに一定数のユーザーが存在する場合、顧客への業務影響を考えると機能リリース後に大きなアップデートを気軽にかけられないという現実問題もあります。
そのためtoBプロダクトでは、リリース前の価値探索フェーズでいかに打率をあげていけるかが重要だと思っています。
カミナシには「現場ドリブン」というバリューが存在し、これまでもプロダクトの作り手が現場でN1のユーザーと向き合って価値探索をしながらプロダクトを開発してきました。
しかし、これまでは各々が思いついたタイミングで属人的に行なっている状態であったため、「実装」サイクルと並行して組織的に「価値探索」サイクルを回せるように取り組んできました。
「実装」サイクルもプロジェクト管理基盤にJIRAを採用し、オペレーションを再構築するなどして整備が進んでいるのですが、今回は「価値探索」サイクルの具体的な取り組み例を紹介します。
①「調査・検証」の取り組み
現場訪問でユーザー調査を行う際には、業務フローや図面などの情報をもとに、事前に仮説課題を関係者で書き起こして、訪問時の検証項目を設計し、訪問後に振り返るようにしています。運用フォーマットも体系化されてきました。
現場訪問時には許可をいただいて動画を撮影させていただき、UXデザイナーが「現場Youtuber」として、業務フローがわかりやすいよう動画にテロップをつけた上で社内共有するなどしてくれています。（訪問先の社員の方にピンマイクもつけていただいているので音声もクリアでした）
②「プロトタイピング」の取り組み
アイデア段階ではGoogleスライド、より具体的なUIも含む場合はFigmaで紙芝居のようなプロトタイプを作っています。
Figmaのプラグイン連携により、スプレッドシート上でプロトタイプのデータを編集できるようしており、ビジネスメンバーが個社向けのプロトタイプを作成できるような試みも行っています。
↓Figmaプラグインのデモ動画です。便利・・・！
最近では、UX-Pinなどのツールを使いながら、誰でも簡単に、よりインタラクティブなプロトタイピングを行える環境の構築に取り組んでいます。
③「ユーザーインタビュー」の取り組み
調査〜プロトタイプ検証を目的に、ユーザーインタビューを行なっています。インタビュー先は以下方法で見つけています。
・既存ユーザーへのインタビュー依頼
・社内のつながり経由でインタビュー依頼
・ビザスクなど外部サービスを活用したインタビュー依頼
特に新規開発を行う際には、毎週のようにインタビューを繰り返していくのですが、toCプロダクトと比較してtoBプロダクトではインタビュー対象者のペルソナが職種や業界などで限定されるため、リクルーティングの負荷が大きいです。（私自身toC/toB双方のPM経験があるのですが、差を感じます）
この問題を解決するためには、toBプロダクトではカスタマーサクセスチームとの連携が有効なのではないかと考えています。カミナシではPM・デザイナーとカスタマーサクセスチームが連携しながらこのような取り組みを行っています。
・既存ユーザーとカスタマーサクセスの定例ミーティングにPM/デザイナーが同席し、インタビューの時間をいただく
・ユーザー理解が深いカスタマーサクセスのメンバーを疑似的なユーザーと見立てて、インタビューを行う
まとめ
各フェーズでプロダクト開発の体制にもさまざま変遷がありました。
1. Product-Market-Fit（社員数：〜10名）
創業者がプロダクトマネジャー（以下PM)を兼務しながら、トップダウン的にプロダクト開発を推進する
2. Go-To-Market-Fit（社員数：〜30名）
創業者から専任PMに権限移譲が進み、スクラム開発などの開発プロセスが整備されはじめる
3. Growth & Moat（社員数：30名〜）
開発チームが複数になり、属人的におこなっていたプロダクト開発の組織化が進む
フェーズごとの体制・注力KPIと合わせて、まとめるとこんなイメージです。
（参考：The Science of Re-Establishing Growth）
今回はSaaSスタートアップのプロダクト開発は、成長ステージごとにどのように変遷するのかをカミナシの具体的な事例を通して紹介しました。
少しでもSaaSプロダクトを作っている人、これから作る人たちの参考になっていればうれしいです。
「デスクレスSaaS」のプロダクトについて詳しく知りたい方は、こちらの記事もご覧ください。
Go-To-Market-Fit期の取り組みはこちらにまとめています。
定期的にTwitterやPodcastでカミナシやSaaSスタートアップに関する発信をしているので、よろしければフォローしてください。
Twitter：@yusuke_kawauchi
Podcast：カミナシSaaS FM
最後に
プロダクト開発の体制も少しずつ進化してきましたが、プロダクトの力で事業成長をさらに加速させていくためには、まだまだ課題が山のようにあります。
どんな課題があるのか「ちょっとだけ話を聞いてみたい」という方は、30分でカミナシのことをご説明します。こちらのMeetyからご連絡ください。
求人一覧はこちらです！
この記事が気に入ったらサポートをしてみませんか？