要件定義の進め方5ステップ｜手戻りを防ぐMoSCoW分析とIPA非機能要求グレード活用法

「要件定義をしっかりやったつもりだったのに、開発途中で大量の手戻りが発生してしまった」——システム開発やSaaS導入プロジェクトを担うビジネス職・PMの方から、こうした声をよく耳にします。

結論: 要件定義の進め方は、(1)現状課題の分析と目的共有、(2)業務要件とシステム要件の切り分け、(3)MoSCoW分析による優先順位付け、(4)非機能要件の数値化、(5)変更管理ルールの策定——という5ステップで進めると手戻りを最小化できます。Web上に多い「4ステップ」記事は変更管理まで踏み込まないケースが多く、本記事はリリース後の合意形成まで含めた実務フローを扱います。

要件定義は、プロジェクトの成否を決める最重要フェーズです。ここで定義が曖昧なまま開発へ進むと、スコープクリープによる予算超過やスケジュール遅延が避けられません。一方、アジャイル開発とは異なりウォーターフォール型でシステムを発注する場合は、初期段階で要件を確定させる体系的なプロセスが特に重要になります（アジャイル開発における要件定義の考え方はアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ、両者の選択基準はアジャイル開発・ウォーターフォール開発の違いを徹底比較！失敗しない選び方をご参照ください）。

この記事では、 手戻りを防ぎプロジェクトを成功に導くための要件定義の進め方を、5つのステップ に絞って具体的に解説します。MoSCoW分析の実例（勤怠管理システム）、IPA（独立行政法人 情報処理推進機構）が公開する「非機能要求グレード」に準拠した数値化サンプルなど、現場でそのまま使えるノウハウを紹介しますので、要件定義の担当者・発注側責任者の方はぜひ最後までご確認ください。

1. 現状課題の分析とシステム化の目的共有

要件定義を進めるうえで、最初のポイントとなるのが現状課題の把握と目的・スコープの明確化です。システムを導入して何を解決したいのか、そのゴールを経営層から現場の担当者まで関係者全員で合意することが、プロジェクト成功の土台となります。

システム化のゴールを合意する

要件を整理するうえで、現場の要望をすべてシステム化しようとすると、開発コストと期間が大きく膨張してしまいます。まずは「何のためのシステムか」という基本事項を整理し、現場のリアルな課題に基づいたスコープ設定を徹底してください。この初期段階での目的がブレてしまうと、後の開発フェーズで大きな手戻りが発生する原因になります。

ゴール合意の場では、(1)現状のKPI（業務時間・処理件数・エラー率など）、(2)システム導入後の目標KPI、(3)達成期限——の3点を最低限の合意項目として議事録に残します。数値で記録しておくと、後工程で要件が膨らんだときに「当初の目的に沿っているか」を客観的に判定できます。

現場部門へのヒアリングと業務プロセスの整理

現場部門へヒアリングを行う際は、現在の業務フローと部門間の連携を正確に把握する必要があります。特にSaaSビジネスや顧客管理システムを構築する場合、部門ごとの役割分担がシステム要件に直結します。

業務プロセスを整理する際は、カスタマーサクセスと営業の違いとは？役割や目標設定など8つのポイントで完全解説 を参考に、各部門の業務範囲や目標を事前にすり合わせておくと、要件の抜け漏れや認識のズレを防ぐことができます。表面的な要望だけでなく、なぜその業務が発生しているのかという「根本的な課題」を深掘りすることが重要です。

新規システムを既存環境と接続する場合は、オンプレミスとクラウドの違いとは？5つの判断基準で最適なシステムを選ぶ方法 で確認したインフラ前提も、この段階で要件の制約条件として明示しておくと、後工程の手戻りを防げます。

2. 業務要件とシステム要件の明確な切り分け

2つ目の重要なポイントは、「業務要件（ビジネス目標）」と「システム要件（開発機能）」の整合性を図り、明確に切り分けることです。

要求（What）と要件（How）の違いを理解する

現場の要望（要求）をそのままシステム機能（要件）として盛り込もうとすると、運用に合わない複雑なシステムができあがってしまいます。ユーザーがやりたいことである「要求（What）」を、システムでどのように実現するかの「要件（How）」へ適切に翻訳する作業が不可欠です。

特にSaaSビジネスの立ち上げ期では、最小限の機能で素早く市場に投入するMVP（Minimum Viable Product）の考え方が重要になります。事業計画とシステム要件のズレを防ぐためにも、企画段階の意図を正しくシステムに反映させましょう。具体的な企画手順については、【実例あり】新規事業の企画書の作り方とプレゼン資料例｜決裁を通す立ち上げプロセス7ステップ も参考になります。

モックアップを用いた視覚的なすり合わせ

要件定義を運用する際は、ステークホルダー間の認識齟齬を防ぐことが最大の課題となります。これを防ぐためには、早い段階でワイヤーフレームやモックアップを作成し、視覚的なフィードバックを回すことが推奨されます。

実際の画面遷移や操作感をプロトタイプで確認することで、テキストベースのドキュメントでは見落とされがちな「使い勝手」や「既存業務フローとの不整合」を早期に発見できます。新規事業や不確実性の高い案件では、モックアップだけでなくPoCとは？ビジネスを成功に導く7つの進め方とIT開発のポイント で扱った概念実証（PoC）を要件定義と並行させ、技術的実現性を先に確かめる方法も有効です。

3. MoSCoW分析を用いた機能の優先順位付け

プロジェクトを成功に導く3つ目のポイントが、「機能の優先順位付け」です。集まった要望に対して客観的な基準で優先度を設定し、今回の開発スコープを明確に区切ります。

MoSCoW分析とは（DSDM由来のフレームワーク）

MoSCoW分析は、英国発のアジャイル開発手法 DSDM（Dynamic Systems Development Method）の中でコンサルタントの Dai Clegg 氏により提唱された優先順位付け手法で、Must / Should / Could / Won't の頭文字を取って命名されました。現在はアジャイル・ウォーターフォール双方の要件定義フェーズで広く採用され、PMI（Project Management Institute）のビジネスアナリシス実務ガイドでもプライオリタイゼーション手法として紹介されています。

実現したい機能を4つのカテゴリに分類（勤怠管理システムの例）

要件の優先順位を判断する際は、フレームワーク「MoSCoW分析」を活用して具体化するのが効果的です。洗い出した要件を以下の4つのカテゴリに分類し、開発の優先度を整理します。ここでは「新規の勤怠管理システム」を開発する場合の具体例とともに解説します。

• Must（必須）: システムの根幹をなし、これがなければ業務が回らない機能
  • 具体例: 打刻機能、労働時間の自動計算、管理者による修正機能
• Should（推奨）: 必須ではないが、実装すれば大きな業務効率化が見込める機能
  • 具体例: 有給休暇の自動付与計算、給与計算システムとのCSV連携
• Could（可能）: あれば便利だが、運用や代替手段でカバーできる機能
  • 具体例: スマートフォンアプリでのGPS打刻、チャットツールへの通知
• Won't（見送り）: 今回のリリースフェーズでは実装を見送る機能
  • 具体例: AIによる将来の残業時間予測機能

このように基準と具体例を明確にすることで、「あれもこれも欲しい」という状態から脱却し、限られたリソースを最も事業価値の高い機能開発に集中させることができます。

なお、DSDM の原典では Won't を「Would not have this time（今回は実装しない）」と表現し、「永久に作らない」のではなく「今リリースのスコープからは外す」という時限的な合意である点が強調されています。次フェーズでの再評価対象として議事録に残しておくと、後の追加要求トラブルを避けられます。

スコープクリープ（要件の肥大化）を防ぐ

この優先順位付けのプロセスを曖昧にしたまま開発工程に進むと、後から次々と要件が追加される「スコープクリープ」に陥るリスクが高まります。

要件の優先順位付けは一度決めたら終わりではなく、プロジェクトの進行状況や市場環境の変化に応じて定期的に見直す柔軟性を持つことも求められます。「何を作らないか」を決める合意形成のプロセスが、結果として高品質なシステムを予定通りにリリースするための鍵となります。

4. 非機能要件の定義と品質保証（IPA非機能要求グレード準拠）

目に見える機能（機能要件）だけでなく、システムの裏側を支える「非機能要件」の定義も極めて重要です。

非機能要件の主要な項目

非機能要件とは、システムの性能、可用性、セキュリティ、拡張性などを指します。ここを疎かにすると、「機能は動くがレスポンスが遅くて使えない」「アクセス集中でシステムがダウンする」といった深刻なトラブルに発展します。

国内の発注実務では、IPA（独立行政法人 情報処理推進機構）が公開している「 非機能要求グレード 」が事実上の標準として使われています。非機能要求グレードでは、可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジーの 6大項目 を細分化し、要件検討項目と複数の指標が体系化されています（参考: IPA「非機能要求グレード」公開資料）。

非機能要求グレードでは、対象システムを以下の 3つのモデル に分けて要求レベルを段階的に提示しています。

• 社会的影響が小さいシステム: 部門内の業務システム等
• 社会的影響が限定されるシステム: 企業の基幹業務システム等
• 社会的影響が極めて大きいシステム: 金融・公共サービス・社会インフラ等

要件定義の冒頭で自社システムがどのモデルに該当するかを発注者・開発者で合意しておくと、後段の数値合意が大幅にスムーズになります。

品質指標を数値化して合意する（具体例サンプル）

非機能要件は「速く動くこと」「安全であること」といった抽象的な表現になりがちです。これを具体的な数値や規格に落とし込み、開発側と発注側で合意することが不可欠です。以下はシステム開発における具体的な合意サンプルの例です。

非機能要件の項目	抽象的な要望（NG例）	具体的な数値・指標での合意（OK例）
性能	サクサク動くようにしてほしい	検索ボタン押下後、結果の95%を 3秒以内 に表示する
可用性	落ちないシステムにしてほしい	システム稼働率を 99.9% とし、月間の計画外停止を43分未満とする
セキュリティ	情報漏洩しないよう安全にしてほしい	全ての通信をTLS 1.3で暗号化し、DB上の個人情報はAES-256で暗号化する
バックアップ	データが消えないようにしてほしい	1日1回 の自動バックアップを取得し、過去30日分のデータを保持する

このように数値を伴ったサンプル基準を用意することで、リリース後の「思ったより遅い」といったトラブルを未然に防ぐことができます。SaaS開発で稼働率や応答時間を契約条件に組み込む場合は、SLAとは？SaaS契約で発注側が確認すべき7つのポイント【稼働率・ペナルティ計算付き】 や SLOとは？SLA・SLIとの違いとエラーバジェット運用7つのポイント で扱うSLA／SLOの考え方も合わせて確認すると、運用フェーズの基準と一貫性を持たせられます。

5. 変更管理ルールの策定とドキュメント化

最後に見落とされがちなのが、変更管理ルールの策定と合意形成の記録です。プロジェクトが進行する中で、ビジネス環境の変化や新たな課題の発見により、初期の要件が変化することは珍しくありません。Web上の要件定義解説で「4ステップ」と紹介される進め方の多くはここを省きますが、本記事が 5ステップ目として変更管理を必ず含める のは、リリース後トラブルの大半がこのフェーズの欠落に起因するためです。

変更要求のフローを事前に定義する

要件定義の段階で「誰が・どのような基準で・どうやって変更を承認するか」という判断ポイントを具体化しておく必要があります。

• 申請: 現場部門が変更理由と影響範囲を記載した申請書を提出する
• 影響調査: 開発チームがコスト・スケジュールへの影響を見積もる
• 承認: プロジェクトマネージャーや経営層が最終判断を下す

このようなフローを事前に定義することで、なし崩し的な要件追加を防ぎ、予算やスケジュールの超過リスクを抑えることができます。

口頭での合意を避け記録を残す

現場で運用する際の注意点として、口頭での合意を避け、必ずドキュメントとして記録に残すことが挙げられます。「言った・言わない」のトラブルを防ぐため、議事録や要件定義書は常に最新のバージョンを保ち、関係者全員がいつでも確認できる状態を維持してください。

よくある質問（FAQ）

要件定義の進め方は「4ステップ」と「5ステップ」のどちらが正解ですか？

Web上の解説では「ヒアリング・整理・優先順位付け・スケジューリング」の4ステップにまとめる例もありますが、本記事は 変更管理ルールの策定を独立した5ステップ目として明示 しています。リリース後に頻発する「言った・言わない」「想定外の追加要件」のトラブルは、変更管理プロセスを要件定義段階で合意できていないことが原因の大半です。ステップ数より重要なのは、変更管理まで含めて合意形成を完了させることです。

MoSCoW分析の「Won't」は「永久に作らない」という意味ですか？

いいえ。MoSCoW分析の原典であるDSDMでは Won't を「 Would not have this time （今回のリリースでは実装しない）」と定義しています。次フェーズでの再評価対象として議事録に残しておくのが正しい運用です。「永久に作らない」と誤解すると、現場との合意形成が難航するため注意してください。

要件定義にかかる期間の目安はどれくらいですか？

プロジェクトの規模によりますが、一般的なシステム開発では全体のスケジュールのうち2割〜3割程度の期間を要件定義に充てることが推奨されます。中規模なシステムであれば1ヶ月〜2ヶ月程度が目安となります。

専門知識がなくても要件定義は進められますか？

ITの深い専門知識がなくても、自社の業務課題や「システムで実現したいこと」を整理することは可能です。ただし、それを技術的な仕様に落とし込むフェーズでは、システムベンダーや開発側のエンジニアとの密な連携が不可欠です。

要件定義の段階で予算がオーバーしてしまった場合はどうすればいいですか？

本文で紹介した「MoSCoW分析」を用いて、機能の優先順位を厳格に見直してください。Must（必須機能）のみに絞り込んで第一フェーズとしてリリースし、Could・Won't は運用開始後の第二フェーズに回すなどの段階的なアプローチを検討しましょう。

まとめ

システム開発における要件定義は、プロジェクトの成否を決定づける最も重要なフェーズです。本記事では、プロジェクトの手戻りを防ぐ要件定義の進め方を、以下の5つのステップで解説しました。

• 現状課題の分析とシステム化の目的共有: 現状KPIと目標KPIを数値で合意する
• 業務要件とシステム要件の明確な切り分け: モックアップとPoCで視覚的にすり合わせる
• MoSCoW分析を用いた機能の優先順位付け: DSDM由来のフレームワークでスコープクリープを防ぐ
• 非機能要件の定義と品質保証: IPA非機能要求グレードに準拠して数値化する
• 変更管理ルールの策定とドキュメント化: 変更フローを定義し、口頭合意を避ける

これらのポイントを実践することで、予算超過やスケジュール遅延のリスクを最小限に抑え、ユーザーにとって真に価値のあるシステム開発を実現できます。要件定義の進め方を体系的に理解し、プロジェクトの成功確率を高めていきましょう。