要件定義の進め方｜基幹システムで決める順番・会議の回し方・期間の目安

基幹システムの要件定義の進め方は、「目的と範囲」→「業務の流れ」→「機能」→「非機能・移行」の順で決め、決めたことを毎回記録して戻らないようにすることに尽きます。期間は、JUASの調査式で試算すると開発規模60人月なら要件定義は約2.4か月が目安です。この記事では、決める順番、会議の回し方、期間の見積もり方を、大手コンサルティングファーム出身の専門家の知見をもとに具体例つきで解説します。

要件定義の進め方の前提：決めるのは発注者、まとめるのを手伝うのがベンダー

要件定義は、新しい基幹システムで何を実現し、何を実現しないかを決める工程です。進め方を考える前に、誰が決める工程なのかを押さえておきます。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」（2019年）は、システムの要件を定義する責任は、システムを使ってビジネスに貢献するユーザ側にあるという立場をとっています。従来のようにベンダーやシステム部門任せにせず、業務部門が主体的に関わるべきだとしています。

契約の形でも同じ考え方がとられています。IPAと経済産業省が公開している「情報システム・モデル取引・契約書」では、要件定義の工程を「要件定義作成支援業務」と位置づけています。発注者（ユーザ）が要件定義書を作り、ベンダーは専門家として調査・分析・整理・提案・助言で支える、という役割分担です。要件定義書を確定させる権限と責任も、発注者側の責任者に置かれています。

つまり、進め方の設計とは「発注者が決めやすい順番と場をつくること」です。ベンダーに「要件をまとめておいてください」と頼むだけでは、決める人がいないまま資料だけが増えます。「要求」と「要件」の違いがあいまいな場合は、先に要求定義と要件定義の違いを確認しておくと、会議での言葉のずれが減ります。

進め方を誤りやすい思い込みも、最初に3つ整理しておきます。

• 「要望を全部集めてから絞る」：集めた要望は、優先順位の基準がないと絞れません。先に目的と成功を測る数字を決め、それに照らして要望を受け付けます。
• 「製品を決めてから要件を考える」：製品のデモを見てから要件を決めると、その製品にある機能が要件になります。業務上どうしても必要なことを先に決め、製品はそれを満たすかで比べます。
• 「要件定義書が厚いほど安心」：量より、決めたことと決めていないことの区別がついているかが大事です。中小企業の基幹システムなら、機能要件一覧と主要業務フロー、未決事項一覧がそろっていれば見積もりは取れます。

要件定義の手順：決める順番8ステップ

基幹システムの要件定義は、次の8ステップで進めます。ポイントは、上のステップで決めたことを前提に、下のステップを決めることです。順番を入れ替えると、決めたことがあとから覆ります。

ステップ3と4は、慣れていないと現行業務の調査に時間をかけすぎます。現行の把握は「将来を決めるための材料集め」と割り切り、主要業務の流れと例外処理が見えた時点で将来業務の議論に移ります。進め方の詳細はAs-Is/To-Beの進め方で、図の描き方は業務フローの書き方で解説しています。

ステップ7の非機能要件は、後回しにされやすい項目です。ただ、「1日止まっても業務は回るか」「何年分のデータを移すか」は費用に大きく効きます。機能の議論と並行して早めに着手します。項目の決め方は非機能要件とはにまとめています。

要件定義の期間の目安：JUASの調査式で試算する

「要件定義に何か月かかるか」は、開発全体の規模から逆算すると根拠のある数字になります。使えるのが、日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査2020」です。

この調査では、ユーザー企業の開発プロジェクトの実績から、次の2つの関係が示されています。

• 全体工期（月）＝ 2.70 × 全体工数（人月）の3乗根（n=892、決定係数0.89）
• 工期の内訳は、要件定義22.9％、設計〜結合テスト59.3％、ユーザー総合テスト17.8％（2018〜2020年の累積98件、約2：6：2）

この2つを組み合わせると、規模別の要件定義期間をおおまかに試算できます。

※JUASの式と工期比率をもとに本記事で試算した説明用の例です。全体工期は要件定義からユーザー総合テストまでを指します。実際の期間は、業務の複雑さ、決裁の速さ、パッケージかスクラッチかで変わります。

この表は、見積もりの妥当性を確かめる物差しとして使います。たとえば60人月規模の刷新で「要件定義は3週間で終わります」という計画が出てきたら、何を省いているのかを確認すべきです。逆に半年を超える計画なら、決める人が決められていないか、範囲が広がっていないかを疑います。

同じ調査では、計画段階で予定工期を標準工期より約8％短く見積もる傾向も示されています。期間を詰めたくなったときは、要件定義を削るより、対象範囲を「必須」に絞るほうが安全です。

期間が延びる要因と、先に打てる手

試算より期間が延びるときは、たいてい次のどれかが起きています。いずれも要件定義が始まる前に手を打てるものです。

• 決裁者が会議に出ない：持ち帰りのたびに1週間ずつ延びます。キックオフ前に、領域ごとの決裁者の出席を経営者から指示してもらいます。
• 拠点や事業部ごとに業務が違う：同じ受注業務でも拠点ごとに検討会が必要になります。統一するのか、違いを残すのかを最初に方針として決めます。
• 現行システムの仕様が誰にもわからない：長年改修してきたシステムでは、計算ロジックを調べるだけで数週間かかります。調査の範囲と期限を区切ります。
• 製品やベンダーが決まっていない：パッケージを使うか作るかが決まらないと、要件の粒度が定まりません。方式の比較は要件定義の前か、序盤に終えておきます。
• 繁忙期と重なる：決算期や年末の繁忙期には実務担当が会議に出られません。12週間のうち、検討会を開けない週を先に除いて計画します。

要件定義の会議の回し方：定例の検討会で「決める」

要件定義の中心は、発注者とベンダーが集まる定例の検討会です。前述のモデル契約書でも、要件定義書を作るために必要な事項を明確にする場として「要件定義検討会」を開くことが定められています。中小企業でも、この会議の設計で進み方が大きく変わります。

会議体は3層に分ける

• テーマ別検討会（週1〜2回・90分）：販売、購買・在庫、会計など業務領域ごとに、決裁者と実務担当が出席して要件を決める場です。
• 全体定例（週1回・60分）：プロジェクト責任者とベンダーの責任者が、進み具合、課題、領域をまたぐ論点を確認します。
• 経営報告（月1回・60分）：経営者が、範囲・予算・スケジュールに関わる判断をします。体制の作り方はステアリングコミッティとはで詳しく解説しています。

テーマ別検討会のアジェンダ（90分の例）

1. 前回の決定事項と宿題の確認（10分）
2. 今回決める論点の説明：事前に配った資料をもとに、選択肢と影響を確認（15分）
3. 論点ごとの議論と決定（50分）
4. 決定事項・継続検討事項・宿題（担当・期限）の読み上げ（10分）
5. 次回の論点と、事前に準備するものの確認（5分）

事前資料と宿題の運用ルール

検討会の質は、会議の前と後で決まります。次の3つをルールにしておくと、90分で決められる論点の数が増えます。

• 論点資料は2営業日前に配る：選択肢ごとに「業務がどう変わるか」「費用や期間への影響」を1枚にまとめます。当日の説明時間が短くなります。
• 宿題には必ず担当と期限をつける：「確認しておきます」で終わらせず、「〇〇課長が、次回までに取引先12社の締め日を一覧にする」と具体的に決めます。
• 議事録は翌営業日までに出す：記憶が新しいうちに出席者が確認できるようにします。異議がなければ承認とみなす期限も決めておきます。

モデル契約書では、会議の議事録に少なくとも「決定された事項」「継続検討とされた事項」「継続検討事項の検討スケジュールと担当」を記載するよう定めています。この3点を毎回その場で読み上げて確認するだけで、「言った・言わない」の行き違いは大きく減らせます。

発注者がやること・ベンダーに任せること

中小企業では、情報システムの専任者がいないことも珍しくありません。だからこそ、発注者が手放してはいけない作業と、ベンダーや外部の専門家に任せてよい作業を分けておきます。

JUASの「企業IT動向調査報告書2026」によると、「ほぼ内製」と「内製が多い」の合計は、システム企画（システム化構想策定）で70.9％、機能要件定義で46.1％でした。一方、設計・実装・テストは「ほぼ外部委託」と「外部委託が多い」の合計が63.4％です。上流は自社で、作るのは外部で、という分担が一般的になっています。

社内の作業時間も、最初に確保しておきます。要件定義の期間中、業務領域の決裁者は週に半日程度、実務担当は検討会への出席と宿題で週に数時間を割く計画にするのが現実的です。通常業務と兼務のまま「空いた時間で協力して」と頼むと、宿題が出てこず、検討会が空回りします。業務の一部を他のメンバーに振る、繁忙期を避けるなど、人の手当てまで含めて計画します。

発注者の協力が不十分だと、法的な責任を問われることもあります。病院情報管理システムの開発をめぐる札幌高等裁判所の判決（2017年8月31日）では、発注者側が仕様の凍結に合意したあとも追加の要望を出し続けたことなどから、発注者の協力義務違反が認められ、ベンダーのプロジェクトマネジメント義務違反は否定されました。この判決は、IPA・経済産業省のモデル契約書（第二版）の解説でも、仕様凍結の合意後にユーザーが大量の追加開発要望を出した例として取り上げられています。要件定義は「お願いする工程」ではなく、発注者が責任を持って決める工程だということがわかります。

要件が膨らむ・決まらないときの止め方

要件定義が長引く典型は、要望が出続けて範囲が広がるケースです。JUASの調査は、この状態がどれほど結果に響くかを示しています。

• 仕様の明確さと満足度：要求仕様が「非常に明確」だったプロジェクトでは全体満足の割合が84.9％、「非常にあいまい」では35.6％でした（ソフトウェアメトリックス調査2020）。
• カスタマイズと満足度：パッケージのカスタマイズが「計画より多かった」プロジェクトでは、「やや不満」「大変不満」が合わせて34.6％ありました。「全く無し」のプロジェクトでは0％です（同調査、回答数は少数）。
• QCDの悪化要因：品質・予算・工期の悪化に影響している工程として「要件定義」を挙げた企業は57.4〜69.0％でした（企業IT動向調査報告書2026）。

要件を止めるための仕組みは3つです。

1. 優先度を3段階でつける
   「必須／あれば／後回し」に分け、「必須」は業務が回らなくなるものだけにします。迷ったら「この機能がなかったら、稼働初月に何が止まるか」を問います。
2. 凍結日を決めて全員に伝える
   要件を締める日を、スケジュールの最初に決めます。凍結日以降の要望は、次の段階（稼働後の改善）に回すか、変更管理の手続きに乗せます。
3. 変更管理の様式を先に用意する
   モデル契約書の変更管理書には、変更の理由、変更の詳細、費用、スケジュール、契約条件への影響などを書く項目があります。この様式を要件定義の初回に見せておくと、「ついでにこれも」が減ります。

パッケージ製品を使う場合は、要望ごとに「標準機能に業務を合わせられないか」を先に検討します。考え方はFit to Standardとはを参考にしてください。

スケジュール例：従業員80名の卸売業で12週間

ここまでの進め方を、具体的なスケジュールに落とすと次のようになります。従業員80名、2拠点の機械部品卸売業が、販売・購買・在庫を刷新し、会計は現行ソフトと連携する想定です。開発規模は60人月程度を見込んでいます。

※説明用の例です。業種・規模・決裁の速さによって期間は前後します。

このスケジュールで押さえたいのは、8週目の中間報告です。全体の3分の2の時点で範囲を見直す機会を経営者と持つと、終盤に「やはりこれも必要」と範囲が戻るのを防げます。要件定義の前に、そもそも目的と範囲が固まっていない場合は、構想策定から始めるほうが結果的に早く進みます。

予定の12週で終わらない見込みになったときは、期間を延ばす前に、未決事項を「設計に入る前に必ず決めるもの」と「設計中に決めてよいもの」に分けます。後者を期限つきで次工程に回せば、全体の遅れを最小限に抑えられます。モデル契約書にも、やむを得ず確定できない事項を、確定予定時期や費用・納期への影響とあわせて書面で確認する「未確定事項」の扱いが定められています。

要件定義を締める前の10のチェック項目

• 刷新の目的と、成功を測る数字が要件定義書の冒頭に書かれている
• 対象範囲だけでなく、対象外の業務・機能が明記されている
• 業務領域ごとの決裁者が決まり、その人が要件を承認している
• 主要業務の将来の流れと、例外処理の扱いが決まっている
• 機能要件のすべてに優先度（必須／あれば／後回し）がついている
• 各機能に受入基準（何ができればOKか）が書かれている
• マスタのコード体系と、移行するデータの範囲・期間が決まっている
• 止まってよい時間・復旧の目標など、非機能要件が業務の言葉で決まっている
• 未決事項が一覧になり、それぞれに担当と期限がある
• 凍結日以降の要望を扱う変更管理の手続きが合意されている

要件定義書そのものの目次や書き方は要件定義書の書き方で、サンプルつきで解説しています。

よくある質問

まとめ

要件定義の進め方は、目的と範囲、業務の流れ、機能、非機能・移行の順に決め、決めたことを毎回記録して戻らないようにすることが基本です。期間は開発規模から逆算でき、60人月規模なら約2.4か月がひとつの目安になります。

進め方を左右するのは、会議の設計と決める人の配置です。議題を「決める問い」で書き、決定事項・継続検討事項・宿題をその場で確認する。凍結日と変更管理の手続きを最初に決めておく。この2点を押さえるだけで、要件定義の手戻りは大きく減ります。

自社の場合、要件定義から始めてよいのか、構想策定から整理すべきか判断がつかないときは、無料診断で現状と次に決めるべきことを整理できます。