2014年11月4日

【失敗しないシステム導入】

～スコープを定義するコツは？～

システム導入が失敗する原因のひとつとして、ベンダに依頼する対象範囲、つまり、スコープが明確になっていないことがあげられます。この場合のスコープとは、開発工程と開発対象業務のことを指します。スコープが明確になっていないと、発注側のユーザが考えるスコープと受注側のベンダが考えるスコープがずれ、空白部分が生じます。

ユーザ、ベンダのどちらも担当しないポテンヒット的なタスクが生じたり、ユーザが開発対象と考えていた業務が対象外になっていたりとシステムの品質、コスト、納期に多大な悪影響を及ぼします。言った言わないの議論になるとドロ沼化必至です。

開発工程については、例えば、要件定義、基本設計、詳細設計、製造など、それぞれの工程において、ベンダに何を依頼するのかが明確になっている必要があります。請負なのか、準委任なのかの契約形態はもちろん、それぞれの工程における各タスクについて、ベンダ、ユーザの役割分担が明確になっていなければなりません。

特に不明確になりやすいのは、移行工程です。要件定義、設計、製造といった主要な一連の開発工程から外れていて、ユーザ、ベンダとも軽視しがちであること、また、移行内容によってユーザ、ベンダの役割分担が大きく変わり定型化しづらいことが原因と考えます。

業務機能については、例えば、購買、生産、生産管理、販売管理など、どこを開発対象とするのかが明確になっている必要があります。WBS（Work Breakdown Structure 作業分解構成図）のような階層形式で漏れなく、重複なく整理し、定義します。

開発工程、開発対象業務とも、教科書的に言えば、RFPの段階でできるだけ詳細にスコープを提示し、それに基づいてベンダに提案してもらい、プロジェクトが始まってからも常にスコープを可視化、共有しマネジメントしていく、ということになりますが、現実問題としてはRFPの段階で詳細にスコープを提示するのは、時間的に困難な場合が多いです。

さらに難しくしているのは用語の問題です。多くの場合、言語でスコープを定義することになりますが、同じ用語でも会社、人によって、驚くほどその意味、対象範囲は異なります。例えば、売掛管理という用語でもそこに含まれる業務、対象範囲は会社、人によって異なります。これがスコープのずれを生む原因になります。

効率よくスコープを定義するひとつのコツとして、“対象外も明示する”という方法があります。対象範囲だけを定義しようとすると、限界があります。対象外を明示することで対象範囲がより明確になります。また、用語の理解のずれに気づくやすくなります。

開発工程であれば、ベンダに依頼する工程、タスクだけではなく、自社（ユーザ）で担当する工程、タスクも明示する。業務機能であれば、WBSのような一覧表に対象外の業務も記載し、対象範囲を明示するといった具合です。このようにすることでベンダ、ユーザ双方の思い違いによるスコープのずれを防ぐことができます。

2014年11月