【2026年版】システム開発の要件定義の進め方｜発注側が準備すること・失敗しないポイント

要件定義は、実際にプログラムを作り始める前の「上流工程」にあたり、そのシステムに必要な機能や条件を明らかにする作業です。開発の進め方を表すV字モデルでは、要件定義は最後の「受入テスト（発注側が納品物を確認するテスト）」と対になります。つまり、要件定義で決めた内容が、そのまま“合格の基準”になるということです。

だからこそ、上流がぶれると後工程に響きます。一般に、要件の欠陥や認識のズレは、後の工程で見つかるほど直すのに手間がかかると言われます。逆に言えば、発注側が要件定義にきちんと関与することが、いちばん効く「手戻り防止」です。

混同されがちですが、実務では「要求」と「要件」を分けて考えると整理しやすくなります。一般的な整理は次のとおりです（用語の使い方には幅があります）。

ポイントは、発注側の仕事は立派な「要件」を書くことではなく、確かな「要求」を出すことだという点です。「なぜやるのか（目的）」と「どうなれば成功か」をはっきりさせておけば、要件への翻訳は開発側が担えます。

要件は大きく「機能要件」と「非機能要件」に分かれます。機能要件は“できること”（画面・帳票・データの登録や検索など、システムの動作内容）です。非機能要件は“どのように動くか”という品質・条件面で、見落とされやすい一方、後から効いてきます。

非機能要件の代表的な観点は、IPA（情報処理推進機構）の「非機能要求グレード」が参考になります。これは、発注側（ユーザー）と開発側の認識の行き違いを防ぐために、非機能の要求項目を洗い出して段階的に示したツールで、次の6つの大項目で整理されています。

• 可用性 — 止まらずに使えるか（稼働時間、障害からの復旧など）
• 性能・拡張性 — 速さや同時利用、将来の増加への耐性
• 運用・保守性 — 監視・バックアップ・変更のしやすさ
• 移行性 — 既存データやシステムからの移し替え
• セキュリティ — 不正アクセスや情報漏えいへの対策
• システム環境・エコロジー — 設置環境や省電力などの条件

要件定義を始める前に、発注側だけで用意しておくと進みが段違いに良くなるものがあります。専門知識は不要で、社内の情報を整理するだけです。次の6つを“持ち物”として準備してください。

• 目的・ゴールの言語化 — 「誰の・どんな困りごとを・どう解決したいか」「どうなれば成功か」を1〜2文で
• 現状業務の棚卸し（As-Is） — いまの手順・使っているツール・困っている点。簡単な業務の流れでよい
• 既存システム・データの一覧 — 今使っているシステム、連携が必要なもの、引き継ぎたいデータ
• 社内の登場人物と決裁ルート — 誰が使い、誰が要望を出し、最終的に誰が決めるか
• 予算・納期の目安と譲れない条件 — 上限と“いつまでに何が要るか”
• 「やらないこと」の線引き — 今回は対象外にする範囲。スコープの肥大化を防ぐ土台になる

要件定義は、おおむね「洗い出し（ヒアリング）→整理→優先順位づけ→文書化→合意（レビュー）」という流れで進みます。ここで効くのが優先順位のつけ方です。すべてを『必須』にすると、費用も期間も膨らみ、結局どれも中途半端になります。

よく使われるのが「MoSCoW（モスクワ）」という4分類です。Must（必須）／Should（あるべき）／Could（あれば良い）／Won't（今回はやらない）に振り分け、Must を欲張りすぎないのがコツです。まずは事業の価値がひとつ伝わる中核から固め、周辺は段階的に、という考え方は、前回の

フェーズ別の費用の記事で触れた「全部を一度に作らない」という進め方ともつながります。要件定義の成果物である「要件定義書」には、背景・目的、業務の流れ、機能の一覧、非機能要件、画面・帳票、外部連携、対象範囲、用語の定義などを、一般には盛り込みます。ただし体裁より、関係者が同じ理解になっていることのほうが大切です。

要件定義は「これから中身を固める」段階なので、成果物をあらかじめ確定しにくい工程です。そのため、要件定義フェーズは準委任契約、その後の開発フェーズは請負契約、という多段階の使い分けが一般的な進め方として紹介されています（IPAのモデル取引・契約書など）。

• 準委任契約 — 専門家として業務を遂行すること自体に対価を払う。誠実に業務を行う義務（善管注意義務）を負うが、成果物の完成そのものは保証しないのが基本（履行割合型）。近年は、成果の完成を条件に報酬を払う『成果完成型』の準委任もあります。要件が固まりきらない要件定義フェーズに向く
• 請負契約 — 成果物を完成させることに対価を払う。仕様が固まった開発フェーズに向く

「要件定義だけをまず依頼したい」も可能です。準委任で要件定義を行い、そこで固めた内容をもとに開発を請負で見積もる、という進め方なら、いきなり大きな金額を約束せずに始められます。契約形態の詳しい話は、前回記事の契約の項も参考になります。

2026年のいま、要件定義の一部にも生成AIが使われ始めています。とはいえ「AIに丸投げすれば要件が決まる」わけではありません。効くのは、繰り返しの作業や下書きを軽くする“補助”としての使い方です。

• ヒアリングの議事録の要約・整理 — 長い打ち合わせメモから要点や決定事項を拾う
• 要求の洗い出し・抜け漏れの点検 — 目的から必要そうな機能を列挙させ、たたき台にする
• 要件定義書やRFP（提案依頼書）のドラフト作成 — 章立てに沿って下書きを素早く用意する

• 要件定義は上流工程で、後の受入テストの“合格基準”になる。ここのズレが手戻りを生む
• 発注側の仕事は立派な「要件」を書くことではなく、確かな「要求（目的とゴール）」を出すこと
• 要件は機能要件と非機能要件に分かれる。非機能はIPAの6観点（可用性・性能拡張性・運用保守性・移行性・セキュリティ・環境）で点検し、測定できない言葉を数値に置き換える
• キックオフ前に、目的・現状業務・既存システム/データ・登場人物と決裁ルート・予算納期・やらないこと、の6点を準備する
• 優先順位はMoSCoWで。Mustを欲張らず、中核から段階的に。文書より“同じ理解”を優先
• 要件定義は準委任、開発は請負が一般的な使い分け。「要件定義だけ先に依頼」も可能
• AIは議事録要約・洗い出し・ドラフトの補助に有効。ただし決めるのは人

当社TokyoScalerは、少数精鋭でWeb・モバイル・AIを活用したシステム開発を手がける受託開発会社です。多層下請けではなく代表（エンジニア）が上流から直接ご相談に応じ、要件定義（準委任）から、必要に応じて発注前の動くモックアップづくりまで伴走します。「何をどこまで頼めるか分からない」段階でも、初回のご相談（無料）からお気軽にどうぞ。あわせて外注先の選び方、AIを使った仕組みの開発を検討している場合はAIエージェント開発の外注、社内に開発チームはあるが稼働を補いたい場合は開発リソース不足の解消方法の記事も参考になります。