大手企業のシステム開発プロジェクトにおいて、外部ベンダーとの協業が必須な中で、多くの現場から「発注したものと違う」「リリース直前で要件漏れが発覚し炎上した」といった声はよく聞こえてきます。
そこで株式会社Sun Asteriskでは、システム開発における失敗の本質的な原因を紐解き、プロジェクトを成功へ導くための「コミュニケーションツール」としての要求仕様書の書き方について解説するウェビナーを開催しました。
目次
登壇者プロフィール
株式会社Sun Asterisk Tech Specialist | Unit Manager
鈴木 義
2009年よりSIerにて要件定義から運用保守まで幅広く従事。2018年からは某SIer上場企業にてプロジェクトマネージャーとして複数案件をこなした。その後、自社サービスの開発マネージャー兼テックリードとして開発に携わった。並行して社内のスクラム開発導入推進に携わり、自らも認定スクラムマスター(CSM)を取得し、いくつかのプロジェクトにてスクラムマスターやプロダクトオーナー、スクラム開発における開発者として従事。2021年Sun*に入社し、複数案件にエンジニア、プロジェクトマネージャーとして参画している。
システム開発の要求仕様書、テンプレートをこちらからダウンロード！
なぜ今「要求仕様書」なのか
昨今の開発現場では、複数のプロジェクトが同時進行し、そのほとんどで外部ベンダーとの協業が発生しています。そうした中で、現場からは以下のような「悲鳴」が聞こえてきます。
- 発注したはずのものと、違うものが出来上がった
- 一応リリースはしたが、現場ではほとんど使われていない
- 終盤になって「要件に入っていません」と言われ、追加費用で炎上した
データで見るプロジェクトの実態
ITプロジェクトの成功率に関する調査（Standish GroupのCHAOS Report 2020）によると、予算・納期・期待成果のすべてを達成して「成功」と言えるプロジェクトは約31%に留まります。
- 成功（31%）：予算内、納期内、期待された成果を達成
- 課題あり（50%）：完成はしたものの、予算超過、納期遅延、要件未達などの問題を抱える
- 失敗（19%）：途中でキャンセルされる、あるいは大幅なスコープ縮小などで目的を達成できない
つまり、何らかの問題を抱えているプロジェクトが約7割を占めているのが実情です。この背景には、長年指摘され続けている「不十分・曖昧・誤った要求」「頻繁でコントロールされていない要求変更」「ユーザー・ステークホルダー関与の不足」という3つの要因が大きく関わっています。
システム開発の相見積もりを取る前に知っておきたい、見方と判断ポイント
システム開発失敗の本質的な原因
多くのプロジェクトが失敗する背景には、共通する「失敗の4パターン」と、それを引き起こす根本的なメカニズムが存在します。
現場で起こる「よくある失敗」4パターン
①発注意図と違うものが出来上がる
原因：解釈のズレ。専門用語が飛び交う会議での曖昧な合意や、ベンダーSEによる「妥当そうな解釈」での進行などが要因です。
②追加開発で予算超過
原因：暗黙の期待。「この機能があるなら、この確認ステップも当然あるはず」といった思い込みや、技術的な前提条件の曖昧さが、後半での雪だるま式な仕様追加を招きます。
③使われないシステムの悲劇
原因：現場理解の不足。発注側のヒアリング不足により、繁忙期の運用やイレギュラー処理など「現場ならではの事情」が仕様に落ちていないケースです。
④セキュリティ・性能不足でのトラブル
原因：非機能要件の曖昧さ。リリース直後のアクセス集中によるダウンや、監査対応での不備など、上流工程での検討不足が後から噴出します。
根本メカニズム：認識ギャップと意思決定の遅さ
これらの失敗は、「要求が悪い」だけで起きるわけではありません。
「認識ギャップ」×「意思決定の遅さ（Decision Latency）」 が負の相乗効果を生んでいます。
要求が不明確なまま、ユーザーの関与が限定され、重要な決定が先送りされた状態でプロジェクトだけが進んでいく――この構造こそが、失敗を引き起こす根本原因です。
要求仕様書は「契約書」ではなく「コミュニケーションツール」
この状況を打開するためには、要求仕様書の捉え方を変える必要があります。要求仕様書は、単なる発注のための契約資料ではありません。
本来、要求仕様書が果たすべき役割は、「発注者とベンダーの間にある見えない壁を可視化し、最初のボタンの掛け違いを防ぐための共通ホワイトボード」 です。
関連ドキュメントとの役割の違い
プロジェクトを円滑に進めるためには、各ドキュメントの目的と「誰に向けたものか」を整理しておくことが重要です。
要求仕様書は、RFPのインプットにもなり、ベンダー選定後も「ビジネス側の意図」を確認する基準点（Single Source of Truth）として機能させるべきです。
伝わる仕様書を書くための5つの秘訣
ベンダーに意図が正しく伝わり、本質的な提案を引き出すための仕様書作成には、5つの重要なポイントがあります。
1. 「What」の前に「Why」を書く
単に「顧客管理機能が欲しい」といった機能名（What）だけを記載すると、ベンダーは言われた通りのものしか作れず、本質的な解決に至らないケースがあります。
OK例：「営業の属人化を防ぐために、過去の全対応履歴を誰でも検索・閲覧できる機能が必要」
このように背景や目的（Why）を記載することで、ベンダー側からもより良いUI/UXや実現手段の提案が引き出せるようになります。実務的には、以下の4点を冒頭に書くことが推奨されます。
- 背景（現状の課題・制約）
- 目的（Why、可能ならKPI/KGI）
- 成功条件（どうなれば成功と言えるか）
- 非目的（今回はあえて扱わないこと）
2. 「絵」で伝える
テキスト中心の仕様書は誤読の元です。完璧なUML図である必要はありません。ホワイトボードのラフスケッチレベルでも良いので、以下の図を用意することが不可欠です。
- 業務フロー図（人・情報・システムの流れが見えるもの）
- 簡単な画面遷移図
- ユースケース図
図があることで全員が同じキャンバスを見ながら議論できるようになり、空中戦を防ぐことができます。清書は後からベンダーに任せれば良いため、まずは発注側の頭の中を外に出すことを優先しましょう。
3. 「やらないこと」を明確にする
仕様書は「やることリスト」になりがちですが、スコープの境界を明確にするために**「やらないことリスト（Non-Goals）」** を作ることが成功の鍵を握ります。
- 「今回はスマホ対応はしない（PCのみ）」
- 「会計連携はCSVまで（自動連携しない）」
- 「過去のデータ移行はマスタのみ」
このように期待値をコントロールすることで、「当然やってくれると思っていた」という暗黙の期待によるトラブルや追加費用を防げます。
4. 「誰が・どう使うか」を物語（ストーリー）で書く
単に「CSV出力機能」と書くのではなく、ユーザーの行動シナリオ（物語） として記述します。
- アクター：経理担当者が
- 目的：月末に弥生会計に取り込むために
- シナリオ：画面を開き、対象月を指定してボタンを押すと、取り込み可能な形式でCSVがダウンロードされる
ユースケースには、正常系のシナリオだけでなく、「データがない場合」などの例外シナリオや、完了とみなす「受入条件」も記載することで、利用シーンが明確になります。
5. 非機能要件は「要望レベル」で言葉にする
性能、セキュリティ、保守性といった非機能要件は、専門知識がないと書けないと思われがちです。しかし、発注者側は専門用語を使わず、「生の不安」を要望として伝えるだけで十分です。
- 「ピーク時に今の10倍のアクセスが来ても落ちないでほしい」
- 「復旧まで半日以上かかるとビジネス的に致命的」
こうした要望を言葉にしておけば、ベンダー側がそれを技術要件（レスポンスタイム〇秒以内、冗長化構成など）に翻訳してくれます。重要なのは、曖昧なままにせず、要望を伝えておくことです。
まとめ
システム開発の失敗を避けるためには、上流工程での「認識のギャップ」をいかに埋めるかが重要です。要求仕様書を「共通の対話の土台」として位置づけ、ビジネスサイド、現場ユーザー、システム部門、そしてベンダーを早期に巻き込み、合意を形成していくプロセスこそが、プロジェクト成功への最短ルートとなります。
Sun*では、1,500人規模のエンジニア組織であらゆるフェーズに伴走しながら支援が可能です。システム開発のご用命がありましたら、ぜひご相談ください。