社内の要望がバラバラで要件定義がまとまらない！業務システム刷新で要望を集めて優先順位をつける進め方

2026年6月25日2026年10月1日

業務システムの刷新を任されて各部署にヒアリングしたら、営業・経理・倉庫・管理部からそれぞれ違う要望が届いた。しかも「全部必要」と言われ、部署同士で言っていることが食い違う。要件定義（＝新しいシステムで何を実現するかを決める工程）の入り口で、多くのプロジェクト担当者がこの状態に陥ります。

「社内の各部署から要望がバラバラに出てきて、要件がまとまらない…」

先に結論をお伝えします。要望がまとまらない原因の多くは、要望の中身ではなく「集め方」と「決め方」が決まっていないことにあります。要望を集める前に「目的」「決める人」「判断基準」を決め、全部署に同じ形式の要望シートで出してもらい、同じ物差しで優先順位をつける。この順番にするだけで、議論はかなり進めやすくなります。

この記事では、社内の要望を1枚の一覧にまとめ、優先順位をつけ、部署間の対立を収めて、開発会社に渡せる状態にするまでの進め方を、要望シートのひな形・チェックリスト・開発会社への質問例とあわせて解説します。

要件定義で社内の要望がまとまらない4つの理由

まずは、なぜ要望がバラバラになるのかを押さえておきましょう。原因が分かると、どこから手を付ければいいかが見えてきます。

理由1：刷新の「目的」が部署ごとに違って見えている

経営層は「コスト削減」、営業は「外出先で在庫を見たい」、経理は「締め作業を早くしたい」。どれも正しい要望ですが、刷新全体の目的が共有されていないと、各部署は自分の困りごとを解決する場として要望を出します。目的という共通の物差しがなければ、要望同士を比べることができません。

理由2：要望の出し方が部署ごとにバラバラ

ある部署は画面のイメージ図、ある部署は口頭の不満、ある部署は現行システムの改善点を長文で…というように、要望の粒度も形式も揃っていないことがよくあります。形式が違うものは、並べても比べられません。

理由3：誰が・何を基準に決めるのかが決まっていない

「要望を集めて、あとは開発会社に整理してもらおう」と考えていると、最終的に誰も決められない状態になりがちです。担当者は各部署と同じ立場なので、どの部署の要望を後回しにするかを1人で決めるのは難しいものです。

理由4：声の大きい要望や、毎日の業務に議論が偏る

会議で強く主張した部署の要望が通りやすくなったり、毎日行う業務の話ばかりで、月に数回しかない業務や例外処理の話が後回しになったりします。後回しにされた要望は、後から追加要望として出てきて、費用や納期に響きます。

まず押さえたい前提：要件をまとめる主役は発注者

公的機関のガイドラインも、要件をまとめる主役は発注者側だと繰り返し述べています。

📰 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド第2版」

IPAはこのガイドの紹介の中で、ITベンダやシステム部門が中心になって要件定義を進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革が必要になっていると説明しています。改訂版では「要件定義マネジメント」（要件定義の立ち上げから終結までを円滑に進める管理）を強化点の一つに挙げています。

📰 出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック（DS-120）」2026年6月12日版

デジタル庁の実践ガイドブックも、外部の事業者に作業を委託する場合の留意点として、優先順位付けや企画内容の決定などの意思決定は発注者が責任を持って行うこと、関係者との調整のように事業者にはできない作業を発注者が担うことを挙げています。政府のシステム向けの資料ですが、「社内の調整と最終判断は発注者の仕事」という考え方は民間の業務システムでも同じです。

開発会社は要望の整理の仕方や、費用・技術面の影響についてはアドバイスできます。ただ、「経理の要望と営業の要望のどちらを先にやるか」は、社内の事情を知る発注者にしか決められません。

社内の要望をまとめる6つのステップ

ステップ1：要望を集める前に「目的・決める人・判断基準」を決める

いちばん大切なのは、要望を集める前に決め方を決めておくことです。後から決めると、「自分の部署の要望が削られたからルールを変えた」と受け取られやすくなります。

先に決めること	例
刷新の目的（2〜3個まで）	受注から出荷までの二重入力をなくす／月次締めを3営業日短くする
今回やらないこと	会計ソフトの入れ替えは今回の対象外
最終的に決める人	担当役員（部署間で意見が割れたときの最終判断者）
優先順位の判断基準	目的との関係・効果・利用頻度・費用（ステップ4で説明）
要望の締め切り	◯月◯日までに要望シートで提出。以降は次の改善で検討

「決める人」は、各部署に対して公平な立場で判断できる人が理想です。多くの会社では、担当役員や経営者がこの役を担います。この5点を社内で1枚にまとめ、キックオフの場で各部署に共有しておくと、その後の話し合いがぶれにくくなります。

ステップ2：全部署に同じ形式の「要望シート」で出してもらう

要望は口頭やメールでばらばらに受け取らず、同じ項目のシート（Excelや共有スプレッドシートで十分です）で出してもらいます。次のようなひな形が使いやすいでしょう。

項目	書いてもらう内容	記入例
部署・記入者	誰の要望か	営業部・◯◯
今の困りごと	今どうしていて、何に困っているか	在庫を確認するたびに倉庫へ電話している
要望	どうなってほしいか	外出先から在庫数を見たい
対象の業務と頻度	どの業務で、どのくらいの頻度か	見積もり作成時、1日10回程度
困る度合い	ないと業務が止まる／手間が増える／あれば便利	手間が増える
効果	実現すると何がどれくらい良くなるか	電話確認の時間が1日30分ほど減る
関係する部署	影響を受ける他の部署	倉庫（在庫の登録タイミング）
補足資料	使っているExcel・帳票など	在庫一覧表.xlsx

ポイントは、「要望（どうなってほしいか）」だけでなく「今の困りごと」と「頻度」「効果」を書いてもらうことです。「CSV出力がほしい」という要望も、困りごとが「毎月の集計に時間がかかる」なら、別の実現方法が見つかるかもしれません。

ステップ3：集まった要望を整理する（重複・食い違い・漏れ）

シートが集まったら、優先順位をつける前に一覧を整理します。

重複をまとめる：部署は違っても、同じ困りごとから出た要望は1行にまとめ、関係する部署を併記する
食い違いに印をつける：「承認を増やしたい（管理部）」と「承認を減らしたい（営業部）」のように、ぶつかる要望は後でまとめて話し合えるように印をつけておく
漏れを探す：月末・年度末・例外処理など、たまにしか発生しない業務の要望が抜けていないか確認する

特に3つ目は見落とされがちです。デジタル庁の実践ガイドブックでも、要件定義では毎日行う業務ばかりに議論が集中して、実施頻度の少ない業務の議論が後回しになりがちだと注意を促しています。年に数回の処理ほど担当者しか知らないことが多いため、担当者に直接聞いておきましょう。

ステップ4：同じ物差しで優先順位をつける

整理した一覧に、ステップ1で決めた判断基準で優先順位をつけます。実践ガイドブックでも、予算やスケジュールの関係で機能を絞らなければならないことはよくあるとした上で、目的との関係や費用対効果を主な観点として優先順位を判断し、機能の代わりになる方法（手作業や運用での対応など）もあわせて検討するよう勧めています。

中小〜中堅企業の業務システムであれば、次の4つの観点で見ると判断しやすくなります。

観点	見るポイント
目的との関係	刷新の目的に直接つながるか
効果	実現すると、時間・ミス・売上などがどれくらい良くなるか
頻度・影響範囲	どのくらいの頻度で、何人・何部署が使うか
費用・難しさ	実現にかかる費用や期間（開発会社に概算を聞いて判断する）

そのうえで、要望を次の3段階（＋今回やらない）に分けます。このような分け方は、英語の頭文字をとって「MoSCoW（モスコウ）」と呼ばれることもあります。

区分	意味	目安
Must（必須）	これがないと刷新の目的を果たせない	目的に直結し、代わりの方法がない
Should（できれば入れたい）	重要だが、当面は手作業などで代わりがきく	効果は大きいが、代替手段がある
Could（余裕があれば）	あれば便利	効果が限定的、頻度が低い
今回やらない	次の改善で検討する	目的の範囲外、または費用に見合わない

「今回やらない」の区分をはっきり作っておくのがコツです。「却下」ではなく「次の改善で検討する」という扱いにすると、要望を出した部署も受け入れやすくなります。なお、費用・難しさは発注者だけでは判断できないため、この段階で開発会社に概算の影響を聞きながら進めるのが現実的です。

ステップ5：部署間でぶつかる要望は「事実」と「決める人」で収める

ステップ3で印をつけた、ぶつかる要望は、担当者1人で調整しようとせず、次の順で進めます。

困りごとに戻る：要望そのものではなく「なぜそれが必要か」を双方から聞く。承認を増やしたい理由が「過去に誤発注があったから」なら、承認以外の方法（金額が一定以上のときだけ承認など）で両立できることがあります
数字で比べる：件数・時間・金額など、ステップ2のシートに書いてもらった頻度や効果をもとに話す
代わりの方法を探す：システムでなく運用ルールで解決できないか、開発会社の意見も聞く
決まらなければ「決める人」が判断する：ステップ1で決めた判断基準に沿って最終判断者が決め、理由を記録して関係部署に伝える

デジタル庁の実践ガイドブックでも、関係者の多いプロジェクトでは、調整が担当者レベルで止まってしまうことが多いため、問題を一段、二段と上の責任者レベルに上げて検討できる体制を作ることが有効だとしています。部署の責任者が同席する場で判断してもらう方法は、社内の調整でも使えます。

「開発会社としては、社内で決まった優先順位と、その理由が分かると本当に助かります。理由が分かれば、同じ目的をもっと安く実現する方法も提案しやすくなります」

ステップ6：整理済みの要望一覧を開発会社に渡す

最後に、整理した一覧を開発会社に渡せる形にまとめます。

刷新の目的・今回やらないこと・決める人（ステップ1の内容）
優先順位つきの要望一覧（Must／Should／Could／今回やらない）
各要望の困りごと・頻度・効果（ステップ2のシート）
まだ決まっていないこと、部署間で調整中のこと

未決事項は隠さず書いておくのがポイントです。開発会社は、決まっていないことが分かれば、それを前提に見積もりの幅を出したり、決めるべき時期を提案したりできます。プロジェクト全体で最初に伝える内容（予算や期限など）は、作りたいシステムを開発会社にどう伝える？初めての発注で準備したい5つのことで紹介している「発注メモ」とあわせて渡すと、情報がそろいます。

要望をまとめるときにやりがちな失敗

要望を全部そのまま開発会社に渡す：優先順位がないと、見積もりは全部入りの金額になり、予算に合わせて削る作業を後からやり直すことになります
全部を「必須」にする：部署の立場からは当然でも、すべてMustでは優先順位の意味がありません。「代わりの方法がないか」で見直しましょう
決める人を決めずに会議を重ねる：同じ議論が何度も繰り返され、スケジュールが延びていきます
要望を出した部署に結果を伝えない：なぜ後回しになったのかが伝わらないと、後から同じ要望が別の形で出てきます。理由とあわせて共有しましょう
締め切り後の要望を黙って追加する：締め切り後の要望も一覧に載せ、同じ基準で優先順位を判断します。追加する場合は費用と期間への影響を開発会社に確認してから決めましょう