このページは
2007
年
07
月
17
日
21時46分58秒
に更新したキャッシュ情報です。
検索キーワード＝ データ入力代行
優先キーワード＝ データ入力
[ 91] ＠IT情報マネジメント：納品されたシステムに対する効果的な検収方法 1/2
[引用サイト] http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/09/01.html
業者側の作業が終了したら、納品されたシステムを検査・検収しなければならない。システムを検収する際のポイントとは？（→記事要約<Page2>へ）
業者側での統合試験が完了すると、いよいよ納品だ。納品後は、速やかに受け入れを実施し、検収しなければならない。単なる心配性から、だらだらと時間をかけるのはよろしくない。要件定義書と要求仕様書に従って、要求どおりにシステムが作られているかどうかを淡々とチェックする。検査中に、プログラムの不具合や要求事項の漏れなどに気が付くかもしれないが、後でまとめて対策を考えることとし、その場で是正作業に入ったり、仕様変更を要求したりしないことだ。
まず検査すべきは、機能である。要件定義書や要求仕様書に記載されている要求機能が正しく実現されていることを一通り確認する。このとき、文書上の要求事項と実際の機能の追跡性（トレーサビリティ）が確保されていれば、漏れなく、素早く検査を実施することができる。 要求どおりに機能が実現されているかをチェックするのは当然だが、要求していないことが実現されていないかも忘れずにチェックしたい。要求していないような機能が盛り込まれていることで、ムダなコンピュータ資源を浪費することもあるので、サービスとばかりに喜んでもいられない。まして、業務上で制約となるような不必要なチェックや制限は無用の長物だ。 また、通常の処理機能だけでなく、例外処理やエラー処理についても漏れなく検査したい。こういった機能は、実際の業務でも発生する頻度が低いため、検査で発見しないと実用開始後に数カ月、あるいは数年後に突然、システム障害を発生することもある。 一通り機能をチェックしたら、不具合事項に優先順位を付けて、いつまでに是正するかを業者と調整し、どのようなレベルで検収するかを確認する。基本的には、不具合はすべて是正してから検収とするが、ささいな不具合にこだわって、スケジュールを遅らせるよりは、ある程度妥協して検収した方が得策なこともある。 自社の業務システムは、あくまで業務の道具（手段）であり、目的は使ってナンボ（もうけること）である。業務上の利益貢献に対して影響の小さいような不具合は、後から是正しても遅くはない。最小の投資で最大の効果を生むシステム構築では、このあたりを判断して割り切ることも肝要である。
応答時間や処理時間は、要求仕様書に明確に記述してあれば、検査自体は、それほど難しいものではない。想定した利用状況において、定められた目標値をクリアすれば可、目標値に達しなければ不可である。問題は、目標値をクリアしなかった場合に、どのように対処するかということだ。目標値に達するように是正を求めるのは簡単だが、そのために払う時間的損失などの代償は、決して安くはない。 なぜなら、性能を向上させるための労力は、機能的な不具合を是正するより、はるかに大きくなるケースが多い。これは、取り得る対策に正解がなく、試行錯誤的にならざるを得ない性格があるからだ。 従って、性能を向上させる作業については、これを別途契約して実施するという業者もいるくらいである。追加の費用を支払ってまで目標値をクリアすることに、どれほどの意味があるかよく考える必要がある。例えば、オンライン・システムに対する要求仕様での目標値が5秒であったとしよう。ところが、実際に納品されたシステムでは6秒であった場合、追加投資をして1秒を短縮したところで、どれほど利益貢献するのだろうか？ 確かに、性能不足のシステムを納品する業者は存在する。しかし、その非を認めさせるには、かなりの専門知識と経験を要する。そのような人材が社内に存在しなければ、外から専門家を招いて調査に当たらせることになる。時間とお金が余っているなら、性能向上に力を注ぐのも良いが、そんな余裕がないか、最小の投資で最大の効果を生むシステムを構築するのであれば、実際の業務上での影響を考慮した割り切りが必要である。業務システムは、F-1マシンではないということだ。
情報マネージャのための「今日のひと言」 - 2007/7/17『透脱（とうだつ）』 仏道をならふといふは、自己をならふなり。自己をならふといふは、自己をわするるなり……>>続きはクリック
＠IT情報マネジメント トップ｜IT戦略 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ
|
戻る
