要件定義書、誰が書くべきかで揉める理由

「要件定義書は御社で用意してください」と言われて、開発の専門知識もないのに何を書けばいいのか分からず手が止まった、という経験はないでしょうか。逆に「そちらの仕様に合わせて開発します」と言われたのに、いざ始まると「詳細はお客様側で決めてほしい」と押し戻されることもあります。

この「誰が書くのか」問題は、担当者の能力や熱意の差ではなく、要件定義という工程そのものの性質に理由があると考えると整理しやすくなります。発注側の業務知識と開発側の技術知識、どちらか一方だけでは完成しないという構造があるためです。

この記事では、要件定義書の作成責任がなぜ揉めやすいのか、その構造と、揉めないための現実的な役割分担の考え方を紹介します。

なぜ「どちらが書くか」で揉めるのか

要件定義書には、大きく分けて2種類の情報が必要になります。ひとつは「現場でどんな業務が、どんな順番で、誰の手を経て行われているか」という業務知識。もうひとつは「その業務をシステムでどう実現できるか、何が技術的に難しいか」という技術知識です。

発注側の担当者は業務には詳しくても、それをシステムの言葉に翻訳する方法が分かりません。開発側は技術には詳しくても、発注企業の業務の細かい事情までは把握していません。どちらも要件定義書を「完成させる」だけの材料を単独では持っていない、という構造があります。ここを分かっていないと、「向こうが専門家なんだから書いてくれるはず」「発注元が業務を分かっているんだから書いてくれるはず」というすれ違いが起きます。

契約形態によっても、どちらが主導すべきかの前提が変わってきます。この点はSIer・フリーランス・自社開発、契約形態で何が変わるかでも扱っていますが、請負契約では成果物の範囲を明確にする責任の重心が開発側に寄りやすく、準委任契約ではむしろ発注側が主体的に整理する場面が増える傾向があります。契約前にどちらの契約形態を想定しているかを確認しておくと、要件定義の役割分担でも認識がずれにくくなります。

「丸投げ」も「丸受け」もうまくいかない理由

現場でよく見られる失敗パターンを2つ挙げます。

失敗パターン1：発注側が丸投げする 「プロなんだからいい感じに作ってほしい」という姿勢で臨むと、開発側は業務の細部が分からないまま推測で仕様を固めることになります。後になって「実際の業務はそうじゃない」という手戻りが発生しやすく、この手戻りが二重コストにつながる典型的な流れです。この構造は要件定義が甘いと二重コストになる仕組みでも詳しく触れています。

失敗パターン2：開発側が丸受けする 逆に、開発側が「言われた通りに作ります」というスタンスに徹しすぎると、発注側の担当者が自分たちの業務を言語化しきれず、曖昧な指示のまま仕様が固まってしまいます。曖昧な指示は曖昧な成果物しか生みません。表面上は「要件定義書」という体裁の書類ができていても、中身がすかすかで、後工程で穴が次々に見つかることになります。

どちらのパターンにも共通するのは、業務知識と技術知識のすり合わせという本来の作業が省略されてしまっている点です。要件定義は「どちらかが書いて、どちらかが確認する」という一方通行の作業ではなく、両者の知識を突き合わせる共同作業だと捉え直すと、責任の押し付け合いが起きにくくなります。

揉めないための役割分担の考え方

現実的な落としどころとしては、発注側と開発側それぞれが担う範囲をあらかじめ言葉にしておくことが挙げられます。

• 発注側が主に担うもの：現状の業務フロー、困っている点、優先順位、予算感といった「何を実現したいか」の材料
• 開発側が主に担うもの：業務フローをシステムでどう実現するか、実現方法ごとの技術的な制約や工数感といった「どう実現するか」の翻訳作業
• 両者ですり合わせるもの：完成後の業務フローの姿、想定していない例外ケースへの対応方針

この整理を最初の打ち合わせの段階で口に出しておくだけでも、後々の「そちらが書くはずだった」という揉め事はかなり減ります。契約書に細かく書き込む前に、口頭でも役割の認識を合わせておくことが実務上のポイントです。

また、発注側が業務フローを箇条書きレベルでも書き出しておくと、開発側の翻訳作業がぐっと進めやすくなります。完璧な文書である必要はなく、叩き台として出す、という感覚で十分です。

まとめ

• 要件定義書の作成責任が揉めやすいのは、業務知識と技術知識のどちらか一方だけでは完成しない工程だからという構造がある
• 発注側の「丸投げ」も開発側の「丸受け」も、すり合わせの作業を省略してしまう点で同じ失敗につながりやすい
• 発注側と開発側、それぞれが担う範囲をあらかじめ言葉にしておくことで、後工程での押し付け合いを避けやすくなる