開発ベンダーとの「言った言わない」を防ぐ要件定義術

なぜシステム開発で「言った言わない」が起きるのか

システム開発プロジェクトにおいて、発注側と開発ベンダーの間で「そんな話は聞いていない」「最初からそう伝えていた」という認識の食い違いが発生することは珍しくありません。本記事では、こうした「言った言わない」問題を防ぐための要件定義の進め方を解説します。情報処理推進機構（IPA）の調査によれば、システム開発プロジェクトの失敗原因の約7割が要件定義フェーズに起因するとされています。要件定義書の必須項目チェックリストと合意形成の具体的手法を押さえることで、プロジェクトの成功確率を大きく高めることができます。

「言った言わない」問題が発生する背景には、いくつかの構造的な要因があります。まず、発注側と開発ベンダーでは、使用する言葉の定義が異なることが多いという点です。たとえば「顧客管理」という言葉ひとつとっても、発注側は「名刺情報の管理」を想定しているのに対し、開発ベンダーは「購買履歴を含む顧客データベース」をイメージしているということがあります。こうした認識のズレは、口頭でのやり取りだけでは解消されにくく、後になって「そういう意味ではなかった」というトラブルに発展します。

また、プロジェクト開始時には決まっていない事項が多く、曖昧なまま進めてしまうケースも少なくありません。「詳細は後で詰めましょう」という合意のもと進めた結果、後から「最初から決まっていたはず」という主張が出てくることがあります。さらに、担当者が途中で変わることで、過去の経緯が正確に引き継がれないという問題も発生しがちです。

要件定義書に必ず盛り込むべき項目

認識齟齬を防ぐためには、要件定義書に必要な項目を漏れなく記載し、双方で合意することが重要です。要件定義書に盛り込むべき必須項目は以下のとおりです。

まず「プロジェクトの目的と背景」を明記します。なぜこのシステムを開発するのか、どのような経営課題を解決したいのかを記載することで、判断に迷ったときの拠り所となります。目的が曖昧なまま進めると、機能の優先順位付けで意見が分かれたときに収拾がつかなくなります。

次に「システムの対象範囲」を明確にします。今回の開発で対応する業務範囲、対応しない業務範囲を具体的に列挙します。「対象外」を明示することが特に重要で、後から「これも含まれていると思っていた」というトラブルを防ぎます。

「機能要件」については、各機能の入力・処理・出力を具体的に記述します。「顧客情報を登録できる」という曖昧な記述ではなく、「顧客の氏名・電話番号・メールアドレス・住所を入力し、データベースに保存する。登録完了時に確認メールを送信する」というレベルまで詳細化します。

「非機能要件」も見落としがちですが重要です。性能要件として同時接続ユーザー数やレスポンス時間、可用性要件として稼働率や障害復旧時間、セキュリティ要件として認証方式やデータ暗号化の方針などを明記します。非機能要件が曖昧なまま開発を進めると、本番稼働後に「想定より遅い」「セキュリティが不十分」といった問題が発覚し、追加費用が発生することになります。

「前提条件と制約条件」も明文化が必要です。既存システムとの連携方式、使用するインフラ環境、開発言語やフレームワークの指定など、開発を進めるうえでの前提となる事項を記載します。

「用語定義」のセクションを設けることも効果的です。プロジェクト内で使用する専門用語や業務用語の定義を統一することで、コミュニケーションの齟齬を防ぎます。

合意形成を確実にするドキュメント運用のコツ

要件定義書を作成するだけでは不十分で、その内容について双方が確実に合意していることを担保する仕組みが必要です。

ドキュメントのバージョン管理を徹底することが基本です。要件定義書は開発の進行に伴って更新されることがあります。その際、どの時点でどのような変更があったのかを追跡できるよう、バージョン番号と更新日、更新内容、更新者を記録します。最新版がどれかわからない状態では、古い情報をもとに作業が進んでしまうリスクがあります。

合意のエビデンスを残すことも重要です。要件定義書の確定時には、発注側と開発ベンダーの責任者が署名または押印する運用をお勧めします。形式的に感じられるかもしれませんが、「この内容で合意した」という事実を明確にすることで、後からの「聞いていない」という主張を防ぐことができます。メールでの承認記録を残す場合は、添付ファイルのファイル名とバージョンを本文に明記し、「本内容で承認します」という文言を含めるようにします。

変更管理プロセスを事前に定めておくことも欠かせません。開発途中で要件の追加や変更が発生することは避けられません。その際に「どのような手順で変更を申請し、承認を得るのか」「変更に伴う費用やスケジュールへの影響をどのように評価するのか」を事前に合意しておきます。変更管理プロセスが曖昧だと、口頭での依頼がいつの間にか正式な要件として扱われ、後から費用請求でトラブルになることがあります。

打ち合わせの議事録で認識を揃える

要件定義フェーズでは多くの打ち合わせが行われます。この打ち合わせの内容を正確に記録し、共有することが「言った言わない」防止に直結します。

議事録は打ち合わせ終了後、できれば当日中、遅くとも翌営業日までに作成・共有するのが理想です。時間が経つと記憶が曖昧になり、参加者間で認識のズレが生じやすくなります。議事録には「決定事項」「継続検討事項」「宿題事項（担当者と期限を明記）」を明確に分けて記載します。特に決定事項については、誰がどのような発言をして、どのような結論に至ったのかを具体的に書きます。

議事録を共有したら、参加者全員に内容確認を依頼し、認識の相違があれば速やかに指摘してもらいます。「異議がなければ承認とみなす」というルールを設け、一定期間（たとえば3営業日）を過ぎたら確定とする運用も有効です。この確認プロセスを経ることで、後から「そんなことは言っていない」という主張が出にくくなります。

要件定義書の必須項目チェックリスト

要件定義書を作成する際に確認すべき項目を整理しておきます。プロジェクトの目的と背景が明記されているか、システムの対象範囲と対象外が明確か、機能要件が入力・処理・出力のレベルで記述されているか、非機能要件（性能・可用性・セキュリティ）が具体的な数値で定義されているか、前提条件と制約条件が明文化されているか、用語定義が統一されているか、バージョン管理のルールが定められているか、合意の証跡を残す方法が決まっているか、変更管理プロセスが合意されているか、これらの項目をプロジェクト開始前に確認し、不足があれば補完してから開発フェーズに進むことが重要です。

今日からできる5つのアクション

御社でシステム開発プロジェクトを計画されている場合、あるいは現在進行中のプロジェクトで認識齟齬の兆候がある場合、以下のアクションを検討してください。

1つ目は、現在の要件定義書を本記事のチェックリストと照らし合わせて確認することです。不足している項目があれば、開発ベンダーと協議のうえ追記します。

2つ目は、用語集を作成することです。プロジェクト内で頻出する業務用語やシステム用語の定義を一覧化し、関係者全員で共有します。

3つ目は、議事録のテンプレートを整備することです。決定事項・継続検討事項・宿題事項を分けて記載する形式を標準化し、確認期限のルールを設けます。

4つ目は、変更管理プロセスを文書化することです。変更申請から承認までの手順、影響評価の方法、費用精算のルールを明確にし、双方で合意します。

5つ目は、定期的なレビュー会議を設定することです。週次または隔週で要件の認識を確認する場を設け、小さなズレを早期に発見・修正します。

まとめ

システム開発における「言った言わない」問題は、要件定義書の充実と合意形成プロセスの整備によって大幅に防ぐことができます。要件定義書には目的・範囲・機能要件・非機能要件・前提条件・用語定義を漏れなく記載し、バージョン管理と合意の証跡を確実に残すことが重要です。議事録の即時共有と確認プロセス、変更管理ルールの事前合意も欠かせません。これらの取り組みを通じて、発注側と開発ベンダーの信頼関係を構築し、プロジェクトを成功に導いてください。

GXOでは、180社以上のシステム開発支援実績をもとに、要件定義フェーズから伴走型でご支援しています。要件定義の進め方にお悩みの場合は、ぜひお気軽にご相談ください。

お問い合わせはこちら