フィージビリティスタディ｜「成立するか」で調査を止めない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

③ 検証する5つの領域

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

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

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

④ 進め方の5ステップ

課題と判断基準を明確にする。「何が確かめられたら進めてよいか」の線を先に引く。
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支援）をご覧ください。