フィージビリティスタディとは｜5つの評価視点と進め方6ステップ

「この事業、本当に成立するんですか？」——新規事業や新機能の稟議で、必ず一度は出てくる問いです。この問いに答えるための調査が、フィージビリティスタディです。

この記事では、まず言葉の意味と進め方を辞書として引ける形で整理し、そのあとで、この調査が現場でどう転ぶか——「成立します」と答えた瞬間に調査が終わってしまう落とし穴と、AI時代にこの工程がどう変わるか——まで話をしていこうと思います。

① フィージビリティスタディとは

フィージビリティスタディの定義をすでにご存じの方は、② PoC・PoV・パイロットスタディとの違いから読み進められます。

フィージビリティスタディ（Feasibility Study）とは、事業・プロジェクト・機能を本格的に作り始める前に、それが実行可能かどうかを調べる工程のことです。日本語では実行可能性調査と訳されます。フィジビリティスタディ、F/S、フィジスタと表記されることもあります。

確かめる中身は、大きく言えば「市場はあるか」「技術的に作れるか」「収支は合うか」の3点です。実施するタイミングは、企画が形になった直後、動くものを作り始める前。目的は3つに整理できます。

1. 投資判断の材料を作る。作る前に、やめる・縮める・進めるを決められるようにする。
2. 作り直しを減らす。設計を左右する制約を、実装の前に並べておく。
3. 関係者の合意を作る。「何を確かめたら進めてよいか」の線を先に引く。

得られるものは4つあります。失敗のコストが投資の前に分かること、設計の入力になる制約の一覧が残ること、関係者が同じ判断基準を持てること、そして「作らない」という選択を早く安く取れることです。

なぜこの工程が求められるかというと、事業の失敗のうちかなりの部分が、作る前に分かることを作ってから知ることで起きているからです。市場の不在も、技術の制約も、収支の前提も、その多くは公開情報に書いてあります。ところが現場では、読むより先に作り始めてしまう。読んでから作るか、作ってから読むか。フィージビリティスタディは、この順番を前者に固定するための工程です。

覚え方として、ひとつ豆知識を置いておきます。1978年、国連工業開発機関（UNIDO）が「工業フィージビリティスタディ作成マニュアル」を刊行しました。市場、原材料、立地、技術、人員、資金計画といった確かめる項目を一覧の形で標準化したもので、18言語に訳され、多くの国の投資計画の作り方がこれに沿って整えられました。調査を機会調査・予備調査・本調査の3段階に分け、進むほど項目を細かくする構成もこのマニュアルが原型です。つまりこの言葉の本体は、48年前から「結論」ではなく「項目の一覧」でした。ここを覚えておくと、あとの落とし穴の話が全部つながります。

フィージビリティスタディの目的と役割

目的は「やるかどうかを決めるための材料を、作る前に揃えること」です。実現可能性調査、FS、フィジビリティスタディとも呼ばれます。

役割は3つに分かれます。

• 投資判断の材料をつくる — 進める・縮める・やめるを決める根拠
• 関係者の前提をそろえる — 何が確かで、何が未確定かを共有する
• 次の工程の対象を決める — 調べても分からなかった欄を実証実験へ渡す

3つ目が抜けやすい役割です。調査は「結論を出す工程」ではなく、結論が出せない箇所を特定する工程でもあります。

フィージビリティスタディを行うメリット

• 手戻りの費用を下げる — 作ってから分かる、を減らす
• 判断が速くなる — 会議の前に事実がそろう
• 社内の説得材料になる — 感触ではなく一次資料で話せる
• リスクを先に見つけられる — 許認可や制約は、後から変えられない
• やめる判断ができる — 早く外れれば、次に回せる

いちばん効くのは最後の1つです。調査に数日かけて「やらない」と決められれば、その時点で数か月ぶんの費用が浮いています。

市場調査との違い

	調べる範囲	出す答え
市場調査	買い手・競合・市場規模	市場はあるか
フィージビリティスタディ	市場に加えて、技術・経済・運用・法規	自社が、この条件で成立させられるか

市場調査はFSの一部です。「市場はある」と分かっても、作れない・回せない・法令で無理、なら成立しません。

ビジネスプラン・ビジネスケース・プロジェクト憲章との関係

文書	何を書くか	FSとの前後
フィージビリティスタディ	成立するかの判断材料	いちばん先
ビジネスケース	やる理由と投資対効果	FSの結果を根拠に書く
ビジネスプラン（事業計画）	どう実行し、どう稼ぐか	進めると決めた後
プロジェクト憲章	目的・体制・権限を正式に定義	実行を承認した後

順番を飛ばすと、後ろの文書が根拠を持てません。FSを省いて事業計画から書き始めると、数字の前提を「そう見込んだ」としか説明できなくなります。

実施するタイミングと、調査にかける期間

タイミングは、アイデアが1つに絞れた後、資源を投じる前です。早すぎると調べる対象が定まらず、遅すぎると使った費用を正当化する調査になります。

期間は対象の規模によりますが、先に打ち切りの期日を決めてください。数日から2週間で区切るのが実務的です。「調査だけで時間が溶ける」のはこの工程の古典的な失敗で、期限を切らないと必ず延びます。

教科書で使われる評価の5視点

一般的な解説では、次の5つの視点で評価します。

視点	確かめること	外すとどうなるか
市場性	需要はあるか。競合と比べて選ばれるか	誰も買わないものを作る
技術性	作れるか。使う技術・システムで実現できるか	途中でできないと分かる
経済性	採算は合うか。投資対効果（ROI）は見合うか	売れても赤字になる
運用性	回し続けられるか。体制・人員は足りるか	始められても続かない
独自性	差別化できるか。真似されたときに何が残るか	価格勝負に引きずり込まれる

この記事の③では、ここに法規を独立させた5領域を使っています。許認可と約款は、あとから交渉で動かせないためです。視点の数より、各視点に一次資料が付いているかを見てください。

進め方1｜調査の目的と範囲を決める

何が確かめられたら進めてよいかを先に文章にします。あわせて、今回は調べない範囲も決めます。

範囲を決めないと、調査は無限に広がります。「関連しそうなこと」を全部調べ始めた時点で、期限は守れなくなります。

進め方2｜情報を集める

業界統計、競合の公開価格、公式の料金表、仕様書、法令・ガイドライン、そして現場の観察と聞き取り。海外が絡む場合は、現地の規制と商習慣も対象になります。

聞き取りだけで済ませないでください。人の話は前提が省略されます。数字と条件は、必ず一次資料で裏を取ってください。

進め方3｜データを分析し、評価する

集めた情報を、採算性（原価・価格・数量）と技術的な制約に落として計算します。前提を1つ動かしたときに、結論が変わるかを見てください。

結論が前提の小さな変化でひっくり返るなら、その前提こそが最初に確かめるべき対象です。

進め方4｜代替案を出して、比べる

1案しか机に載っていない調査は、「やる／やらない」の二択にしかなりません。範囲を縮めた案、外部に任せる案、既存の仕組みで代用する案。最低でも3つ並べます。

比較の軸を先に決めてください。費用、期間、確実性、撤退のしやすさ。軸が無いまま並べると、声の大きい案が通ります。

進め方5｜リスクを洗い出し、対応を決める

起こりうる不都合と、その影響の大きさ、起こりやすさを並べます。そのうえで、避ける・減らす・移す・受け入れるのどれにするかを決めます。

「リスクがある」で止めないでください。対応が書かれていないリスク一覧は、読む側から見ると「やらない理由の列挙」に見えます。

進め方6｜最終評価と、報告書にまとめる

最初に引いた線と突き合わせて、進める・縮める・やめるを決めます。判断の根拠を、報告書として残します。

この記事の④では、実務向けに「埋まらない欄を仕分ける」工程を独立させた5ステップで書いています。上の6ステップは一般的な教科書の並びで、中身は同じものを、どこで区切るかの違いです。

報告書に盛り込む項目と構成

上司や投資家に出す報告書は、次の順で組むと読まれます。

• 結論 — 進める・縮める・やめると、その条件
• 調査の目的と範囲 — 何を調べ、何を調べていないか
• 評価の視点ごとの結果 — 市場性・技術性・経済性・運用性・独自性
• 根拠にした一次資料 — 出所と日付
• 代替案の比較 — 選ばなかった案と、その理由
• リスクと対応
• 埋まらなかった欄 — 次に確かめる対象

最後の項目を必ず入れてください。「分からなかったことが書いていない報告書」は、読む側から見ると、調べ漏れなのか無かったのか区別できません。

課題1｜調査のコストと期間が膨らむ

調べれば調べるほど不確かさは出てきます。期日を先に決め、そこで打ち切ってください。

打ち切った時点で埋まらなかった欄は、調べ続けるのではなく、実証実験に回す対象として明記します。

課題2｜情報の信頼性と、評価の偏り

都合のよい資料だけが集まることがあります。やりたい人が調べると、やれる材料が集まります。

対策は2つ。出所と日付を必ず残すことと、「この事業をやらない理由」を1つは自分で挙げることです。

課題3｜人材と専門知識が足りない

技術、法規、海外の規制。社内に読める人がいない領域は、読めないまま「問題なし」になりがちです。

分からない領域は、分からないと書いてください。そのうえで、外部に確認するか、実証実験に回すかを決めます。

課題4｜報告書の説得力が足りない

よくある形は、感触が根拠になっていることです。「需要はありそう」「技術的には可能」は、判断材料になりません。

各主張の横に、一次資料の名前を置いてください。料金表、仕様書の制限事項、法令の条番号、統計の出所と年。これがあるだけで、質問の量が減ります。

調査を効率化する5つのヒント

• 目的と評価基準を先に決める — 何が揃えば判断できるかを1文で
• 欄を先に作ってから埋める — 調べながら項目を増やさない
• 情報を1か所にまとめる — 誰が見ても同じものを見られる状態に
• 役割を分ける — 領域ごとに担当を決める
• 進み具合を見えるようにする — 埋まった欄の数で進捗を測る

2つ目がいちばん効きます。調べながら項目を足していくと、いつまでも「あと少し」の状態が続きます。

小規模なプロジェクトでも必要か。海外進出でも使えるか

小規模でも必要です。ただし分量は変わります。数日で、変えられない制約（料金表・仕様の限界・契約の手順・時間の制約・相手の運用）だけを埋める形で足ります。

海外進出では、むしろ重要度が上がります。規制、認証、通関、決済、現地の商習慣、撤退のしやすさ。国内なら常識で埋まる欄が、全部「調べないと分からない欄」になります。

フィージビリティスタディについてよくある質問（基本編）

Q. フィージビリティスタディと市場調査は、どう違いますか。
市場調査は「市場はあるか」を調べ、FSは市場に加えて技術・経済・運用・法規まで含めて「自社がこの条件で成立させられるか」を確かめます。市場調査はFSの一部です。

Q. どの段階で実施すべきですか。
アイデアが1つに絞れた後、資源を投じる前です。早すぎると調べる対象が定まらず、遅すぎると使った費用を正当化する調査になります。

Q. 調査期間はどれくらいかかりますか。
対象の規模によりますが、先に打ち切りの期日を決めるのが要点です。数日から2週間で区切り、埋まらなかった欄は実証実験へ回します。

Q. 小規模なプロジェクトでも必要ですか。
必要です。ただし分量は変わり、変えられない制約（料金表・仕様の限界・契約の手順・時間の制約）だけを数日で埋める形で足ります。

Q. 海外進出のプロジェクトでも使えますか。
使えますし、重要度は上がります。規制・認証・通関・決済・現地の商習慣・撤退のしやすさなど、国内なら常識で埋まる欄が、すべて調べる対象になるためです。

ここまでが、フィージビリティスタディの一般的な整理です。目的、評価の視点、進め方、報告書、そして詰まりやすい場所。

ここから先は、この言葉を現場で使うときの線引きの話をします。最初に扱うのは、よく並べて語られる3つの言葉との違いです。

② PoC・PoV・パイロットスタディとの違い

似た言葉との違いは、「何で確かめるか」で線を引くと一度で覚えられます。

用語	何で確かめるか	確かめること
フィージビリティスタディ	公開情報・一次資料・机上の計算。	実行可能か（作る前の判断）。
PoC（実証実験）	動くものを作って試す。	技術的に本当に動くか。
PoV	動くものを使ってもらう。	価値が出るか（効果の検証）。
パイロットスタディ	本番の縮小版を運用する。	本格展開に耐えるか

順番としては、フィージビリティスタディが最初です。机上で埋められることを先に埋め、埋まらなかった不確かさだけを、動くものを作る工程に回します。とはいえ、すべてが机上で埋まるわけではないので、次の順路が要ります。

段階	やること	出口の判断
フィージビリティスタディ	5領域を一次資料で埋める。	埋まらない欄はどこか。
実証実験	埋まらなかった技術の不確かさを、動くもので潰す。	本当に動くか
試作（MVP）	市場の不確かさを、使われ方で潰す。	使われるか

実証実験で最後に残るものの実録は実証実験では出ない0.1%の話に、試作の検証の回し方は4週間で回す検証の話に書いてあります。

③ 検証する5つの領域

教科書では市場・技術・財務・運用の4領域で語られることが多いのですが、実務では法規を独立させた5領域をお勧めします。各領域で大事なのは、確かめる問いと、その問いに答える一次資料をセットで持つことです。

領域	確かめる問い	一次資料の例
市場	買い手は実在するか。いくらなら払うか。	業界統計、競合の公開価格、現場の観察。
技術	作れるか。できないことは何か。	API仕様書、技術文書の「制限事項」の章。
財務	収支は合うか。原価は何で決まるか。	公式料金表、見積書、課金規約。
運用	回し続けられるか。人はいつ動くか。	相手先の営業時間、締切、処理件数の上限。
法規	やってよいか。許認可・約款に反しないか。	法令、業界ガイドライン、利用規約。

実は、この表でいちばん大事なのは一次資料の列です。「市場はあるか」に肯定の感触で答えるのと、統計と価格表で答えるのとでは、同じ「はい」でも設計に使える情報量が違います。とくに技術の領域では、できることの確認よりも、仕様書に書かれた「できないこと」の確認のほうが、あとで効きます。

④ 進め方の5ステップ

1. 課題と判断基準を明確にする。「何が確かめられたら進めてよいか」の線を先に引く。
2. 5領域の項目一覧を作る。埋めるべき欄を先に全部並べる。
3. 一次資料で埋める。料金表・仕様書・規約・統計を実物で読む。聞き取りだけで済ませない。
4. 埋まらない欄を仕分ける。調べても分からない欄は、実証実験に回す対象として明記する。
5. 評価して判断する。進める・縮める・やめるを、最初に引いた線と突き合わせて決める。判定のしかたは単純で、埋まった一覧の中の「変えられない制約」が事業の前提を壊すかどうかで見る。壊さないなら進める。一部を壊すなら、その部分を避けて範囲を縮める。根幹を壊すなら、やめる。

ただし、調査には期限が要ります。対象の規模にもよりますが、数日から2週間と決めて打ち切ります。「調査だけで時間が溶ける」のはこの工程の古典的な失敗で、期限を切らないと必ず延びます。期限までに埋まらなかった欄は、調べ続けるのではなく、ステップ4の仕分けに回します。

⑤ 現場に置き換える｜自社ECを始める会社の一覧

定義だけでは使えるようにならないので、架空の場面にいったん置き換えます。中堅の食品メーカーが、卸中心の商売から自社ECの直販に踏み出すとします。5領域の一覧は、たとえばこう埋まります。

領域	埋まった中身（例）
市場	競合の直販価格は自社想定より2割安い。ギフト需要は自社の観察と合致。
技術	カートSaaSの仕様書に、在庫連携APIは「5分間隔の同期のみ」とある。即時反映は不可。
財務	決済手数料は売上の3.6%。送料は地域別の公式料金表どおり。ギフト梱包の資材費が想定より重い。
運用	出荷できるのは工場の物流課で、受付は平日16時まで。土日出荷は現状不可能。
法規	食品表示法の表示義務と、特定商取引法の表記が必要。

この一覧の価値は、埋めた瞬間に設計が決まり始めることです。在庫の即時反映ができないなら、売り切れ表示の作り方が変わります。土日出荷ができないなら、お届け日の約束の仕方が変わります。「ECは成立するか」という問いへの答えは「はい」の一言ですが、この一覧は、そのままサイト設計と業務設計の入力になります。

⑥ 欠陥と潮流｜「成立するか」で止まる。AI時代はどうなるか

この工程には、構造的な欠陥があります。「成立するか」という問いは、はい・いいえで答えが出ます。そして、はいと出た瞬間に調査が終わるのです。市場はある、技術はある、収支は合う。3つのはいが揃うと、それ以上仕様書や料金表を読む理由がなくなります。

対策は、問いをもう1つ足すことです。「何が変えられないか」。相手の会社のAPI仕様、公開されている料金表、契約と審査の手順、法規。これらはこちらの設計をどう工夫しても変えられません。そして、変えられないものの一覧は、はい・いいえで終わらず、そのまま設計の入力になります。「成立するか」の調査は作る許可を出して終わり、「何が変えられないか」の調査は作る形を決める。同じ調査でも、届く先が違います。

潮流の話もしておきます。生成AIの調査支援によって、一次資料を集めて要約するコストは下がり続けています。埋める作業が安くなるなら、この工程は不要になるのでしょうか。実は、逆だと考えています。作る速度も上がっているため、変えられない壁に当たるまでの時間が短くなっているからです。埋める作業はAIに任せられても、どの欄を立てるか、判断の線をどこに引くかは残ります。フレームワーク全般に起きているこの反転は、新規事業のフレームワークを検出器として選び直す話で詳しく書きました。

⑦ 実例｜公開されていた料金表を、実装後に読んだ

自社プロダクトohbag（オーバッグ）での実例です。訪日客がホテルから荷物を送れる機能を、大企業との共創事業として開発・運用しています。配送会社の送り状をAPIで自動発行し、「請求額を予測して、先に価格として提示する」形で手数料をいただくモデルです。

作る前の調査で、市場・技術・収支の3点は確かめていました。3つとも青信号で、実装に入りました。ところが実装が進むほど、あとから壁に当たります。当たってから仕様書を読み直すと、壁は最初から書いてあったのです。

• このAPIは送り状の発行専用で、「配送追跡やステータス照会のAPIは無い」。
• 「発行後の取消・変更のAPIも無い」。発行した送り状はシステムからは戻せない。
• 発行したラベルPDFの取得有効期限は1〜24時間。取り置くには発行直後に自分の側へ保存が要る。

料金では、思い込みで作った部分までありました。空港カウンター宛の配送は特別な料金体系だと考え、専用の料金表をデータベースに設計したのです。腑に落ちなかったので公式サイトの料金ページを機械で全部読んだところ、発地12地域×着地12地域×サイズ8区分の1,416件は例外ゼロで、空港宛は地上料金に一律660円を足しただけでした。ページの注記には「空港手数料+660円」と、そのまま書いてありました。設計した専用の料金表は、丸ごと削除になりました。

一方で、この失敗のあとに順番を変えた決済連携では、逆のことが起きています。実装の前に変えられないものを並べたら、決済の与信は最長7日で切れる、送り状は発行後に取り消せない、という2つの制約が衝突していると分かりました。そこで処理の順番を「与信→発行→確定」に置き、発行に失敗したら与信を解放する形にしたところ、「課金済みなのに発行に失敗」というお金が宙に浮く状態が、返金運用ごと構造から消えました。実装後の検証は39件中39件が通っています。

「成立するか」で調査を止めた前半と、「何が変えられないか」を並べた後半。調査の問いの立て方ひとつの差が、この対比にそのまま出ています。

⑧ チェックリスト｜変えられないもの5項目

実例から抽出した、作る前に必ず埋める5項目です。⑤の一覧の、技術・財務・運用の欄を実務向けに具体化したものに当たります。

項目	確かめること	実例での実物
公式の料金・価格表	注記と例外まで読む。疑わしければ実測。	「空港手数料+660円」の注記。
API・仕様の限界	できないことの明記を探す。	追跡なし、発行後の取消なし。
契約と審査の手順	申込から本番までの段取りと日数。	契約→ID発行→ドメイン登録→審査。
時間の制約	有効期限、締切、保持期間。	PDFは1〜24時間、与信は7日。
相手の運用	人が動く時間帯と処理の単位。	集荷時刻、1回1,000件まで。

⑨ 一緒に覚えておきたい概念

フィージビリティスタディは、確かめる工程の入口です。隣り合う概念とセットで覚えると、順路として使えるようになります。

• PoC（実証実験） — 調査で埋まらなかった不確かさを、動くもので潰す次の段階。実証実験では出ない0.1%が、本番で最後に残る
• MVP検証 — 市場の不確かさを、使われ方で潰す段階。4週間で回す。完成度より学習の輪
• 新規事業の立ち上げの順番 — どこから作り始めるかの議論。受けたものが現場の作業になる出口から作る
• フレームワークの選び方 — 埋める道具ではなく検出器として選ぶ。失敗の検出器として12種を選び直す

よくある質問

Q. フィージビリティスタディとは何ですか？ A. 事業や機能を本格的に作る前に、実行可能かどうかを調べる工程です。日本語では実行可能性調査と訳されます。市場・技術・財務・運用・法規の5領域を、一次資料で埋める形で進めるのがこの記事の勧める形です。

Q. PoC（実証実験）との違いは何ですか？ A. フィージビリティスタディは公開情報と机上の調査で確かめる工程、実証実験は「動くものを作って確かめる」工程です。先に調査で埋められる欄を埋め、埋まらなかった不確かさだけを実証実験に回すと、作って確かめる範囲が小さくなります。

Q. どのくらいの期間をかけるべきですか？ A. 数日から2週間と期限を決めて、打ち切ります。期限までに埋まらなかった欄は、調べ続けるのではなく、動くもので確かめる側に仕分けます。

Q. 小さな機能追加にも必要ですか？ A. 外部の会社・契約・法規が関わるなら、規模によらず「変えられないもの一覧」だけは作る価値があります。自社の中だけで完結する機能なら、変えられないものが少ないので、作って確かめるほうが速いことが多いです。

Q. フィージビリティスタディは日本語で何と言いますか？ A. 実行可能性調査、または事業化可能性調査と訳されます。表記はフィージビリティスタディのほかに、フィジビリティスタディ、F/S、フィジスタなどの揺れがありますが、すべて同じ言葉です。

Q. フィージビリティスタディの検証項目には何がありますか？ A. この記事では市場・技術・財務・運用・法規の5領域で整理しています。教科書的には市場性・技術的実現性・経済性の3点が核で、そこに運用と法規を加えると実務で漏れが出にくくなります。各領域に「確かめる問い」と「一次資料」をセットで持つのがポイントです。

Q. 誰が実施するべきですか？ A. 事業の言い出し役と作る側の両方が関わるのが理想です。企画側だけで進めると技術と運用の欄が聞き取りだけで埋まり、開発側だけで進めると市場と財務の欄が浅くなります。一覧を1枚にして、埋まらない欄を専門側に割り振る形が実務的です。

Q. 調査を飛ばして、いきなり作ってはだめですか？ A. 自社の中だけで完結する小さな機能なら、作って確かめるほうが速いことも多いです。ただし外部の会社・契約・法規が関わる場合は、変えられない制約に後から当たると作り直しになるため、一覧だけは先に作ることをお勧めします。

この記事を書いた会社について

アルチェコ（ARCHECO）は、UXデザイン・AI開発・新規事業開発を組み合わせた事業共創スタジオです。実例に出てきた荷物配送の機能は、大企業との共創事業として実際に開発・運用しているもので、「空港手数料+660円」の実測も「与信→発行→確定」の決済設計も、その現場の記録から書いています。事業化判断の前段からの伴走は、新規事業コンサルティング（MVP・PoC支援）をご覧ください。