システム開発の「要件定義」で何を決めておくべきか｜発注前に準備すること

「要件定義に参加したが、何を決めているのかよくわからなかった」という発注側の担当者からの言葉は、珍しくない。会議室でエンジニアとベンダーが専門用語を使いながら話を進めていて、自分たちが何を決めているのかが見えない。そのまま開発が始まって、できあがったものを見て「思っていたのと違う」となる。

要件定義の主役は発注側だ。ベンダーはあなたの業務を知らない。どれだけ優秀なエンジニアでも、現場を毎日生きているあなたの代わりにはなれない。「ベンダーに任せれば引き出してくれる」という期待は、往々にして手戻りと追加費用という形で裏切られる。

要件定義で決めるべき四つのこと

①誰がどの業務をシステムで行うか

「社員が使います」では足りない。何年目の、どんな業務を担当している、どの程度ITに慣れた人間が、1日に何回、どういう状況で操作するのか。営業が外出先でスマホから入力するのか、経理が事務所のPCで月次処理をするのか。この違いだけでUI設計は大きく変わる。

現場担当者を要件定義の場に1人でも連れてこられるなら、ぜひそうしてほしい。決裁者だけで仕様を固めた結果、実際の使い手が「使いにくい」と感じるシステムを量産してきた歴史は長い。誰が使うかを具体的に想定することが、後の「誰も使わないシステム」を防ぐ最初の一手だ。

②何のためのシステムか（目的と成功基準）

これが最も見落とされる問いだ。システムを入れること自体が目的になってしまい、導入後に「なんとなく便利になった気がする」で終わるプロジェクトを何度も見てきた。成功の定義は数値で持てるなら数値がいい。「月次集計の工数が今の半分以下になる」「ヒューマンエラーによる返品が月5件以下になる」。

ゴールが明確だと、要件定義の途中で「この機能は必要か」という判断軸が生まれる。逆にこれがないと、機能追加の歯止めが利かなくなり、スコープが膨らんでコストが跳ね上がる。「成功したかどうか」が後から確認できる状態を作ることが、発注側の重要な責任だ。

③何を入力して何を出力するか（データの流れ）

システムは「データを受け取り、処理し、出力する」機械だ。「注文が入ったら何が起き、誰が何をして、次にどこへ渡るか」——この流れを文章か図にできない状態でシステム開発に入ると、ほぼ確実に手戻りが発生する。

重要なのは「例外処理」まで書くことだ。業務の8割は標準フローで動くが、残り2割の例外が現場の頭を悩ませている。その例外こそ、システムに組み込むべきか、割り切って手運用にするかを判断しなければならない。ここを曖昧にしたままベンダーに伝えると、後から「そのケースは想定外です」という会話が必ず生まれる。

④既存システムとの接続（連携設計）

会計ソフト・受発注システム・在庫管理・顧客データベース——すでに使っているシステムと新しいシステムをどうつなぐかは、要件定義の時点で決めておかなければならない。「後で考える」にすると、開発の終盤に「実は連携が必要で」という話になり、追加費用と工期延長につながる。

連携の方法にはAPIによるリアルタイム連携、CSVによるバッチ取り込み、手動でのデータ移行など複数の選択肢がある。それぞれコストと運用負荷が違う。「何をどのタイミングでどう連携させるか」を早い段階で確認しておくことが、後の混乱を防ぐ。

発注前に発注側が準備すべきこと

要件定義の前に、まず現場観察から始めることを勧めたい。会議室でヒアリングするより、現場で実際に作業している人を1時間観察することで気づくことの方が多い。人は自分の業務を完全には言語化できない。身体で覚えた手順や、なんとなくやっている確認作業が、システム化した途端に「そこが抜けた」と問題になることがある。

次に、「現在どこに何のデータがあるか」を整理する。ExcelファイルA、スプレッドシートB、紙の台帳C——これらがどこに保存されていて、誰が管理していて、どの頻度で更新されているかを棚卸しする。このデータの棚卸しをしないまま開発を始めると、「実は別のところにもデータがあった」という状況が後から出てきて、設計変更につながる。

発注側が「仕様はベンダーに任せる」と言った瞬間、プロジェクトは受け身になる。ベンダーはRFP（要件定義書）に書かれていないことには責任を持てない。書かれていないことが問題になったとき、「それは要件に入っていませんでした」という返答は、技術的には正しい。だが業務は止まる。準備に時間をかけることが、開発工数を減らすことに直結する。

要件定義でよく起きるすれ違いのパターン

「認識が合っていると思っていたが、実際に動くものを見たら違った」——これが最も多い失敗パターンだ。発注側は「こういう画面が欲しい」という完成イメージを持っていた。ベンダー側は「こういう機能を作る」という仕様として受け取っていた。完成イメージと機能仕様は、言葉にするまで同じとは限らない。

プロトタイプやワイヤーフレームを使って「こういう画面ですか」を確認するプロセスは、このすれ違いを事前に解消するためのものだ。言葉で合意するより、画面を見ながら確認する方が、ずっと精度が高い。開発に入る前にプロトタイプを確認することを、コストの「追加」ではなく「節約」として捉えてほしい。

発注側が準備できていると、開発の質が上がる

要件が明確な発注者からの依頼は、エンジニアにとっても動きやすい。「何を作ればいいか」がはっきりしているから、技術的な判断に集中できる。逆に要件が曖昧だと、エンジニアが「たぶんこういうことだろう」と推測しながら作ることになる。推測が当たれば問題ないが、外れると手戻りが発生する。

準備に時間をかけることは、開発工数を減らすことに直結する。要件定義に1ヶ月かけて開発が3ヶ月になるより、要件定義が2週間で開発が6ヶ月になる方が、最終的なコストも品質も悪い。手を動かす前に頭を使う時間を惜しまないことが、システム開発成功の第一条件だ。

要件定義にかける時間の正しい考え方

「要件定義に時間をかけると開発が遅くなる」という誤解がある。実際には逆だ。要件が曖昧なまま開発に入ると、途中で何度も仕様変更が発生し、その都度開発が止まる。要件定義の1日は、開発フェーズの数日分の手戻りを防ぐ。

発注側が要件定義に積極的に関与することで、「自分たちが作ってもらっているもの」という意識が生まれる。導入後の定着率も上がる。現場担当者が要件定義から参加していると、「自分たちの意見が反映されたシステム」として受け入れられやすい。要件定義は開発の前置きではなく、プロジェクト成功の鍵だ。