フィジビリティスタディとは？進め方・調査項目と開発の判断基準

2023-03-24 2026-10-11

システムを作るかどうかを決める前に、そもそも実現できるのか、かけた費用に見合うのかを調べておく。この調査をフィジビリティスタディと呼びます。

ただ、いざ始めようとすると手が止まります。何を調べたら「調査した」ことになるのか。どこまで分かれば判断に進んでよいのか。そして、どういう結果が出たら見送るのか。

この記事は、最後の点を中心に書きます。調べる項目の決め方と進め方を押さえたうえで、進める・条件付きで進める・見送るをどう分けるか。判断の出口を先に決めておくと、調査の範囲も自然に決まります。

Enlyt（エンライト）では、要件が固まりきらない段階からの相談を受けています。そこで出てくる論点をもとにまとめました。

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

作るかどうかを決めるための調査

ISO・IEC・IEEEが共同で管理する用語データベース SEVOCAB には、feasibility study の項目があります。出典は ISO/IEC 2382:2015 です。

「study to identify and analyze a problem and its potential solutions in order to determine their viability, costs, and benefits」（ISO/IEC 2382:2015 より引用。Copyright © ISO/IEC）

問題とその解決候補を洗い出して分析し、それらの成立性と費用と便益を判断するための調査、という定義です。

目を引くのは、この定義が調べる領域の分類をいっさい置いていないところです。成立するのか、いくらかかるのか、何が得られるのか。到達点はそう決めていますが、この定義だけでは、具体的な調査項目までは指定されていません。

表記については、公的機関や辞典類でも統一されていません。省庁の資料では内閣府や国土交通省のように「フィージビリティ」が目立ち、グロービス経営大学院のMBA用語集やWikipedia日本語版は「フィジビリティ」です。JICAは制度名としてカタカナを使わず「協力準備調査」と呼んでいます。略すときは FS、F/S のどちらも見かけます。どちらかが誤りということはないので、社内の文書でどちらかに寄せておけば足ります。

作らないという結論も成果になる

この調査について書かれた古典的な文献に、国連工業開発機関（UNIDO）のManual for the Preparation of Industrial Feasibility Studies（1978年初版、1991年改訂版）があります。工業プロジェクトの投資を対象にした手引なので、システム開発にそのまま当てはまるものではありませんが、投資判断の考え方として参考になります。

改訂版に、次の一節があります。

「even a feasibility study that does not lead to an investment recommendation is of great value as it prevents the misallocation of scarce capital」

投資を勧める結論に至らなかった調査であっても、限りある資本の配分を誤らせずに済む点で大きな価値がある、という意味です。

これは建前ではなく、調査の設計を左右します。「やる」という結論しか許されない空気のなかで調査を始めると、集める材料が最初から偏ります。調査にかけた時間と費用を無駄にしたくない、という気持ちも働きます。調査を依頼する側が、見送りという結論も成果として受け取ると先に表明しておくかどうかで、出てくるものが変わります。

同じ文献には、こんな警告もあります。

「The term “feasibility study” is often misunderstood and deliberately misused by suppliers of equipment or technology」

設備や技術の売り手が、この言葉を誤解したまま、あるいは意図的に誤用することが多い、と書かれています。売りたい技術を前提にした資料がフィジビリティスタディと名乗ってしまう、という指摘です。1991年の文章ですが、いまの開発会社にも返ってくる話で、私たちも自戒するところです。

調べる項目と、項目の決め方

調査項目は、分野と調査目的によって変わる

「フィジビリティスタディでは技術・財務・市場・運用の4領域を評価する」といった説明をよく見かけます。これは実務で使われる整理のひとつです。権威のある出典を並べてみると、分け方はそろっていません。用語の定義、工業投資の評価、国の調査費の区分と、それぞれ対象と目的が違うので、違って当然のところです。

PMI の用語集にも feasibility analysis の定義があり、4つの変数を挙げる前に「one or more of the following」と書かれています。すべてを埋めることを求めていないわけです。なおこちらは参照したのが Version 4.0（2024年）で、現行の Version 5.0 での記述は確認できていません。

分野ごとの項目一覧のほうは存在します。工業プロジェクトの投資なら先に挙げた UNIDO のマニュアル、公共施設の整備なら内閣府の手引、自治体の情報システムなら総務省の手順書に、調べる項目が並んでいます。自分の案件に近い分野の文書があれば、そこを出発点にするのが早道です。

システム開発での出発点

システム開発の案件であれば、次の6つを確認の出発点にできます。

• 技術・連携。作れるか、つなぐ先からデータを取り出せるか
• 費用と効果。総費用がいくらで、それに見合う効果が見込めるか
• 運用体制。公開後に動かし続ける人を確保できるか
• スケジュール。必須期限までに出せるか
• 法務・セキュリティ。満たすべき条件と、その満たし方があるか
• 利用・需要。効果の前提になる利用率や件数が見込めるか

この6つは、抜け漏れがないかを確かめるために使います。どこに重点を置くかは、次に書く問いの立て方で決めます。6つを均等に調べる必要はありません。

判断に必要な問いから逆算する

領域の一覧を先に置いて上から埋めていく進め方には、落とし穴があります。

市場を調べ、技術を調べ、費用を積み、運用体制を書いた。分厚い資料ができあがった。それでも会議で「で、どうするの」と言われて止まる。調査としては抜けがないのに、判断の材料になっていない状態です。

原因はたいてい、判断が何にかかっているのかを決めないまま調べ始めたことにあります。ある案件では、技術的に作れるかどうかはとっくに明らかで、本当に決まらないのは運用する人員を確保できるかどうかだけ、ということがあります。そこで4領域を均等に調べると、人員の話は全体の4分の1しか書かれません。

そこで、領域ではなく問いから組み立てます。あわせて、その問いに答えが出たときに何が言えるようになるのかも書いておきます。情報が整理された状態と、判断ができる状態は別物だからです。

右の2列を先に書いておくのが肝心なところです。例外の種類と頻度が一覧になった、というだけでは判断できません。その一覧をもとに、どこまでをシステムに載せてどこから手作業で残すかを決め、残った運用負荷が許容できるかまで進んで、はじめて答えが出たことになります。

結果として技術・財務・市場・運用に近い並びになることはあります。それは構いません。順番が逆になっているだけです。

システム開発での進め方

調査の順序は案件によって変わりますが、先に押さえておくと後が楽になるものがあります。ひとつは、誰がいつ決めるのかです。決裁する人と決裁のタイミングが分かっていないと、何をどこまで調べればよいのかが決まりません。資料の粒度も、読む相手によって変わります。

もうひとつは、問いを書き出す向きです。実施する理由だけを並べると、見送りや代替案を比較しにくくなります。いま決まっていない理由、止まっている理由のほうから書き出すと、何が解ければ進むのかがはっきりします。

机上で分かることと、作らないと分からないこと

調べるといっても、資料だけでは答えが出ない問いがあります。外部システムとの接続が通るか、想定したデータ量で処理が間に合うか、現場の人が実際に使えるか。こうした問いは、小さく作って動かしてみないと確かめられません。

ここで出てくるのが PoC やプロトタイプです。調査と対立するものではなく、調査のなかで使う手段にあたります。後の章で整理します。

調べる範囲をどこで切るか

すべての不確かさを消してから判断する、という進め方は現実には成り立ちません。予算の編成時期や既存システムのサポート期限など、動かせない締切があるためです。

そこで、必須の問いを先に片づけます。必須というのは、答えが出ないと判断そのものができない問いのことです。残った問いは、追加で検証するのか、条件付きで進めて進行中に確かめるのか、期限までに答えが出ないので見送るのか、という扱いの違いとして整理します。

調査を終える基準は、問いが全部埋まったことではありません。必須の判断材料がそろい、残っている不確かさを意思決定者が受け入れられる状態になったかどうかです。

進める・条件付きで進める・見送るの判断基準

調査後の対応を4つに分ける

調査後の対応は、進める・条件付きで進める・追加で検証する・見送るの4つに分けて考えます。必須条件を満たしているかと、未確認事項をどう扱うかで判断します。進めるか見送るかの2択にすると、現場で扱いにくくなります。

未確認であることだけを理由に見送ってしまうのは、もったいない場面があります。何をどこまで確かめれば答えが出るのか、その手立てがあるのかどうかで、追加検証と見送りは分かれます。

見送り・再検討につながる状態

何が分かったら見送るのか。一般的な例として挙げると、次のような形になります。

この表はあくまで形の例です。実際の案件では、許容額がいくらなのか、どのデータが必須なのか、どの期限が動かせないのかを、具体的な数値と条件で決めておく必要があります。

費用の行で注意したいのは、予算に収まることと採算が合うことは別だという点です。予算が1,000万円で総費用が800万円なら予算内ですが、同じ評価期間で見込む効果が500万円相当なら、それだけで投資を正当化することはできません。許容額と投資判断の基準は、分けて置いておきます。

比べるときは期間をそろえます。初期費用に加えて、導入後3年間など合意した評価期間の運用・保守費を含めた総額と、同じ期間で見込む効果を並べる形です。

業務システムでは、効果を金額に換算しにくい場合があります。その場合は、業務にかかる時間、入力や照合のミスの件数、問い合わせから回答までの時間、利用者の手間といった指標で測ります。金額に直せないからといって効果を空欄にすると、費用だけが並んだ資料になり、判断ができません。どの指標を見るかは、効果の測定方法として報告書に書いておきます。

必須条件と許容額は、調査の前に合意する

見送りの基準でよく揉めるのは、調査が終わったあとに基準を決めようとしたときです。結果が出てから「この金額なら許容範囲だ」「このデータは必須ではなかった」と動かせてしまうので、どんな結果でも進める結論を作れてしまいます。

そこで、調査に入る前に次の3つを決めて、関係者で合意しておきます。

• 必須条件。満たせなければ見送る、という線をどこに引くか
• 許容額。保守と運用を含めた総額で、どこまでなら出せるか
• 必須期限。いつまでに本番に出ている必要があるか、その期限は何に縛られているか

この3つが先に決まっていると、調査の範囲も自然に決まります。許容額が決まっていれば、そこを超えるかどうかを確かめるだけで済む項目が出てきますし、必須期限が決まっていれば、期間に収まらない範囲を切り落とせます。

判断に至った例

判断の形を示すための想定例です。実在の案件ではありません。

条件付きで進めた形

社内の受注管理を仕組みにしたい、という相談を想定します。調査の前に決めた条件は3つ。必須条件は、既存の会計システムから請求データを取り出せること。許容額は、初期費用と導入後3年間の運用・保守費を合わせた総額で設定。必須期限は次の期首です。

調べたところ、請求データは取り出せるものの、既存システム側の出力が日次のバッチでした。業務の手順を見直すと、翌日の反映で支障がない範囲と、受注後すぐに反映されていないと困る範囲に分かれます。バッチの回数を増やせば後者にも対応できますが、既存システム側の改修が必要で、許容額に収まりません。

結論は、条件付きで進めるです。翌日反映で足りる範囲を先に作り、受注後すぐの反映が必要な範囲は当面手作業で残します。付ける条件は、残る手作業を月10時間以内とすること。公開から3か月後に実測し、超えていたら対象範囲を見直す。確認する担当者と、見直しの判断をする人を決めてから進みます。

見送った形

利用者向けのアプリを作って予約を取りたい、という相談を想定します。採算の前提として、既存の利用者のうち3割がアプリから予約することを置きました。この利用率を下回ると、3年間で見込む効果が総費用を下回ります。意思決定の期限は2か月後です。

前提を確かめるため、既存の利用者層を調べ、すでに動いている電話とWebの予約窓口の実績を当たりました。しかし、3割という利用率を裏づける材料は出てきませんでした。確かめるには一部の利用者に先行して使ってもらう必要があり、2か月では間に合いません。

結論は見送りです。採算の前提になる利用率を確認できず、追加検証も意思決定の期限までに実施できないためです。記録として、どの利用率を前提にしていたのか、何が確認できなかったのかを残します。再検討する条件は、対象の利用者による予約アプリの先行利用を実施でき、採算の前提となる利用率を検証できることです。Web予約の利用実績は、その検証を設計するための参考材料として扱います。

この2つの違いは、技術的に作れるかどうかではありません。前者は条件を付ければ残るリスクを許容範囲に抑えられ、後者は採算の前提を期限内に確かめられない。そこで分かれています。

PoC・MVP・要件定義との違い

要件定義との違い

実務でよく混ざるのが、この調査と要件定義です。主な目的が違います。要件定義は、作ると決めたあとに何を作るかを決める工程で、フィジビリティスタディは、作るかどうかを決めるための工程です。終わったときに手元に残るものも違い、要件定義では仕様に近い文書が残り、この調査では判断とその根拠が残ります。

ただし実際には、きれいに前後に並ぶわけではありません。実現性を確かめるには作る範囲を仮に決める必要があり、範囲を決めるには要件をある程度整理する必要があります。両者は行き来します。問題になるのは、作ると決まっていないのに仕様を詰める時間が長くなり、関わる人が増えて引き返しにくくなることです。

発注側で要件をどこまで整理してから相談すればよいかについては、システム開発の要件定義はどう依頼するかにまとめています。

PoCは、実現性を確かめる手段

PoC（Proof of Concept、概念実証）について、経済産業省のDXレポート（2018年9月7日公表）に括弧書きの定義があります。

「新しいプロジェクト全体を作り上げる前に実施する戦略仮説・コンセプトの検証工程」

同じレポートには、PoC がうまくいかない型として「戦略なき技術起点の PoC は疲弊と失敗のもと」という記述も出てきます。何を確かめるのかを決めないまま、使えそうな技術から入ると、動くものはできても判断が進まない、という指摘です。

国際的な定義のほうも見ておきます。SEVOCAB に収録されている proof of concept の定義は、INCOSE のシステムズエンジニアリング・ハンドブック（第5版、2023年）が出典です。

こちらは、実現できる度合い（feasibility）を示すために、アイデアや技術を実現してみることだと定義されています。同じデータベースにある feasibility の項目（ISO/IEC/IEEE 24765:2017）では、制約のもとで要求や設計や計画を実現できる度合いだと説明されています。調査という工程ではなく、実現できる度合いそのものを指す言葉です。つまり PoC は、この調査が判断しようとしている対象を、作って示す行為にあたります。確かめ方のひとつとして、調査の内側に置くと実務に合います。

Enlytでも、本番システムを作る前の検証用の開発を請けることがあります。たとえば動画配信TVアプリのPoC開発の事例では、事業者の閉域網を使ったIP伝送でテレビアプリとして成り立つかを確かめるため、PoCに必要な機能だけに絞って3か月で作りました。

プロトタイプとパイロット

似た言葉がもう2つあります。どちらも SEVOCAB に定義があります。

プロトタイプは、ISO/IEC TR 7052:2023 の注記で、複雑な画面の改善や仕様化、フィジビリティスタディ、要件の洗い出しのために使われるものだと説明されています。確かめる対象は画面や操作に限りません。処理の流れや技術構成、連携の成否を試すために作る場合も、プロトタイプと呼ばれます。

パイロットのほうは、フィジビリティスタディと同じ ISO/IEC 2382:2015 に pilot project として定義があります。実際の運用条件のもとで、ただし範囲を限って先行版を試し、そのうえで確定版のテストにも用いるプロジェクト、という内容です。実際の運用条件で動かすところが、机上の検証や試作との違いです。本番に出すかどうかを決める前に置かれることもあれば、出すと決めたあとの段階的な導入として置かれることもあります。

MVP

MVP（Minimum Viable Product）は、Eric Ries が2009年8月のブログ記事で自ら定義を置いています。

「the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort」

顧客について検証された学びを、できるだけ少ない労力で、できるだけ多く集められる版、という定義です。同じ記事で本人が「MVP, despite the name, is not about creating minimal products」とも書いています。名前に引きずられて、単に小さい製品を作る話だと受け取らないように、という念押しです。

規格の側にも定義はあり、SEVOCAB には IEEE 2675-2021 と PMBOK ガイド第8版を出典とする2つが収録されています。ただしどちらも、フィジビリティスタディとの関係には触れていません。

実務上の位置づけとしては、顧客に関する仮説を少ない労力で検証するための作り方です。検証して得た学びをもとに、方向転換するか続けるかを決めるところまでが含まれるので、本格的な開発に投資するかどうかの判断にも使われます。この調査と役割が重なる場面があるわけで、前後に並ぶとは限りません。

進め方そのものはMVPとはとMVP開発の進め方で、顧客の課題と解決策が合っているかを確かめる段階はPSF、市場との適合はPMFで扱っています。

言葉の整理

PoV（Proof of Value）という言い方も使われますが、今回参照した用語集では項目を確認できませんでした。社外との文書で使うときは、何を指しているのかを書き添えておくと行き違いが減ります。

報告書に書くこと

結論から書く

UNIDO のマニュアルで、フィジビリティスタディの構成として挙げられている章立ては executive summary から始まります。背景も分析も、そのあとです。

決裁する人が読む順番を考えれば自然な並びです。結論と、その結論を覆しうる条件を先に置き、根拠を後ろに回す。根拠から積み上げる構成にすると、読み手が結論に行き着く前に時間切れになることがあります。

盛り込む項目

費用だけを書いた資料では判断できません。効果と対にして、測り方まで書いておきます。

費用は一点の数字ではなく幅で出し、幅が生じている原因を書き添えます。原因が書かれていれば、読む側は「この条件を固めれば幅が縮む」と判断できます。見積もりの幅がどこから生まれるかは、システム開発の見積もりを人月から読み解くで扱っています。

書き方で結論が動いてしまうことがある

調査の資料は、書き方しだいで同じ材料から別の結論に見せられます。進めたい側が書けば進む材料が並び、止めたい側が書けば止まる材料が並ぶ。悪意がなくてもそうなります。

防ぐには、採らなかった選択肢とその理由を書き残すことです。比較した跡が残っていれば、読む側が自分で重みを付け直せます。逆に、ひとつの案だけが詳しく書かれた資料が出てきたときは、読むときに気をつけたほうがよい形だといえます。

先ほど引いた UNIDO の警告も、ここに関わります。開発会社に調査を頼むなら、その会社が作りたいものに寄った資料が出てくる可能性を、依頼する側があらかじめ織り込んでおいたほうがよいでしょう。採らなかった案を書かせる、他社にも当たる、社内で評価する人を分ける。どれかを組み合わせておくと、資料の読み方が変わります。

期間と費用を左右する要因

期間を決めるのは、調べる範囲

どのくらいの期間がかかるかは、調べる範囲に加えて、システムの規模や複雑さ、関係者の回答の速さにも左右されます。必須の問いが2つなのか8つなのか、机上で片づくのか作ってみないと分からないのかで、必要な時間は変わります。

期間を縮めたいときに効くのは、調査を一度で終わらせようとしないことです。まず短い打ち合わせで答えが出る問いを片づけて、残った問いだけを本格的に調べる。UNIDO のマニュアルも、投資前の期間を opportunity study、pre-feasibility study、feasibility study、appraisal report の段階に分けていて、見込みの薄い案に本調査をかけずに済むようにしています。

期間と費用を押し上げる要因

調査が長引くと、判断のタイミング自体を逃します。必須の判断材料を優先し、期限までに確認できない事項は、延期・追加検証・見送りとして扱います。

公共の案件では呼び方が変わる

自治体や公共施設の案件では、フィジビリティスタディという言葉はあまり出てきません。別の名前で、近い性質の工程が置かれています。

たとえば総務省の「自治体情報システムの標準化・共通化に係る手順書【第4.0版】」（2024年9月9日）には、ベンダーへの情報提供依頼（RFI）について、こう書かれています。

「RFI の目的は、想定している次期システムの要件等を実現性（想定している調達スケジュールが現実的か、【標準オプション機能】の実装見込みはどの程度か等）・経済性（自団体が想定している費用（予算）の範囲内で調達することは可能か）の観点から確認するものである」

移行そのものは法律で求められているので、やるかどうかを決める工程ではありません。ただ、どの方式でなら実現できるのか、予算に収まるのかを先に確かめるという点では、この記事で扱ってきた作業と同じです。公共施設の整備にも、内閣府の優先的検討の仕組みのなかに「詳細な検討（導入可能性調査）」が置かれています。

長く使われてきた仕組みが業務の中心にある場合は、問いの立て方が少し変わります。作るかどうかより、いまの仕組みをいつまで使えるか、どこまで直せば延命できるかが先に来ます。その見極め方はレガシーシステムは作り直すべきかで整理しています。

よくある質問

FSとF/Sは違うものですか

どちらも feasibility study の略で、指しているものは同じです。資料によって書き分けが異なるだけです。社内文書ではどちらかに統一しておくと、あとから探すときに拾いやすくなります。

フィジビリティとフィージビリティ、どちらが正しいですか

どちらも使われていて、正誤はありません。省庁の資料では「フィージビリティ」が目立ち、ビジネス系の用語集では「フィジビリティ」が使われる傾向があります。

小さい案件でも実施する必要がありますか

規模で決めるものではなく、決まっていないことがあるかどうかで決まります。関係者のあいだで作るものの像が一致していて、費用も期間も見えているなら、あらためて調査を立てる意味は薄いでしょう。一方、規模が小さくても、つなぐ先のシステムに不確かさが残っているなら、そこだけ確かめる短い調査に価値があります。

社内でやるべきですか、外部に頼むべきですか

業務の実態を知っているのは社内の人なので、問いを立てる部分は社内でやるほうが早く進みます。技術的に成り立つかを確かめる部分は、外部の手を借りたほうが確かめやすいことが多いです。全部を外に出すと、何が決まっていないのかを外部が探すところから始まります。Enlytで相談を受ける場面でも、ここに時間を取られることがあります。

開発会社に調査を頼んでも大丈夫ですか

頼んで構いませんが、出てくる資料が作りたいものに寄る可能性は見ておいたほうがよいです。UNIDOのマニュアルが1991年の時点で指摘しているとおり、売り手が出す資料は、売りたいものを前提にしがちです。採らなかった選択肢とその理由を書くよう依頼する、評価する人を分けるといった対策を取ると、資料の読み方が変わります。

調査の結果、見送りになったら費用は無駄になりますか

作り始めてから引き返す場合と比べれば、支出は小さく収まります。UNIDOのマニュアルも、投資を勧める結論に至らなかった調査について、限りある資本の配分を誤らせずに済む点で価値がある、と書いています。判断とその理由が記録として残る分も含めて、無駄とはいいにくいところです。

PoCとフィジビリティスタディは、どちらを先にやりますか

PoCは調査のなかで使う手段にあたるので、調査の設計が先になります。何を確かめるために作るのかが決まっていない状態でPoCから始めると、動くものはできても判断が進まない、という形になりやすいです。経済産業省のDXレポートが「戦略なき技術起点のPoCは疲弊と失敗のもと」と書いているのも、この順序の話だと読めます。

調査が終わったあと、何が残りますか

進めると決まった案件では、問いと答えの整理がそのまま要件定義の土台になり、作る範囲を決める作業が速く進みます。見送りになった案件でも、何が理由で見送ったのか、どの条件が変われば結論が変わるのかが残ります。半年後や1年後に同じ話が出てきたときに、ゼロから調べ直さずに済みます。

判断がつかない段階からの相談

Enlytでは、受注前の無料コンサルティングをご用意しています。開発を進めるべきか、既存のサービスで対応できるか、まだ判断できていない段階からご相談いただけます。

受注前の工程では、まず現在の業務や実現したいことを伺い、その内容をもとに開発範囲・機能・進め方を整理した要件まとめをドキュメントでお渡しします。多くの案件では暫定のUIフロー図もあわせて作成し、認識をすり合わせたうえで概算見積提案書をご説明します。実現性を確かめるための検証用の開発まで必要になる場合は、確かめる範囲を決めたうえで、基本的には別途お見積りとなります。

何が決まっていないのかを書き出すところから一緒に進めますので、相談内容が固まっていない段階でも差し支えありません。

この記事で参照した資料

• SEVOCAB（ISO・IEC・IEEEの用語データベース）。feasibility study は ISO/IEC 2382:2015、pilot project も同規格、feasibility は ISO/IEC/IEEE 24765:2017、prototype は ISO/IEC TR 7052:2023、proof of concept は INCOSE Systems Engineering Handbook 第5版（2023年）、minimum viable product は IEEE 2675-2021 と PMBOK ガイド第8版が出典。ISO/IEC が出典の定義は、出典を明記することを条件に引用が認められています
• UNIDO, Manual for the Preparation of Industrial Feasibility Studies（W. Behrens / P. M. Hawranek、1991年改訂版。初版は1978年）
• PMI Lexicon of Project Management Terms, Version 4.0（2024年）。feasibility analysis の項。現行は Version 5.0
• 内閣府「次期SIPのフィージビリティスタディ（FS）の運営方針」（2022年2月17日）
• 経済産業省「DXレポート」（2018年9月7日）
• Eric Ries, Minimum Viable Product: a guide（2009年8月3日）
• 総務省「自治体情報システムの標準化・共通化に係る手順書【第4.0版】」（2024年9月9日）
• 内閣府「PPP/PFI手法導入優先的検討規程 策定・運用の手引」（2026年3月）
• IPA「共通フレーム2013」（2013年3月）。企画プロセスのうちシステム化計画の立案に「実現可能性の検討」というタスクが置かれています（カタカナではなくこの日本語の名前です）

金子 遼平

フィリピンの語学学校スタッフとして5年間勤務後、Enlytに参画。 現在はフィリピン在住で完全リモートにて、開発ディレクター・PM・デザイナーとして複数プロジェクトを担当。 UI/UX設計とプロジェクトマネジメントを横断できる点を強みとし、リモート環境下でも安定した品質とスピードを実現している。

View More