この記事のポイント！
- リスク管理と市場分析が重要
- 多角的視点で実行可能性を検証
- 外部知見で判断精度向上へ
新規事業や大型投資の計画を前に、「この構想は本当に実行できるのか」「投じる費用に見合う成果を得られるのか」と判断に迷うことがあります。フィージビリティスタディは、こうした問いに答えるため、事業やプロジェクトの実現可能性を事前に調査・評価する取り組みです。市場の需要、必要な技術、採算性、運営体制などを横断して確かめ、計画を進めるか、修正するか、見送るかを判断する材料を整えます。
調査といっても、市場規模や売上予測だけをまとめればよいわけではありません。顧客が求めているものを提供できるか、必要な人材や設備を用意できるか、法規制や資金繰りに問題がないかなど、複数の条件がそろって初めて実行の見通しが立ちます。前提や不確実性を明らかにし、根拠の強さも含めて整理することが、実務で役立つフィージビリティスタディの要点です。
一方で、調査に時間をかけすぎて意思決定が先送りになったり、推進したい結論に合わせて都合のよい情報だけを集めたりすると、期待した効果は得られません。何を確かめるのか、どの水準なら進めるのかを先に定め、結果を次の行動に結び付ける必要があります。意味や目的に加え、評価項目、具体的な手順、PoCなどとの違い、報告書のまとめ方、陥りやすい失敗まで、実務の流れに沿って解説します。
フィージビリティスタディとは何か
フィージビリティスタディ（feasibility study）は、新しい事業やプロジェクトが実行可能かどうかを調査し、判断するための検討です。日本語では「実現可能性調査」「実行可能性調査」などと表現され、F/SやFSと略されることもあります。ここでいう実行可能性は、技術的に作れるかだけを指しません。市場で必要とされるか、投資を回収できる可能性があるか、継続して運営できるかといった条件を含む、計画全体の成立見込みを意味します。
たとえば、新しい業務サービスを企画する場合、顧客の課題を解決できる機能を作れることは重要ですが、それだけで事業として成り立つとは限りません。利用者が料金を支払うか、販売や導入を担う人員を確保できるか、問い合わせや障害に対応できるか、個人情報などを適切に扱えるかも確認が必要です。フィージビリティスタディは、個別の条件を並べるだけでなく、互いの関係を調べ、計画が全体として成立するかを評価します。
検討の結果は、必ずしも「実施する」か「中止する」かの二択ではありません。対象顧客を絞る、提供方法を変える、開始時期を見直す、外部企業と組む、まず小さく試すなど、計画を修正して成立の可能性を探る選択肢もあります。前提条件を整えれば実行できる計画と、前提が変わっても実行が難しい計画を区別し、どの条件が判断を左右するのか明確にすることが大切です。
フィージビリティスタディは、計画を正当化するための資料作りではありません。調査の結果、事業化を見送る判断に至ることもありますが、投資や人員投入が大きくなる前に重大な障害を把握できれば、損失や手戻りを避ける判断につながります。進める結論を出すことだけを成功とせず、得られた情報をもとに、より妥当な選択を行うことを目的に据えます。
実施するタイミングと、調査の規模を決める考え方
フィージビリティスタディは、構想や事業案の輪郭が見え、実際の大規模な投資や開発に着手する前に行うのが基本です。早い段階で調べれば、計画の変更や中止に伴う負担を抑えやすくなります。ただし、アイデアが漠然としていて対象顧客や解決したい課題も定まっていない段階では、調査対象が広がり、結論につながる情報を集めにくくなります。最低限の仮説を置いてから調査範囲を決めましょう。
対象となるのは新規事業に限りません。新製品の開発、海外市場への進出、工場や店舗の新設、社内システムの刷新、既存業務の外部委託など、投資規模や関係者が多く、やり直しが難しい計画で活用できます。既存の計画と似ていても、法規制、調達先、顧客層、社内の運用条件が異なるなら、過去の成功をそのまま当てはめず、変化した条件を確認する価値があります。
すべての企画に、大掛かりな調査が必要なわけではありません。影響範囲が限られ、失敗しても短期間で元に戻せる小規模な施策なら、主要なリスクや費用だけを確認する簡易な検討で足りる場合があります。反対に、多額の資金を長期間にわたって投じる計画や、許認可、環境、安全、個人情報などへの配慮が必要な計画は、関係分野の専門家も交えて深く調査します。
調査の継続にも判断が必要です。事前確認の段階で、法的に実施できないことが確定している、資金の上限を大きく超える、必須となる技術や資源を調達できないなど、解消の見込みがない障害が見つかれば、全項目を調べきる前に中断する選択もあります。ただし、条件を変えれば成立する可能性がある場合は、代替案を確認してから判断します。調査に進む基準と、打ち切る基準をあらかじめ決めておくと、不要な作業を抑えられます。
評価で押さえる五つの視点
フィージビリティスタディの評価領域は、事業の種類によって調整しますが、市場、技術、財務、運用、法務・規制を軸に整理すると抜け漏れを防ぎやすくなります。技術や財務だけを詳しく調べても、顧客が必要としていない、日常の運営が続かない、許認可を取得できないといった問題が残れば、計画は成立しません。各項目を独立して評価したあと、相互に矛盾がないかも確かめます。
評価項目は、単に「確認すること」の一覧ではなく、判断につながる問いとして設定します。たとえば市場性なら「想定顧客のどの課題を解決し、どのような根拠で利用意向を判断するか」、技術性なら「必要な性能をいつまでに、どの体制で実現できるか」と表現します。回答に必要な証拠や情報源、判断の基準まで定めておくと、調査結果を関係者が検討しやすくなります。
市場性・顧客価値を確かめる
市場面では、対象となる顧客や利用場面を具体的にし、商品・サービスが解決する課題を確認します。市場規模の数字だけでは、実際に自社が獲得できる需要は分かりません。顧客が現在どのように課題を解決しているか、既存の選択肢にどんな不満があるか、乗り換えにどの程度の負担があるかを調べます。対象者を広く設定しすぎると、誰にとって価値があるのかが曖昧になります。
情報収集には、公開されている統計や業界資料、競合の提供内容の調査、顧客へのインタビュー、アンケートなどを組み合わせます。インタビューでは「使いたいですか」と尋ねるだけでなく、最近その課題に直面した状況や、現状に費やしている時間・費用、実際に選んだ代替手段を聞くと、行動に基づく理解が得られます。調査対象者の発言を市場全体の需要と見なさず、情報の範囲と限界を記録することも欠かせません。
競合には、同じ商品を提供する企業だけでなく、顧客が課題を解決するために使う別の方法も含まれます。競合の価格、機能、販売経路、顧客層を比較し、自社が選ばれる理由を明確にします。差別化の根拠が「品質が高い」「便利」といった抽象的な表現にとどまる場合は、顧客が価値を感じる条件に置き換えて検討します。市場に受け入れられる可能性と、自社が継続的に提供できる強みの両方を見る必要があります。
技術性・運用性・法規制を確かめる
技術面では、必要な機能や性能、品質、安全性を定義し、現在の技術で実現できるか、開発や調達にどの程度の時間がかかるかを確認します。既存システムと連携する場合は、データ形式や接続方式、移行作業、停止可能時間なども調査対象です。試作品で一部の機能が動いても、利用者が増えたときの処理能力や保守性が不足することがあります。実験で確認できた範囲と、まだ仮説にとどまる範囲を分けて記録します。
運用面では、提供開始後に必要となる人員、担当部署、業務手順、教育、問い合わせ対応、保守、障害時の対応を洗い出します。特定の担当者の経験に依存していないか、繁忙期や担当者不在時にもサービスを維持できるか、現在の業務に無理なく組み込めるかを確認しましょう。社内で担えない業務がある場合は、外部委託やパートナーとの連携を検討します。その際、委託先の選定や契約管理に必要な作業も見積もります。
法務・規制の確認では、関連する法律、業界のルール、許認可、契約上の義務、知的財産権、個人情報や機密情報の取扱いを調べます。海外展開なら、現地の規制や商習慣、税制、データ移転に関する条件も論点になります。法務確認を企画の終盤に回すと、設計や販売方法を大きく変えることになりかねません。判断が難しい内容は、適切な資格や経験を持つ専門家に相談し、確認した日付や前提を残しておきます。
財務性・投資回収の見通しを立てる
財務面では、初期投資だけでなく、事業を続けるために必要な費用を含めて収支を検討します。開発費や設備費のほか、人件費、販売促進費、物流費、保守費、決済手数料、外部委託費など、提供開始後に発生する費用も対象です。売上については、顧客数、購入頻度、単価、契約継続率など、予測を構成する要素を分けて考えます。算出根拠が不明な一つの売上予測だけで結論を出さないようにします。
投資収益率（ROI）は、投資に対してどれほどの利益が見込まれるかを考える指標です。投資回収期間は、投じた資金を回収するまでの期間を捉えます。これらは比較に役立ちますが、計算結果だけで投資の妥当性が決まるわけではありません。利益が出る時期、資金が必要となる時期、収益予測の確からしさ、撤退時に残る費用もあわせて確認します。長期の事業では、短期の利益だけでなく継続性も見ます。
予測には不確実性があるため、基準となるケースだけでなく、売上が想定より伸びない場合、費用が増える場合、開始が遅れる場合など、条件を変えた複数のシナリオを作ります。感度分析とは、前提となる条件を変えたときに結果がどの程度動くかを調べることです。たとえば、顧客獲得数や原材料費の変化が損益に与える影響を比較します。どの条件が損益や資金繰りを左右するのかが分かれば、優先的に確かめる仮説を絞れます。
フィージビリティスタディを進める実務の手順
調査を始める前に、意思決定者と調査担当者が、目的、対象範囲、期限、必要な成果物を共有します。調査のゴールが「事業化の可否」なのか、「候補地の比較」なのか、「投資案の選定」なのかで、必要な情報は変わります。調査範囲が広すぎると時間を使い切り、狭すぎると重要なリスクを見落とします。何を決めるための調査かを一文で表し、対象外とする事項も含めて合意しましょう。
進行役を一人置き、各領域の責任者と情報の確認方法を決めると、作業の重複や空白を抑えられます。市場調査、技術確認、財務分析、法務確認の担当が別々に動く場合は、共通の前提を使うことが重要です。市場側では顧客数を一定と見込み、財務側では別の顧客数を使うと、報告書の中で計画が食い違います。前提条件を共有する記録を用意し、更新時には関係者に知らせる運用にします。
目的と仮説を決め、情報を集める
最初に、調査対象となる計画の概要を整理します。顧客、解決する課題、提供価値、収益の仕組み、必要な資源、実現したい時期を記し、まだ分かっていない点を仮説として示します。仮説は結論ではなく、調査で確かめるための暫定的な見立てです。「顧客は関心を持つはず」と書くのではなく、どの顧客が、どの場面で、何に対価を払うと考えるのかまで具体化すると、確かめ方を設計できます。
次に、仮説ごとに必要な情報、情報源、調査方法を決めます。公開資料で確認できる市場動向と、顧客への聞き取りが必要な利用実態を区別し、技術仕様や法規制は一次情報にあたることを基本にします。一次情報とは、法律の原文や公的機関の資料、直接実施した調査など、情報の出所に近い資料です。二次情報を使うときは、元資料の作成者、調査時期、対象範囲を確認し、根拠の強さを見極めます。
情報収集では、肯定的な意見だけでなく、否定的な証拠や反対の見解も意識して探します。推進側の担当者だけに聞くと、計画の弱点が表に出にくくなります。顧客、現場担当者、技術者、法務・財務の担当者など、立場の異なる関係者に確認し、意見が分かれた理由を記録しましょう。情報には取得日を添え、変化の速い市場や制度については、古い資料を現在の状況として扱わないようにします。
複数案を比較し、判断材料にまとめる
有力案が一つに見えても、実現方法を変えた案や段階的に進める案を並べて比較します。自社開発と外部委託、既製サービスの利用、対象地域や顧客層の縮小など、選択肢は事業の性質に応じて設定します。比較する際は、費用や期間だけでなく、品質、柔軟性、運用負荷、外部依存、撤退のしやすさも見ます。評価項目をそろえることで、案ごとの長所と短所を同じ土俵で検討できます。
代替案の比較後は、残っているリスクを整理し、発生可能性と影響の大きさを見ながら優先順位をつけます。リスクとは、計画の成果や進行に影響を及ぼす不確実な出来事です。対策を実施しても残るリスクがあるなら、その内容と許容できる条件を明記します。発生前に行う予防策だけでなく、問題が起きた場合の対応、責任者、判断期限も定めておくと、実行段階で対処しやすくなります。
最後に、調査結果を「実行する」「条件付きで実行する」「追加調査を行う」「計画を修正する」「見送る」など、次の行動が分かる形でまとめます。条件付きの場合は、必要な許認可の取得、パートナーの確保、追加資金の承認など、条件を具体化します。調査で判明した事実、予測、未確認事項を混在させずに記載し、結論の根拠を追えるようにします。報告の場では、結論だけでなく、判断を変え得る情報も共有します。
PoC・市場調査・事業計画との違い
PoC（Proof of Concept）は「概念実証」と訳され、技術やアイデアが実際に機能するかを、試作品や限定的なテストで確かめる活動です。フィージビリティスタディが事業やプロジェクト全体を対象に、実行する価値や条件を幅広く検討するのに対し、PoCは特定の機能や技術上の仮説に焦点を当てます。たとえば、顧客需要や収支に目途が立った後、重要な技術が想定どおり動くかを試す場面でPoCを使います。
ただし、両者の順番は常に固定されているわけではありません。フィージビリティスタディの途中で、技術的な不確実性が計画全体の成否を左右すると分かったら、その部分を小規模なPoCで確かめ、その結果を評価に戻すことがあります。反対に、技術の実現性が明らかな場合は、PoCを行わずに他の検討へ進むこともあります。大切なのは名称や順番にこだわることではなく、どの問いをどの方法で確かめるかを明確にすることです。
市場調査は、顧客ニーズ、競合、価格、流通など、市場に関する情報を集めて分析する活動です。フィージビリティスタディでは市場調査を利用しますが、それだけでは技術、財務、法務、運用の実現可能性までは判断できません。市場調査で需要が見込まれても、提供コストが高すぎたり、必要な許認可を取れなかったりすれば、事業化の条件は整いません。市場調査は全体評価の一部と捉えると、役割を混同せずに済みます。
事業計画は、事業の目的や顧客、提供内容、販売方法、収益、必要な体制などを具体化した計画書です。フィージビリティスタディの調査結果は、事業計画を作るための根拠や前提として活用できます。一方、事業計画に示された売上や投資額が妥当かを検証する役割もあります。ビジネスケースは、ある取り組みを行う理由や期待される効果、費用、選択肢を示して意思決定を支える資料です。組織によって呼び方や作成順は異なるため、用語よりも成果物の目的を確認しましょう。
報告書の作り方と、結論を意思決定につなげる方法
フィージビリティスタディの報告書は、調査結果の保管だけを目的とするものではありません。経営層や関係部門が、実行の可否や必要条件を判断できるように構成します。冒頭に結論と提言を置き、その後に調査の目的、範囲、前提、評価項目、分析結果、リスク、代替案、次の行動を続けると、読み手が全体像をつかみやすくなります。詳細資料や計算根拠は付録にまとめ、必要に応じて確認できる形にします。
数値を示す際は、出典、対象期間、計算方法、単位を明記します。たとえば「売上が見込める」とだけ書くのではなく、顧客数や単価など、予測を構成する要素と根拠を示します。確定情報と推定値、社内で置いた仮定を区別し、どの前提が変われば結論が変化するかも説明します。グラフや表を使う場合も、見た目を整えることより、比較対象や読み取るべき点が明確であることを優先します。
評価結果を一つの総合点にまとめる方法は分かりやすい反面、重大な問題を見えにくくすることがあります。市場性や採算性が高くても、安全性や法令順守に関する条件を満たせないなら、単純な平均点で相殺できません。必須条件と改善可能な条件を分け、足切りとなる要件がある場合はその理由を示します。定性的な評価を含めるときは、「高い」「低い」という言葉だけで済ませず、判断に用いた情報や比較対象を記載します。
報告後には、意思決定の担当者、決定内容、未解決の論点、次の確認時期を記録します。「継続検討」とだけ決めて担当者や期限を置かないと、調査結果が棚上げになるおそれがあります。実行する場合は、調査で置いた前提をプロジェクト計画に引き継ぎ、実際の状況と定期的に照合します。前提が崩れた際に再評価する条件を決めておけば、開始時の判断に固執せず、状況に応じて計画を修正できます。
よくある失敗と、調査の質を保つ対策
よくある失敗の一つは、調査の結論を先に決めてしまうことです。事業を推進したい気持ちが強いほど、賛成意見や都合のよい市場データを集め、否定的な情報を軽く扱うことがあります。これを防ぐには、調査の開始時に反証となる情報も探すと決め、計画に直接関与していない人にもレビューを依頼します。推進担当者と評価者の役割を分けることも、判断の偏りを見つける助けになります。
次に、売上予測や市場規模など、見栄えのする数字に頼りすぎる問題があります。大きな市場が存在しても、その全体を自社が獲得できるわけではありません。顧客の具体的な行動、販売経路、競争条件、提供能力を含めて、実際に届く範囲を検討する必要があります。数字の出所や計算過程を示せない場合は、確かな事実ではなく仮説として扱い、検証の優先度を上げましょう。
評価項目に運用や法規制を含めないことも、実務で起こりやすい見落としです。企画段階では製品やシステムを完成させることに注意が向き、保守、教育、顧客対応、契約、許認可などが後回しになりがちです。開発担当者だけで検討を完結させず、実際に運用する部署、法務、情報システム、財務などに早い段階で参加してもらいます。担当部門が決まっていない業務は、誰が担うのかを決めること自体が調査課題です。
調査を精緻にしようとするあまり、結論を出せないほど時間をかけるのも問題です。情報を集め続ければ不確実性がなくなるわけではなく、調査期間が延びる間に市場や制度が変わることもあります。意思決定に必要な最低限の証拠と、追加調査によって判断が変わる可能性を見極め、期限を区切りましょう。確度が低い情報は低いまま明示し、残る不確実性を受け入れて進むのか、範囲を縮小して試すのかを話し合います。
仮想ケースで見る、調査結果の活用方法
たとえば、ある企業が、複数の拠点で働く従業員向けに新しい予約サービスを提供する構想を持っているとします。担当者は、利用者が多いはずだという見込みから開発を提案しました。しかし、フィージビリティスタディでは、まず対象者を具体化し、現在どのような方法で予約しているのか、現行の方法にどのような不便があるのか、誰が費用を負担するのかを調べます。ここでは実在企業の事例ではなく、検討の流れを示すための仮想ケースです。
市場面の調査で、利用者の関心だけでなく、導入を決める管理者の要件も確認します。技術面では、既存の勤怠や認証システムとの連携、利用者情報の管理、アクセス集中時の性能を検討します。財務面では、開発・導入費だけでなく、問い合わせ対応や機能更新に必要な運用費を含めます。運用面では、予約変更への対応、利用者への案内、障害時の代替手段を整理し、実際に担当する部門の負荷も確かめます。
仮に、複数の論点のうち、各拠点で運用手順が異なることが大きな障害だと判明した場合、全拠点への一斉導入だけが選択肢ではありません。対象業務を限定する、共通化できる手順から導入する、既存サービスを組み合わせるなどの代替案を比較できます。各案について、費用、導入期間、業務への影響、得られる情報を並べ、どの案が次の判断に最も役立つかを考えます。調査で得た知見が、計画の変更に結び付く例です。
その結果、限定した条件で試験導入する判断になったなら、実施前に確認する指標を定めます。利用者数だけでなく、予約の完了状況、問い合わせの内容、担当者の作業負荷、システム障害など、継続判断に必要な情報を決めておきます。試験の結果を見て対象範囲を広げるのか、機能を直すのか、計画を取りやめるのかも事前に合意します。フィージビリティスタディは、調査報告で終わらず、次の検証や投資判断の設計にも役立ちます。
実施前に確認したいよくある疑問
「どのくらいの期間が必要か」は、対象範囲や情報の入手しやすさによって変わります。既存資料と社内情報を整理する調査なら比較的短期間で進められる一方、顧客調査、現地確認、許認可の調査、技術試験などが必要な計画では、準備や関係者との調整を含めて時間がかかります。期間を一律に決めるより、調査項目ごとに作業と依存関係を洗い出し、意思決定の期限から逆算して計画を立てます。
「誰が実施するのか」は、社内の担当者だけで完結するとは限りません。事業の責任者が調査目的と判断事項を持ち、各分野の担当者が専門的な情報を確認する形が基本です。社内に必要な知識がない場合は、外部の調査会社や技術者、法律・会計などの専門家に協力を求めます。外部委託をする場合も、結論をそのまま受け取るのではなく、調査の前提や情報源、分析方法を確認できる体制を整えます。
「調査の結果、実現が難しいと分かったらどうするか」という疑問に対しては、まず障害がどの条件に由来するかを分けて考えます。提供対象や開始時期を変えれば解消できるのか、追加の資源や提携先があれば成立するのか、あるいは事業の根本的な前提に問題があるのかを確認します。代替案で課題を解消できるなら再評価し、解消の見込みが乏しい場合は中止も選択肢です。調査の目的は、必ず進めることではありません。
「小規模な企画にも必要か」は、失敗した場合の損失や影響の大きさで考えます。少額で短期間に試せて、利用者や業務への影響が限定されるなら、必要な論点に絞った簡易な確認が適しています。一方、金額が小さくても、安全、法令、個人情報、顧客との契約に関わる場合は、該当分野の確認を省けません。規模に応じて調査の深さを調整しつつ、取り返しのつかないリスクは金額だけで判断しないことが大切です。
まとめ：フィージビリティスタディを判断と行動に結び付ける
フィージビリティスタディは、事業やプロジェクトが実行可能かを、市場、技術、財務、運用、法務・規制などの視点から検討する取り組みです。重要なのは、計画を肯定する材料を集めることではなく、実施の条件や障害、予測の不確実性を明らかにすることです。市場の需要があっても、技術や運用、採算、法的要件が整わなければ継続は難しくなります。複数の要素を関連付けて評価しましょう。
実務では、何を決めるための調査かを定義し、仮説と評価基準を置き、必要な情報を集め、複数の選択肢とリスクを比較して、結論を報告書にまとめます。情報の出所や前提を明示し、事実、予測、未確認事項を分けて扱うことが、判断の納得感につながります。調査項目を増やすこと自体を目的にせず、意思決定を変える可能性のある論点から確認し、期限を決めて進めることも欠かせません。
結論は、実行、条件付き実行、追加調査、計画修正、見送りなど、次の行動が分かる形にします。進める場合は、調査で置いた前提をプロジェクトの計画に引き継ぎ、状況が変わったときに再評価する条件も設定します。見送る場合も、何が障害となったのか、どの条件が変われば再検討できるのかを記録すれば、後の判断に生かせます。フィージビリティスタディを意思決定のための道具として活用し、根拠と責任のある一歩につなげてください。
