なぜクライアントの要望をそのまま受け入れると失敗するのか

要件定義についてこのようなお悩みはありませんか？

「要件定義の成果物の内容の目次は？」
「要件定義の成果物を正しく作成するコツは？」
「なぜクライアントの要望通りの要件定義は失敗するのか？」

本記事では、要件定義について成果物の内容やクライアントの要望通りだと失敗する理由について解説していきます。

そもそも要件定義とは？
要件定義の成果物の内容
要件定義の成果物を正しく仕上げるためのコツ
クライアントの要望を受け入れたシステムが失敗する理由
まとめ

そもそも要件定義とは？

要件定義とは、要求定義にてヒアリングした顧客の課題・理想の状態・システム機能などの内容をもとにしてRFPに落とし込み、ベンダを選定することです。

要件定義の大きな目的は、クライアントの要求をどのようなシステムで実現していくかの具体化をした後に要件定義書に文書でまとめることによって発注側と受注側の間にある認識のズレを無くし、円滑にシステム開発の業務を遂行するために必要になります。

要件定義の成果物の内容

要件定義の成果物では、システムの設計・実装に必要な取り決めを記載しますが、要件定義の目次は下記のような内容が一般的になります。

システムの目的、方針
解決すべき課題
課題を解決するための仕組み
システム要件
実行計画

それぞれの目次の内容について詳しく解説していきます。

1. システムの目的、方針

「システムの目的、方針」の目次では、システム化の背景と目的、成果、制約条件、スコープ、ロードマップについて記載します。

2. 解決すべき課題

「解決すべき課題」の目次では、システムにおける現状課題について記載します。

3. 課題を解決する仕組み

「課題を解決する仕組み」の目次では、課題解決するための仕組み、業務、システム機能について記載します。

4. システム要件

「システム要件」の目次では、新しい業務の仕組みで必要なシステムの機能、機能要件と非機能要件について記載します。

5. 実行計画

「実行計画」の目次では、ロードマップ、スケジュール、体制、スケジュール、リソース（人員、予算、装置）について記載します。

要件定義の成果物を正しく仕上げるためのコツ

要件定義の成果物を正しく仕上げる方法は、要件定義の期間で上記で解説した要件定義の目次の各項目について、レビューを設けて品質をチェックすることです。

要件定義書の内容をクライアントが理解しないまま進めてしまうと、テスト段階になってからはじめてクライアントが要件定義の内容を理解してしまうため、テスト段階以降の仕様変更が多発し、大幅に遅延するというケースが後を絶ちません。

このようなトラブルを防ぐためには、要件定義時期において要件定義書を開発会社が作成し、成果物として納品した後に、クライアントチームメンバー全員で読み合わせてレビューすることが重要です。

要件定義書のレビューの方法としては、まず机上で書類をレビューしてエクセルなどで質問管理表を作成して要件定義書に対する質問や訂正要望を書き込み、質問管理表にまとめられた内容をシステム開発者側が回答し、要件定義書を修正します。

この作業を繰り返しおこないすべてのレビューと修正を完了させることで、はじめて納品や開発会社に請求できることができるのです。

また、要件定義段階でレビューを実施することでスケジュールの後工程での手戻りが少なく、プロジェクトが成功する確率が高まるというメリットもあります。

クライアントの要望を受け入れたシステムが失敗する理由

要件定義ではプロのITの目線で「なぜ」という観点で要望を検証する必要がありますが、クライアントの要望をそのまま受け入れてしまうと素人が考えたアイデアをもとに設計することになるため辻褄が合わない・保守ができないシステムになってしまうため、クライアントの要望を受け入れたシステムは使い物にならず失敗してしまうケースが多発しているのです。

しかし、クライアントの要望を無視することはできないため、ヒアリングにおいてクライアント（顧客）の要望をそのままの意味で設計するのではなく、クライアントの「なぜその機能が欲しいのか」という要望の真の意図を組み取り、最適解の業務フローと最適解のシステム機能に落とし込む必要があります。

昨今のクライアント（顧客）側の担当者は、人材不足や売上減少に適応した業務改革のプレッシャーに追われており、グローバルや、DX/IT化の流行や必然に伴って業務の見直しが必要なシステム開発案件が急増していますが、要件定義において現行システムの課題と多大な今後の業務改善の要望をヒアリングし、解決できるシステムの開発を提案する能力が求められています。