フィージビリティスタディ(feasibility study)
本格的に始める前に、その計画が実際にやれるかを確かめる調査。やめる判断も結果の1つ。
もう少し詳しい説明
フィージビリティスタディ(feasibility study、実現可能性調査)は、本格的に始める前に、その計画が実際にやれるかを確かめる調査です。
feasible は「実行できる」という意味です。実行可能性調査やF/Sとも呼ばれます。
なぜ先に調べるのか
計画は、進むほど引き返しにくくなります。
人を集め、機材を買い、取引先と約束をしたあとで「やはり無理だった」となれば、そこまでにかけたお金と時間が戻ってきません。
いちばん安く失敗できるのは、始める前です。 調査にかかる費用は、計画全体から見れば小さく済みます。
何を確かめるのか
「できるか」を1つの面だけで見ると、見落とします。いくつかの面から確かめます。
| 面 | 確かめること |
|---|---|
| 技術 | いまある技術で作れるか。必要な技能を持つ人を集められるか |
| 経済 | かかる費用に見合う効果が出るか。採算が合うか |
| 法律・制度 | 法令や業界の規則に触れないか。許可が要らないか |
| 日程 | 決められた期限に間に合うか |
| 運用 | 完成したあと、現場の人が実際に使えるか。回していけるか |
最後の「運用」が抜けやすいところです。 技術的に作れて、採算も合うのに、現場の手順に合わなくて使われない、ということが起きます。
経済の面を見るときは、TCO(総所有費用)(導入から廃棄までにかかる費用の合計)で考えます。買うときの値段だけを見ると、運用と保守の費用を見落とします。
「やめる」も結果の1つ
ここが、この調査でいちばん大事な点です。
フィージビリティスタディは、進めるための手続きではありません。 「できる」と「できない」の両方が、正しい結果です。
やめる判断が出たときに、ちゃんとやめられるか。 ここが実際には難しいところになります。調査を始めた時点で、関わる人は「やる前提」で動きがちです。
そのため、何をもって「できない」と判断するかを、調査の前に決めておくことがあります。「費用が◯円を超えたら見送る」のように、線を先に引いておくわけです。
どこに置かれる工程か
システムを作る流れの中では、企画のすぐ後ろ、設計や製造よりも前に置かれます。作り始める前の段階です。
- 企画 … 何のために作るのかを決める
- フィージビリティスタディ … やれるかを確かめる ←ここ
- 要件定義 … 作るものに何が必要かを決める
- 設計、製造、テスト、運用
調査で「進める」となってから、RFP(提案してほしい内容をまとめた依頼書)を出して、作ってくれる相手を探す流れになります。
調査の中で洗い出した心配ごとは、そのままリスクマネジメント(リスクを見つけて手を打つ活動)へ引き継ぎます。調べて終わりにせず、先の工程で見張る材料にします。
試験ではこう出る
科目A(旧・午前)のストラテジ系(システム企画)で出ます。ITパスポートでも出ます。
いちばん多いのは、目的を選ばせる問題です。「計画の実現可能性を、技術・経済・法律などの面から評価する」という表現が答えになります。
誤答として並ぶのは、テスト(作ったものが動くかの確認)、問題管理(障害の原因究明)、調達(発注先の選定)です。どれも始めたあとの話で、フィージビリティスタディは始める前です。いつの話かで切り分けてください。
応用情報では、確かめる面を選ばせる形まで出ます。技術・経済・法律・日程・運用のうち、運用の面が抜けている選択肢が誤りとして作られることがあります。
関連する用語
- RFP
- 提案してほしい内容をまとめた依頼書。実現できると判断したあとに出す
- TCO(総所有費用)
- 導入から廃棄までにかかる費用の合計。採算が合うかを見るときの土台
- リスクマネジメント
- リスクを見つけて手を打つ活動。調査で洗い出したリスクを引き継ぐ
- 要件定義
- 作るものに何が必要かを決めること。実現できると決まってから進む工程
ミニクイズ
フィージビリティスタディの目的として、最も適切なものはどれか。
正解は 2番:計画を本格的に進める前に、実現できるかどうかを多面的に確かめる
フィージビリティスタディは、計画を本格的に進める前に行う調査です。技術的にできるか、採算が合うか、法律に触れないか、期限に間に合うかといった面から確かめ、進めるかどうかを判断します。完成したシステムが要求どおり動くかを確かめるのはテスト、障害の原因を突き止めるのは問題管理、提案を比べて発注先を決めるのは調達の段階で、いずれも別の場面です。
この分野をまとめて解く → システム戦略と技術戦略のミニテスト(全28問)
最終更新:2026-11-05