システム開発の発注側と開発側の役割分担｜要件定義の前に「誰が何を決めるか」を明確にする方法ARTICLE

「開発会社に頼んでいるのに、なぜか前に進まない」「言った通りに作ってもらったはずなのに、現場で使われない」——システム開発の相談を受けていると、こうした声をよく聞きます。

原因を掘り下げていくと、技術の問題であることはまれです。ほとんどの場合、発注側と開発側の間で「誰が何を決めるか」が曖昧なまま進んでいることにたどり着きます。

本記事はシリーズ「発注側のための要件定義」の第1回です。要件定義の進め方そのものは全体像の記事で解説しているので、この回ではその手前にある、発注側と開発側の役割分担を扱います。システムに詳しくない事業部の方、DX推進の担当になったばかりの方を想定して書いています。

なぜ役割分担が要件定義の出発点なのか

システム開発は、発注側（システムを使って事業を動かす側）と開発側（システムを作る側）の共同作業です。ところがこの2つの立場は、同じ日本語を話していても、前提としている「当たり前」がまったく違います。

発注側の頭の中にあるのは、売上や利益、KPI、費用対効果、解約率、稟議や予算といった言葉です。開発側の頭の中にあるのは、品質・コスト・納期（QCD）、インフラ、アジャイルやスクラムといった進め方、APIといった言葉です。

どちらが正しいという話ではありません。問題は、お互いに「これくらいは言わなくても分かるだろう」と思っている範囲が重なっていないことです。発注側が「解約率を下げたい」と言えば、開発側には「で、何を作ればいいのか」が分かりません。開発側が「この要件だと非機能要件の検討が必要です」と言えば、発注側には何を聞かれているのか分かりません。

だからこそ、要件定義に入る前に、どちらが何に責任を持ち、どこで受け渡すのかを決めておく必要があります。役割が決まっていれば、「それはこちらで決めます」「そこは提案をください」と、通じない言葉を翻訳しながら進められます。

発注側と開発側は、どこで分かれるか

まず、2つの立場の定義をそろえます。

• 発注側：事業の目標を達成し、業務を運営することに責任を持つ側です。営業、マーケティング、商品企画、カスタマーサポート、経営管理など、システムを使って成果を出す部門が該当します。
• 開発側：技術的な手段でそれを実現し、維持することに責任を持つ側です。社内の情報システム部門、開発会社、インフラを担当するチーム、テクニカルサポートなどが該当します。

社内に情報システム部門がある場合、その部門は「開発側」に入ります。事業部から見れば社内の人でも、役割としては開発側です。逆に、開発を外注していても、要求を出し、成果物を受け入れる責任は発注側に残ります。

一言でまとめると、次のようになります。

この一行を関係者全員が共有できているかどうかで、プロジェクトの進み方は大きく変わります。

責任は5組の対応関係になっている

発注側の責任と開発側の責任は、独立しているわけではなく、対になっています。発注側が出したものを開発側が受け取り、それに基づいて次の成果物を作る、という関係です。

1. 目的を示す → 技術的な解決策を提案する：発注側が「何のためのプロジェクトか」を示し、開発側がその目的に合った技術的な手段を提案します。目的が曖昧だと、開発側は手段を選べません。
2. 要求を明確にする → 要求に基づいて実装する：発注側の要求がはっきりしているほど、開発は迷いなく進みます。要求が途中で変わると、実装もやり直しになります。
3. ビジネス要件を決める → システムを設計する：業務としてどうあるべきかを発注側が決め、それを土台に開発側がシステムの構造を設計します。
4. 関係者の要求を集める → テスト計画を作る：現場や関係部門から集めた要求は、開発側が「何をテストすれば要求を満たしたと言えるか」を決める材料になります。
5. 期待する成果物を示す → 成果物を納品・リリースする：最終的に何が納品されれば完了なのかを発注側が示すことで、開発側は迷わず納品でき、受け入れの判断もぶれません。

この対応関係を見ると分かるとおり、左側（発注側）が空欄のまま右側（開発側）だけを進めることはできません。「よく分からないので、開発会社にいい感じにしてもらう」が成り立たないのは、このためです。

工程ごとに、主役が入れ替わる

役割分担は「発注側はこれ、開発側はこれ」と固定ではなく、工程によって主役が入れ替わります。

• 企画・要求定義：発注側が主役です。なぜやるのか、誰のために、何を実現したいのかを言葉にします。開発側は、技術的に可能かどうかの相談相手として協力します。
• 要件定義：両者で握る工程です。発注側の要求を、開発側がシステムの条件に翻訳し、すり合わせます。どちらか一方に任せられない唯一の工程と言ってもよいでしょう。
• 設計・実装・テスト：開発側が主役です。発注側は、途中の確認や質問への回答で協力します。
• 受入テスト：再び発注側が主役になります。できあがったものが業務で使えるかを判断できるのは、業務を知っている発注側だけだからです。
• 運用：両者で担います。発注側は業務での利用と改善要望、開発側は保守と障害対応を受け持ちます。

失敗しやすいのは、主役が入れ替わるタイミングで、バトンが渡されないケースです。企画は発注側で盛り上がったのに、要求が言葉になる前に「あとはお願いします」と開発側に渡してしまう。あるいは、開発が終わったのに、受入テストを開発側の動作確認で済ませてしまう。どちらも、本来の主役が不在のまま工程が進んでいます。

体制は「消えないペン」で決める

役割分担を実際に機能させるには、体制を決める必要があります。ここで最も重要なのが、次の2人を名前で決めることです。

• プロジェクトオーナー：予算と優先順位について、最終的に決める人です。多くの場合、事業部長や役員クラスになります。
• プロジェクトマネージャー（PM）：決まった方針のもとで日々の進行を管理し、関係者を調整する人です。発注側と開発側にそれぞれ1人ずつ置きます。

「消えないペンで」と書いたのは、この2人が曖昧なまま始まるプロジェクトがあまりに多いからです。「オーナーは……まあ部長ですかね」「PMは私が兼務で」という状態で始めると、次のようなことが起きます。

• 担当者レベルで決めたことが、あとから経営層に「聞いていない」とひっくり返される
• 部門間で要望がぶつかったときに、誰も裁定できず、両方入れて膨らむ
• 開発側から「どちらにしますか」と聞かれても、持ち帰りが続いて答えが出ない

いずれも、決める人が決まっていないことが原因です。逆に、オーナーとPMが名前で決まっていれば、開発側は「この判断は誰に聞けばよいか」が分かり、発注側の中でも「これはオーナー判断、これはPM判断」と切り分けられます。

なお、社内にシステムに詳しい人がいないと、発注側のPMを誰にするかで悩みがちです。ここはシステムの知識より、業務の目的と現場の実態を知っていることを優先してください。技術的な翻訳が必要な部分は、開発側のPMや外部パートナーが補えます。逆は成り立ちません。

「誰が・何を・いつまでに」を表にする

体制が決まったら、プロジェクトで決めるべきことを洗い出し、誰が決めるのかを表にします。ポイントは、「作業」ではなく「決めること」を書くことです。

実際に使うときは、次のように担当者名と期限を添えます。

この表があると、開発側から質問が来たときに「誰に聞くべきか」で止まらなくなります。また、発注側の中でも、「技術の選定は開発側に任せる」「画面の要件はこちらで決める」という線引きが共有されるので、口を出しすぎたり、逆に任せきりにしたりすることが減ります。

表は最初から完璧である必要はありません。要件定義を進める中で「これは誰が決めるのか」という項目が出てきたら、そのつど足していきます。

役割分担でよくあるつまずき

K.S.Rogers が要件定義の相談を受ける中で、役割に関して繰り返し見てきたつまずきを3つ挙げます。

1. オーナー不在のまま、担当者だけで進める

最も多いパターンです。担当者が熱心に要求をまとめ、開発側と詰めていったのに、予算や優先順位の段階で「そんな話は聞いていない」と経営層に止められます。担当者にも開発側にも非はなく、最終決定者を最初に決めていなかったことだけが原因です。

2. 「そこは御社で決めてください」と開発側に投げる

目的や優先順位、業務の流れといった、発注側にしか決められないことを開発側に委ねてしまうケースです。開発側はシステムを作る専門家ですが、発注側の業務の事情や、社内で何を優先したいかは知りません。任された開発側は一般的な正解で埋めるしかなく、できあがるのは「どこにでもあるが、自社の業務には合わないシステム」です。

3. 発注側が技術の判断にまで踏み込む

逆のパターンもあります。使う技術やツール、画面の細かな実装方法まで発注側が指定してしまい、開発側が提案できなくなるケースです。発注側が決めるべきなのは「何を実現したいか」であり、「どう実現するか」は開発側の専門領域です。役割表で「技術の選定は開発側が決め、発注側は確認する」と線を引いておくと、この踏み込みすぎを防げます。

支援の現場で見た、役割が整うと変わること

K.S.Rogers の要件定義支援でも、最初に手を付けるのは役割の整理であることがほとんどです。

オンライン診療プロダクトの開発体制を立て直した事例では、進まない原因は開発そのものではなく、その手前の要求整理にありました。要件定義書がなく、プロダクトを触らないと要件が分からない状態から、主要な立場の人に一通り話を聞き、各視点の課題を集めて共通認識にするところから始めています。

音声ライブ配信アプリの開発体制を整えた事例では、機能要望が次々と出る一方で優先順位やスケジュールが見えづらく、経営と開発の期待値にずれが生じていました。誰が優先順位を決め、どう伝えるかを整えることで、リリース後も継続的に改善できる状態になっています。

どちらも、技術を入れ替えたわけではありません。誰が何を決めるかが整理されただけで、止まっていたプロジェクトが動き出すというのは、珍しいことではないのです。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版」：発注側（ユーザ企業）の視点で、要件定義で起きやすい問題と解決策が整理されています。役割分担についても、ユーザ側が担うべきことが具体的に書かれています
• IPA「情報システム・モデル取引・契約書（第二版）」：ユーザ企業とITベンダの役割分担を前提にしたモデル契約です。開発を外注するときに、どこまでが発注側の責任かを確認できます
• 経済産業省「デジタルスキル標準」：DX推進に必要な人材の類型と役割が定義されています。社内で発注側の体制を考えるときの参考になります

役割の整理からご一緒します ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。オーナーとPMをどう置くか、誰が何を決めるかの整理は、その最初の一歩です。

「社内にシステムに詳しい人がいない」という段階からで構いません。決める権限は御社に残したまま、翻訳と整理を伴走します。

まとめ

• 発注側と開発側は、同じ日本語でも「当たり前」が違います。役割を決めておくことが、通じない言葉を翻訳しながら進めるための土台になります
• 発注側は目的と要求を明確にする責任、開発側はそれに基づいて技術的な解決策を提案し実装する責任を持ちます。この2つは5組の対応関係になっていて、発注側の欄を空けたまま開発側だけを進めることはできません
• 主役は工程ごとに入れ替わります。企画と要求定義は発注側、設計と実装は開発側、要件定義は両者で握り、受入テストは発注側に戻ります
• プロジェクトオーナーとPMは、最初に名前で決めます。そのうえで「誰が・何を・いつまでに決めるか」を表にし、要件定義の中で育てていきます

次回は、発注側が主役になる最初の工程として、システム開発の企画書の作り方（現状分析と課題の抽出）を扱います。要件定義の進め方の全体像は要件定義の進め方を、自社の体制について相談したい方はお問い合わせからお気軽にご連絡ください。