事業の方向転換はいつ必要?|ピボットする前に確認したい顧客・課題・提供方法の見直し方

はじめに

新規事業や小さなサービスを続けていると、

「思ったほど売れない」
「もっと対象を広げた方がいい?」
「商品を変えた方がいい?」
「月額サービスにした方が伸びる?」

と考える場面があります。

こうしたときに出てくるのが、

事業の方向転換(ピボット)

です。

しかし、

売れない
↓
顧客を変える

利用頻度が低い
↓
月額サービスにする

入力が面倒と言われた
↓
自動化機能を作る

といった判断は、
少し飛躍しています。

問題が起きていることと、

何を変えればその問題が解決するのか

は別だからです。

事業を方向転換するときは、

  • 何がすでに機能しているか
  • どこに問題が確認されているか
  • 問題の原因まで分かっているか
  • 何を変える根拠があるか
  • 何はまだ変えない方がよいか

を分けて考える必要があります。

この記事では、

事業全体を作り直す前に、どこを残し、どこだけ変えるべきか

を判断する方法を整理します。


事業の方向転換とは?

事業の方向転換というと、

「今の商品をやめて、別の商品を作る」

という大きな変更をイメージすることがあります。

しかし、実際の方向転換にはさまざまな大きさがあります。

例えば、

  • 対象顧客を絞る
  • 利用場面を絞る
  • 顧客課題の捉え方を見直す
  • 提供内容の一部を変える
  • 提供方法を変える
  • 価格や課金条件を見直す
  • 販売方法を変える

といった変更もあります。

つまり、

方向転換=事業を全部作り直すこと

ではありません。

むしろ、
すでに一部で購入や再利用が確認できているなら、

確認できている価値を残し、問題がある部分だけ変える

方が合理的な場合があります。


「売れないからピボット」は早い

例えば、

AIで案件情報を整理するサービスを作ったとします。

顧客は使ってくれるものの、
売上が思ったほど伸びていません。

そこで、

「対象顧客を変えよう」
「もっと多機能にしよう」
「月額サービスにしよう」

と考えたとします。

しかし、実際には、

  • 一部の顧客は購入している
  • 再購入も発生している
  • 特定の利用場面では評価されている
  • 利用されない理由は入力作業の負担だった

という可能性があります。

この場合、

商品全体が悪い

とは言えません。

問題は、

利用前の入力方法

かもしれません。

それにもかかわらず、

  • 顧客を変える
  • 商品を変える
  • 価格を変える
  • 販売方法を変える

と複数の条件を一度に変更すると、

何を変えたことで結果が変わったのか

分からなくなります。


STEP1:まず現在の事業を分解する

方向転換を考える前に、

現在の事業が何でできているか

を分けます。

例えば、

対象顧客

誰に提供しているか。

顧客課題

何に困っている人を対象としているか。

利用場面

どんなときに使う商品・サービスなのか。

提供内容

顧客に何を提供しているか。

提供方法

どのように商品・サービスを利用するのか。

価格

いくらで販売しているか。

課金方法

都度払いなのか、月額なのか。

販売方法

どのように顧客へ案内しているか。

これらを一つの「事業」としてまとめて考えるのではなく、分解します。

すると、

全部が悪いのか、一部だけに問題があるのか

を見やすくなります。


STEP2:まず「残すもの」を探す

方向転換というと、

何を変えるか

から考えたくなります。

しかし、その前に見るべきなのは、

何を残す根拠があるか

です。

例えば、

あるサービスで、

  • 顧客課題を複数人が訴えている
  • 実際に利用されている
  • 購入されている
  • 再購入もある
  • 利用後の価値も確認されている

なら、

その部分まで変える必要はありません。


一度使われたから残す、ではない

ただし、

1人が使った
1人が買った
1人が褒めた

だけで、

「ここは絶対に残すべき」

とは判断できません。

見るべきなのは、

  • 複数顧客で課題が確認されているか
  • 実際の利用と結びついているか
  • 支払いが発生しているか
  • 再利用・再購入があるか
  • 利用後に具体的な価値が確認されているか

です。

つまり、

発言だけではなく、行動も見る

ことが重要です。


STEP3:変更する根拠がある部分を探す

次に、

どの部分に問題が確認されているか

を整理します。

例えば、

利用者から、

「整理結果は便利だけど、使う前に情報をまとめるのが面倒」

という声が複数出ているとします。

さらに、

「使いたい案件はあるけれど、入力が面倒で使わなかった」

という利用停止理由まで確認できているなら、

問題があるのは、

提供内容ではなく、提供方法

である可能性があります。


問題と変更場所を合わせる

ここが方向転換で特に重要です。

例えば、

入力が面倒

なら、

提供方法を見直す

根拠になります。

しかし、

対象顧客を変える

根拠にはなりません。

短期案件では使われない

なら、

利用場面を絞る

根拠になる可能性があります。

しかし、

値下げする

根拠とは限りません。

広告から売れない

なら、

広告経由の購入が確認できていないことは分かります。

しかし、

商品を変える
顧客を変える

根拠にはなりません。

このように、

確認された問題と、変更対象を対応させる

必要があります。


STEP4:対象顧客を変えるべきか考える

方向転換でよくあるのが、

「この顧客層では市場が小さそうだから、もっと広げよう」

という判断です。

しかし、

市場が小さそう

という感覚だけでは、対象顧客を変える根拠にはなりません。

例えば、

Web制作・受託開発系の顧客で、

  • 課題が確認されている
  • 購入されている
  • 再購入されている

なら、

まずその顧客層には一定の根拠があります。

それにもかかわらず、

コンサルタント
士業
不動産
営業職

などへ一気に広げると、

新しい顧客層で、

  • 同じ課題があるか
  • 実際に利用するか
  • 支払うか

を一から確認する必要があります。


「対象顧客を変える」と「対象を絞る」は違う

例えば、

個人事業主全般

を対象にしていたサービスで、

実際には、

顧客とのやり取りが長い人
修正が何度も発生する人

だけが繰り返し使っていたとします。

この場合、

Web制作だけにする

より、

長期・複雑案件を持つ人へ絞る

方が、実際の利用条件に近い可能性があります。

つまり、

業種

ではなく、

案件の状態

が重要だった可能性があります。

方向転換では、

「誰だったか」

だけでなく、

どんな条件のときに使われたか

を見ることが重要です。


STEP5:利用場面を見直す

商品そのものではなく、

使う場面が広すぎる

ケースもあります。

例えば、

「案件整理に使えるサービス」

と説明していても、

実際に使われているのが、

  • 修正が何度も入ったとき
  • 顧客とのやり取りが長くなったとき
  • 案件を再開するとき
  • 引き継ぎ前

だけなら、

複雑になった案件の途中整理

へ利用場面を絞る方が、実際の価値に近くなります。


利用頻度が低いから「毎日使う商品」にしない

利用頻度が低いと、

「毎日使えるサービスにすればいい」

と考えたくなります。

例えば、

  • 案件一覧
  • 毎日のTODO管理
  • 通知
  • 進捗管理

などを追加する方法です。

しかし、

毎日使われていない
=毎日使える機能が必要

ではありません。

そもそも、

必要になる場面自体が月に数回しかない商品

かもしれません。

その場合、
無理に毎日利用される商品へ変えると、
元々確認できていた価値から離れてしまう可能性があります。


STEP6:提供内容と提供方法を分ける

商品改善では、

何を提供するか

と、

どう提供するか

を分けることも重要です。

例えば、AIが、

  • 決定事項
  • TODO
  • 未決事項
  • 確認事項
  • 次にやること

を整理するサービスがあったとします。

利用者から、

「結果は便利」

と言われている一方、

「入力するまでが面倒」

と言われている場合、問題は、

提供内容

ではなく、

提供方法

です。


「入力が面倒」から自動化まで飛ばない

ここでも飛躍に注意が必要です。

例えば、

「チャットを整理して貼るのが面倒」

と言われたからといって、すぐに、

Slack連携
メール連携
自動取得
完全自動化

を作る必要はありません。

まずは、

未整理のチャットやメールをそのまま貼れるようにする

だけで解決する可能性があります。

つまり、

確認された問題に対して、最小の変更から試す

のが基本です。


大きな変更ほど証拠を強くする

例えば、
入力欄を少し変えるだけなら、小さな変更です。

失敗しても、
元に戻すことが比較的簡単です。

一方、

  • 自動連携を開発する
  • 新しい顧客層向けに作り直す
  • 月額サービスへ変更する
  • 販売チャネルを全面変更する

となると、
費用・時間・開発工数が大きくなります。

そのため、

変更が大きいほど、その変更を支持する証拠も強くする

必要があります。


STEP7:価格・課金方法を変えるべきか考える

売上が伸びないと、

値下げした方がいい?

と考えることがあります。

再利用が少ないと、

月額課金にした方がいい?

と考えることもあります。

しかし、価格や課金方法も、

問題が確認されてから変更する

のが基本です。


実際に支払われている価格は重要な証拠

例えば、
1回2,000円で、

  • 5人が購入
  • 3人が再購入

しているなら、
少なくとも、

2,000円では誰も買わない

とは言えません。

一方で、

2,000円が最適価格

とも言えません。

つまり、

現在の価格で支払いが成立している

ことと、

最適価格である

ことは別です。


再購入されたから月額化、でもない

3人が再購入していても、

毎月使う

とは限りません。

例えば、

複雑な案件が発生したときだけ使う

商品なら、
都度払いの方が利用実態に合っている可能性があります。

月額化を考えるなら、

  • 一定頻度で利用されているか
  • 継続的な必要性があるか
  • 継続支払いが受け入れられるか

を確認します。


STEP8:販売方法を変えるべきか考える

例えば、
既存接点では売れたものの、
Xからは売れていないとします。

この場合、

Xはダメ
↓
広告へ変える

とは限りません。

なぜ売れなかったのかが分からないからです。

例えば、

  • 対象顧客に届いていなかった
  • 利用タイミングではなかった
  • 説明が伝わっていなかった
  • そもそも課題が弱かった

可能性があります。

したがって、

チャネルの結果と、商品そのものの価値を分けて考える

必要があります。


方向転換は一度に全部変えない

例えば、
売上を増やしたいからと、

  • 対象顧客を変える
  • 利用場面を変える
  • 機能を追加する
  • 価格を変える
  • 月額化する
  • 広告を始める

を一度に行ったとします。

結果が良くなっても、

何が効いたのか

分かりません。

悪くなっても、

何が原因だったのか

分かりません。

そのため、

変更は必要最小限にする

ことが重要です。


方向転換候補を小さくする

例えば、
現在、

Web制作・受託開発系向け
案件途中整理サービス

があり、
入力準備が負担になっているとします。

この場合、
大きな方向転換として、

毎日使う案件管理SaaSへ変更

するより、
まず、

チャットやメールを整理せず、そのまま入力しやすくする

方が変更範囲は小さくなります。

その状態で、

利用・再利用が増えるか

を確認できます。


追加確認が必要な変更と、すぐ試せる変更を分ける

すべての変更に大規模な検証が必要なわけではありません。

例えば、

小さく試せる変更

  • 入力方法を簡単にする
  • 利用場面の説明を明確にする

などは、

現在確認できている問題に直接対応しているなら、
比較的小さく試せます。

一方、

追加確認してから進めたい変更

  • 別業種への全面展開
  • 月額課金
  • 自動連携の開発
  • 多機能化
  • 大規模広告

などは、
費用や影響が大きいため、
より強い根拠が必要です。


分からないことがあるから、全部調査する必要はない

方向転換判断では、

「まだ分からないことがある」

状態が普通です。

しかし、

分からない
=調査する

ではありません。

重要なのは、

その情報が分かれば、判断が変わるか

です。

例えば、
現在の価格が最適か分からなくても、
入力方法を改善するかどうかを決めるには、必ずしも必要ありません。

一方、
月額課金へ変えるなら、

継続利用頻度

は重要です。

つまり、

今回の判断に必要な情報だけ確認する

ことが重要です。


方向転換でよくある失敗

売れないから顧客を変える

購入されない原因が顧客層だとは限りません。

市場が小さそうだから対象を広げる

現在の顧客層で需要が確認されているなら、まずその条件を詳しく見る必要があります。

利用頻度が低いから多機能化する

低頻度利用が商品の性質なら、多機能化しても毎日使われるとは限りません。

入力が面倒だから完全自動化する

小さな提供方法変更で解決する可能性があります。

再購入されたから月額化する

再購入と定期利用は別です。

広告で売れなかったから商品を変える

広告結果だけでは、商品に問題があるとは判断できません。

顧客から要望があったから機能追加する

一人の要望だけで、全体の方向転換を決めないことが重要です。


事業方向転換で見るべき順番

方向転換を考えるときは、

まず、

何が機能しているか

を確認します。

次に、

どこに問題があるか

を確認します。

さらに、

その問題の原因まで確認できているか

を見ます。

そのうえで、

問題が確認された場所だけ、小さく変える

という順番で考えると、判断しやすくなります。

整理すると、

維持するもの
↓
問題があるもの
↓
原因が分かっているもの
↓
変更するもの
↓
変更後に確認するもの

という流れです。


AIを使うと方向転換判断をどう整理できるか

事業を運営している本人は、

「もっと大きなサービスにしたい」
「本格的なSaaSにしたい」
「月額モデルにしたい」

といった希望を持つことがあります。

一方で、

「ここまで作ったものを変えたくない」

という気持ちも出ます。

こうした状態では、

事実と希望が混ざりやすくなります。

AIを使うと、

  • 維持する根拠
  • 変更する根拠
  • まだ原因が分からない問題
  • 追加確認が必要な変更
  • 最小変更で済む候補

を分けて整理できます。

ただし、

「どうピボットすればいい?」

とだけ聞くと、
AIが新しい顧客や商品案を大量に作ることがあります。

それより、

現在の証拠から、どこを変える必要があるか

を整理させる方が、
現在の事業を活かした判断につながります。


WorkPaletteでは「事業方向転換判断」で整理できる

WorkPaletteの「事業方向転換判断」では、

まず、

  • 対象顧客
  • 顧客課題
  • 利用場面
  • 提供内容
  • 提供方法
  • 価格
  • 課金方法
  • 販売方法

を分けます。

そのうえで、

  • 維持する根拠がある部分
  • 変更根拠がある部分
  • まだ原因が分からない部分

を整理します。

さらに、

何を残して、どこだけ変えるか

を比較します。

例えば、

入力が面倒

という問題が確認されたとしても、

すぐに、

自動連携を開発する

とは判断しません。

まず、

入力前の整理作業を減らす

など、より小さな変更で対応できないかを見ます。

また、

再購入がある

という理由だけで、

月額課金へ変更

することもありません。

現在確認できている利用頻度や支払い行動から、
変更根拠があるかを整理します。


事業継続・撤退判断との違い

WorkPaletteには、「事業継続・撤退判断」というAIフローもあります。

こちらは、

この事業自体を今後どう扱うか

を判断するためのものです。

例えば、

  • 現条件で継続
  • 条件を絞って継続
  • 追加検証
  • 縮小
  • 一時保留
  • 方向転換
  • 撤退

を比較します。

一方、「事業方向転換判断」では、
方向転換する可能性がある事業について、

何を残し、何を変えるのか

を整理します。

つまり、

事業継続・撤退判断
↓
方向転換が候補になる
↓
事業方向転換判断
↓
変更箇所を特定する

という使い分けができます。


まとめ

事業の方向転換では、

何を変えるか

だけを考えないことが重要です。

まず、

何を残すべきか

を確認します。

そのうえで、

  • 対象顧客
  • 顧客課題
  • 利用場面
  • 提供内容
  • 提供方法
  • 価格・課金
  • 販売方法

を分け、

問題が確認された部分だけを見直します。

特に、

売れないから顧客を変える
利用頻度が低いから月額化する
入力が面倒だから自動化する
広告で売れないから商品を変える

といった飛躍を避けることが大切です。

すでに、

  • 購入
  • 再購入
  • 利用後の価値

が確認されている部分まで変える必要はありません。

方向転換とは、

事業をすべて作り直すことではなく、
確認済みの価値を残しながら、
問題がある部分だけを変えること

でもあります。

大きく変える前に、

今の事業で何がすでに機能しているのか

から整理してみてください。

WorkPaletteの「事業方向転換判断」では、
現在の利用・購入・顧客反応・改善結果から、

維持するもの
変更するもの
まだ変更しないもの
変更後に確認するもの

を順番に整理できます。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です