アイデア会議を3回開いて、ホワイトボードに残ったのは前回とほぼ同じ案。新規事業の現場で繰り返される場面です。HASSANの使い方で差がつくのは、この「同じ案しか出ない」状態を崩せるかどうかにあります。この記事では、入力前に整理する5項目、選別に使う4つの判断軸、選んだ案を社外検証へ渡す手順までを、一続きの運用として解説します。
案が似るのは、参加者の力量の問題とは限りません。事業領域、顧客像、収益モデルの前提が固定されたままでは、誰を呼んでも似た案が続きます。HASSANは正解を受け取る道具ではなく、チームが無意識に置いている前提を動かし、比較できる仮説候補を増やすための道具です。
入力前の準備、案を出した後の選別、顧客へ確かめる問いへの変換までを、2つの仮想例とあわせて追います。正式な画面名、ボタン名、保存・共有方法、データ取扱条件は、契約時点の公式情報と社内規程で確認してください。
使い始める前に決めること｜発散の範囲を1枚に収める
HASSANを使う前に、「誰の、どの場面を、何のために変えたいか」を1枚に書き出します。範囲を先に決めておくと、既存事業の言い換えや実行条件を無視した案が続いたとき、どの前提を見直すべきかすぐ判断できます。
準備するのは完成した企画書ではありません。仮置きで十分です。次の5項目を、各1〜3文で書いてください。
入力前に整理する5項目
- 対象者：困りごとを抱えている人、利用者、支払者
- 困る場面：その問題が起きる業務、場所、時間
- 利用できる資産：顧客接点、技術、データ、設備、販売網、知見
- 外せない条件：法務・品質・提供地域・事業領域などの制約
- 今回広げたい方向：顧客、提供方法、収益の得方、利用場面のどれを変えるか
ここで「20代」「大企業」といった属性だけを書いても、対象者の状況は見えてきません。同じ20代でも、月末の経費精算に追われる担当者と、店舗の閉店作業を担う責任者では、困る瞬間がまるで違うからです。属性より場面。そう書き換えるだけで、出力の違いを比較しやすくなります。
逆に、入力前から条件を固めすぎるのも失敗のもとです。「自社アプリで」「月額課金で」「既存顧客向けに」まで固定してしまうと、AIが組み替えられる前提がほとんど残りません。今回は何を固定し、何を動かすのか。固定条件と可変条件を分けておくのがコツです。
HASSANに任せる範囲と、人が判断する範囲も先に分けます。発散した案を採用するか、顧客へ何を確かめるか、どの事実が出たら撤退するかは、チーム側で決める事項です。
HASSANを使う前後の流れ｜発散から持ち出しまで
HASSANをチームの業務へ組み込むときは、発散テーマの設定、前提情報の整理、案の発散、選別、検証への受け渡しを、それぞれ別の作業として扱います。会議と検証を止めないための進行手順として整理します。
発散前に行うこと
- 発散テーマを作る 1回の利用で扱う問いを1つに絞ります。「新規事業全般」ではなく、「法人営業の提案準備にかかる手作業を減らすサービス案」のように、対象者と困る場面が見える粒度へ落とします。
- 前提情報を整理する 使える資産、避けたい領域、対象者、変えたい条件を整理します。社名や顧客名などの機密情報を扱う前に、自社の利用規程と、契約時点におけるHASSANのデータ取扱条件を確認してください。確認できない情報は入力しません。
発散後に行うこと
- 案を発散させる 最初から完成度を求めず、方向の違う案を並べます。似た案が多いときは、単に再生成するのではなく、「対象者を変える」「提供する時間を変える」「支払者を変える」など、動かす条件を指定します。
- 残す案と保留する案を分ける
出力をその場の好みで採点せず、評価軸を先に置きます。この段階では、明らかな重複と、外せない条件に反する案だけを除外します。
- 次の作業へ持ち出す 選んだ案を「誰が、どんな場面で、何に困り、どんな変化を得るのか」という仮説文へ直します。チームで共有するときは、採用理由、保留理由、最初に確かめる問いも一緒に残します。
発散の途中で「これは無理」「前にも見た」と評価を始めると、似た意見だけが残りやすくなります。案を増やす時間と、案を減らす時間を分けてください。似た案が続くなら対象者や支払者など動かす条件を変え、制約違反が多いなら外せない条件を短く書き直します。
HASSANへの入力文の作り方｜固有名詞より状況を書く
HASSANで発散する前提を文章にするときは、事業アイデアそのものより、対象者・困る場面・利用できる資産・制約・動かしたい条件を整理します。会社情報を増やすことより、困りごとが起きる状況を具体化するほうが、案同士の違いを検討しやすくなります。
編集部作成の入力文例
たとえば「製造業向けの新規事業案を出す」では範囲が広すぎます。製造業の誰が、いつ、何をしている場面なのかが抜けているからです。次のように分解すると、AIが組み替えられる材料が増えます。
対象者は、複数拠点の設備保全を担当する管理者。故障対応の記録が拠点ごとに分散し、過去の対応を探すまでに時間がかかっている。自社は保守担当者との顧客接点と、設備の運用知見を持つ。新しい専用機器の開発は今回の対象外。提供方法と支払者を変えた案を広げたい。
実際に入力できる項目や上限は、利用時点のHASSAN画面と公式案内で確認してください。
入力文を書いたら、次の点を読み返します。
入力前のチェックリスト
- 対象者と支払者を同じ人だと決めつけていないか
- 「困っている」だけでなく、困る作業や時間帯が書かれているか
- 自社の資産を商品名だけでなく、顧客接点や運用知見まで含めているか
- 守る条件と、あえて変える条件が分かれているか
- 出力へ期待する幅が「顧客」「提供方法」「収益の得方」などの言葉で指定されているか
長い指示文を書くこと自体を目的にしないでください。狙いは、事業の前提を分解し、固定する条件と動かす条件をチームで合意することです。出力が似通うなら可変条件を変え、案が制約から外れるなら固定条件を見直します。戻る先がはっきりします。
HASSAN活用の設計例1｜新規サービス案を広げる
新規サービスの検討では、HASSANを「完成案の生成」ではなく「同じ課題に対する解き方の差分づくり」に使います。顧客課題を固定し、提供方法・支払者・利用頻度を順に動かすと、どの前提から案の違いが生まれたかを比較できます。
例として、法人営業の提案準備にかかる手作業を減らすテーマを考えます。対象者は提案書作成に追われる営業担当者、困る場面は初回商談後の情報整理、利用できる資産は過去の提案資料と商談記録、と置きます。
条件を1つずつ動かす
1回目は、提供方法だけを動かします。自動作成、レビュー支援、抜け漏れ検知、共同編集など、解決の接点が違う案を出します。2回目は、支払者を営業部門、営業企画、事業部責任者などへ変えます。3回目は、利用する時間を商談前、商談直後、提案提出前へずらします。
ここで見るべきは「最も賢そうな案」ではありません。同じ課題でも、誰が予算を持ち、いつ使い、どの既存業務と置き換わるかで、事業の形は変わります。案を横に並べ、どの前提を動かした結果なのかを記録すると、チームが固定していた条件が浮かび上がります。
出力から3〜5案を残したら、それぞれを1文の仮説へ直します。「営業担当者向けの提案作成AI」では足りません。「初回商談後に情報整理へ時間を取られる法人営業担当者は、商談記録と過去資料から提案の論点を抽出できれば、提出前の手戻りを減らせる」のように、対象者、場面、困りごと、期待する変化をつなぎます。数値効果は検証前に書きません。
HASSAN活用の設計例2｜既存資産から隣接案をつくる
既存資産を起点にする場合は、商品一覧だけでなく「接点・データ・運用知見」に分解して発散の前提を整理します。既存商品の横展開ばかりが続くときは、資産の使われ方を変える方向へ問いを置き直します。
たとえば、複数地域の事業者と継続的な接点を持つ企業を想定します。ありがちな発想は、その接点へ既存商品を売り込む案です。そこで商品名をいったん外し、「定期的に現場の困りごとを聞ける関係」「地域ごとの運用差を把握している知見」「既存の連絡網」という資産へ分解します。
商品名を観察可能な資産へ分解する
発散させる方向は、販売以外にもあります。現場情報を匿名化して業界の課題把握へ使う、複数事業者の共通作業をまとめる、事業者同士で知見を交換する場を作る、といった方向です。ただし、データ利用や第三者提供を含む案は、利用目的、同意、契約、情報管理の確認なしに進めてはいけません。HASSANの出力は法務判断の代わりにならないからです。
この使い方で詰まりやすいのは、資産と強みを混同する場面です。「ブランド力」「技術力」のような自己評価だけでは、案同士を比較する材料が足りません。誰との接点があり、どの工程を日常的に回し、どんな記録が残っているのか。観察できる名詞と動詞へ直して整理します。
HASSANの出力を選別する方法｜好みではなく検証可能性で残す
HASSANの出力は、魅力的に見える順ではなく「誰に何を聞けば間違いだと分かるか」が明確な順に残します。初期の選別で重視するのは完成度ではなく、短い検証で前提の誤りを見つけられるかどうかです。
選別会議では、評価軸を4つに分けると扱いやすくなります。
選別に使う4つの判断軸
- 課題の明確さ：誰の、どの場面の困りごとかを1文で説明できる
- 自社との接続：使う資産が具体的で、保有部署や担当者を特定できる
- 確かめやすさ：話を聞く相手と、聞くべき問いが見えている
- 撤退条件：どんな事実が出たら案を捨てるかを先に書ける
点数は順位を決めるためではなく、議論の食い違いを見つけるために使います。ある案を営業部門が高く評価し、開発部門が低く評価したなら、平均点で丸めてはいけません。何を事実として見ているかを言葉にします。顧客課題の評価が違うのか、実装負荷の評価が違うのかで、次に確認する相手が変わるからです。
似た案が多い場合は、付箋のように短い名前を付け、近いものをまとめます。HASSANから出た文章を一字一句守る必要はありません。複数案の一部を組み合わせても構いませんが、誰の課題を扱う案なのかだけは混ぜないでください。
選別後に残すのは、企画書ではなく仮説カードです。1案につき「対象者」「困る場面」「現状の代替手段」「提案する変化」「最初に確かめる問い」「撤退条件」を記録します。この形なら、会議の結論と次に確かめる事項を同じ1枚に残せます。
選別をやり直すサイン
採用理由を「面白いから」としか説明できない、評価者によって順位が反転する、全案の撤退条件が空欄のまま。このいずれかが起きたら、点数を足す前に評価軸を見直します。課題の有無で割れているなら顧客候補へ、実現条件で割れているなら社内の保有部署へ、先に確認する相手を切り分けてください。
HASSANで選んだ案を検証へ渡す方法｜出力を答えにしない
HASSANで選んだ案は、顧客インタビューや試作品の評価へ渡して初めて事業仮説になります。AIが生成した文章は需要の証拠ではなく、現実の相手へ確かめる問いを作るための候補です。
誰に何を確かめるかを決める
たとえば「提案準備を自動化するサービス」という案を残したとします。インタビューで「このサービスを使いたいですか」と聞くだけでは、回答者の意向しか分かりません。先に聞くのは、直近で提案を作ったときの手順、使った資料、かかった時間、手戻りが起きた箇所、今の代替手段です。解決策を見せるのは、現状の行動を聞いた後にします。
検証相手は、顧客候補だけとは限りません。業務の成立条件を知る有識者、類似事業を経験した実務者、資産を保有する社内部署など、確かめたい前提に応じて選びます。AIの出力と相手の過去行動が食い違ったら、出力を守るために質問を誘導せず、「対象者」「困る場面」「支払者」「実現条件」のどれが外れたかを記録してください。
顧客の過去行動と仮説が一致しない場合は、対象者や困る場面を更新します。相手へたどり着けず検証が止まる場合は、社外人材との接点づくりや面談運用を支援する外部サービスも比較対象になります。外部へ任せるのは相手探索や日程・記録など合意した実務までとし、仮説の採否と次の投資判断は自社に残します。契約範囲は個別に確認してください。
検証で得た事実を次の発散条件へ戻すと、一度きりの案出しで終わりません。発散だけを繰り返すのではなく、選別して外へ出し、否定された前提を更新します。この往復が、成果を左右する要因の一つです。
まとめ｜HASSANは発散の後まで決めて使う
HASSANの使い方は、入力して終わりではありません。対象者と困る場面を決め、条件を動かして案を広げ、検証可能性で残し、実在する相手へ確かめるところまでを、1つの運用として組みます。
実務で押さえる点は次のとおりです。
- 入力前に、対象者・困る場面・利用できる資産・制約・動かす条件を書く
- 1回のテーマを1つの問いに絞り、発散中は評価を差し込まない
- 入力文には会社紹介より、困りごとが起きる具体的な状況を書く
- 新規サービス案では課題を固定して、提供方法・支払者・利用時間を動かす
- 既存資産の活用では、商品名を顧客接点・データ・運用知見へ分解する
- 出力は見栄えではなく、確かめる相手と撤退条件が書ける案から残す
- 顧客から得た行動事実を次の入力へ戻し、発散と検証を往復する
HASSANの画面上で利用できる入力項目、保存・共有方法、データ取扱条件は、利用時点の公式案内と契約条件を確認してください。