受託開発で「要件定義は開発会社の仕事だから任せておけばいい」と考えると、たいてい失敗します。要件定義や設計は、発注側と開発会社が一緒に進める工程で、どこまで自分たちが決め、どこから任せるかの線引きができていないと、できあがったシステムが業務に合わない、後から追加費用が出る、といった結果になりがちです。
この記事では、受託開発の要件定義と設計で、発注側が何をすればよいのかを実務目線で整理します。丸投げが失敗につながる理由、任せることと決めることの線引き、要件定義で用意すべき情報、そして設計フェーズで設計書の何を確認すればよいかまで、発注担当者が迷わないように順番に解説します。
この記事のポイント
- 受託開発の要件定義は丸投げできず、発注側にしか決められないことがある
- 専門知識は開発会社に任せ、業務と優先順位は発注側が責任を持つのが線引き
- 要件定義書のレビューでは要求との一致と抜け漏れを発注側が確認する
- 設計フェーズも任せきりにせず、基本設計書で認識のズレを早く潰す
要件定義書そのものの書き方や成果物の中身を先に知りたい場合は、要件定義書の作り方と成果物サンプルを読むと、この記事の関わり方の話がつながりやすくなります。
目次
受託開発の要件定義で発注側がやること
要件定義を丸投げすると失敗する理由
受託開発でよくある失敗の入り口は、要件定義を開発会社に丸投げしてしまうことです。要件定義は「何を作るか」を決める工程ですが、どの業務にどんな課題があり、何を優先したいのかは、発注側にしか分かりません。ここを伝えないまま任せると、開発会社は推測で埋めるしかなく、結果として現場で使えないシステムになります。
要件定義の内容に最終的な責任を持つのは、開発会社ではなく発注側の自社です。要件が曖昧なまま開発が進むと、後工程で「思っていたものと違う」と気づき、手戻りと追加要望で費用が膨らみます。丸投げは楽に見えて、実はいちばん高くつく進め方だと考えておくと安全です。
よくあるのは、こんな連鎖です。忙しさから要件定義を任せきりにする、開発会社は無難な一般的仕様で組む、テストの段階で現場が「この操作では回らない」と気づく、仕様変更を依頼する、追加費用と納期延長が発生する。最初に少し時間をかけて関わっていれば防げたズレが、後になるほど大きなコストに化けます。関与のコストは前払いのほうが必ず安く済みます。
受託開発全体がどんな工程で進むかを先に押さえたい場合は、受託開発の流れと発注者が各工程でやることもあわせて確認すると、要件定義がどの位置にある工程か見えてきます。
発注側が決めることと開発会社に任せること
丸投げと適切な依頼を分ける境目は、線引きにあります。専門知識が必要な部分は開発会社に任せ、自社にしか分からない部分は発注側が責任を持って決める。この役割分担がはっきりしていると、要件定義はスムーズに進みます。
発注側が決めるのは、目的、対象業務、解決したい課題、優先順位、予算や納期の制約、社内の承認事情です。一方で、その要求をどんな機能・画面・データ・処理で実現するかという技術的な設計は、開発会社の領域です。誰が要件定義書を書くかという役割分担の考え方は、要件定義書は誰が作るのか（発注側と開発会社の役割分担）で詳しく整理しています。
線引きで迷いやすいのが、「決める」と「丸投げ」の境目です。開発会社に相談しながら決めるのは丸投げではありません。むしろ、実現方法の選択肢や技術的な制約は積極的に開発会社に聞くべきです。丸投げになるのは、業務や優先順位という自社にしか分からない判断まで相手に委ねてしまうときです。相談は歓迎、判断は自社、と覚えておくと関わり方を間違えにくくなります。
| 領域 | 主に担う側 | 具体例 |
|---|---|---|
| 目的・課題・優先順位 | 発注側 | 何のために作るか、どの業務を優先するか |
| 業務の実態 | 発注側 | 現状の手順、例外処理、承認の流れ |
| 実現方法・技術選定 | 開発会社 | 機能・画面・データ構造・処理の設計 |
| 抜け漏れの指摘 | 開発会社 | 非機能要件や例外の洗い出し支援 |
| 最終的な合意 | 発注側 | 要件を確定し、次工程へ進める判断 |
要件定義で発注側が用意する情報
要件定義の打ち合わせを実りあるものにするには、発注側が事前に情報を用意しておくことが大切です。完璧な要件定義書は必要ありませんが、たたき台になる材料があるほど、開発会社は具体的な提案を返せます。
最低限そろえておきたいのは、現状の業務フロー、困っていること、理想の状態、利用する人と役割、扱うデータ、既存システムとの関係です。特に、承認者が不在のときや入力ミスがあったときといった例外処理は、要件から抜けやすい割に運用で効いてくるため、早めに書き出しておきます。
数値目標がまだ出せない場合でも、「何が減れば成功か」「何が増えれば成功か」を決めておくと、機能の優先順位を判断しやすくなります。ここが曖昧だと、要件定義の途中で「あると便利」な機能が次々に増え、収拾がつかなくなります。
情報を用意するとき、きれいな資料にする必要はありません。手書きのメモや箇条書き、既存のExcelやマニュアルをそのまま持ち込むだけでも十分です。大事なのは体裁ではなく、現場のリアルな実態が伝わることです。むしろ整えすぎた資料は、都合の悪い例外が省かれていることがあり、かえって要件の抜けにつながります。ありのままの業務を見せるつもりで用意すると、開発会社も精度の高い提案を返せます。
要件定義書のレビューで発注側が見る観点
要件定義書ができあがったら、開発会社に任せず発注側もレビューします。ここで確認するのは、文章のきれいさではなく、自社の要求と一致しているか、決めたはずの業務が抜けていないか、この内容で見積もりと設計に進めるかという実務的な観点です。
レビューでは、目的と機能がつながっているか、現場の例外処理が反映されているか、非機能要件（性能・運用・セキュリティなど）が漏れていないかを見ます。特に非機能要件は発注側が言語化しにくく、抜けやすい領域です。抜け漏れを体系的に点検したいときは、要件定義書のレビューシート（要件の抜け漏れ点検）を使うと、確認すべき項目を発注前に洗い出せます。
未確定の項目があっても構いません。決まっていること、保留していること、開発会社に相談したいことを分けて見える状態にしておけば、次の設計工程で順番に潰していけます。
受託開発で要件定義後の設計を発注側が確認する観点
基本設計と詳細設計の違いと発注側の関与
要件定義が固まると、開発会社は設計に入ります。設計は大きく基本設計と詳細設計に分かれ、発注側の関わり方も変わります。基本設計は「利用者から見てどう動くか」を決める工程で、画面、操作の流れ、扱うデータ、他システムとの連携などを設計します。ここは発注側もレビューに関わる工程です。
詳細設計は、基本設計をもとに「内部でどう作るか」を決める工程で、処理の細かなロジックやデータの受け渡しなど、技術的な内容が中心になります。詳細設計は主に開発会社の内部でレビューされるため、発注側が細部まで確認する必要はありません。どこに関与すべきかを間違えないことが、無駄なく品質を守るコツです。
言い換えると、発注側の力を注ぐべきは基本設計までです。詳細設計まで口を出そうとすると、専門外の議論に時間を取られ、肝心の業務目線の確認がおろそかになります。基本設計で業務との一致をしっかり見て、詳細設計は開発会社を信頼して任せる。この配分が現実的です。
| 工程 | 決めること | 発注側の関与 |
|---|---|---|
| 基本設計 | 画面・操作の流れ・データ・連携 | レビューして要求とのズレを確認 |
| 詳細設計 | 内部処理・ロジック・データ受け渡し | 主に開発会社内部で確認（深追い不要） |
基本設計書で発注側が確認する観点
基本設計書を見せられたとき、技術用語に圧倒されて「よく分からないのでお任せします」と流してしまうのは危険です。発注側が見るべきは技術の正しさではなく、要件定義で決めたことがきちんと反映されているかどうかです。
具体的には、想定した業務が画面と操作の流れで再現できているか、必要な項目やデータが揃っているか、権限や例外処理が抜けていないかを確認します。要件定義で網羅しきれていなかった点が基本設計で見つかることもよくあります。ズレや漏れに気づいたら、その時点で開発会社に相談し、早めに解消しておきます。
確認のときは、自分の業務の一日を頭の中でなぞってみると抜けに気づきやすくなります。朝に受注が入り、担当者が確認し、承認者が承認し、月末に集計する。この流れを設計書の画面と突き合わせ、どの画面で何をするのかをたどってみると、「この操作はどこでやるのか」といった疑問が具体的に出てきます。抽象的に「問題なさそう」と眺めるより、自分の仕事に当てはめて読むほうが、実務で効く指摘ができます。
画面イメージや操作の流れは、文章よりも実物に近い形のほうが判断しやすいものです。認識がずれそうな場合は、画面ラフやプロトタイプを見せてもらうと、後の手戻りを減らせます。
設計フェーズで認識のズレを防ぐ関わり方
設計フェーズで失敗しないための関わり方は、要件定義と同じく「任せきりにしない」ことです。開発会社から仕様の判断で質問が来たとき、返事が遅れると設計全体が止まります。即答できなくても、いつまでに社内で決めて返すかを伝えておくと、開発会社は段取りを組み直せます。
レビューは粗探しの場ではなく、認識をそろえる場だと考えると関わりやすくなります。私の感覚では、基本設計のレビューに発注側がきちんと参加したプロジェクトほど、後半のテストや検収で大きな手戻りが起きにくい印象があります。ここでの数時間の確認が、納品直前の揉め事を防ぎます。
もう一つ意識したいのは、窓口を一本化しつつ、判断が必要な場面では現場や決裁者を巻き込むことです。担当者一人がすべてを抱えると、確認が滞ってプロジェクト全体が止まります。逆に、関係者を毎回全員集めると議論が発散します。ふだんの窓口は一人にまとめ、要件の確定や設計レビューという節目だけ、短時間でも判断できる人を集める。この緩急が、設計フェーズを滞らせない関わり方です。
受託開発の要件定義と設計でよくある質問
要件定義・設計への関わり方について、発注担当者からよく受ける質問をまとめました。個別の状況によりますが、考え方の目安として参考にしてください。
- Q. 要件定義は開発会社に任せてはいけないのですか？
- A. 進行や構造化の支援は任せて構いませんが、目的・業務・優先順位を決める責任は発注側にあります。ここを丸投げすると現場で使えないシステムになりやすいため、任せる部分と決める部分を分けて関わるのがコツです。
- Q. 設計書の技術的な内容が分からなくても確認できますか？
- A. できます。発注側が見るのは技術の正しさではなく、要件定義で決めた業務や項目が反映されているかです。画面の流れや必要なデータが揃っているかを、自社の業務目線で確認すれば十分です。
- Q. 要件の抜け漏れはどうやって防げばよいですか？
- A. 特に非機能要件や例外処理が抜けやすいので、チェックリストで体系的に点検すると効果的です。決まっていること・未確定のこと・相談したいことを分けて見える化しておくと、設計工程で順に潰せます。
