システム開発を外注すると、たいてい最初に直面するのが要件定義です。とはいえ、要件定義をどんな手順で進めるのか、発注側である自分は何をすればいいのか、全体像が見えずに不安になる方は多いはずです。
要件定義の進め方は、大きく「ヒアリングで要望を引き出す」「現状と要望を整理する」「要件定義書にまとめて合意する」という流れで進みます。文書を作るのは開発会社でも、何を作るかを決めるのは発注側です。だからこそ、進め方の全体像を発注側が把握しておくと、ベンダー任せにならずにプロジェクトを動かせます。
この記事では、要件定義とは何かという基本から、進め方のステップ、発注側がつまずかないための準備、要件定義の後に続く開発の流れまでを、初めての発注でも追えるように整理しました。各ステップで発注側が何をするのかが分かる形にしています。
この記事のポイント
- 要件定義の進め方はヒアリング・要件整理・要件定義書づくりの3つの流れが基本
- 文書化は開発会社、何を作るか決めるのは発注側という役割分担を押さえる
- 進め方でつまずく原因の多くは発注側の準備不足と意思決定の遅れ
- 要件定義で合意した内容が以降の設計・開発・費用・納期の基準になる
目次
要件定義の進め方を知る前に押さえる基本
要件定義の目的と位置づけ
システム開発における要件定義とは、システム化で解決したい課題を明確にし、必要な機能や条件をまとめていく工程です。本格的な設計や開発に入る前の上流工程にあたり、ここで決めた内容がプロジェクト全体の土台になります。
要件定義の目的は、発注側が頭の中で描いている「こうしたい」を、開発会社が作れる形の「要件」に翻訳することです。ここが曖昧なまま進むと、出来上がったシステムが業務に合わず、設計のやり直しや予算超過につながります。逆に要件定義が丁寧にできていれば、以降の工程は驚くほどスムーズに進みます。
要件定義は全体の流れの中で、要求の整理 → 要件定義 → 基本設計 → 詳細設計 → 開発 → テスト → リリース・運用、という順序の最初のほうに位置します。最も後戻りのコストが大きい工程なので、時間をかける価値がある段階だと考えてください。家づくりでいえば、間取りや暮らし方を決める設計図の前段階にあたり、ここを曖昧にしたまま建て始めると、後から壁を壊して作り直すような事態になりかねません。
要求定義との違い
要件定義と混同されやすい言葉に「要求定義」があります。簡単に言うと、要求定義は発注側が「何を実現したいか」を整理したもの、要件定義はそれを受けて「そのために何をどう作るか」を定義したものです。
たとえば「問い合わせ対応の手間を減らしたい」というのが要求で、それを「よくある質問を自動で表示する機能を作る」という形にしたものが要件です。要求が出発点で、要件はその実現策にあたります。
実務では両者がまとめて「要件定義」と呼ばれることも多く、用語の厳密な区別に神経質になる必要はありません。大事なのは、まず発注側が自分たちの要求（やりたいこと）を言葉にすること。そこが空っぽだと、開発会社も要件に落とし込めません。よく「要件定義は丸投げできない」と言われるのは、この要求の部分が発注側にしか出せないからです。開発会社は要求を要件へ翻訳するプロですが、翻訳する元の要求がなければ何も始まらないのです。
進め方の前に押さえる役割分担
進め方の各ステップに入る前に、一つだけ前提を確認します。要件定義は発注側と開発会社の共同作業であり、それぞれ担う役割が違うということです。
業務の実態や要望を提供し、優先順位を決め、内容を承認するのは発注側の役割です。一方、それを引き出す質問をし、要件定義書という文書にまとめ、技術的な実現方法を考えるのが開発会社の役割です。どちらが欠けても要件定義は完成しません。詳しい線引きは要件定義書は誰が作るかの解説で整理しているので、不安な方は先に読んでおくと進め方が腹落ちします。
この役割分担を踏まえると、これから説明する進め方の各ステップで、発注側が何を期待されているのかが見えてきます。要件定義を「開発会社にお任せする工程」ではなく「自分たちの要望を固める工程」と捉え直すと、準備すべきことが具体的に見えてくるはずです。
要件定義の進め方とステップごとの流れ
ステップ1：課題と目的を整理する
進め方の出発点は、システム化で何を解決したいのかをはっきりさせることです。「業務を効率化したい」だけでは漠然としているので、「どの業務の、どの作業に、どれくらい時間がかかっていて、どうなれば成功か」まで具体化します。
ここは開発会社に渡す前に、発注側の中で整理しておきたい部分です。課題と目的が定まっていないままヒアリングに入ると、議論が発散し、要件も定まりません。完璧でなくてよいので、解決したい課題を箇条書きにし、優先順位をつけておきましょう。
このステップで意識したいのは、手段ではなく目的から考えることです。「在庫管理システムが欲しい」という手段から入ると、本当に解決したかった課題からずれることがあります。「在庫の数が合わず棚卸しに毎月時間がかかっている」という困りごとから出発すると、開発会社もより良い実現方法を提案しやすくなります。何に困っていて、それがどうなれば成功なのかを、自分たちの言葉で言えるようにしておくことが、進め方の最初の関門です。
ステップ2：ヒアリングで要望を引き出す
次に、開発会社が発注側にヒアリングを行い、業務の流れや要望を聞き取ります。要件定義の進め方の中で、最も発注側の関与が濃いステップです。現状の業務、困りごと、例外的な処理などを、開発会社に正確に伝えることが求められます。
このヒアリングの質は、発注側の準備で大きく変わります。何を聞かれ、何を用意し、誰を出席させるべきかは要件定義のヒアリングで発注側が準備すべきことに詳しくまとめました。現場を知る利用部門を巻き込むこと、現行の帳票を見せることが、進め方を加速させるコツです。
ヒアリングは1回で終わらないのが普通です。初回で全体像を聞き、2回目以降で細部を詰めていきます。その場で答えられない質問は無理に即答せず、持ち帰って社内で確認し、期限を決めて回答すれば問題ありません。むしろ曖昧なまま答えてしまうほうが、後の要件のブレにつながります。分かることは正直に伝え、分からないことは確認する。この姿勢がヒアリングの精度を支えます。
ステップ3：機能要件と非機能要件に整理する
ヒアリングした内容は、開発会社が「機能要件」と「非機能要件」に整理していきます。機能要件は、検索機能や自動通知といった、システムが何をするかという要件です。発注側にとっても分かりやすく、要望として挙げやすい部分です。
非機能要件は、性能やセキュリティ、稼働時間といった、どれくらいちゃんと動くかという条件です。専門的で発注側からは見えにくいですが、稼働後の使い心地を左右します。同時に何人が使うか、いつ使うか、止まると困る時間帯はいつかなど、業務の前提を伝えると、開発会社が適切な非機能要件を設計できます。
このステップで気をつけたいのが、要望の優先順位をはっきりさせることです。あれもこれもと機能を盛り込むと、予算も納期も膨らみます。「絶対に必要」「あると嬉しい」「今回は見送る」の3段階に仕分けておくと、開発会社が予算内で最大限の効果を出す構成を提案しやすくなります。すべてを必須にするのは、優先順位をつけていないのと同じだと考えてください。
| 種類 | 内容 | 発注側が伝えること |
|---|---|---|
| 機能要件 | システムが行う具体的な機能 | やりたいこと・業務上必要な操作 |
| 非機能要件 | 性能・セキュリティ・稼働条件 | 利用人数・利用時間・止まると困る度合い |
ステップ4：要件定義書にまとめて合意する
整理した内容を、開発会社が要件定義書という文書にまとめます。要件定義書には、目的、機能要件、非機能要件、業務フロー、スケジュール、体制などが記載されます。これが以降の設計・開発・検収の基準になります。
発注側の仕事は、この文書が自社の業務と要望に合っているかを確認し、承認することです。専門用語の正しさではなく「やりたいことが反映されているか」「現場で使えるか」を見ます。要件定義書の項目や読み方は要件定義書の作り方と成果物サンプルで確認できます。ここで承認した内容が後で覆ると追加費用につながるため、進め方の中でも特に丁寧に進めたいステップです。
合意できたら要件定義は完了し、次の設計工程へ進みます。逆に言えば、ここまでの進め方を丁寧に踏めば、開発の土台は固まったと言えます。
なお、要件定義書の合意は口頭で済ませず、必ず文書で残してください。「あのとき言った・言わない」を防ぐためであり、後から仕様変更が発生したときに、どこからが追加なのかを線引きする基準にもなります。承認は単なる事務手続きではなく、発注側が内容に責任を持つという意思表示です。気になる点があれば、承認前にすべて質問して解消しておきましょう。
進め方でつまずく原因と対策
要件定義の進め方でよくつまずくのが、発注側の準備不足と意思決定の遅れです。要望が固まらないまま打ち合わせを重ねると、要件が二転三転して期間だけが延びます。また、社内で優先順位や予算が決まっていないと、開発会社が提案しても判断できず、進め方が止まります。
対策はシンプルで、課題と優先順位を発注側の中で先に決めておくこと、そして決める人を明確にしておくことです。要件定義は開発会社のペースではなく、発注側が判断を返すスピードで進みます。準備と即断ができれば、進め方は一気に楽になります。
数値レンジで言えば、小規模なシステムでも要件定義に数週間、規模が大きければ1〜数か月かかることもあります。あくまで一般的な目安で、実際の期間は個別の見積もりで確認してください。短すぎる要件定義はかえって後工程のリスクになると考えておきましょう。
要件定義の後に続く開発の流れ
要件定義書の合意が終わると、システム開発は次の工程へ進みます。大まかには、基本設計、詳細設計、開発（プログラミング）、各種テスト、リリース、保守・運用という順序です。
発注側の関与は要件定義がピークで、以降は確認と承認が中心になります。とはいえ、設計段階で画面イメージを確認したり、テスト段階で実際に操作して業務に合うか検証したりと、節目では発注側の出番があります。要件定義で固めた内容が、これらの工程すべての判断基準になるため、最初の進め方が後工程の負担を決めると言っても過言ではありません。
全体の工程と各フェーズの呼び方を先に把握しておくと、開発会社との会話もかみ合いやすくなります。システム開発全体がどんな流れで進むのかは、発注の段取りとあわせて押さえておくと安心です。要件定義はその最初の山場であり、ここを越えれば、あとは開発会社が主導する工程に移っていくとイメージしておきましょう。
