LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

新規事業の要件定義とは、まだ無い事業で誰にどんな価値を届けるかを決めたうえで、そのためのシステムが備える機能や性能を決め、文書にまとめる工程です。既存システムの刷新ならいま動いている業務や仕様から要求を読み取れますが、新規事業には読み取る元が無いため、最初の版を作り、利用者の反応で要求を確かめながら決めていく点が違います。社内に経験者がいない技術を使うなら、外部のフリーランスのエンジニアに試作や見積りを頼み、何を要件とするかは社内が決める、という分担で進めます。

本記事では、IPA（情報処理推進機構）の要件定義ガイドをもとに、刷新との違い、要件が決まりにくい理由、社内で決めること、フリーランスと進める手順を整理します。

新規事業の要件定義とは

要件定義は、システムに何をさせるのか、どの程度の速さや使いやすさで動かすのかを決め、開発する側に渡せる文書にまとめる工程です。IPAの「ユーザのための要件定義ガイド 第2版」は、要件定義を、ITシステムをビジネスに活用する当事者であるユーザが「自ら中心になって実施すべきもの」としています。^*1 新規事業でも既存システムの刷新でも、何を要件とするかを決めるのは発注する側の会社です。

違いは、要求がどこから出てくるかにあります。ガイドは、ITシステムを、基幹業務のデータ処理を中心とする「守りの分野」と、顧客とのつながりや新しい技術を生かす「攻めの分野」に分けて説明しています。攻めの分野では「要求のすべてが開発段階で明らかになっていないことが多く」、サービスを始めてから徐々に明らかになる要求に応え続ける必要があるとしています。一方、守りの分野の再構築では、長年の保守で積み重なった業務仕様を十分に理解できていないことが難しさになると述べています。^*1

ただし、考える中身まで変わるわけではありません。ガイドは、新しいビジネスモデルづくりで考えることとして「お客様が本当に欲しい価値は何なのか」「ビジネスにどういう価値を作るのか」などを挙げ、それは従来の要件定義と同じだとしています。新規事業だから要件定義を省けるのではなく、決める順番と確かめ方が変わる、と捉えるとよいでしょう。刷新の場合に今の業務やシステムをどう把握するかは「SESのエンジニアとシステム刷新の要件定義を進める手順」で扱っています。

外部のエンジニアと進めるときも、この違いが分担に表れます。新規事業では、試作や画面の案を作り、要求ごとに実現の手間を見積もる作業をフリーランスに頼み、最初の版に何を入れ、何を後回しにするかは社内が決めます。

なぜ要件が決まりにくいのか

同じガイドは、デジタル時代の要件定義の難しさを次のように説明しています。ビジネスを取り巻く環境の変化が激しいため、要件が決められず、決めた要件も頻繁に変わる。そのため「要件が確定するのを待っていると市場競争に負けてしまう」というのです。^*1 利用者の反応を見る前に機能を決め切ろうとすると、要件が何度も変わり、サービスを出す時期が遅れがちです。

ガイドが挙げる進め方は、実用最小限の製品・システム（MVP。以下、最初の版）をできるだけ早く作って利用者に提供し、その反応を確かめた結果をもとに、当初のアイデアの改良や軌道修正、さらには破棄を図るというものです。これをリーンスタートアップ（新しい事業を試作と検証の繰り返しで進める方法）と呼び、それを支えるには要求の変更に柔軟な開発、つまりアジャイル開発（短い期間で作って確かめることを繰り返す開発）が要るとしています。^*1

もう一つの理由は、決める人どうしの意見がそろわないことです。ガイドは要件が決まらない原因として、「ユーザ側で要件が絞り込めない」ことと「部門間で意見が対立する」ことを挙げています。^*1 新規事業では、比べられる今の業務が無いぶん、営業や企画の担当者と開発の担当者が、それぞれ別の利用者像を思い描いたまま話を進めてしまうことがあります。

社内で決めること

ガイドは「要件定義はゼロから始まるわけではない」とし、要件定義を始める前に、システム化の企画で構想した内容を確かめるよう求めています。確かめる項目は次の5つです。^*1 新規事業に当てはめたときに書いておきたいことを右の列に並べました。

ガイドは、企画の目的が「サプライチェーン業務の見直し」のようにあいまいだと、何のために見直すのかが不明確になり、関係者の間で目的の捉え方がずれると指摘しています。新規事業でいえば、「新しい顧客層に向けたサービスを始める」だけでは足りず、どの顧客のどんな困りごとを解決するのかまで書いておく必要があります。企画の内容が不十分なら、「無理に要件定義を開始せずに、構想・企画に差し戻し、再検討を依頼する」ことも求めています。^*1

事業の骨組みそのものがまだ固まっていないこともあります。ガイドは、事業の全体像をまとめる方法の一つとしてビジネスモデルキャンバスを紹介しています。9つの欄に分かれ、中央の価値提案（利用者に何を提供するか）を軸に、顧客や収益などを1枚に書く方法です。構想立案そのものが必要だと判断したときは、要件定義とは別に期間を確保して行うよう勧めています。^*1

フリーランスに頼みやすい作業

ガイドは、要件定義の体制づくりで起きがちな問題として、「業務知識を持つキーマンの時間が十分に確保できない」ことと並べて、「要件定義に必要な分野の IT 技術をもった人材が確保できない」ことを挙げています。^*1 また、IT技術に詳しい人が上流工程（企画や要件定義など開発の前半の工程）から加わることも必要になってきていると述べています。新規事業で社内に経験者がいない技術なら、フリーランス（会社に雇われずに個人で仕事を請け負う人）のエンジニアに加わってもらうのが一つの方法です。

頼みやすいのは、試作や画面の案を実際に作り、要求が妥当かを確かめる作業です。たとえば次のようなものがあります。

• 最初の版に入れる機能を、利用者が操作できる形にした試作
• 画面遷移図（画面のつながりを示す図）と画面レイアウトの案
• 一から作るか、既製のソフトウェアやクラウドのサービスを使うかといった実現方式の比較
• 要求ごとに、実現にかかる工数の見積り

ガイドは、画面遷移図や画面レイアウトを、利用者が操作する画面を見ながら、要求が妥当か、実現できるかを確かめるための資料としています。^*1画面や試作があれば、「この項目は申し込みの時点では要らない」といった判断を、その場で下しやすくなります。

ガイドの事例には、要件定義の経験の深い外部のコンサルタント1名に、プロジェクトの中身ではなく、進め方や進捗管理を支援してもらった例もあります。

どう進めるのか

フリーランスに加わってもらうときは、次の順で進めると、社内で決めることと任せる作業が混ざりにくくなります。

1つ目は、企画の5項目を関係者全員で読み合わせることです。ガイドも、企画の項目が関係者全員の共通認識となるよう読み合わせをし、疑問点は要件定義を始めるまでに明らかにするよう求めています。 加わってもらうエンジニアにもこの場に出てもらうと、なぜその機能が要るのかを最初から共有でき、技術面で実現が難しい点もその場で指摘してもらえます。

2つ目は、要求事項の一覧を作ることです。この段階では、システムで実現するかどうかはまだ決めず、要求の漏れがないかを確かめます。ガイドの一覧の例では、要求ごとに理由、優先順位、要求元を発注する側が書き、実現にかかる見積りを開発する側が書く形になっています。^*1 新規事業では、見積りの欄をフリーランスのエンジニアに埋めてもらうと、どの要求の実現に手間がかかるのかが早く分かります。新しい業務の手順や量を項目ごとに書き出す方法は「フリーランス活用で上流工程の業務要件整理、書き出す8つの項目」で扱っています。

3つ目は、最初の版に入れる機能を決めて試作することです。優先順位の高い要求だけを選び、利用者に見てもらえる形にします。4つ目は、利用者の反応をもとに要求を見直すことです。反応が思わしくない機能は改良するか、やめるかを決めます。この2つを繰り返すあいだ、要求事項の一覧はそのつど書き換えます。

5つ目は、決まらない要件を台帳に残すことです。ガイドは、決まっていない要件の一覧表（要件未決事項台帳）の項目として、責任者、未決による影響、決定のための条件などを挙げています。後回しにしてよい要件の基準も例示しており、システムの効果に直接関係せず、システム化の対象を変えないことなどを挙げています。^*1

つまずきやすい点

一つ目は、試作を見て判断する社内の人が、打ち合わせに出られないことです。ガイドの事例では、業務部門から出た代表者の時間が確保できず、課題の解決やレビューが遅れ、要件定義工程が大きく遅延したことがありました。次のプロジェクトでは、その代表者を専任にし、兼務する人が関わる工数を依頼書に書いて、プロジェクトオーナーから現場の管理者に依頼し、合意を得ています。^*1 新規事業でも、事業の責任者が既存の仕事と兼務のままだと、試作ができても採否が決まりません。

二つ目は、決まらない要件のために期間を延ばし続けることです。ガイドは、期間をずるずると延ばすと後に続く工程の期間が圧迫されるとし、システム化しないことによる業務への影響と、要件が決まらないことによる後続工程への影響を評価するよう求めています。そのうえで、期間を延ばす、システム化しない、いったん対象から外して別に検討する、といった選択肢を挙げ、決めた内容はプロジェクトオーナー（プロジェクトで最終的な判断を下す人）の承認を得るとしています。^*1

三つ目は、決めた要件で本当に狙いどおりの効果が出るのか確信が持てないまま、開発に進むことです。ガイドは、要件定義の内容に自信が持てず、関係者で確かめても大丈夫という確証が得られないときは、「いったんその施策の実施を棚上げ・中止することを選択肢に加える」としています。^*1

外部に委託するときに確認しておきたい点

フリーランスのエンジニアに加わってもらうときは、頼む作業と期間を先に書いておきます。「最初の版の申し込み画面の試作を6週間で作る。並行して画面遷移図と画面レイアウトの案をまとめ、要求事項の一覧の見積り欄を埋める」——このくらいまで書けていれば、求める経験もはっきりし、候補者と具体的に話せます。

あわせて、試作を見て採否を決める社内の人と、その人が打ち合わせに出られる日を決めておきます。試作に使ったプログラムを本番のシステムに使うのか、要求を確かめるためだけに使うのかも、最初にエンジニアに伝えておきます。どこまで作り込むかについて、社内とエンジニアの考えが食い違うのを防げます。事業の目的と頼む作業の決め方は「フリーランス活用で始める新規事業｜目的と頼む作業を決める」で扱っています。

まとめ：新規事業の要件定義で確かめたい3つの点

新規事業の要件定義は、既存システムの刷新と違い、利用者の反応から要求を確かめながら決めていきます。外部のフリーランスと進めるうえで確かめておきたい点は3つです。第一に、誰に何を届ける事業なのか、最初の版で何を確かめたいのかを、要件定義を始める前に社内で書いておくこと。第二に、試作や画面の案を作って要求を確かめる作業をフリーランスに頼み、採否は社内の人が決めること。第三に、決まらない要件は影響を評価し、期間を延ばすか対象から外すかを、プロジェクトオーナーの承認のもとで決めることです。この3点を踏まえておけば、「試作はできたのに、何を作るのかがいつまでも決まらない」という事態を避けやすくなります。最初の版に入れる機能の決め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *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年10月確認）

Tweet