#
KISED関連事業（予備創業パッケージ、初期創業パッケージなど）の書類審査では、限られた時間内に数十件の申請を審査します。審査員は、「課題 → 原因 → 解決策」が一本の流れとしてつながっているかを素早く確認します。その流れが途切れると、後に続くすべての項目の信頼性も崩れます。
多くの創業者は、課題が実在することの証明に力を入れます。しかし、審査員が本当に問うているのはそこではありません。「このチームの提案する解決策は、課題の根本原因に本当に働きかけるのか」という点です。課題が存在する証拠、原因の分析、解決策の設計の論理を、一つの流れにつなぐ必要があります。
以下の3つのパターンは、どこでつながりが切れるかによって区別できます。パターン1は課題と原因の間、パターン2は原因と解決策の間で切れます。パターン3は、解決策の設計理由そのものが欠けているケースです。
#
これは最もよく見られるパターンです。社会的な動向や市場統計を並べた後、いきなり「だから、私たちの解決策が必要です」と結論づけます。課題の規模の大きさは示されていても、なぜ起きているのかという分析がありません。審査員から見ると、「課題が大きいのはわかるが、このチームが具体的にどこを直そうとしているのかがわからない」という印象になります。
| 項目 | 修正前 | 修正後 |
|---|---|---|
| 課題の提示 | 韓国の中小企業の60%超が、デジタルトランスフォーメーションに苦戦している。 | 韓国の中小企業の72%には専任のIT担当者がおらず、外部ソリューションを導入する際に社内の運用担当者を育成する余力もない。そのため、45%が導入後6か月以内に新しいツールの利用を断念している。 |
| 原因分析 | （なし — すぐに解決策へ進む） | 根本原因は「ツール不足」ではなく、導入後の運用段階における支援の空白にある。既存のソリューションは初期設定に注力し、日常の運用に入ると利用者への支援が途切れる。 |
| 解決策との接続 | そこで、私たちはプラットフォームを開発した。 | 運用段階の支援の空白を埋めるため、現場担当者が別途研修を受けずにすぐ使える運用アシスタントを設計した。導入後6か月分の現場の運用ログから、自動対応シナリオを生成する。 |
「修正前」のように原因分析が欠けていると、解決策がどれほど高度でも、なぜその形を取るのかを説明する根拠がありません。「修正後」のように原因を明示して初めて、解決策の設計方針に必然性が見えてきます。
#
2つ目は、課題の提示と原因分析はしっかりしているのに、解決策がその原因に働きかけていないパターンです。原因としてAを挙げながら、実際にはBを解決するツールを提示しています。ここで審査員は、「原因分析と解決策がかみ合っていない」と判断します。
よく見られる例が、原因分析で「医師と患者の間の情報の非対称性が問題」と述べながら、解決策として「病院予約の自動化プラットフォーム」を提示するケースです。情報の非対称性と予約の利便性は、別の問題です。原因分析が正確でも、解決策がその原因に触れていなければ、その時点でつながりは切れます。
このパターンの主な原因は、先に製品を設計し、事業計画書を書く段階で、それに合う課題と原因を後から当てはめることにあります。解決策がすでに固まった状態で原因を書くと、解決策の実際の機能と、記述された原因がずれやすくなります。
- まず、原因分析の文を書く。「この課題は、なぜ実際に起きているのか」を1文にまとめる。
- その原因を述べた文を、解決策の説明の冒頭にそのままつなげる。「この原因に対処するため、私たちは___を設計した」という構造にする。
- 解決策の主要機能を列挙し、それぞれが原因のどの部分を解消するのか、1行ずつ対応づける。
- 記述した原因につながらない機能があれば、別の「差別化要素」または「付加価値」の項目へ移す。
- 最後に、課題、原因、解決策の設計の論理を述べた3つの文を続けて声に出して読み、論理がつながっているか確認する。
#
3つ目は、課題・原因・解決策の流れが表面的にはつながっていても、解決策がなぜその仕組みで機能するのかを説明していないパターンです。典型的な表現は、「AIによるパーソナライズされたレコメンドを提供する」「ビッグデータ分析で課題を解決する」といったものです。技術名は示されていますが、その技術が原因をどう解消するのかという説明が抜けています。
| 記述の種類 | 表現例 | 審査員が気づく論理の抜け |
|---|---|---|
| 技術名を挙げるだけ | 自然言語処理を用いて、ユーザーの困りごとを解消する。 | なぜ自然言語処理なのか。この技術は、原因のどの部分に働きかけるのか。 |
| 効果を宣言するだけ | ユーザー満足度を30%向上させられる。 | 30%の根拠は何か。この数値は、原因の解消とどうつながるのか。 |
| 抽象的な差別化 | 既存のソリューションとは異なる、革新的なアプローチを取る。 | 具体的に何が、どう違うのか。その違いは原因とどうつながるのか。 |
| 設計理由の明示（推奨） | 既存のソリューションではユーザー自身が手動で設定する必要があり、それが初期離脱の原因になっている。私たちは、ユーザーの最初の3回の利用ログを自動分析して設定を事前に行うことで、設定段階の離脱を仕組みで防ぐ。 | 原因（設定段階の離脱）→ 設計の論理（自動での事前設定）→ 効果（離脱の防止）が、一つの因果関係でつながっている。 |
設計理由を明示するには、既存の方法ではなぜ原因を解消できないのかを1行で書き、その後に、自社の方法ではどう違う対応をするのかを続けます。背景にある技術の名前を挙げるより、実際の仕組みを説明するほうが、論理をつなぐうえでははるかに効果的です。
#
以下の5段階のチェックリストは、事業計画書を提出する前に、自分で論理のつながりを確認するための手順です。どこかの段階で条件を満たさなければ、次に進む前に該当箇所を書き直してください。
- 課題の項目で、誰が、どのような状況で、どの程度の頻度でこの課題を経験するのかを、具体的な数値やインタビューの根拠で示しているか。
- 原因分析は、症状の言い換えにとどまらず、構造的な理由を1つに絞っているか。原因が3つ以上ある場合は、中心となる1つに絞る。
- 解決策の説明の最初の文に、原因分析のキーワードを直接用いているか。
- 解決策の主要な機能がそれぞれ原因のどの部分を解消するのか、明示しているか。
- 課題、原因、解決策の段落を順に読んだとき、事業の予備知識がない第三者が「なぜ、この方法なのか」に納得できるか。
5段階すべてを満たしていても、書き手が自分の論理の飛躍を見つけるのは難しいものです。事業の背景をすべて知っているため、文章では省略されているつながりを、無意識に補ってしまうからです。だからこそ、提出前の最後のステップとして、第三者によるレビューが必要です。
#
Q. 課題を狭く定義すると、市場が小さく見えてしまいませんか？
A. 原則として、課題の定義と市場規模は別の項目で扱います。課題の項目では、「具体的に誰の課題なのか」を狭く、正確に書くほうが、論理のつながりに有利です。市場規模は、その課題を持つ人が何人いて、経済的な規模がどれほどあるかという観点で、後から説明できます。広く書いて因果関係が途切れるよりも、狭く正確に課題を示して因果関係を完成させるほうが、高い評価につながります。
Q. 原因が複数ある場合は、どうすればよいですか？
A. 原因が複数ある場合は、自社の解決策が実際に解消するものを1つ特定する必要があります。残りの原因には、課題全体の複雑さを説明する背景として簡潔に触れつつ、解決策に直接つながる中心的な原因を明示してください。原因が3つあり、解決策がそのうち1つにしか働きかけないなら、残りの2つは「現時点の対象範囲外」と明確に書くほうが、むしろ信頼につながります。
Q. 申請書の様式によって項目構成が違いますが、因果関係の原則は同じように適用できますか？
A. 項目名や分量は様式によって異なり、韓国の予備創業パッケージ、初期創業パッケージ、創業跳躍パッケージでもそれぞれ違います。しかし、審査員が課題・原因・解決策のつながりを確認することは、様式にかかわらず同じです。項目が書類上で離れていても、原因分析の文が、それらをつなぐ橋渡しとして機能する必要があります。
#
ここで扱った3つのパターン、つまり原因のない課題、原因とかみ合わない解決策、設計理由が示されていない解決策は、書き手自身では見つけにくいものです。事業の背景をすべて知っているため、文章に欠けているつながりを頭の中で補ってしまいます。審査員には、その背景知識がありません。読むのは文章だけです。
論理の飛躍を見つけるには、事業をあらかじめ知らない人の目が必要です。第三者が書類だけを見て、なぜこの原因からこの解決策が導かれるのかに納得できることが重要です。不採択になってから原因を探るよりも、提出前に確認するほうがはるかに効率的です。