事業を方向転換した後は何を検証する？｜全部やり直さず、変更した部分だけ再検証する方法

はじめに

事業やサービスを方向転換したあと、

「もう一度MVPからやり直した方がいい？」
「顧客課題も確認し直すべき？」
「価格もまた検証した方がいい？」
「以前の購入実績はもう使えない？」

と迷うことがあります。

方向転換すると、
それまで積み上げてきた検証結果まで、
すべて使えなくなったように感じることがあります。

しかし、

方向転換した
↓
すべて最初から検証し直す

必要があるとは限りません。

一方で、

過去に一度検証した
↓
方向転換後もそのまま使える

とも限りません。

重要なのは、

何を変えたことで、どの前提が変わったのか

を見ることです。

例えば、
入力方法だけを変えたなら、
顧客課題や対象顧客まで最初から確認し直す必要がない場合があります。

一方、
対象顧客そのものを変えたなら、
以前の顧客で確認した購入・再購入実績を、
新しい顧客にもそのまま当てはめることはできません。

この記事では、

方向転換後に、どこまで戻って再検証すればよいか

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

---

方向転換後の再検証で大切なこと

方向転換後の再検証では、
二つの極端な考え方を避けることが重要です。

一つは、

全部やり直す

ことです。

もう一つは、

以前確認したから、何も確認し直さない

ことです。

どちらも、
変更範囲を見ていません。

見るべきなのは、

• 今回変更したもの
• 今回維持したもの
• 過去に確認できていたもの
• 変更によって使えなくなった証拠
• 変更後も引き継げる証拠
• 新しく不明になったこと

です。

つまり、

変更された前提だけを再検証する

という考え方が基本になります。

---

STEP1：まず何を変えたかを分解する

最初に、

方向転換前と後で、何が変わったか

を整理します。

例えば、

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

を分けます。

方向転換といっても、
このすべてが変わるとは限りません。

例えば、

利用者が情報を整理して入力する

方式から、

未整理のメールやチャットをそのまま入力する

方式へ変えた場合、
変わっているのは主に、

提供方法

です。

対象顧客や顧客課題、
価格まで変わったわけではありません。

---

「方向転換した」という言葉だけで全部変更扱いにしない

方向転換という言葉は、
かなり大きな変更に聞こえます。

しかし、

「ピボットした」

と表現していても、
実際には、

• 利用場面を絞った
• 入力方法を変えた
• 対象顧客を絞った
• 販売方法だけ変えた

という小さな変更の場合があります。

そのため、

方向転換の大きさではなく、実際に変えた項目を見る

ことが重要です。

---

STEP2：方向転換前に何が確認できていたか整理する

次に、
方向転換前の証拠を整理します。

例えば、

• 顧客課題についての発言
• 実際の利用
• 購入
• 支払い
• 再利用
• 再購入
• 継続支払い
• 利用後の価値
• 改善結果
• 販売結果

などです。

ここで重要なのは、

方向転換前の証拠を全部捨てないこと

です。

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

• 実際に利用された
• 2,000円で購入された
• 再購入された
• 整理結果に価値を感じてもらえた

なら、
それらは、

その顧客層では成立した事実

です。

方向転換したからといって、
その事実自体が消えるわけではありません。

---

ただし「以前確認した」は新しい条件の証拠ではない

一方で、
以前の証拠が、

変更後にもそのまま成立するか

は別です。

例えば、
Web制作・受託開発系では、

1回2,000円で購入された

としても、
対象顧客を士業へ変えた場合、

士業も2,000円を払う

とは言えません。

つまり、

過去の実績は事実として残るが、新しい条件での成立証拠にはならない

ことがあります。

---

STEP3：証拠を「引き継げるもの」と「引き継げないもの」に分ける

方向転換後は、
過去の証拠を、

• そのまま引き継げる
• 一部だけ引き継げる
• 変更後にはそのまま使えない
• 判断材料不足

に分けると整理しやすくなります。

---

提供方法だけ変えた場合

例えば、
対象顧客も顧客課題も変えず、

入力方法だけを変更した

とします。

この場合、

• 顧客課題の存在
• 対象顧客
• これまでの利用場面
• 過去の購入実績
• 過去の再購入実績

まで、
すべて未確認に戻す必要はありません。

一方で、

新しい入力方法でも問題なく使えるか

は新しく確認する必要があります。

---

対象顧客を変えた場合

一方で、

Web制作・受託開発系
↓
士業

のように、
対象顧客そのものを変更したとします。

この場合、
旧顧客で確認した、

• 顧客課題
• 利用
• 顧客価値
• 購入
• 支払い
• 再購入

は、

士業でも成立する証拠

にはなりません。

ただし、

• AI整理機能が動く
• Webフォームで提供できる
• 都度払いができる

といった提供・運用面まで、
最初から作り直す必要はありません。

---

STEP4：変更によって何が新しく不明になったかを見る

方向転換後の再検証では、

変更したことで、何が新しく分からなくなったか

を確認します。

例えば、
提供方法を変えた場合、

未整理のチャットをそのまま貼れる

ようにしたとします。

このとき新しく不明になるのは、

• 実際に入力しやすくなったか
• AIの整理結果の品質を保てるか
• 入力と結果確認を含む総負担が減ったか
• 利用につながるか
• 再利用につながるか

などです。

一方、

顧客課題があるか

まで未確認に戻るとは限りません。

---

変更した項目によって戻る地点は変わる

再検証の戻り地点は、
変更内容によって変わります。

例えば、

提供方法だけ変更

なら、

変更部分だけ再検証

で済む場合があります。

販売方法だけ変更

なら、

その販売方法で顧客へ届くか

を確認すればよく、
顧客課題まで戻る必要はないことがあります。

価格変更

なら、

新価格で実際に支払われるか

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

対象顧客変更

なら、

顧客課題まで戻って再検証

する必要がある場合があります。

---

STEP5：どの地点まで戻るか決める

再検証では、
例えば次のような戻り地点を考えられます。

• 追加検証不要で継続
• 変更部分だけ再検証
• 販売条件まで戻って再検証
• MVPとして再検証
• 解決策まで戻って再検証
• 顧客課題まで戻って再検証

重要なのは、

できるだけ上流まで戻ること

ではありません。

逆に、

できるだけ検証を省くこと

でもありません。

今回の変更によって、
どこから先の証拠が使えなくなったのかを見ることが重要です。

---

提供方法だけ変えたケース

例えば、
AI案件整理サービスで、

変更前は、

利用者がメールやチャットを整理してから入力

していたとします。

それを、

未整理のまま貼り付け、AI側で整理

する方法へ変えたとします。

この場合、
対象顧客も顧客課題も、
価格も中核機能も変わっていません。

方向転換前に、

• 5人が2,000円で購入
• 3人が再購入
• 顧客課題も複数人で確認
• 整理結果への評価も確認

できているなら、

顧客課題から再検証

する必要はありません。

---

この場合に再検証すること

見るべきなのは、

• 未整理の情報をそのまま入力できるか
• 入力準備の負担が減るか
• 結果確認まで含めた総負担が減るか
• 整理結果が実務で使えるか
• 新しい方法でも有料利用されるか
• 再利用・再支払いにつながるか

です。

つまり、

変更部分だけ再検証

します。

---

過去の購入実績はどう扱う？

このケースでは、
過去の2,000円での購入実績を、

なかったことにする

必要はありません。

しかし、

新しい提供方法でも2,000円を払う

ことまで確認済みではありません。

したがって、

旧価格で支払いが成立した実績は引き継ぐが、新方式でも支払われるかは確認する

という扱いになります。

この区別が重要です。

---

対象顧客を変えたケース

次に、
対象顧客そのものを変えるケースです。

例えば、

Web制作・受託開発系
↓
士業

へ変更したとします。

旧顧客では、

• 顧客課題
• 実利用
• 顧客価値
• 2,000円での購入
• 再購入

まで確認できていたとします。

しかし、
士業では、

「案件ごとにメールを探すことがある」
「確認事項を見失うことがある」

という発言だけ確認できている状態です。

---

この場合は顧客課題まで戻る

対象顧客を変えた場合、
確認する必要があるのは、

• 士業でも同じ課題が強く存在するか
• どんな場面で困るか
• 現在の整理内容に価値を感じるか
• 実際に利用するか
• 2,000円を支払うか
• 再利用するか

です。

つまり、

顧客課題まで戻って再検証

します。

---

ただし全部作り直すわけではない

ここでも重要なのは、

顧客課題まで戻る
＝サービスを全部作り直す

ではないことです。

例えば、

• 現在のAI整理機能
• Webフォーム
• 5つの整理項目
• 1回2,000円
• 都度払い

は、
そのまま試すことができます。

つまり、

市場側の証拠だけ取り直す

という形です。

---

2,000円の価格は再設計する必要がある？

対象顧客を変えた場合でも、

2,000円という価格を一度捨てる

必要はありません。

旧顧客では、
実際に2,000円で購入されています。

そして、
新しい顧客向けに価格変更が必要だという証拠もまだありません。

そのため、

2,000円を検証価格として固定して試す

ことができます。

ただし、

士業でも2,000円が成立する

と確定扱いにはしません。

---

売れなかったから価格が悪い、とも限らない

新しい顧客で2,000円の商品が売れなかった場合、

価格が高い

とは限りません。

例えば、

• 課題が弱い
• 利用場面が違う
• 整理結果に価値を感じない
• 案内方法が伝わっていない

可能性もあります。

そのため、

購入されなかった＝価格問題

と決めつけないことも重要です。

---

STEP6：再検証する問いを絞る

再検証では、

分からないことを全部調べる

必要はありません。

重要なのは、

今回の方向転換判断に必要な問いだけ残す

ことです。

例えば、
提供方法だけ変えた場合、

• 顧客課題があるか
• 市場規模は十分か
• 月額課金がよいか
• 新しい販売チャネルはあるか

まで調べる必要はありません。

確認すべきなのは、

新しい提供方法が成立するか

です。

---

「確認できること」と「確認すべきこと」は違う

検証できるテーマは、
いくらでも増やせます。

しかし、

確認できる
＝確認すべき

ではありません。

例えば、
入力方法を変えた直後に、

市場規模を調べる

ことができたとしても、
入力方法変更の採否判断には必要ないかもしれません。

見るべきなのは、

その情報が分かると、今回の判断が変わるか

です。

---

STEP7：固定する条件を決める

再検証するときは、

何を変えないか

も重要です。

例えば、
対象顧客を士業へ変えた場合、

• AI整理機能
• Webフォーム
• 5つの整理項目
• 価格2,000円
• 都度払い

を固定したまま試すことができます。

そうすることで、

新しい顧客でも現在の仕組みが成立するか

を確認しやすくなります。

---

一度に複数条件を変えない

例えば、
対象顧客を変えるのと同時に、

• 価格も変える
• 月額化する
• 機能を追加する
• 販売方法も大きく変える

と、

結果が変わったときに、

何が原因だったか

分かりにくくなります。

そのため、

方向転換で変えた部分以外は、できるだけ固定する

ことが重要です。

---

STEP8：再検証後に何を判断するか決める

再検証の目的は、

データを集めること

ではありません。

最終的には、

方向転換後の条件を採用するか

を判断するために行います。

例えば、
提供方法を変えた場合、

• 入力負担が減った
• 結果品質も保てた
• 実際に利用された
• 支払いが発生した
• 再利用された

なら、
新しい提供方法を維持する根拠になります。

一方、

入力は楽になったが、結果修正の負担が増えた

なら、
提供方法をさらに見直す必要があるかもしれません。

---

方向転換後の再検証でよくある失敗

方向転換したから全部MVPからやり直す

変更していない顧客課題や価格まで、
自動的に未確認になるわけではありません。

過去に売れたから、新しい顧客にも売れると思う

旧顧客の購入実績は、
新顧客での購入証拠にはなりません。

対象顧客を変えたのに販売方法だけ試す

顧客が変わったなら、
課題・価値・利用・支払いまで確認する必要があります。

提供方法だけ変えたのに市場調査からやり直す

変更範囲に対して、
検証範囲が広すぎます。

価格を変えていないから支払いを見ない

旧価格で支払われていても、
変更後の条件でも支払われるかは別です。

未確認事項を全部調べる

今回の判断に影響しない未確認事項まで、
再検証する必要はありません。

---

方向転換後の再検証で見る順番

再検証を考えるときは、

まず、

何を変えたか

を確認します。

次に、

何を変えていないか

を確認します。

そのうえで、

過去の証拠のうち、何を引き継げるか

を整理します。

さらに、

変更によって何が新しく分からなくなったか

を確認します。

最後に、

その部分だけ再検証する

という流れにすると整理しやすくなります。

まとめると、

変更点を確認
↓
維持した条件を確認
↓
既存証拠を整理
↓
無効になった証拠を特定
↓
戻る地点を決める
↓
必要な問いだけ再検証

という流れです。

---

AIを使うと再検証範囲をどう整理できるか

方向転換した直後は、

「全部もう一度確認した方が安全そう」

と思いやすくなります。

逆に、

「ここまで検証したのだから、もう確認しなくていい」

と思うこともあります。

AIを使うと、

• 今回変更したもの
• 変更していないもの
• 引き継げる証拠
• 引き継げない証拠
• 新しく不明になったこと
• 戻るべき検証地点
• 再検証する問い
• 固定する条件

を分けて整理できます。

ただし、

「方向転換後は何を調べればいい？」

とだけ聞くと、
確認項目が広がりすぎることがあります。

それより、

何を変えたことで、どの証拠が使えなくなったのか

を基準に整理させる方が、
再検証範囲を小さくできます。

---

WorkPaletteでは「方向転換後再検証設計」で整理できる

WorkPaletteの「方向転換後再検証設計」では、

まず、

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

について、
方向転換前後の差分を整理します。

そのうえで、

• 方向転換前に確認できていた証拠
• そのまま引き継げる証拠
• 一部だけ引き継げる証拠
• 変更後には使えない証拠
• 新しく確認が必要になったこと

を分けます。

さらに、

• 追加検証不要で継続
• 変更部分だけ再検証
• 販売条件まで戻って再検証
• MVPとして再検証
• 解決策まで戻って再検証
• 顧客課題まで戻って再検証

を比較します。

---

事業方向転換判断との違い

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

何を残し、どこを変えるか

を決めます。

一方、
「方向転換後再検証設計」では、

変えたあと、どこまで確認し直すか

を決めます。

つまり、

事業方向転換判断
↓
変更箇所を決める
↓
方向転換後再検証設計
↓
必要な範囲だけ再検証する

という流れです。

---

事業継続・撤退判断からつなげることもできる

さらに前段では、

「事業継続・撤退判断」で、

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

を比較できます。

そこで、

方向転換

が候補になった場合、

事業方向転換判断
↓
方向転換後再検証設計

とつなげることができます。

---

まとめ

方向転換したからといって、

すべての検証を最初からやり直す必要はありません。

一方で、

以前確認した証拠を、変更後にもそのまま使えるとは限りません。

重要なのは、

• 何を変えたか
• 何を維持したか
• どの証拠が成立していたか
• 変更によってどの証拠が使えなくなったか
• 何が新しく不明になったか

を分けることです。

例えば、
提供方法だけを変えたなら、

変更部分だけ再検証

で済むことがあります。

一方、
対象顧客そのものを変えたなら、

顧客課題まで戻って再検証

する必要がある場合があります。

それでも、

• AI機能
• Webフォーム
• 現在の価格
• 課金方法
• 既存システム

まで、
すべて作り直す必要はありません。

方向転換後の再検証では、

過去の証拠を捨てすぎず、使い回しすぎない

ことが重要です。

変更によって成立条件が変わった部分だけ、
もう一度確認してみてください。

WorkPaletteの「方向転換後再検証設計」では、
方向転換前後の差分と既存証拠を整理しながら、

どこまで戻るか
何を再検証するか
何を固定するか
何を再検証しなくてよいか

を順番に整理できます。