要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方

この記事では、要件定義とは何か、新規事業のシステム開発でなぜ抜け漏れや認識のズレが起きやすいのか、そしてそれを減らす進め方を順を追って解説します。読み終えるころには、要件定義で何を決めるのか、発注前に何を準備すればよいのか、開発会社に何を確認すればよいのかが分かります。

要件定義とは何か

要件定義とは、システムで「何を実現するのか」「どんな条件で作るのか」を整理し、発注側と開発側で合意する工程です。開発のいちばん最初に行い、後の設計・実装・テストはこの内容を土台に進みます。土台がずれていれば、その上に何を積んでもずれたままです。

IPA（情報処理推進機構）が公表している「共通フレーム」でも、要件定義は、利害関係者（システムに関わる人たち）のニーズを整理し、システムが満たすべき要件としてまとめる活動として扱われています。

機能要件と非機能要件

要件は大きく2種類に分けて考えると整理しやすくなります。

• 機能要件：システムが持つ機能。たとえば「利用者が会員登録できる」「管理者が申込内容を承認できる」「承認後に通知が届く」など。
• 非機能要件：機能以外の品質や条件。たとえば「同時に何人が使えるか」「どのくらいの速さで表示されるか」「障害時にどう復旧するか」「誰がどのデータを見られるか」など。

打ち合わせでは機能の話が中心になり、非機能要件は後回しになりがちです。しかし運用が始まってから問題になるのは、非機能要件であることも少なくありません。IPAは「非機能要求グレード」という、非機能要件を漏れなく確認するための資料を公開しています。項目を洗い出す際の参考になります。

要件定義で決めること

要件定義でまとめる内容は、おおむね次のとおりです。

• システムを作る目的と、成功したと言える状態
• 想定する利用者と、使う場面
• 業務や利用の流れ（フロー）
• 機能の一覧と優先順位
• 画面や帳票、データの扱い
• 非機能要件（性能、セキュリティ、運用など）
• 制約条件（期限、既存システムとの連携、法令など）
• 今回は作らないもの（範囲外）

最後の「今回は作らないもの」は見落とされやすい項目です。何を作るかと同じくらい、何を作らないかを書いておくことが、後のズレを防ぎます。

新規事業で要件定義が難しくなる理由

要件定義は、どんなシステム開発でも重要です。ただ、新規事業では難しさが一段増します。

正解がまだ分かっていない

既存業務のシステム化であれば、今のやり方という「見本」があります。新規事業にはそれがありません。誰に、何を、どんな形で提供すれば価値になるのかは仮説の段階で、要件を詳しく決めようとしても、決める根拠が足りない場面が出てきます。

無理に細部まで固めると、「確定しているように見えて、実は仮説のまま」という要件書ができます。開発が進んだあとで仮説が崩れると、作り直しが必要になります。

決裁者と現場で、判断の材料と速度が違う

新規事業では、経営陣などの決裁者と、現場の立案者が、同じ目的を見ているのに話が噛み合わないことがあります。原因は目的の違いではなく、進め方の違いです。決裁者は「投資に見合うか」を判断する材料を求め、現場は「まず動かして確かめたい」という速度で考えています。

要件定義がこの2者の間にある状態で進むと、現場が作った要件を決裁者が後から見て「イメージと違う」となり、手戻りが起きます。要件を決める段階から、決裁者が判断できる形で情報を見せることが大切です。

言葉だけで決めると、同じ言葉を別の意味で受け取る

要件定義書は文章と図で書かれます。ところが、文章はそれを読む人によって解釈が変わります。たとえば「会員」という言葉ひとつでも、発注側は「購入経験のある人」、開発側は「登録した人すべて」と受け取っているかもしれません。言葉だけで決めた要件は、この種の認識違いを抱えたまま進みやすくなります。

開発全体の流れについては、新規事業のシステム開発の進め方｜構想から運用までの全体像でも整理しています。

抜け漏れとズレは、どこで起きるのか

要件定義の失敗は、大きく「抜け漏れ」と「ズレ」に分けられます。どこで起きやすいかを知っておくと、確認すべき場所が見えてきます。

種類	起きやすい場所	具体例
抜け漏れ	例外・異常時の動き	決済が失敗したとき、入力ミスがあったときにどうするか
抜け漏れ	権限とデータの扱い	誰が何を見られるか、退会したユーザーのデータをどうするか
抜け漏れ	運用に関わる部分	問い合わせ対応の画面、データの修正手段、通知の設定
ズレ	用語の解釈	「承認」「会員」「完了」の範囲が人によって違う
ズレ	完成イメージ	画面の見た目や操作の手順を、それぞれが別に想像している
ズレ	優先順位	決裁者と現場で「最初に必要な機能」が異なる

抜け漏れの多くは、「当たり前だから書かなかったこと」に潜んでいます。話す側は当然だと思っているため口に出さず、聞く側も確認しないまま進んでしまいます。ズレは、逆に「同じものを見ているつもり」の状態から生まれます。

新規事業のための要件定義の進め方

ここからは、抜け漏れとズレを減らすための進め方を、順番に紹介します。新規事業で特に効果のある点を中心に整理しています。

ステップ1：目的と「確かめたいこと」を先に決める

最初に、機能ではなく目的を書きます。「何のためのシステムか」と、「この段階で何を確かめたいのか」の2つです。

たとえば「サービスの申込から提供までをオンラインで完結させる」ことが目的だとします。その場合、確かめたいことは「利用者が迷わず申込を完了できるか」「運営側が無理なく対応できるか」などになります。

確かめたいことが決まると、機能の優先順位が決まります。それに関係しない機能は、後回しにしても問題ありません。

ステップ2：利用者と利用場面を具体的にする

「ユーザー」とひとまとめにせず、誰がどんな場面で使うのかを具体的に書きます。利用者が複数いる場合は、それぞれに分けて考えます。

• 一般の利用者（サービスを申し込む人）
• 運営側の担当者（申込を確認し、対応する人）
• 管理者（全体の設定やデータを管理する人）

新規事業では、利用者だけでなく運営側の画面や作業が後回しにされがちです。しかし、事業が動き出してから運営側が回らなくなる例は珍しくありません。最初から運営側の視点も含めて洗い出します。

ステップ3：流れを図にして、例外も書き込む

機能を並べる前に、利用の流れを図にします。申込から始まり、確認、提供、請求、完了までを順に描きます。

そのうえで、各段階で「うまくいかなかったらどうするか」を書き込みます。入力に誤りがあった場合、途中でキャンセルされた場合、担当者が不在の場合などです。抜け漏れの多くは、この例外の部分で見つかります。

ステップ4：機能に優先順位をつける

機能が出そろったら、優先順位をつけます。よく使われる方法に、MoSCoW（モスクワ）法があります。機能を次の4つに分ける考え方です。

• Must：これがなければ事業の検証ができない機能
• Should：重要だが、初回になくても検証はできる機能
• Could：あれば望ましい機能
• Won’t：今回は作らないと決めた機能

新規事業では、Mustをできるだけ絞ることが重要です。多くの機能を最初から入れると、開発の期間が伸びるだけでなく、何が事業の成否を分けたのかも分かりにくくなります。

ステップ5：範囲外と未確定事項を書く

要件定義書には、「今回は作らないもの」と「まだ決まっていないこと」をはっきり書きます。

未確定事項の一覧には、決めるべき内容、決める人、決める期限を添えます。決まっていないことを隠さず記録しておけば、開発途中で「聞いていない」「決まっていたはず」といった行き違いが起きにくくなります。

ステップ6：非機能要件を確認する

非機能要件は、聞かれないと答えにくい項目です。細かい数値を最初から決める必要はありません。ただ、次の点はおおまかに確認しておきます。

• 想定する利用者数と、今後の増え方
• 扱うデータの重要度（個人情報や決済情報を含むか）
• 障害や不具合が起きたときの対応と、許容できる停止時間
• 運用を誰が担当するのか

事業が小さく始まる場合でも、個人情報を扱うならセキュリティは最初から考える必要があります。「後から追加する」と決めた項目は、そのこともあわせて書き残します。

ステップ7：合意の取り方を工夫する

要件定義書ができあがったら、関係者全員で内容を確認します。このとき、次の点を意識します。

• 決裁者にも、判断に必要な部分が伝わる形で見せる（全文ではなく要点と図で）
• 用語集をつくり、重要な言葉の意味をそろえる
• 「読みました」ではなく、「この画面でこの操作をするとどうなるか」を口頭で説明してもらい、理解のずれを確かめる

言葉だけの要件定義には限界がある

ここまでの手順を踏んでも、文章と図だけの要件定義には限界があります。画面の操作感や、情報の見せ方、操作の流れの自然さは、実際に触ってみないと分からないからです。

要件定義書を読んで「問題ない」と判断した人が、完成したシステムを見て「これじゃない」と感じることは、珍しくありません。読んでいる間は理解したつもりでも、実物とのあいだに頭の中で補っていた部分があるからです。

動く実物で確かめるという考え方

この問題への有力な対処法が、プロトタイプ（動く試作品）を先に作り、それを見ながら要件をすり合わせる方法です。実物を触りながらであれば、「ここはこうしたい」「この操作は分かりにくい」といった指摘が具体的に出てきます。言葉だけの認識違いや、使ってみて初めて分かる「これじゃない」を、早い段階で直せます。

新規事業では特に、この方法が向いています。要件が仮説の段階であることが多く、仮説を実物で確かめながら決めるほうが、机上で決め切るより無理がないからです。決裁者にとっても、企画書だけでは伝わりにくい「何ができるのか」を動く実物で確認できるため、判断しやすくなります。

近年は、AIを活用した開発によって、試作品をつくるまでの手間が以前より小さくなってきています。「要件を全部決めてから作る」以外の選択肢が、現実的なものになってきたと言えます。ただし、プロトタイプで確かめるのは「何を作るか」の判断であり、それを決めるのは人です。要件定義の考え方そのものは、変わらず重要です。

発注前のチェックリスト

最後に、外注する前に確認しておきたい点をまとめます。

発注側で準備しておくこと

• システムの目的と、この段階で確かめたいことを一文で言える
• 想定する利用者と、運営側の担当者を洗い出している
• 利用の流れを、大まかにでも図にしている
• 最初に必要な機能（Must）と、後回しにできる機能を分けている
• 最終的に判断する人（決裁者）が誰かが決まっており、早い段階から関与できる
• 分からないことを、分からないと伝える準備がある

すべてがそろっていなくても構いません。仕様が固まっていない段階だからこそ、相談する価値があります。

開発会社に確認したいこと

• 要件が固まっていない部分を、どう扱うのか
• 開発の途中で要件が変わったとき、どのように対応するのか
• 要件を確認するために、どんな方法（文書、図、実物など）を使うのか
• 契約を判断する前に、何を見て確認できるのか
• 納品後の運用や、機能追加をどう支援してもらえるのか

これらへの答え方から、その会社が要件定義をどう考えているかが分かります。丁寧に説明してくれるか、こちらの不安を具体的に聞いてくれるかも、判断の材料になります。

まとめ

要件定義は、システムで何を実現し、何を作らないかを、関係者全員で合意する工程です。新規事業では正解が未確定であることに加え、決裁者と現場で判断の材料と速度が異なるため、抜け漏れやズレが起きやすくなります。

防ぐためのポイントは次のとおりです。

• 機能より先に、目的と「確かめたいこと」を決める
• 利用者と運営側の両方の視点で、流れと例外を洗い出す
• 優先順位をつけ、「今回は作らないもの」と未確定事項も書き残す
• 言葉だけで決め切らず、動く実物で確かめながらすり合わせる

要件定義の目的は、完璧な仕様書を作ることではなく、作るものについて全員が同じ認識を持つことです。新規事業では、その認識を「実物を見ながら」つくるほうが、無理が少なく進められます。

JustFitは、株式会社LEGAREAが運営する受託開発サービスです。「先に作って、後から決める（PROTOTYPE FIRST）」という考え方のもと、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただけます。仕様が固まっていない段階でも相談できますので、詳しくはJustFitのサービス紹介をご覧ください。