全5094文字
PR

 皆さんはスコープ(範囲)をどう決めていますか。システムを開発する場合、あるスコープの中で業務プロセスやデータベース、アプリケーションを設計し、進めていきます。エンタープライズレベルのシステム開発では極めて重要なポイントにもかかわらずスコープは何となく決められてしまいがちです。

 「画面をこうしてほしい」、「この仕事はこういう流れでやるもの」といったように、ユーザーインターフェースや業務プロセスにはあれこれ注文が付き、関係者が相応の議論をするものです。ところが、もっと大事なスコープについては「制度改定があったし更改時期も来たから再構築しよう」「来期に始める新事業のための販売管理システムをつくってほしい」といったように、あらかじめ大体決まっており、突っ込んだ議論をしないことが案外多いのです。

 残念なことに情報システム開発のトラブルは依然として無くなりません。失敗の原因は要件仕様、開発者のスキル、採用した技術など様々なところにありますが、私はそもそものスコープのとり方に問題がある場合が多いとにらんでいます。

 スコープがおかしいと拡張性に乏しいシステムが作られます。2次開発プロジェクトを始めると、1次開発プロジェクトにおける分析不足が原因で、多くの変更が現行システムに発生してしまいます。現行システムとデータが密接に関係する別システムが登場した途端、予期していなかったデータ項目が必要になり、現行システムのデータモデルまで変更を強いられるからです。ひどい場合、現行システムまで開発し直すことになりかねません。

 こうしたトラブルを避けるために本稿では2点、提案します。第1はスコープを決める際、「1つ外側のスコープへの拡張」を常に意識しておくこと。第2は、複数のスコープに分けて開発を進めざるを得ない場合、できあがってくる複数のシステムを統合する仕組みを用意することです。

デザインスコープはプロジェクトスコープより大きい

 スコーピング(スコープを決めること)の難度はますます上がっています。近年になってシステムのスコープは広がる一方だからです。LOB(Line of Business、事業部門)から全社(1法人)へ、さらに国内のグループ企業群、最終的にグローバルのグループ企業群へとスコープが広がってきました。

図 拡大するシステムのスコープ
図 拡大するシステムのスコープ
[画像のクリックで拡大表示]