« 41 会社と社員の変貌 | トップページ | 43 情報システムの設計/開発と必要なスキル »

2006.03.28

42 情報システムのトラブル

システム開発の規模にかかわらず,開発ソフトに関する発注者(顧客)と受注者(プロバイダー)の間でのトラブルやアプリケーションシステムのトラブルが絶えない.ハードウエアーの品質やトラブル対策は発達してきたが,ソフトは依然として’雨降って地固まる'的性格を持ったままである.最近の銀行や証券等の社会的巨大システムのトラブルを契機に改めてその対策が議論され始めた.

トラブルは大きく分けて開発段階のトラブル(機能,開発規模,開発費用,納期、引渡し方法etc)と運用段階のトラブル(誤動作,機能不足,性能,資源不足,操作性etc)に分かれる

開発段階のトラブル

システム開発の契約は建築物の契約のように図面があって契約する事は皆無である.システム開発の仕事は荒削りの段階から概要設計,詳細設計,プログラム開発,テスト,移行仕様,移行システム等具現化していく事であるからである.

従って開発途上で当初計画から乖離していく事は当たり前であり,ここに調整が常に発生するのである.ただし開発費用の増大等の調整はベンダー側の実力不足,過小見積,当初機能に含まれるとの主張を理由に顧客側は納得しない事が多い.

その背景は,,曖昧な契約でも,ベンダーが専門家として具現化してくれるとの期待が顧客側にあるからである.期待を込めてリスクも含めて発注する.そしてシステムが安定稼動後,開発費を払う考えである.

この事から

①リスク負担が受注競争のポイントになりやすい
②開発工程の重要性を低下させる要因になる
③設計確認,システム確認,テスト評価など顧客責任の意識が低下する
④顧客は安定稼動まで金を払わない

等の顧客の盲目的丸投げが,トラブルを必要以上に増加させていると思う.顧客もベンダーも結果的には甚大なトラブルを背負うことになる.

開発契約書においても何を契約したのか不明で金額だけが存在している場合が多い.いわゆる一式いくら,一山いくらの契約(実際は発注書)である.

この実態を見ると,単に契約段階でシステム内容を明確化しようとの論調は顧客側主体で設計開発部隊を持ち,設計図を作り,足らない所を発注するケースしかない.この考えでシステム開発をしている企業はあるが,ほとんどは概要を示す程度の取引である.

典型的な分野は公共分野,医療分野である.公共,医療分野は専門組織を持たず,フルターンキービジネスになっている.情報システムをまだ道具を買う意識にとどまっているのである.機能を表す単語を並べたRFPで競争入札している現実では契約段階での明確化はまず不可能である.

曖昧さのリスクはすべてベンダーの責任として応札しているとの事から過去にどれだけベンダーの負担をしてきたか計りしれない.残念ながら,これからもこの問題は続く.官が率先してシステム開発の特性を踏まえた入札や契約のあり方を考えるべきである.

そこで,ソフト開発の特性を踏まえた契約方法であるが,業務仕様や性能が明確化されたシステムは一括契約書で,明確化されていないシステムは工程別分割契約書で契約することが自然である.曖昧のままで丸投げは一見顧客側にノーリスクに写るが青天井の費用・リスクはベンダーは受け入れないはずであるし,受け入れたとしても,トラブルは顧客自身にも甚大な被害が出るのである.

やむなく,工程別分割契約が出来ない曖昧なままでの一括契約をする場合,せめて予想されるリスクの対応方法を決めておく事が大事である.解約の条文,業務仕様作成・確認の条文,費用変動時の条文,プロジェクト推進やシステム確認・検収に関する条文,等が必要である.

特に業務仕様を誰が作り,誰が確認するのかを契約で明らかにする事である.金額やリスクに大きく関係するからである.このような契約内容で双方の共通認識をし,プロジェクトを進めるべきなのである.

この約束があって契約金額が決まるのである.この契約書によって双方が活動計画を共有しプロジェクトが開始する.そんな契約を進めたいものである.契約書を見ない,見ても行動につながらない契約書・風土は早くやめなければならない.トラブルが起こってからでは遅いのである.

尚,契約は玉虫色で一般的にし,契約後,覚書あるいは会議録で仕事の進め方や問題対応の取り決めを行なう事があるが,金額が無関係になったり,受注後に大事な取り決めを行なう事は順番が逆である.本来,契約で一本化すべきである.従って,ベンダー側はプロジェクトごとに契約内容を決めることになる.これで生きた契約書になるのである.顧客側,ベンダー側ともに,契約ベースの文化に移らなければならない.

運用段階のトラブル

次に重要な事はシステム稼働中に起こる甚大なトラブル,被害発生の問題である.業務仕様やプログラム仕様あるいはプログラムそのものの不備,漏れ,ミス及び操作などで発生するいわゆるソフトの品質問題である.

これをどう防ぐか,すぐ影響が出る場合,長期に誤動作している場合があるが,判明したときの対応をどのようにするか,被害の賠償問題をどうするか,顧客の責任での処置になるが,きわめて難しい問題である.

この問題は契約における受託者の瑕疵責任,無償修正作業で処置できるものではない.社会や顧客へのダメージ,膨大な逸失利益や費用の発生など,企業の存亡にかかる事態になる可能性を持っているのである.

このトラブル防止には当然の事ながらリスク要因を少なくする機能設計,わかりやすい構造的設計,システムのセルフチェック機能の設定,仕様とプログラムの徹底的なチェック,テスト等が必要となる.もちろん実績のあるパッケージの活用や出来るだけ作らない発想の設計も必要である.

巨大なシステムのテスト・チェックは空前の作業となる.設計・開発作業と並行した体制と準備が必要になる.この費用は設計・開発とほぼ同等のコスト・期間が必要である.重点思考とデッドラインの確保の認識が必要となるが,リスク認識が顧客側に不足している事が多い.前述の通り,ベンダーに開発を一括発注している感覚があるからである.

特に安全の費用対効果で言えば,冗長性や機能の低下があっても,仕様の簡素化,テストのし易い設計を考える事が必要である.日本人は欧米人に比べ複雑にする傾向がある.例外処理も多い.コンセプトや目的意識が弱く,割り切りが出来ない性格が災いしていると思う.又,同一業務を複数部隊で開発し,完成度の高いシステムを選択する方法もある.余分な開発費がかかるが,出来の悪いシステムを深追いするより安全である.

現在はソフト化の時代である.企業情報システムだけではなく,あらゆる機器にソフトが入る.複雑で巨大なソフトも機器に組み込まれる.当然リスクも大きくなる.ソフト化の利便性の付加価値はほとんど安全対策に向かうはずである.しかし,いつの日か,ソフトの品質確保の限界がソフト化の限界になるかもしれない.

.

|

« 41 会社と社員の変貌 | トップページ | 43 情報システムの設計/開発と必要なスキル »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/134518/9297693

この記事へのトラックバック一覧です: 42 情報システムのトラブル:

« 41 会社と社員の変貌 | トップページ | 43 情報システムの設計/開発と必要なスキル »