要件定義は誰がやる？発注側が準備するものと見積もりが出る条件

要件定義書をまとめるのは開発会社の仕事です。発注側が出すのは、いまの業務の実態・優先順位・決裁の3つで、ここだけは代わりがいません。「要件定義書を自分たちで書かなければいけないのか」と身構える必要はありませんが、丸投げだけは成立しません。

「受発注をExcelと紙で回していて、締め日は毎回残業になっている」「システム化しようと開発会社に相談したら、要件が固まっていないと見積もりは出せませんと言われた」。社内にIT担当がいない企業から、こうしたご相談をよくいただきます。何をどこまで決めれば見積もりが出るのかが分からず、そこで止まってしまう状態です。

◆この記事の要点

• 役割分担：要件を出すのは発注側ですが、要件定義書にまとめるのは開発会社の仕事です。文書づくりは任せて構いません
• 丸投げが危ない理由：発注側にも協力義務があります。これを怠った発注者に約14億9,700万円の支払いを命じた裁判例もあります
• 見積もりが出る条件：対象の業務、使う人数、つなぐ既存システムが分かれば、おおよその金額は出せます。稟議に使える金額が固まるのは、画面まで決めたあとです
• 準備するもの：いまの業務の流れ、使っているExcel・帳票、困っていること、関係部署と決裁者、つなぎたい既存システム。この5つが分かる材料があれば十分で、きれいに揃っていなくても相談できます

» 【無料】要件が固まっていない段階から株式会社ペンタゴンに相談する

本記事では、スタートアップから大手企業まで10年以上アプリ・Webシステム開発に携わってきた「株式会社ペンタゴン」の代表である筆者が、要件定義における発注側の役割と、見積もりが出るまでに決めるべきことを解説します。当社が実際に行っている進め方と金額をそのまま書いています。

関連記事：システム開発の要件定義とは？進め方から成功のコツまで徹底解説（要件定義の工程そのものを詳しく知りたい方はこちら）

アプリ開発専門のプロ「株式会社 Pentagon（ペンタゴン）」とは？

Pentagon（ペンタゴン）は、アプリ開発を専門に行う会社です。私たちは単なる開発会社ではなく、お客様の事業の成長を共に創り上げるアプリ開発パートナーです。お客様の事業の成長に本気で向き合うため、当社のアプリ開発では、

• 「もっとこうすれば良くなる」という提案を次々と出します
• 「使いやすさ」と「成果があがること」のどちらも妥協しないアプリを作ります
• リリース後もデータを見ながら、改善・グロースまで一緒に考えます

詳しくはペンタゴンの特徴をご覧ください。無料相談はこちらから

要件定義は誰がやる？発注側と開発会社の役割分担

要件定義書をまとめるのは開発会社の仕事です。発注側が担うのは、いまの業務の実態を伝えること、優先順位を決めること、決裁することの3つです。ヒアリングも文書化も画面設計も開発会社側の作業なので、社内に情報システム担当がいなくても進められます。

表のとおり、書類を書く作業はほぼ開発会社側にあります。発注側にしかできないのは「いま実際にどう回っているか」を伝えることと、「どれを先に作るか」を決めることです。この2つは業務を知っている人にしか出せません。

要求定義と要件定義の違い

要求定義は「何に困っていて、どうなりたいか」を発注側が言葉にする工程、要件定義はそれを「作れる仕様」に変換する工程です。よく混同されますが、外注できるのは後者だけだと考えると分かりやすくなります。前者を開発会社が推測で埋めると、出来上がったシステムが現場で使われないという結果になります。

「丸投げ」だけは成立しない。発注側には協力義務がある

文書の作成は開発会社に任せてよいのですが、業務の情報を出す・決めるという役割は外注できません。システム開発では発注側にも協力義務があるとされ、それを怠った側が賠償を命じられた裁判例もあります。

札幌高等裁判所は2017年8月31日、旭川医科大学とNTT東日本の裁判で一審の判断を覆し、発注側である旭川医科大学がNTT東日本に約14億9,700万円を支払うよう命じました。理由とされたのは発注側の協力義務違反です。仕様が確定した後に90項目を超える追加のカスタマイズ要望を出し続けたこと、現行システムの情報提供が不足していたこと、必要な作業を行わなかったことが認定されました。極端な事例ではありますが、「開発会社に任せたのだから後は待つだけ」という姿勢が法的にも通らないことを示しています。

実務でつまずくのは、たいてい次の3つです。

• 現場の例外運用が出てこない：管理職だけがヒアリングに答えると、「この取引先だけ手書き」「月末は順序が変わる」といった実態が漏れる。開発後に使えないと言われる原因の大半がこれです
• 決裁者が会議に出ない：担当者レベルで合意しても、後から決裁者が別の要望を出すと作り直しになります
• 仕様が固まった後に追加要望が続く：優先順位を決めずに「あれもこれも」と足していくと、費用も期間も膨らみます

逆に言えば、この3つを避けるだけで要件定義の失敗はかなり減ります。当社が最初の打ち合わせで関係部署と決裁者の同席をお願いしているのは、そのためです。

発注側が準備しておくもの（完璧でなくてよい5点）

用意していただきたいのは、現行の業務フロー、いま使っているExcel・帳票、困りごとのリスト、関係部署と決裁者、連携が必要な既存システムの5点です。体裁は問いません。「いま実際にどう回しているか」が分かる材料であれば十分です。

準備できていなくても相談してよい

この5点が揃っていないと相談できない、ということはありません。揃っていれば打ち合わせの密度が上がるというだけです。実際には「Excelが部署ごとにバラバラで、どれが正しいのか分からない」という状態からご相談いただくことが多く、その整理自体を要件定義の作業として行います。準備が終わるのを待っていると、いつまでも着手できません。

どこまで決まれば見積もりが出るのか

概算の見積もりは「対象業務・利用者数・連携先」の3つが分かれば出せます。金額が動かなくなる確定見積もりには、画面とデータ項目まで決める必要があります。「要件が固まらないと見積もれない」と言われた場合、多くは後者の話をしています。

つまり、稟議に出せる金額がほしいなら要件定義を終える必要がありますが、「だいたいいくらか」を知るだけなら、いまの状態のままで聞けます。当社では初回のご相談時に、対象業務と利用者数、連携先を伺ったうえで規模帯の目安をお伝えし、そのうえで要件定義の進め方をご提案しています。

注意したいのは、前提を揃えずに複数社から見積もりを取ると、金額が数倍ばらつくことです。同じ相談をして300万円と1,200万円が返ってくるのは珍しくありません。差が出るのは作り方とスコープが各社バラバラなまま見積もられているからで、金額の高低だけでは判断できません。見積書の読み解き方はシステム開発の見積もりチェックポイント - 内訳の詳細と妥当性の見極め方で解説しています。

要件定義の進め方（当社の場合・1〜2ヶ月）

当社は週1回の定例会議を軸に、現行業務の調査、画面設計、要件定義書と見積もりの順で進めます。関係部署の合意が必要な局面では、ステークホルダーを交えて週2〜3回に増やします。発注側にお願いするのは、この定例に出て判断していただくことです。

画面を先に見せて合意する（Figma）

当社は画面設計を要件定義の納品物としています。文章だけの要件定義書は、書いた側と読んだ側で解釈がずれたまま合意されてしまうためです。実際の画面をFigmaで作って「この一覧にこの項目が並びます」「ここを押すとこの画面に移ります」と見せると、現場から「この項目では判断できない」「この順番だと入力しづらい」という指摘がその場で出ます。開発が始まってから出るはずだった指摘を、要件定義のうちに前倒しできます。

発注側にとっての利点は、専門用語を読み解かなくても判断できることです。「非機能要件の可用性は99.9%とする」と書かれても判断のしようがありませんが、画面を見て「この項目が足りない」なら誰でも言えます。

AI駆動開発だから、要件定義に時間を使える

当社はFigmaをベースにしたAI駆動開発に取り組んでいます。コーディングの工数が圧縮される分を、要件定義と検証に振り向けられるのが発注側にとっての利点です。

図の左が従来の開発、右が当社のAI駆動開発です。作る時間が減り、決める時間と確かめる時間が増えます。要件定義に十分な時間を取れるのは、この構造があるからです。

関連記事：AI駆動開発のWebシステム開発費用・期間｜要件定義が全て

現行業務・現行システムの調査で何を見るか

要件定義の前半は、いま実際にどう回っているかの調査に使います。文書化されていない既存システムやSaaSとの連携があるほど、この調査に時間がかかります。理想の業務フローから描き始めると、現場の例外運用が抜け落ちて後で作り直しになります。

注意が必要なのは連携先です。API（外部連携の仕組み）の仕様が公開されているSaaSなら調査は短く済みますが、仕様が文書化されていない既存システムに接続する場合は、調査と検証に人の時間がかかります。ここが期間と費用の振れ幅になるため、初回の打ち合わせで必ず確認しています。

要件定義にかかる期間と費用

要件定義の期間は1〜2ヶ月、費用は開発費全体の10〜15%が一つの目安です。当社の場合、金額にすると100〜200万円で、内訳は現行業務の調査と画面設計です。規模が大きくなっても要件定義の費用が比例して増えるわけではなく、調査対象の数と連携先の複雑さで決まります。

要件定義にこれだけの時間と費用をかける価値があるかは、その後の手戻りで判断してください。画面まで合意せずに開発へ進み、テスト段階で「この項目では承認できない」と分かった場合、作り直しの費用は要件定義の費用を簡単に超えます。業務システム全体の費用と、効果が費用を上回る条件は業務システム開発の費用相場と内訳｜元が取れる条件と試算法で試算方法まで解説しています。

安すぎる見積もり・高すぎる見積もりの見分け方

金額の高低ではなく、何をやるかで判断してください。数十万円で要件定義を請ける場合、現場ヒアリングを行わず、既存のテンプレートに聞き取り内容を流し込んで終わることがあります。この成果物では開発の見積もりの前提になりません。逆に数百万円の見積もりでも、対象業務が多く、仕様書のない既存システムとの連携調査が必要なら妥当です。

• 現場担当者へのヒアリングが工程に入っているか（決裁者への説明だけで終わっていないか）
• 画面まで作るのか、文章の要件定義書だけなのか
• 連携先の調査が範囲に含まれているか、別見積もりか
• 開発の見積もりとスケジュールまで出るのか

予算がまだ通っていないなら、要件定義から先に契約する方法もある

開発予算の全額が確保できていない段階では、要件定義フェーズだけを先に契約する進め方もあります。当社の目安は1〜2ヶ月・100〜200万円で、契約は請負、成果物の著作権も費用に含めてお渡しします。要件定義の結果として開発の金額と期間が確定するため、そのまま稟議に使えます。

実際にBtoBマッチングアプリの案件で、要件定義のみを先に受注したことがあります。約2ヶ月・100万円程度で納品し、その後、発注側で予算が確保できて開発に移行しました。全体を一度に契約すると社内稟議が通らない状況でしたが、要件定義書と画面設計という具体的な資料が手元にあることで、「いくらで、何ができて、いつ終わるか」を根拠のある数字で申請できたためです。

実績：出品から支払管理まで一気通貫のBtoBマーケットプレイスアプリ開発

ただし、要件定義と開発を同じ会社で通したほうが、総額も期間も抑えられます。会社が変わると現行業務の調査と画面設計のすり合わせをもう一度行うことになり、その分が重複するためです。工程を切り出すのは、予算の都合や社内の事情でどうしても分ける必要がある場合の選択肢と考えてください。

要件定義でつまずかない開発会社の選び方

画面まで作るか、現場ヒアリングを行うか、成果物が発注側の資産として残るか、非機能要件まで書くか、優先順位の相談に乗るか。この5つで見分けられます。いずれも商談で質問すればその場で分かります。

⑤は見落とされがちですが重要です。要件を全部積み上げると予算に収まらないのが普通で、そこから「何を先に作るか」を一緒に決められる会社かどうかで、プロジェクトが動くかどうかが変わります。

要件定義と発注についてよくある質問

要件定義書は自社で書かないといけませんか？

書く必要はありません。要件定義書をまとめるのは開発会社の作業です。発注側にお願いするのは、現在の業務を説明していただくことと、優先順位を決めていただくことの2つです。ただし内容のレビューと合意は発注側の役割なので、出来上がった要件定義書を読んで「この業務はこうではない」と指摘していただく必要はあります。

要件が固まっていない段階でも見積もりは出せますか？

概算であれば出せます。対象業務の範囲、使う人数、連携する既存システムの有無が分かれば、規模帯の目安をお伝えできます。稟議に使える確定見積もりは、画面とデータ項目まで決めた要件定義の完了時になります。「要件が固まらないと見積もれない」と言われた場合は、概算でよいので目安がほしいと伝えてみてください。

社内に情報システム担当がいなくても進められますか？

進められます。実際、ご相談いただく企業の多くは情報システム部門を持っていません。必要なのはIT知識ではなく、業務を説明できる現場担当者と、優先順位を決められる決裁者です。専門用語は使わず、画面を見ながら判断していただく形で進めます。

RFP（提案依頼書）は作ったほうがよいですか？

複数社に同じ条件で提案を求めたい場合は有効です。ただし、RFPがないと相談できないわけではありません。困りごとと対象業務が言葉になっていれば、そこから一緒に整理できます。書き方を知っておきたい方は「RFPの書き方」アプリ開発の品質が上がる無料テンプレ付きを参考にしてください。

現行システムの資料が残っていないのですが大丈夫ですか？

対応できますが、調査の工数を見込みます。仕様書が残っていない既存システムやSaaSと連携する場合、実際の画面と出力データから仕様を推定し、検証する作業が必要です。この工数は事前に切り分けて見積もりに明示します。資料がなくても、実際に使っている画面と出力される帳票・CSVがあれば調査は進みます。

まとめ

要件定義書をまとめるのは開発会社の仕事です。発注側が担うのは、いまの業務の実態を伝えること、優先順位を決めること、決裁することの3つで、この部分だけは外注できません。丸投げが通らないのは実務上の話にとどまらず、発注側の協力義務違反が認められた裁判例もあります。

見積もりについては、概算なら「対象業務・利用者数・連携先」の3つで出せます。金額が動かなくなる確定見積もりは、画面とデータ項目まで決めた要件定義の完了時です。準備が整うのを待つ必要はありません。Excelが部署ごとにバラバラという状態からでも、その整理自体を要件定義の作業として進められます。

株式会社ペンタゴンは、Figmaで画面を先に固める要件定義と、FigmaをベースにしたAI駆動開発で、中小企業の業務システム・Webシステムを開発しています。「何から決めればいいか分からない」段階からご相談ください。

» 【無料】要件が固まっていない段階から株式会社ペンタゴンに相談する