y.takky　てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

トップ > All for SaaS SaaS立ち上げのすべてを読んだ

All for SaaS SaaS立ち上げのすべてを読んだ

All for SaaS [SaaS立ち上げのすべて]を完読した。 自分が気になった点をまとめる。

自分が気になったところだけなので、書籍全体ではこれ以上の内容があるので 気になった方は是非購入しよう。

まとめ

立ち上げ時の組織体制

  • プロダクトサイド(プロダクトマネージャー、エンジニア、デザイナー:企画検討開発を担当)とビジネスサイド(マーケ、セールス:インサイド/フィールド、導入コンサル、カスタマーサクセス、カスタマーサポートなど)に分かれる
  • プロダクトサイドで20人程度の場合
    • CEO -> プロダクトマネージャー
      • プロダクトマネージャはプロダクトが向かう先を定義して、具体的な施策や要件の落とし込みを行う。プロダクトサイドやビジネスサイドを巻き込む。
    • CTO -> エンジニア
      • エンジニアはフルスタックより 　- 組織横断的にチームを編成して、プロダクトマネージャーが企画検討、エンジニアが開発
  • プロダクトサイドが50-100人程度の場合
    • 機能分化
    • CPO/VPoPがディレクター、プロダクトマネージャーを見る
    • CTO/VPoEがエンジニアリングマネージャを見て、その下に職能別でエンジニアがいる
    • クロスファンクションチームで動く
  • QAも忘れてはいけない

目標設定・人事評価

  • 関係者が多くなるのでOKRなどで目標設定をしてチーム運営に活かす
  • Objectiveは組織やチーム単位でのミッションステートメント。定性的でワクワクして人を引き付けるもの
  • Key-Result は検証可能性が高いもの。期間内に達成可能であること
    • リリース時期など開発前提をKey-Resultにしても意味ない。開発の意思決定が予定調和になりがちになるので
  • クロスファンクションチームでの成果をもとに人事評価される仕組みが不可欠
    • 所属組織に寄せるか、クロスファンクションチームに寄せるか折衷案か
    • 所属組織の場合、クロスファンクションチーム内でのパフォーマンスを振り返る場を設けて行う
    • クロスファンクションチームの場合は、企業の組織上の部門と認定して評価者をアサインして評価する
    • 折衷案は個人目標で決める

プロトタイプ

  • 調査によるアウトプットなどでロードマップを決める
  • プロトタイプを作るうえで、プロダクトビジョンが重要
  • 企業全体のミッションに即して、プロダクトを通してどんな価値提供ができるかを簡潔にまとめたもの
    • ポイントの一つに熱狂できるものであること。がある 　- ビジネスサイドがその先にいるユーザにも思いが伝わるような力強さが必要

  • プロダクトビジョンを策定する手法の1つとしてプレスリリースを書くというのがある。

    • ユーザドリブン
    • 提供する価値をベースにした要件
    • ユーザ課題・ビジネス機会・ユーザの声など
    • 参考: note.com

  • 開発にかかる時間やリソースが低減できなければプレスリリースではない。

  • プロトタイプを通して何を検証したいのか明らかにする必要がある

MVP(ミニマム・ヴァイアブル・プロダクト)という言葉の罠

  • SaaSにおいて、ユーザが価値を感じられる最低限の要件は、立場によって異なる。
    • 開発と販売と企画では異なる場合がある。
  • 定義が曖昧だと混乱するので、リリース前で仮説検証フェーズならばプロトタイプ。リリースフェイズであればMVPと呼び分けるとよいだろう。

開発

  • ユーザストーリマッピングという手法で共通認識をつくる
  • プロトタイプの過程で出たフィードバックをもとに、なぜ、だれのために、何を実現したいかを洗い出す。
  • アジャイル開発が前提
  • ユーザストーリは関係者が共通認識を持つうえでの重要なポイント。
  • 開発に関係しないメンバーとも要件を議論する必要がある。もう一段抽象的なユーザストーリから共通認識を持ち議論する必要がある
    • ビジネスサイドからのFBがもとになることが多いので、プロダクト側だけで通じるユーザストーリだと共通認識が持てない
  • SaaS開発におけるエンジニアリングマネージャでは、ユーザストーリ起点で開発見積もりの制度と速度を担保しつつプロダクトを徐々に正解に近づけていくマインドと実行力が必要

QA

  • スプリント開発に合わせてQAもアジャイルで進めるとよい。
  • 品質担保できたタイミングでリリースする

ゴー・トゥ・マーケット戦略

  • プライシング・事業計画・販売戦略を順番に決めていくようにする
  • ただし相互関連性がある
  • プライシングの策定は欧米では専門家がいる分野
  • プライシングは定期的に見直すべき
  • プライシングはユーザ視点が起点になる。
    • サービスを提供してお金をいただくという形なので
  • 競合の価格競争などでプライシングに対する要請がある場合
  • コストカットして利益を出すようにしたり、価値に見合ったプロダクトに進化するようにしたり
    • 度合いが超える場合はプロダクトビジョンに立ち返って再構築が必要かもしれない
  • サポートコストは蔑ろにされやすいが、コスト感を把握する必要がある
  • ユーザ要望はユーザ固有のものがある可能性があるので真摯に確認することを前提に一般的なものでほかのユーザからも上がってきそうか確認したい。
  • 公開済みのロードマップに類似するユーザ要望に関してはスケジュールを守れる範囲で正確に伝えたい
  • CREについても述べられていた

リリース

  • リリースに向けて自走できるメンバーと協働、推進していく必要がある
    • 自走:新規プロダクトのリリースに向けてファンクションの責任者として対応方針をゼロから設計でき、タスクの洗い出しと実行をできる
  • リリース判定基準を設けてリリースを行うかを決める必要がある
  • リリース判定基準タイミングでユーザストーリの実現のための機能開発を行っている場合は残タスクを鑑みて、リスケに踏み切る必要もある
  • リリース直後だと機能不足で失注しがち。とくに大企業だと業務プロセスの変革までせずに運用する傾向が強いので。
  • 対応方針として以下3つ
    • 熱意をもってプロダクトビジョンを伝え、共感してもらい受注する
    • ロードマップまではいかないが、機能開発の実績を伝える
    • ロードマップを公開して、今後の展開も含めてプロダクトと認識してもらう　: ロードマップセリングと呼ばれる
  • 盲目的にロードマップセリングを行うことは順守できない開発を約束してしまうので最低限注意を払うべき
  • 社内における開発ロードマップをそのまま伝えない
  • リリース時期に余裕を持たせてこの時期ならば絶対リリースできるという時期を伝える
  • ロードマップの公開範囲や機能を絞る。いわゆる期待値調整
  • ロードマップセリング自体の振り返りを定期的に行うべき
    • ロードマップに掲げたどの機能で販売促進ができたか
    • スケジュール通り実現できたか