LASSIC Media らしくメディア
フリーランス活用で新規事業の要件定義を進める、試作から決める手順
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 新規事業の要件定義は、事業の目的と最初に作る機能を社内で決めてから、フリーランスに加わってもらうと進めやすくなります。
- IPA（情報処理推進機構）の要件定義ガイドは、変化の激しい事業では実用最小限の製品を早く作り、利用者の反応をもとに改良や軌道修正を図る進め方を挙げています。
- 決まらない要件は、業務と後の工程への影響を見たうえで、期間を延ばすか対象から外すかを決め、最終判断者の承認を得ます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
新しい事業の企画は通ったのに、システムに何を求めるのかがまとまらない。社内にその分野の開発を経験した人がおらず、打ち合わせを重ねても機能が決まらない——。新規事業を任された開発の現場では、こうした行き詰まりが起こりがちです。新規事業の要件定義とは、新しい事業で誰にどんな価値を届けたいのかをもとに、そのためのシステムが備える機能や性能を決め、文書にまとめる工程です。
社内にない技術や経験を持つフリーランスのエンジニアに加わってもらうフリーランス活用は、この工程で使いどころのある方法です。試作や画面の案を実際に作り、要求が妥当かを確かめる作業を任せやすいためです。ただし万能ではなく、事業の目的や、どの要求を後回しにするかの判断までは任せられません。本記事では、新規事業を担当する開発マネージャーに向けて、要件が決まりにくい理由、社内で決めること、フリーランスに頼みやすい作業と進め方、そして外部に頼むときに確認したい点を整理します。
目次
新規事業の要件定義とは
今ある業務を新しいシステムに置き換える場合、何を実現したいのかの多くは、いまの業務の手順や帳票から読み取れます。新規事業では、その業務自体がまだありません。利用者が誰で、どんな場面でサービスを使い、何にお金を払うのかを決めるところから、要件定義が始まります。
IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」は、新しいビジネスモデルづくりで考えることとして、「お客様が本当に欲しい価値は何なのか」「ビジネスにどういう価値を作るのか」などを挙げています。そのうえで、考える中身は従来の要件定義と変わらないとしています。*1 新規事業だからといって要件定義を省けるわけではなく、決める順番と確かめ方が変わる、と整理できます。
なぜ要件が決まりにくいのか
同じガイドは、デジタル時代の要件定義の難しさを次のように説明しています。ビジネスを取り巻く環境の変化が激しいため、要件が決められず、決めた要件も頻繁に変わる。そのため「要件が確定するのを待っていると市場競争に負けてしまう」というのです。*1 新規事業で利用者の反応を見る前に機能を決め切ろうとすると、決めた要件が何度も変わり、サービスを出す時期が遅れがちです。
ガイドが挙げる進め方は、実用最小限の製品・システム（MVP。以下、最初の版）をできるだけ早く作って利用者に提供し、その反応を確かめた結果をもとに、当初のアイデアの改良や軌道修正、さらには破棄を図るというものです。これをリーンスタートアップ（新しい事業を試作と検証の繰り返しで進める方法）と呼び、それを支えるには要求の変更に柔軟な開発、つまりアジャイル開発（短い期間で作って確かめることを繰り返す開発）が要るとしています。*1
もう一つの理由は、決める人どうしの意見がそろわないことです。ガイドは要件が決まらない原因として、「ユーザ側で要件が絞り込めない」ことと「部門間で意見が対立する」ことを挙げています。*1 新規事業では、比べられる今の業務が無いぶん、営業や企画の担当者と開発の担当者が、それぞれ別の利用者像を思い描いたまま話を進めてしまうことがあります。
社内で決めること
ガイドは「要件定義はゼロから始まるわけではない」とし、要件定義を始める前に、システム化の企画で構想した内容を確かめるよう求めています。確かめる項目は次の5つです。*1 新規事業に当てはめたときに書いておきたいことを右の列に並べました。
| 企画の項目 | 新規事業で書いておきたいこと |
|---|---|
| システム化の背景・目的 | 誰に向けた、どんなサービスを始めるのか。システムが無いと何ができないのか |
| 問題・課題の内容 | 利用者が今どんなことに困っていて、サービスで何を解決するのか |
| 問題解決・課題達成のポイント | 最初の版で確かめたいこと（申し込みまで進むか、料金を払ってもらえるか など） |
| 方策の立案と期待効果 | 最初の版に入れる機能と、どうなれば期待どおりとするか |
| プロジェクト計画 | 最初の版を出すまでの期間、体制、費用、社内の誰が判断するか |
ガイドは、企画の目的が「サプライチェーン業務の見直し」のようにあいまいだと、何のために見直すのかが不明確になり、関係者の間で目的の捉え方がずれると指摘しています。新規事業でいえば、「新しい顧客層に向けたサービスを始める」だけでは足りず、どの顧客のどんな困りごとを解決するのかまで書いておく必要があります。企画の内容が不十分なら、「無理に要件定義を開始せずに、構想・企画に差し戻し、再検討を依頼する」ことも求めています。*1
事業の骨組みそのものがまだ固まっていないこともあります。ガイドは、事業の全体像をまとめる方法の一つとしてビジネスモデルキャンバスを紹介しています。9つの欄に分かれ、中央に置く価値提案（利用者に何を提供するか）を軸に、顧客、収益、コストなどを1枚に書く方法です。構想立案そのものが必要だと判断したときは、要件定義とは別に期間を確保して行うよう勧めています。*1 構想が固まっていなければ、要件定義は始めずに、先に構想をまとめます。
フリーランスに頼みやすい作業
ガイドは、要件定義の体制づくりで起きがちな問題として、「業務知識を持つキーマンの時間が十分に確保できない」ことと並べて、「要件定義に必要な分野の IT 技術をもった人材が確保できない」ことを挙げています。*1 また、IT技術に詳しい人が上流工程（企画や要件定義など開発の前半の工程）から加わることも必要になってきていると述べています。新規事業で社内に経験者がいない技術なら、フリーランス（会社に雇われずに個人で仕事を請け負う人）のエンジニアに加わってもらうのが一つの方法です。
頼みやすいのは、試作や画面の案を実際に作り、要求が妥当かを確かめる作業です。たとえば次のようなものがあります。
- 最初の版に入れる機能を、利用者が操作できる形にした試作
- 画面遷移図（画面のつながりを示す図）と画面レイアウトの案
- 一から作るか、既製のソフトウェアやクラウドのサービスを使うかといった実現方式の比較
- 要求ごとに、実現にかかる工数の見積り
ガイドは、画面遷移図や画面レイアウトを、利用者が操作する画面を見ながら、要求が妥当か、実現できるかを確かめるための資料としています。*1 紙の上の要求一覧だけでは、事業の担当者は出来上がりを想像しにくいものです。画面や試作があれば、「この項目は申し込みの時点では要らない」といった判断を、その場で下しやすくなります。
ガイドの事例には、要件定義の経験の深い外部のコンサルタント1名に、プロジェクトの中身ではなく、進め方や進捗管理を支援してもらった例もあります。 試作を作る人だけでなく、要件定義の進め方を知っている人に加わってもらう方法もある、ということです。
どう進めるのか
フリーランスに加わってもらう新規事業の要件定義は、次の順で進めると、社内で決めることと任せる作業が混ざりにくくなります。
1つ目は、企画の5項目を関係者全員で読み合わせることです。ガイドも、企画の項目が関係者全員の共通認識となるよう読み合わせをし、疑問点は要件定義を始めるまでに明らかにするよう求めています。 加わってもらうエンジニアにもこの場に出てもらうと、なぜその機能が要るのかを最初から共有でき、技術面で実現が難しい点もその場で指摘してもらえます。
2つ目は、要求事項の一覧を作ることです。この段階では、システムで実現するかどうかはまだ決めず、要求の漏れがないかを確かめます。ガイドの一覧の例では、要求ごとに理由、優先順位、要求元を発注する側が書き、実現にかかる見積りを開発する側が書く形になっています。*1 新規事業では、見積りの欄をフリーランスのエンジニアに埋めてもらうと、どの要求の実現に手間がかかるのかが早く分かります。
3つ目は、最初の版に入れる機能を決めて試作することです。優先順位の高い要求だけを選び、利用者に見てもらえる形にします。4つ目は、利用者の反応をもとに要求を見直すことです。反応が思わしくない機能は改良するか、やめるかを決めます。この2つを繰り返すあいだ、要求事項の一覧はそのつど書き換えます。
5つ目は、決まらない要件を台帳に残すことです。ガイドは、決まっていない要件の一覧表（要件未決事項台帳）の項目として、責任者、未決による影響、決定のための条件などを挙げています。後回しにしてよい要件の基準も例示しており、システムの効果に直接関係せず、システム化の対象を変えないことなどを挙げています。*1
つまずきやすい点
一つ目は、試作を見て判断する社内の人が、打ち合わせに出られないことです。ガイドの事例では、業務部門から出た代表者の時間が確保できず、課題の解決やレビューが遅れ、要件定義工程が大きく遅延したことがありました。次のプロジェクトでは、その代表者を専任にし、兼務する人が関わる工数を依頼書に書いて、プロジェクトオーナーから現場の管理者に依頼し、合意を得ています。*1 新規事業でも、事業の責任者が既存の仕事と兼務のままだと、試作ができても採否が決まりません。
二つ目は、決まらない要件のために期間を延ばし続けることです。ガイドは、期間をずるずると延ばすと後に続く工程の期間が圧迫されるとし、システム化しないことによる業務への影響と、要件が決まらないことによる後続工程への影響を評価するよう求めています。そのうえで、期間を延ばす、システム化しない、いったん対象から外して別に検討する、といった選択肢を挙げ、決めた内容はプロジェクトオーナー（プロジェクトで最終的な判断を下す人）の承認を得るとしています。*1
三つ目は、決めた要件で本当に狙いどおりの効果が出るのか確信が持てないまま、開発に進むことです。ガイドは、要件定義の内容に自信が持てず、関係者で確かめても大丈夫という確証が得られないときは、「いったんその施策の実施を棚上げ・中止することを選択肢に加える」としています。*1 試作への利用者の反応が思わしくないなら、機能を増やして乗り切ろうとせず、事業の企画に戻って考え直すことも選択肢になります。
外部に委託するときに確認しておきたい点
フリーランスのエンジニアに加わってもらうときは、頼む作業と期間を先に書いておきます。「最初の版の申し込み画面の試作を6週間で作る。並行して画面遷移図と画面レイアウトの案をまとめ、要求事項の一覧の見積り欄を埋める」——このくらいまで書けていれば、求める経験もはっきりし、候補者と具体的に話せます。
あわせて、試作を見て採否を決める社内の人と、その人が打ち合わせに出られる日を決めておきます。試作に使ったプログラムを本番のシステムに使うのか、要求を確かめるためだけに使うのかも、最初にエンジニアに伝えておきます。どこまで作り込むかについて、社内とエンジニアの考えが食い違うのを防げます。事業の目的と頼む作業の決め方は「フリーランス活用で始める新規事業｜目的と頼む作業を決める」で、今あるシステムを刷新するときの要件定義は「SESのエンジニアとシステム刷新の要件定義を進める手順」で扱っています。
まとめ：新規事業の要件定義で確かめたい3つの点
フリーランス活用で新規事業の要件定義を進めるうえで、確かめておきたい点は3つに整理できます。第一に、誰に何を届ける事業なのか、最初の版で何を確かめたいのかを、要件定義を始める前に社内で書いておくこと。第二に、試作や画面の案を作って要求を確かめる作業をフリーランスに頼み、採否は社内の人が決めること。第三に、決まらない要件は影響を評価し、期間を延ばすか対象から外すかを、プロジェクトオーナーの承認のもとで決めることです。この3点を踏まえておけば、「試作はできたのに、何を作るのかがいつまでも決まらない」という事態を避けやすくなります。最初の版に入れる機能の決め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
新規事業の要件定義には、どのくらいの期間を見込めばよいですか
一律の目安はありません。最初の版に入れる機能を少なく絞れば、試作と見直しを早く回せます。期間を決めるときは、試作を見て判断する社内の人が打ち合わせに出られる日数も数に入れておくと、予定どおりに進めやすくなります。
フリーランスのエンジニアに、要件定義書の作成まで任せてもよいですか
文書にまとめる作業は任せられますが、何を要件とするかを決めるのは社内です。書き上がった文書は、事業の担当者が読んで意図どおりかを確かめます。
要件定義に加わったフリーランスに、その後の開発も続けて頼めますか
頼めます。要求がなぜそう決まったのかを知っている人が開発に加わると、説明の手間が減ります。ただし、その人しか経緯を知らない状態にならないよう、要求事項の一覧や決まらない要件の台帳は、社内で読める形で残しておきます。
新規事業の要件定義を相談したいとき
最初の版に入れる機能の整理や、試作を任せる人材の探し方からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf）。出典：独立行政法人情報処理推進機構 社会基盤センター（2019年）。1.1.4（DXに見える今後求められるシステム開発）、1.2.2（パラダイムシフト）、6.1.1（構想・企画の確認、表6.1 企画内容の確認、表6.3 要求事項一覧フォーマット）、6.2.4（体制・チームビルディング、事例11 キーマンの時間が十分に確保できない）、6.4.1（要求評価）、6.4.2（2）（表6.28 要件未決事項台帳の例）、7.1.1（ビジネスコンセプト確認ドキュメント）、7.9を参照（2026年9月確認）
