← エピソード一覧に戻る Episode 146 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― なぜ便利なだけのSaaSは残らないのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトのかなり重要な論点、コアワークフローを扱います。便利な機能をたくさん積んでも継続率が伸びない会社がある一方で、機能数は少なくても毎日開かれるプロダクトがあります。その差はどこにあるのか、という話です。
ミカ
ミカです。たしかにありますね。営業資料ではすごく多機能に見えるのに、契約後は全然使われない SaaS。逆に、少し地味でも現場が毎日触るものもある。今日はその違いを、経営者がどう見抜けばいいかを知りたいです。
タカシ
先に結論を言うと、顧客の中心業務の流れに入り込めているかです。入力して、判断して、誰かに渡して、次の仕事が進む。その一連の流れのど真ん中で自然に開かれる SaaS は残りやすい。逆に周辺にあるだけだと、真っ先に後回しになります。
ミカ
なるほど。『便利』より『その仕事を回す場所になっているか』が大事なんですね。今日は定義だけじゃなくて、実際にどんな会社がどう設計しているのか、数字も含めて聞いていきたいです。
Chapter 2 基本 ― コアワークフローは顧客の中心業務を占めること
タカシ
コアワークフローは、顧客が毎日とか毎週くり返す中心業務の流れです。営業なら案件管理から受注後の引き継ぎまで、サポートなら問い合わせ受付から解決連絡まで、開発なら要望の収集から実装と顧客返答まで。その流れの真ん中にいるかを見ます。
ミカ
つまり、単に一機能が便利かではなく、そのツールを開かないと次の仕事が進まない状態を作れているか、ということですね。カレンダーを見ないと会議が始まらない、みたいな感覚に近いかもしれません。
タカシ
その理解で合っています。Amplitude は 2025 年の benchmark で、7 日目の activation が強いプロダクトの 69% が 3 カ月後の retention でも上位だったと示しました。早く価値を感じたユーザーは、その製品を自分の workflow に組み込み、追加の用途まで見つけやすいんです。
ミカ
69% はかなり大きいですね。しかも『気に入る』というより『仕事の流れに組み込む』から残るわけだ。初回オンボーディングで全機能を見せたくなる気持ちも分かりますけど、それだと中心業務に届く前に迷子になりそうです。
タカシ
まさにそこです。経営者が見るべきなのは、ログイン数そのものより『顧客の重要な仕事のどこで開かれたか』です。毎日 1 回でも受注判断や障害対応の起点になっていれば強い。一方、月に何度か見るレポート置き場だと、景気が悪くなると削られやすいんですね。
Chapter 3 具体例 ― LinearとIntercomはどう中心業務に入り込むのか
タカシ
Linear の continuous planning は分かりやすい例です。Slack、サポート、営業など各所から来る feature request を、一つの triage queue に集め、候補プロジェクトへ整理し、顧客要望数や revenue impact で優先順位を付ける。発見から計画までが一本の流れになっています。
ミカ
要望がたくさん来ること自体より、入口が一つにそろっていることが重要なんですね。営業は営業、サポートはサポートで別々に管理すると、結局いちばん大事な仕事が見えなくなる。これは SaaS の現場でかなり起きがちな気がします。
タカシ
さらに Linear は Customer Experience の運用も公開しています。Intercom や Slack の顧客の声を triage に流し、担当者が bugs はエンジニアに、feature request は candidate project に振り分け、PR がマージされたら顧客への返答までつなぐ。この一連が切れないのが強いんです。
ミカ
面白いですね。問い合わせ対応が『別部門の後工程』じゃなくて、プロダクト改善の入り口になっている。しかも直ったら顧客への返答まで戻るなら、現場としても学びがたまりやすいし、信頼も積み上がりそうです。
タカシ
Intercom も近いです。2015 年の roadmap の記事では、PM が毎週 hundreds の customer conversations を読み、bug、usability issue、feature request などに分類された会話を見ながら優先順位を決めると説明しています。つまり会話がそのままプロダクト判断の材料なんですね。
ミカ
スプレッドシートの集計だけだと、『なぜ困っているか』が抜け落ちますもんね。会話の文脈まで拾えてはじめて、中心業務のどこで痛みが起きているのかが分かる。だから support sessions みたいな取り組みも効いてくるわけか。
Chapter 4 経営判断 ― 速い業務フローは定着率と拡張売上をつくる
タカシ
Linear を導入した Scale AI では、あるチームの bug resolution time が 3 カ月で 52% 改善しました。背景には、全 issue が project、team、engineer にひも付き、triage の責任者が一次判断する設計があります。担当が曖昧だと workflow はすぐ詰まります。
ミカ
52% 改善は大きいですね。単に管理ツールを替えたというより、誰が受け取り、誰が判断し、誰が返すかを明確にしたことで、仕事の滞留が減った。これってプロダクト機能より、経営オペレーションの設計そのものですね。
タカシ
そうです。コアワークフローの議論は UI 論ではなく、経営設計なんです。たとえば大口顧客の例外要望を重ねすぎると標準導線が複雑になり、中心業務の完了時間が延びる。短期受注には効いても、長期の継続率や開発速度を削ってしまいます。
ミカ
ありますね。大事な顧客向けの特例を積み重ねた結果、新規ユーザーには何をしたらいいか分からない画面になる、みたいなやつです。売れているのに、なぜか定着しない SaaS はここを疑ったほうがよさそうです。
タカシ
もう一つは分断です。顧客の声は support、優先順位はスプレッドシート、開発は別ツール、顧客返信は人力だと、毎回の handoff で熱が落ちます。Atlassian も 2025 年に、support と product、dev、ops をつなぐ単一基盤で社内検証し、年換算最大 1000 万ドルのコスト削減と CSAT 6% 向上を見込むと公表しました。
Chapter 5 クロージング ― 明日から見るべきは機能数ではなく仕事の流れ
タカシ
実務では、まず顧客の流れを『入力、判断、実行、共有』の四段階で書き出してください。その上で、自社の SaaS がどこに入っているか、どこで別ツールに飛ばされるか、どこで手戻りが起きるかを確認する。ここが経営者の最初の診断ポイントです。
ミカ
次に、継続率の高い顧客に『週次の仕事の中で何回開くか』『どの画面から始めるか』『終わったあと誰に何を渡すか』を聞くんですね。満足度アンケートより、仕事の流れを聞くほうが、かなり本質に近づけそうです。
タカシ
はい。ロードマップ会議でも、『この開発は顧客の中心業務を何分短くするのか』『どの handoff を減らすのか』を必ず問うといいです。便利機能を増やすより、コアワークフローを速く、自然に、繰り返し使われる形にするほうが SaaS は強くなります。
ミカ
今日はコアワークフローでした。次に SaaS を見るときは、機能一覧より『顧客の一番大事な仕事の流れに入り込めているか』から考えてみます。そこが見えると、定着率の理由も、作るべき機能もかなり変わりそうです。ミカでした。
タカシ
タカシでした。お聴きいただきありがとうございました。また次回、SaaS プロダクトを経営の言葉で分解していきましょう。