«

»

1月 04

014やってはいけないシステム要件定義の禁じ手とは

システム要件定義は、業務の要件をシステムの作り手に伝える重要な情報である。曖昧な要件定義に代表される、やってしまうと後から面倒なことになる「やってはいけないこと」と、そのデメリットをご紹介する。

□ 大ざっぱな要件提示でも問題ない場合
情報システムのユーザー企業の担当者が、ITベンダーのエンジニアに口頭で要件を伝え、後日、エンジニアがまとめた仕様を確認した上で発注し、プログラム開発に着手する。継続的な取引関係にある場合によく見られる光景である。このような場合、エンジニアはユーザー企業の業務やシステムの仕様を熟知しているため、ことは上手く運ぶ。しかし、全く新しい業務であったり、これまで該当業務で取引がないITベンダーが相手であったりした場合は事情が大きく異なるので注意が必要だ。

□ 曖昧なシステム要件定義のケース
例えば、販売管理システムの再構築のために、RFP(提案依頼書)を作成して、提案と見積りを依頼することを考えてみよう。RFPを発行する動機の多くは、複数のITベンダーを競合させて少しでも安くて良い提案をもらうことである。
この企業では、余りにも古くて、保守費が高く、使いづらい現行のシステムを、もう少しマシなものにしたいという程度で考えていたとする。在庫管理がしっかりしていて、見積り書出力もしやすく、請求書作成の手間が少なくて済むくらいのシステムを想定している。その他の機能については社内でも十分検討はしていないが、安くて良さそうな機能がついているならそれに越したことはない、という曖昧な感覚で要件をまとめ、RFPを発行する。

□ 曖昧なシステム要件定義で発生する問題
この場合、次のような問題に発展する可能性がある。
(1)法外な見積り金額を提示される
例えば、「顧客管理機能を保有すること」のような書き方では、ITベンダーとしては、ポイントカードまで含むかどうかなどが分らないため、とりあえず考えられる限りの範囲で見積もらざるを得ない。どうしても高めの見積りになる。

(2)デラックス過ぎるシステム構成を提案される
これも「法外な見積り」につながるが、例えば、「障害の少ない信頼性の高いシステムとする」という要件ならば、サーバーやネットワークの二重化を提案されるかもしれない。

(3)過小な仕様と想定されてしまう
(1)と逆な意味で、小さく考え勝ちなITベンダーは、ユーザー企業想定より相当少ない要件と受取ることもある。あとから機能がないことを指摘しても「想定してなかった」ということになり、費用追加請求が発生する可能性がある。

(4)基本設計段階でもめる
システムの仕様を具体的に固める基本設計で、双方の想定する前提が異なり、これも仕様変更、仕様追加による費用増加の原因となる。

(5)提案参加社数が少ない、もしくは出ない可能性がある
余りにも曖昧な要件定義では、ITベンダーとしても上記のようなトラブルが将来あると考え、提案に応じてくれないことも考えられる。

□ 極端な結果になることは実際には少ないがデメリットはやはり多い
まともなITベンダーであれば、受け取ったRFPが余りにもひどければ質問するなどして極力正常な、顧客が受入れられる提案を作ろうとするのは当然だが、それにも限界はある。ひどい場合には、社内でロクに検討もされていない事項なのに「取りあえず見積りだけはしてもらいたい」、というようなことで提案依頼範囲に入れてしまうこともある。
このようなユーザー企業が、どの機能が必要で、どれが不要かを真剣になって考えるのは見積書を受け取ってからである。真剣な見直し検討の後、要件のまとめ直し、再見積りということになり、大切な時間をロスするだけでなく、これから長年つきあっていくITベンダーからの信用をも落としてしまいかねないデメリットが懸念される。

□ システム要件定義での禁じ手
以上で、曖昧な状態で提案依頼、見積り依頼をするのは避けるべきというのは理解いただけたと思う。以下に上記のケースも含めたシステム要件定義では避けるべき禁じ手を挙げておこう。
▼曖昧なシステム要件定義
▼技術的なことがよく分らないのに信頼性などの技術的な部分にかかわる要件を強く提示すること
-上記(2)のことだが、これについては当サイト別記事「システム要件定義のシステム的部分のまとめ方」で、対応方法を記載しているので参照されたい。
▼業務の要件が社内で合意できていないシステム要件定義
-曖昧の元になる上、あとからひっくり返ることもある
▼社内用語がふんだんに使われた要件定義書
-社内独特の用語はITベンダーにとっては外国語である。標準語に変えるか、辞書(用語集)をつける必要がある。
(2012.3.9 執筆:山田一彦)