MVP設計

【対象顧客】 副業を始めたいが、 次に何をすればいいか迷って行動が止まりやすい会社員。 【今回検証したい顧客課題】 副業を始めようとしても、 次にやることを決められず行動が止まること。 【課題について確認できていること】 9人に話を聞きました。 ・3人から「何から始めればいいか分からない」「調べているうちに時間が過ぎる」といった話が出た ・2人は副業を始めたが現在は継続していない ・1人から「毎日やることを決めてくれたら続けられそう」という発言があった ・YouTubeで大体やり方が分かるという人もいる 「次にやることが分からない」ことが主要原因かは確認できていません。 【今回検証する解決方向】 利用者の状況を聞き、 その時点で次に行う小さな行動を1つ提示するAI支援。 【この解決方向で期待していること】 次にやることを自分で考える負担が減り、 情報収集だけで終わらず実際の行動に移りやすくなると考えています。 ただし、実際に行動が増えるかは未確認です。 【顧客に最低限体験してほしいこと】 ・自分の現在の状況を伝える ・次にやる行動を1つ受け取る ・その行動を実際にやるか判断する ・実施後に次の行動を受け取る 【現時点で考えている機能・提供内容】 ・現在の副業状況を入力する ・AIが次の行動を1つ提示する ・行動後の状況を入力する ・次の行動を再度提示する 【MVPでは省いてもよいと思っているもの】 ・ログイン ・プロフィール ・過去履歴一覧 ・通知 ・ランキング ・成果グラフ ・課金 ・スマートフォンアプリ化 【人手で代替できそうなもの】 AIへの入力内容を見て、 裏側で人が次の行動候補を作ることは可能だと思っています。 ただし、 「AIが自分の状況に合わせて次の行動を出してくれること」自体に価値があるかを確認したいので、 完全に人による相談サービスへ変えるのは違う気もしています。 【現在使える既存ツール・方法】 ・フォーム ・メール ・チャット ・生成AI ・スプレッドシート 新しいアプリを作らなくても、 これらを組み合わせれば試せるのではないかと考えています。 【顧客側に必要になりそうなこと】 ・現在の状況を入力する ・提示された行動を読む ・実際に行動する ・行動したかどうかを返す 【現在ある制約】 ・開発に大きな工数はかけたくない ・まず解決方向が有効か確認したい ・少人数で運営する ・具体的な検証期間や人数はまだ決めていない 【確認済みの事実】 ・AIによる次の行動提示を実際に使った顧客はいない ・次の行動を提示すれば行動が増えるかは確認していない ・AIである必要があるかも確認していない ・継続利用意思は確認していない ・支払意思も確認していない 【まだ仮説だと思っていること】 ・次の行動が分かれば実際に動ける ・行動を1つに絞ると迷いが減る ・AIなら状況に応じて適切な行動を出せる ・AIによる個別提示に価値がある ・何度か使えば副業を継続しやすくなる ・将来的に月額サービスとして成立する 【自分が作り込みたくなっているもの】 ・ユーザー登録 ・行動履歴 ・毎日の通知 ・進捗グラフ ・AIとのチャット画面 ・おすすめ副業診断 ・継続日数表示 ・有料プラン ただ、 これらを最初から作る必要があるのか疑問です。 【MVPで特に判断したいこと】 ・「次の行動を1つ提示する」という解決方向自体に意味があるか ・提示された行動を実際に行うか ・AIであることが必要なのか ・どこまで人手で代替しても同じ仮説を検証できるか ・最初のMVPに最低限何を含めればよいか ・何を作らずに済ませられるか ・MVP実施後に何を見て次の判断をすべきか

【今回のMVPで検証する顧客課題】 副業を始めたい会社員が、次に何をすればよいか決められず、情報収集だけで時間が過ぎるなどして行動が止まること。 9人への聞き取りでは、3人から関連する発言があり、2人は副業を継続していなかった。ただし、**「次の行動を決められないこと」が行動停止や中断の主要原因かは未確認**である。 --- 【今回検証する解決方向】 利用者の現在の副業状況、すでに行ったこと、止まっていることを確認し、その時点で次に行う小さく具体的な行動を、生成AIを利用して1つだけ提示する。 利用者が実施結果を返した後、その状況に応じた次の行動をもう1つ提示する。 --- 【最優先で検証する仮説】 1. 対象顧客は、この課題を解決するために現在の状況を入力し、行動提示を受ける。 2. 状況に合った小さな行動を1つ提示すると、次に何をするかが明確になり、考える負担や迷いが減る。 3. 提示された行動が具体的かつ実施可能であれば、利用者は実際に開始または完了する。 4. 利用者は、状況入力と実施結果の報告に必要な負担を許容できる。 5. 提示された行動は、利用者の現在の状況に合っており、「今の自分が次に行うこと」として受け入れられる。 6. 実施結果を返した利用者が、結果に応じた2回目の行動を受け取るところまで進める。 これらは現時点では仮説であり、実際の行動増加、継続利用、AIの必要性は確認されていない。 --- 【今回のMVPで答える問い】 **副業を始めたいが次の行動を決められず止まっている会社員に対して、現在の状況に合った小さな行動を1つ提示すると、必要な入力・報告負担を許容したうえで、実際にその行動を起こすか。** あわせて、結果を報告し、2回目の行動を受け取るところまで基本的な反復体験が成立するかを確認する。 AIであることの必要性、長期的な継続、支払意思、事業成立は、この中心的な問いと分けて扱う。 --- 【対象となる顧客】 以下に該当する会社員を対象とする。 - 副業を始めたい意向が現在もある - 次に何をすればよいか迷い、行動が止まりやすい - 現在の状況、すでに行ったこと、止まっていることを入力できる - 提示された行動を実施するか判断できる - 実施・未実施の結果を返せる 次にやることがすでに明確で、時間、疲労、不安、優先順位など別の理由だけで止まっている人については、今回想定する課題への該当状況を分けて記録する。 --- 【顧客に提供する最低限の体験】 1. 現在の副業状況、すでに行ったこと、止まっていることを伝える。 2. 現在の状況に応じた、小さく具体的な行動を1つだけ受け取る。 3. その行動が自分の状況に合うか、実施できるかを判断する。 4. 実際に行動を開始または完了する。実施しない場合も、その事実を返す。 5. 実施・未実施と、その後の状況を報告する。 6. 報告内容に応じた2回目の行動を1つ受け取る。 今回必要な変化は、副業の収益化や長期継続ではなく、**「迷って止まっている状態」から「具体的な行動を1つ実施した状態」へ移ること**である。 2回目の行動の実施までは、全利用者の必須体験とはしない。 --- 【MVPに含めるもの】 - フォーム、メール、チャットのいずれか1つによる状況入力 - 以下の最低限の入力項目 - 現在の副業状況 - すでに行ったこと - 現在止まっていること、迷っていること - 入力内容を使った、生成AIによる次の行動の作成 - 「今、次に行う小さく具体的な行動1つ」に限定した提示 - 必要な場合に限った、人によるAI出力の確認・最小限の修正 - 行動を同じ連絡手段で利用者へ返す手順 - 実施・未実施と実施後の状況を報告する手段 - 結果報告に応じた2回目の行動作成と提示 - スプレッドシートなどによる以下の記録 - 利用者の入力内容 - AIへ渡した内容 - AIが生成した行動 - 人による修正の有無、内容、程度 - 実際に提示した行動 - 実施・未実施 - 未実施理由 - 実施後の状況 - 2回目に提示した行動 - 入力から提示までの応答状況 --- 【MVPに含めないもの】 - ログイン - 会員登録、ユーザー登録 - プロフィール画面 - 詳細な職歴や目標収入の必須入力 - 過去履歴一覧 - 行動履歴を閲覧・管理する画面 - ダッシュボード - 専用のAIチャット画面 - 毎日の通知、自動通知 - 進捗グラフ - 継続日数表示 - ランキング - おすすめ副業診断 - 検索 - 分析機能 - レポート - エクスポート - 専用の管理画面 - 決済、課金機能 - 有料プラン - 権限管理 - 外部サービス連携 - API - スマートフォンアプリ - 副業全体の詳細な計画 - 複数の行動候補を比較・選択する機能 - 長期継続を促す仕組み - AIだけで応答を完結させる仕組み - 長期間の行動履歴 - 2回目に提示した行動の実施を全利用者に求めること - フォーム、メール、チャットのすべてを用意すること --- 【人手・既存手段で代替できるもの】 - フォーム、メール、チャットのいずれか1つで、入力・提示・結果報告・2回目の提示を行う - 運営者が利用者の入力を既存の生成AIへ手動で渡す - 生成AIの出力について、実施不可能、具体性不足、状況との不一致がある場合だけ人が修正する - 人が生成された行動を利用者へ送信する - 実施結果やAI出力、人の修正内容をスプレッドシートへ記録する - 結果報告を人が生成AIへ渡し、2回目の行動を作成・送信する 自動連携、自動送信、専用画面、専用データベースは今回の体験に必須ではない。 ただし、人は追加相談、励まし、複数の助言を行わず、顧客体験を「状況を伝え、行動を1つ受け取る」範囲に保つ。 --- 【代替すると確認できなくなること】 ### 人が最初から行動を作成した場合 確認できるのは、「作成者を問わず、次の行動を1つ提示すると行動につながるか」までとなる。 以下は確認できない。 - AIが状況に応じた行動を作れるか - AIによる個別提示に価値があるか - AI単独で十分な品質を出せるか - AIである必要があるか - 人による確認や修正をなくせるか ### 人がAI出力を大幅に書き換えた場合 以下が判断しにくくなる。 - 生成AIが実用的な行動候補を作れるか - AI出力を今回の提供に利用できるか - 人による修正をどこまで減らせるか ### 人が相談や励ましを追加した場合 「行動を1つ提示した効果」と「人による相談支援の効果」を分けられなくなる。 ### 人手運用により返答が大幅に遅れた場合 行動しなかった原因が、解決方向ではなく応答の遅さである可能性が生じる。 --- 【MVP実施に必要な条件】 - 利用者が想定顧客に該当するか確認できる - 状況入力から2回目の行動受領まで、一連の体験を提供できる - 提示内容を、複数案ではなく行動1つに限定する - 行動が具体的で、完了条件を判断でき、実施可能な大きさになっている - 行動作成に生成AIを使用する - 人が修正した場合は、AI出力と最終提示を分けて記録する - 人による修正方針を途中で大きく変えない - AIへの入力方法や指示を検証途中で大きく変えない - 未実施の場合も報告できる - 未報告と未実施を同一視しない - 応答の遅さや入力方法の分かりにくさが、主な障害になっていないか確認できる - 人による励まし、追加相談、複数の助言を加えない - 通知、進捗表示、ランキングなど、今回確認しない要素を同時に追加しない - AIへの印象と、提示された行動そのものへの評価を分けて記録する --- 【検証時に確認すること】 - 次に何をするかが明確になったか - 自分で次の行動を考える負担や迷いが減ったか - 提示内容が現在の状況に合っていたか - 具体的で、何をすれば完了か判断できたか - 実施可能な大きさだったか - 実際に行動を開始または完了したか - 実施しなかった場合、何が妨げになったか - 状況入力や結果報告の負担が利用を止めなかったか - 行動は実施したが、報告だけしなかった可能性がないか - 結果を報告して2回目の行動を受け取ったか - 2回目の提示を必要と感じたか - AI出力をそのまま提示できたか - 人による修正が必要だった場合、その程度と理由 - AIであることが利用判断や行動判断に影響したか - YouTubeや検索などの既存方法で十分だったか、個別提示に追加の意味があったか --- 【顧客へ確認すること】 ### 利用前 - 副業を始めたい意向が現在もあるか - 次に何をするか分からないことが、実際に止まっている理由か - 次にやることが分かっている場合、何が行動を妨げているか - これまでに調べたこと、試したこと、迷っていること - YouTubeや検索などの既存方法で不足していること、または十分だと感じていること ### 行動を受け取った後 - 内容を具体的な次の行動として理解できたか - 何をすれば完了か判断できたか - 現在の状況に合っていたか - 実施できる負担だったか - 1つに絞られたことで判断しやすくなったか - 自分で考える負担が減ったか - 実施しようと思ったか、思わなかった場合はなぜか ### 実施・未実施後 - 実際に開始または完了したか - 提示がなくても同じタイミングで行っていたと思うか - 実施・未実施の理由 - 結果報告に負担や報告しにくさがなかったか - 2回目の行動を受け取る必要を感じたか - AIであることが利用や行動の判断に影響したか - 同じ内容がAI以外から同じ条件で提示されても利用したと思うか --- 【行動として確認すること】 感想とは分けて、以下の事実を確認する。 - 状況入力を完了した - 最初の行動を受け取った - 提示内容を読んだ - 実施するか判断した - 行動を開始した - 行動を完了した、または途中で止まった - 実施・未実施を報告した - 未実施理由を報告した - 実施後の状況を入力した - 2回目の行動を受け取った - 2回目の行動も具体的で状況に合っていた - AI出力がそのまま提示されたか、人が修正したか - 応答の遅れが行動へ影響しなかったか 「便利だった」「役立ちそうだった」という感想だけでは、行動変化を確認したことにしない。 報告がない場合は、未実施、実施済みだが未報告、未受領、理解不足、利用方法の誤解、報告負担、確認不能を区別する。 --- 【今回のMVPでは判断できないこと】 - 「次の行動が分からないこと」が副業停止の主要原因であると一般化できるか - AIであること自体に追加価値があるか - AIと人のどちらが優れているか - AI単独で十分な品質を出せるか - 人による確認や修正をなくせるか - 完全自動化が必要か - 長期的に副業を継続できるか - 副業の収益化や成果につながるか - 毎日利用するか - 長期的な継続利用意思があるか - 支払意思があるか - 適切な価格 - 月額サービスとして成立するか - 商品として成立するか - 事業として成立するか - 通知、履歴、進捗表示などが継続に有効か - 専用アプリや専用画面が必要か --- 【MVP実施後に判断すること】 利用者ごとの前提条件、提示内容、行動、未実施理由を対応づけて、以下を判断する。 ### 継続して検証するか - 次の行動が明確になった - 考える負担や迷いが減った - 実際の行動開始または完了が確認された - 結果報告後に2回目の行動を受け取る流れが成立した - ただし、対象条件、AIの必要性、反復利用などに未確認事項が残っている ### 解決方向を見直すか 適切な対象者に、状況に合った具体的で実施可能な行動を提示しても、以下が繰り返し確認された場合に検討する。 - 次に何をするかが明確になっても行動しない - 行動停止の中心的な理由が、時間、不安、疲労、優先順位など別の要因だった - 1つに絞っても迷いが減らない - 状況入力の負担が、受け取る価値を上回る - 既存の情報収集方法で十分で、個別提示を必要としない - 2回目の行動を受け取る必要がない ### AIの役割を見直すか - AI出力が、人による大幅な修正なしでは実施可能な内容にならない - AIであることが利用判断や行動判断に影響しない - 人による支援のほうが必要だと確認される これは、「次の行動を1つ提示する」という方向全体の評価と分けて判断する。 ### 判断を保留するか - 対象顧客が合っていなかった - 入力情報が不足していた - 提示内容が抽象的または実施不可能だった - 応答が遅かった - 報告漏れと未実施を区別できなかった - 人の介入が大きすぎた - 検証途中で提供条件を大きく変更した 人数、期間、成功率などの合格ラインは、現時点では設定されていないため新たに作らない。 --- 【次の行動】 1. フォーム、メール、チャットから使用する手段を1つ決め、状況入力、行動提示、結果報告、2回目の提示までの流れを準備する。 2. 生成AIへの入力方法、「小さく具体的な行動1つ」の基準、人が修正する範囲、記録方法を揃える。 3. 想定顧客への該当状況を確認したうえで、最低限の体験を提供する。 4. 利用者の入力、AI出力、修正内容、最終提示、実施・未実施、未実施理由、2回目の提示までを対応づけて記録する。 5. 結果を「継続検証」「解決方向の見直し」「AIの役割の見直し」「判断保留」に分け、確認できたことと未確認のことを整理する。

【対象顧客】 小規模なWeb制作会社や受託開発会社で、 複数案件を同時に担当しているディレクターやプロジェクト担当者。 【今回検証したい顧客課題】 案件情報を探したり、 会議後に決定事項やTODOを整理したりする手間が一部の担当者にあること。 【課題について確認できていること】 8人に話を聞きました。 ・3人から、過去情報を探すのが面倒という話が出た ・2人から、案件が増えると情報整理が大変という話が出た ・1人は会議後に決定事項をNotionへ手動転記している ・1人は「今の方法で特に困っていない」と話した 具体的な作業時間、 頻度、 業務への影響、 支払意思は確認していません。 【今回検証する解決方向】 メール、チャット、議事録などの案件情報から、 ・決定事項 ・TODO ・未決事項 ・担当者 ・期限 をAIが案件ごとに整理する方法。 【この解決方向で期待していること】 ・会議後の手動整理を減らせる ・過去情報を探す手間を減らせる ・案件状況を確認しやすくなる と考えています。 ただし、 実際に負担が減るかは確認していません。 【顧客に最低限体験してほしいこと】 ・実際の案件情報を渡す ・AIで整理された案件情報を受け取る ・内容が現在の案件状況として使えるか確認する ・必要なら誤りや不足を修正する ・普段の整理や確認より負担が減ったか判断する 【現時点で考えている機能・提供内容】 ・案件情報の入力または取り込み ・AIによる決定事項、TODO、未決事項、担当者、期限の整理 ・整理結果の表示 ・必要な場合の修正 【MVPでは省いてもよいと思っているもの】 ・ログイン ・案件一覧画面 ・ダッシュボード ・自動通知 ・権限管理 ・複数人での共同編集 ・課金 ・管理画面 ・スマートフォンアプリ 【人手で代替できそうなもの】 顧客から受け取った案件情報を、 運営者が生成AIへ手動で入力し、 出力結果を顧客へ返すことはできると思っています。 一方で、 人が案件内容を読んで自分で決定事項やTODOを整理してしまうと、 「AIで案件情報を整理できるか」は確認できなくなると思っています。 【現在使える既存ツール・方法】 ・メール ・チャット ・フォーム ・生成AI ・スプレッドシート ・Notion 新しいSaaSを作らなくても、 最初の検証はできるのではないかと考えています。 【顧客側に必要になりそうなこと】 ・検証に使う案件情報を提供する ・整理結果を確認する ・間違いや不足があれば伝える ・普段の方法と比べて使えるか判断する 【現在ある制約】 ・少人数で運営する ・本格開発前に解決方向を確認したい ・大きな初期開発は避けたい ・顧客企業の案件情報を扱う可能性がある ・具体的な検証人数や期間はまだ決めていない 【確認済みの事実】 ・AI整理を実際に業務で試した顧客はいない ・AI整理によって作業負担が減るかは確認していない ・AI出力が業務で使える品質か確認していない ・現在の方法から変更する意思は確認していない ・継続利用意思は確認していない ・支払意思は確認していない 【まだ仮説だと思っていること】 ・AIなら案件情報を実用的に整理できる ・整理結果を確認する方が手動で整理するより楽 ・AIの誤りを修正する負担は小さい ・顧客は案件情報を外部サービスへ渡せる ・AI整理を繰り返し使いたい顧客がいる ・将来的に月額SaaSとして成立する 【自分が作り込みたくなっているもの】 ・Slack連携 ・Gmail連携 ・案件一覧 ・案件詳細画面 ・案件ごとのタイムライン ・自動通知 ・検索 ・チームメンバー招待 ・権限設定 ・履歴管理 ・ダッシュボード ・Stripe課金 ・独自の案件管理DB ただし、 最初からここまで作る必要があるのか疑問です。 【MVPで特に判断したいこと】 ・AIによる案件整理そのものが実務で使えるか ・整理結果の確認や修正を含めても負担が減るか ・どこまで人手で代替してよいか ・人手代替すると何が検証できなくなるか ・SaaSを作らずにどこまで検証できるか ・最初のMVPに最低限何を含めるべきか ・MVP実施後に何を見て次の判断をすべきか

【今回のMVPで検証する顧客課題】 小規模なWeb制作会社・受託開発会社で複数案件を担当する一部のディレクターやプロジェクト担当者に、以下の手間があることを検証対象とする。 - 過去の案件情報を探す手間 - 会議後に決定事項やTODOを整理・転記する手間 - 案件が増えた場合に情報を整理し、状況を把握する手間 8人へのヒアリングでは、過去情報の探索や案件増加時の整理を面倒とする発言、Notionへの手動転記が確認されている。一方、具体的な作業時間、頻度、業務への影響、課題の優先度、現在の方法を変更する意思、支払意思は未確認である。 したがって、課題は一部の担当者に存在する可能性が確認されているが、課題の強さや広がりは確定していない。 --- 【今回検証する解決方向】 顧客が提供した実際のメール、チャット、議事録などの案件情報から、生成AIが案件ごとに以下を整理する方法を検証する。 - 決定事項 - TODO - 未決事項 - 担当者 - 期限 専用SaaSを構築せず、既存の生成AIとメール、チャット、フォーム、スプレッドシート、Notionなどを利用する。 検証範囲は、AIが整理結果を出すところだけではない。顧客が未修正のAI出力を確認し、必要な修正を行い、普段の方法より負担が減ったか、現在の案件状況として使えるかを判断するところまでとする。 --- 【最優先で検証する仮説】 1. 課題を感じている対象顧客は、案件情報の探索・整理の手間を実際に減らしたい。 2. AIは実際の案件情報から、決定事項、TODO、未決事項、担当者、期限を実務で使える形に整理できる。 3. AI出力の確認・修正を含めても、最初から手動で整理するより顧客の負担が小さい。 4. 修正後の整理結果を、現在の案件状況を確認する情報として使える。 5. 顧客は、検証に必要な実案件情報を運営者と使用する生成AIへ提供できる。 6. 顧客が、現在の方法からAI整理へ変更する理由を感じる。 これらは現時点では仮説であり、AI整理の実務利用、負担軽減、変更意思はいずれも確認されていない。 --- 【今回のMVPで答える問い】 > 実際の案件情報をAIで整理した結果は、顧客が案件状況の把握に使える品質であり、誤りや不足の確認・修正を含めても、現在の手動整理や確認より負担を減らせるか。 あわせて、以下を確認する。 - 対象顧客は、その手間を実際に減らしたいか - 実案件情報を検証に提供できるか - AI出力にはどのような誤りや不足が生じるか - 現在の方法からAI整理へ変える理由を感じるか - 専用SaaSを作らずに、解決方向そのものを検証できるか --- 【対象となる顧客】 以下の条件に該当する担当者を対象とする。 - 小規模なWeb制作会社または受託開発会社に所属している - 複数案件を同時に担当するディレクターまたはプロジェクト担当者である - 案件情報の探索、会議後の整理、案件増加時の情報整理のいずれかに手間を感じている - 検証に使える実案件情報を提供できる - 案件状況を把握しており、AI出力の正誤を確認できる 現在の方法で特に困っていない人や、実案件情報を提供できない人は、今回の中心的な検証対象には含めない。 --- 【顧客に提供する最低限の体験】 1. 顧客が普段の整理・確認方法と、手間を感じている作業を共有する。 2. 顧客が検証対象となる案件、期間、情報源、対象範囲を指定する。 3. 顧客が実際のメール、チャット、議事録などを提供する。 4. その情報を生成AIが以下に整理する。 - 決定事項 - TODO - 未決事項 - 担当者 - 期限 5. 顧客が、運営者による事前修正のないAI出力を受け取る。 6. 顧客が元情報や実際の案件状況と照らし、正誤や不足を確認する。 7. 必要な場合、顧客自身が修正するか、具体的な修正内容を伝える。 8. 顧客が修正後の結果を、現在の案件状況の確認に使えるか判断する。 9. 顧客が、確認・修正まで含めて普段より負担が減ったか判断する。 10. 顧客が、現在の方法からAI整理へ変える理由を感じたか回答する。 AI出力を見るだけで終わらせず、元情報との照合、修正、実務利用の判断までを最低限の体験とする。 --- 【MVPに含めるもの】 - 対象顧客に該当するかの確認 - 顧客が現在行っている整理・確認方法の確認 - 顧客が感じている手間の確認 - 実際の案件情報の受け取り - 顧客による整理対象範囲の指定 - 既存の生成AIへの案件情報の入力 - AIによる以下の整理 - 決定事項 - TODO - 未決事項 - 担当者 - 期限 - 未修正のAI出力の保存と顧客への提示 - 顧客による元情報との照合 - 誤り、不足、不要、判断不能の記録 - 顧客による修正、または具体的な修正指示 - 修正後の内容が案件状況として使えるかの確認 - 普段の方法と比べた負担の確認 - 現在の方法から変更する理由を感じたかの確認 - AI整理品質と、手動受け渡しや待ち時間への評価の切り分け 専用システムではなく、既存ツールと手動運用で提供する。 --- 【MVPに含めないもの】 - ログイン・会員登録 - 専用の入力画面 - 専用の結果表示画面 - 専用の編集・修正機能 - 案件一覧画面 - 案件詳細画面 - 案件ごとのタイムライン - ダッシュボード - 独自の案件管理DB - Slack連携 - Gmail連携 - その他の自動取り込み - 検索 - 自動通知 - チームメンバー招待 - 複数人での共同編集 - 権限設定・権限管理 - 履歴管理 - 整理結果の継続保存 - 複数案件を横断する管理機能 - Stripe課金などの決済機能 - 管理画面 - スマートフォンアプリ また、以下は今回の必須検証には含めない。 - 長期間の利用検証 - 継続利用の検証 - 支払意思や価格の検証 - 厳密な作業時間・利用頻度の継続計測 - 月額SaaSとしての成立性の検証 --- 【人手・既存手段で代替できるもの】 | 対象工程 | 代替方法 | |---|---| | 案件情報の受け取り | メール、チャット、フォーム | | 生成AIへの入力 | 運営者が手動で入力 | | AIによる整理 | 既存の生成AI | | 整理結果の受け渡し | メール、チャット、スプレッドシート、Notion | | 顧客による確認・修正 | スプレッドシート、Notion、メール、チャット | | 顧客指定の修正反映 | 運営者が指定内容だけを反映 | | 評価の回収 | メール、フォーム、チャット | | 単発の結果保存 | スプレッドシート、Notion | 人手で代替してよい範囲は、原則として以下に限定する。 - 情報の受け取り - 生成AIへの入力 - AI出力の転送 - 顧客から指定された修正の反映 - 評価の回収 運営者が案件内容を読んで独自に整理したり、AI出力を顧客へ渡す前に修正したりしてはならない。 --- 【代替すると確認できなくなること】 手動運用と既存ツールで代替するため、今回のMVPでは以下を確認できない。 - Slack・Gmail連携の必要性や設定体験 - 自動取り込みによる負担軽減 - 顧客が自分で入力して即時に結果を受け取る価値 - 専用画面の使いやすさ - 案件一覧、案件詳細、タイムライン、検索、通知の必要性 - 複数案件を横断して管理する価値 - 共同編集、権限管理、履歴管理の必要性 - 長期間・複数案件での継続利用 - 実際に現在の業務方法を変更するか - 支払意思、価格、月額SaaSとしての成立性 - 手動運用を含む採算性 また、運営者が案件内容を独自に整理した場合は、以下が確認できなくなる。 - AI単独の整理品質 - AIが起こす誤りや不足 - AI出力に対する顧客の確認・修正負担 - AIで案件情報を整理できるか 運営者がAI出力を事前修正した場合も、AI品質と顧客側の本来の修正負担を確認できない。 --- 【MVP実施に必要な条件】 ### 顧客側 - 想定対象顧客に該当している - 実際の案件情報を提供できる - 整理対象となる案件、期間、情報源、範囲を指定できる - 案件情報を運営者と使用する生成AIへ渡せる - 外部提供できない情報がある場合、提供可能な範囲を明確にできる - 案件状況を把握している担当者がAI出力を照合する - 必要な修正を行うか、具体的な修正内容を伝える - 普段の方法と今回の方法を比較して評価する ### 提供側 - 顧客が指定した情報の範囲と、生成AIへ入力する範囲を一致させる - AIに整理させる項目を共通化する - 運営者が案件内容を独自に整理・補完しない - AI出力を顧客へ渡す前に修正しない - 元情報にない担当者や期限を推測して補わない - AIの未修正出力と顧客の修正後の内容を区別する - 顧客指定の修正だけを反映する - AI整理品質と、受け渡し方法・待ち時間への評価を分けて記録する - 顧客が外部提供と生成AIへの入力を認められる情報範囲を事前に確認する 実案件情報が使えない、未修正出力を提示できない、顧客が元情報と照合しない、普段の方法と比較しない場合は、中心仮説の検証は成立しない。 --- 【検証時に確認すること】 - 顧客が最低限の体験を最後まで完了したか - AIが各項目を実務で使える形に整理できたか - 元情報に明記された内容を取りこぼしていないか - 元情報にない内容を事実のように追加していないか - 誤り、不足、不要、判断不能がどこに発生したか - 業務上見落とせない重大な誤りや不足があったか - 顧客が確認のために元情報をどの程度読み直したか - どの程度の修正が必要だったか - 修正後の結果が現在の案件状況の確認に使えたか - 元情報の探索や手動転記を実際に省けたか - 確認・修正まで含めて、普段より負担が減ったか - 現在の方法から変更する具体的な理由が生じたか - 情報提供や匿名化などの準備が負担になったか - AI整理に固有の負担と、手動MVPに固有の負担を分けられたか - 運営者の独自判断や事前修正が混ざっていないか 厳密な作業時間の計測は必須としないが、顧客が把握できる場合は判断材料として記録する。 --- 【顧客へ確認すること】 ### 普段の方法と課題 - 普段、案件情報をどのように整理・確認しているか - 過去情報の探索、会議後の整理、案件増加時の管理のどこに手間を感じているか - 今回の対象範囲が普段の作業と比較可能だったか - AI出力を確認・修正する場合と、最初から手動整理する場合のどちらが楽だったか - 負担が減った、変わらなかった、増えたと判断した理由は何か ### AI出力 - そのまま使えた内容は何か - 誤っていた内容は何か - 不足していた内容は何か - 不要だった内容は何か - 元情報だけでは判断できなかった内容は何か - 重大な誤りや不足があったか - 誤りを見落とす不安から、元情報をすべて読み直す必要があったか - 修正後の結果を案件状況の確認に使えたか ### 利用理由と提供条件 - 現在の方法からAI整理へ変える理由を感じたか - 今回と同じ条件でも再び使いたいか - 再び使う場合、どの作業を置き換えたいか - 使いたくない場合、AI出力、確認負担、情報提供、待ち時間、受け渡し方法のどれが理由か - 案件情報を運営者と生成AIへ渡すことに問題があったか - 提供できなかった情報が出力品質に影響したか - 匿名化や情報選別が必要だった場合、その作業が負担だったか 「便利だった」「また使いたい」という感想だけでなく、その理由と実際の行動を分けて確認する。 --- 【行動として確認すること】 - 実案件情報を実際に提供した - 整理対象の案件、期間、情報源、範囲を自分で指定した - 未修正のAI出力を元情報と照合した - 誤り、不足、不要、判断不能を具体的に指摘した - 必要な修正を行った、または具体的な修正指示を出した - 修正後の結果を現在の案件状況の確認に使った - 元情報の探索や手動転記を一部でも省いた - 反対に、確認のために元情報を最初から読み直した - AI整理結果を使わず従来の方法へ戻った - 情報提供や匿名化の負担により、中心体験へ進めなかった - 再利用の機会があった場合、実案件で再利用した 試用したこと、好意的な感想、再利用意思、実際の再利用は、それぞれ別に記録する。 --- 【今回のMVPでは判断できないこと】 - 課題が対象市場にどの程度広く存在するか - 課題の優先度が高いか - AI整理が長期間・複数案件でも負担を減らすか - 顧客が実際に現在の業務方法を変更するか - 顧客が継続的に利用するか - Slack・Gmail連携や自動取り込みが必要か - 即時に結果を得られることの価値 - 案件一覧、案件詳細、タイムライン、検索、通知の必要性 - 専用画面の使いやすさ - 共同編集、権限管理、履歴管理の必要性 - SaaSとして提供する必要があるか - 支払意思や適切な価格 - 月額SaaSとして成立するか - 商品・事業として成立するか - 採算性や運営コスト AI整理が動いた、利用された、便利と言われたという結果だけで、継続利用、支払意思、商品成立、事業成立まで確認できたとは扱わない。 --- 【MVP実施後に判断すること】 MVP実施後は、結果を以下のいずれかとして整理する。 ### 継続して検証する 以下が確認された場合は、AI整理という解決方向に一定の可能性があると判断する。 - 修正が必要でも、最初から手動整理するより負担が小さい - 修正後の結果を案件状況の確認に使える - 元情報の探索や手動転記を実際に減らせた - 現在の方法から変更する具体的な理由がある - 主な不満がAI整理品質ではなく、手動受け渡しや転記にある - 実案件情報を繰り返し提供できる見込みがある この結果だけで本格SaaS開発や事業成立を決定しない。 ### 解決方向を見直す 前提条件を満たした上で以下が確認された場合は、AIによる案件整理の方法を見直す。 - 元情報に明記された必要事項を十分に整理できない - 実務利用を妨げる誤りや不足が発生する - 元情報にない内容を事実のように出力する - 誤りを見つけるために元情報をすべて読み直す必要がある - 確認・修正負担が手動整理と同等またはそれ以上である - 修正後も案件状況の確認に使えない - 対象顧客が中心体験を完了しても変更理由を感じない - 情報提供上の制約により、この方法では中心体験を成立させにくい ### 判断を保留する 以下の場合は、解決方向の成否を判断しない。 - 実案件情報を使えなかった - 未修正出力を顧客が照合していない - 案件状況を把握している担当者が評価していない - 元情報に必要事項が存在しなかった - 運営者の整理・補完・事前修正が混ざった - 手動受け渡しへの不満とAI整理品質への不満を分離できなかった - 想定対象外、または課題を感じていない参加者の結果しかない - 普段の方法と比較できなかった 検証人数、期間、誤りの許容割合、負担削減幅などの合格ラインは未設定であるため、新たな数値基準は設けず、各結果の前提と行動変化を基に判断する。 --- 【次の行動】 1. 対象顧客への該当条件、実案件情報の提供可否、普段の整理方法、整理対象範囲を確認する手順を整える。 2. AIへ入力する範囲、整理する5項目、未修正出力の保存・提示方法、顧客による評価方法を共通化する。 3. 実案件情報を受け取り、人による整理や事前修正を加えず、既存の生成AIと既存ツールで最低限の体験を提供する。 4. 顧客による照合・修正・実務利用を確認し、AI品質、負担変化、受け渡し上の不便を分けて記録する。 5. 得られた結果を「継続して検証する」「解決方向を見直す」「条件不足により判断を保留する」に整理する。