要件定義は3層で考える｜経営要求・業務要求・システム要求の分け方

「トップ画面に売上グラフを出してほしい」

要件定義の打ち合わせで、こうした要望が出ることはよくあります。

ここで「承知しました」と受けてしまうと、後で困ることになります。なぜなら、その要望が何のためのものか、誰も分からないまま作られてしまうからです。

グラフが欲しい理由が「毎朝の会議で先月比を確認したい」なら、必要なのはグラフではなく、比較できる数字かもしれません。

この記事では、要件を3つの層に分けて整理する方法を解説します。

なお、発注側が準備すべき資料や進め方については、システム開発の要件定義、発注側は何を準備すればいい？で詳しく解説しています。この記事では要求を整理する考え方に絞ります。

要件は3つの層に分かれている

要件定義でよく起きる混乱は、レベルの違う話が同じ場で飛び交うことに原因があります。

整理すると、要件には3つの層があります。

層	問い	決める人	例
経営要求	会社として何を達成したいか	経営者	間接業務の人件費を年60万円削減する
業務要求	そのために業務をどう変えるか	業務責任者・現場	受注情報の二重入力をなくす
システム要求	そのために何が必要か	IT担当・開発会社	受注データから請求書を自動生成する

この3つは上から下へ流れます。経営要求があって業務要求が決まり、業務要求があってシステム要求が決まる。

逆流させてはいけません。「こんな機能が欲しい」から始めると、それが何の役に立つのか誰も説明できなくなります。

層が混ざるとどうなるか

実際の打ち合わせでは、こんな会話が起こります。

• 経営者「とにかく効率化したい」（経営要求）
• 現場「この画面にボタンを追加してほしい」（システム要求）
• 経理「月末の作業を減らしたい」（業務要求）

3人とも正しいことを言っていますが、話している層が違うため議論がかみ合いません。

この状態で開発を進めると、声の大きい人の要望が採用され、全体としてちぐはぐなシステムができあがります。

層を上へたどる｜「なぜ」を3回聞く

現場から出てきた要望を、上の層へたどる方法があります。「なぜそれが必要か」を繰り返し聞くだけです。

段階	やり取り	層
最初の要望	トップ画面に売上グラフを出してほしい	システム要求
なぜ？	毎朝の朝礼で、今月の進捗を共有したいから	業務要求
なぜ？	月末になって未達に気づくのを避けたいから	業務要求
なぜ？	早く気づけば、月内に手を打てて売上目標を守れるから	経営要求

ここまで来ると、本当に必要なものが見えてきます。

この例で必要なのは「グラフ」ではなく、目標に対する進捗と、遅れている場合の早期の気づきです。

だとすれば、グラフを作るより「未達の見込みになったら通知する」ほうが目的に合っているかもしれません。安く、確実で、しかも見忘れがない。

要望をそのまま実装していたら、この選択肢は出てきませんでした。

3層で整理する要求一覧の作り方

実際に整理するときは、次の形式で書き出します。

経営要求	業務要求	システム要求	優先度
間接業務の負担を減らし、利益率を改善する	受注情報の二重入力をなくす	受注データから請求書を自動生成する	必須
間接業務の負担を減らし、利益率を改善する	請求漏れをゼロにする	未請求の受注を一覧で表示する	必須
間接業務の負担を減らし、利益率を改善する	担当者以外も受注状況を把握できる	受注一覧を全社員が閲覧できる	推奨
受注増に耐えられる体制を作る	月末に集中する作業を分散する	締め日を取引先ごとに設定できる	推奨
受注増に耐えられる体制を作る	新人でも受注処理ができる	入力時に必須項目をチェックする	必須

同じ経営要求が繰り返し出てきますが、それで構いません。1つの経営要求に、複数の業務要求がぶら下がる形が自然です。

この表には、3つの効果があります。

• 抜けが見つかる。経営要求に対して業務要求が1つしかない場合は、検討不足の可能性が高い
• 要らないものが見つかる。どの経営要求にもつながらないシステム要求は、外す候補になる
• 優先度を説明できる。「なぜこれが必須か」を経営要求まで遡って答えられる

2番目は特に重要です。どの経営要求にもぶら下がらない機能は、あれば便利なだけの機能です。

忘れられやすい「機能以外の要求」

要件定義では、どうしても機能の話に集中しがちです。

しかし、実際にトラブルの原因になるのは、機能以外の部分であることが少なくありません。

種類	決めておくこと	決めないと起きること
性能	何件まで扱うか。何秒以内に表示するか	データが増えると使い物にならなくなる
同時利用	何人が同時に使うか	繁忙期に動作が重くなる
権限	誰が何を見られるか	見せたくない情報が全員に見える
記録	誰がいつ何をしたかを残すか	トラブル時に原因を追えない
データ移行	過去データをどこまで移すか	移行作業が想定外の工数になる
障害時	止まったらどうするか	復旧手順がなく業務が長時間止まる
運用	誰が管理するか。追加費用はどうするか	稼働後に「誰も分からない」状態になる

特に「権限」と「データ移行」は、後から変更すると影響が大きい項目です。

権限設計は、システムの土台に関わります。「あとで細かく分けたい」と言われても、簡単には変えられません。

要求は「決めきる」より「決め方を決める」

要件定義でよくある誤解が、「最初にすべてを決めなければならない」というものです。

現実には、進めながらでないと分からないことが必ずあります。

そこで重要になるのが、後から決める項目と、その決め方を先に合意しておくことです。

先に決めるべき	後から決めてよい
解決したい課題と目標の数値	画面の配色やボタンの位置
対象業務の範囲と対象外	帳票の細かなレイアウト
データの持ち方と権限	メール文面や通知の言い回し
予算の上限と稼働の期限	入力補助の細かな挙動
誰が最終決定するか	画面に表示する項目の並び順

左の列のいちばん下、「誰が最終決定するか」を決めておくことが、実は最も効果的です。

意見が割れたときに決着をつける人がいないと、判断が先送りされ、そのぶんスケジュールが遅れます。

要件定義でよくある失敗

現行システムの画面をそのまま再現しようとする

「今と同じ操作感で」という要望は、一見合理的です。教育コストが下がるためです。

ただ、古いシステムの画面は、当時の技術的な制約から生まれた形であることが多く、今なら不要な手順が含まれています。

再現すべきは画面ではなく、その画面で達成していたことです。

例外処理を後回しにする

「基本的な流れはこうです。特殊なケースは後で」——これが最も危険な進め方です。

例外処理は、設計の土台に影響します。後から追加すると、作り直しになることがあります。

件数が少なくても、種類は最初に洗い出してください。実装するかどうかは、そのうえで判断できます。

「いい感じに」で合意した気になる

「使いやすく」「見やすく」「柔軟に」。

これらの言葉は、双方が納得した気になりますが、実際には何も決まっていません。完成後に「思っていたのと違う」となる典型的な原因です。

抽象的な言葉が出たら、「具体的にはどういう状態ですか」と必ず聞き返してください。

現場の要望をすべて集めてから絞ろうとする

広く意見を集めるのは良いことですが、集めた後に絞る作業は非常に困難です。

一度「検討します」と受けたものを外すと、現場の協力が得にくくなるためです。

集める段階で「今回の目的はこれです」と枠を示しておくと、そもそも枠外の要望が出にくくなります。

明日からできる3つのこと

1. 出てきた要望に「なぜ」を3回聞く
   経営要求までたどり着けば、別の解決策が見えることがあります。
2. 3層の表を1枚作る
   どの経営要求にもつながらない機能があれば、それが外す候補です。
3. 権限とデータ移行の方針を先に決める
   後から変えにくい2項目です。ここだけは時間をかける価値があります。

よくある質問

要件定義は開発会社に任せてはいけませんか？

作業自体は任せて構いません。多くの開発会社が支援します。

ただし、経営要求だけは自社で決める必要があります。何を達成したいのかは、外部には決められません。

ここが曖昧なまま任せると、機能は充実しているのに目的に合わないシステムができあがります。

現場から要望が出てきません

「何か要望はありますか」と聞いても、たいてい出てきません。

聞き方を変えてください。「今の作業で一番面倒なのはどこですか」「どこでミスが起きやすいですか」のように、具体的な場面を尋ねると出てきます。

要件が途中で増えていきます

増えること自体は避けられません。問題は、増えた分をどう扱うかです。

新しい要望が出たら、「どの経営要求につながるか」「今回やるか、次回に回すか」をその場で判断してください。

判断を保留にしたまま検討リストへ入れ続けると、範囲は静かに膨らみ続けます。

まとめ｜「なぜ必要か」を説明できる要件にする

• 要件は経営要求・業務要求・システム要求の3層に分かれる
• 層は上から下へ流れる。機能から考え始めない
• 要望には「なぜ」を3回聞いて、上の層へたどる
• どの経営要求にもつながらない機能は、外す候補
• 権限とデータ移行は、後から変えにくいので先に決める

要件が整理できたら、次はそれを関係者で共有し、合意する段階です。

ところが、経営者・現場・システム会社は、それぞれ違うものを見ています。次回は、この認識のズレをどう埋めるかを扱います。

複数社に相談する場合の依頼書の書き方は、RFPの書き方｜中小企業はA4 7枚で足りる。12項目テンプレートと「見積もれないRFP」の5つの穴で解説しています。

みんなシステムズでは、要求の整理段階からご相談を承っています。「要望は出ているが、何を作るべきか判断できない」という場合も、お気軽にお問い合わせください。