システム運用段階の失敗と要因

システム運用段階の失敗と要因

 システムは構築して終わりではありません。稼働後にシステムを継続して運用・改善していく必要があります。特に新機能が多く搭載された新システムの場合は、実際の業務で使いながら一定水準に達するまで定期的に機能改善・強化のバージョンアップをしていくことになります。

 

システム運用時の失敗事象

 それでは、運用段階のシステムの失敗と要因について考えていきましょう。運用とは、システムを安定的に稼働・維持させることです。システムが突然止まってしまえば、システムを利用中の社内は大混乱します。

 

 短時間でシステムを復旧できれば、それほど大きな問題にはなりませんが、長い間メインシステムが復旧できない場合は業務への影響は甚大です。もし個人や外部取引先も利用するBtoCやBtoBの基幹システムが長期間の稼働不可能状態に陥ったら、企業の存続に関わる一大事です。ゆえに、通常のシステムメンテナンスによらない予期せぬシステムダウンは、絶対に避けなければなりません。

 

システム運用時の失敗要因

 システムダウンの主な原因は3つです。“ハード故障”、システム管理者やユーザーによる“操作ミス”、システム内に潜在していた“バグ”の発現です。

 

 “ハード故障”は物理的な障害です。サーバーやハブなどの製品の故障は致し方がないことです。ハード故障によるシステムダウンを防いで稼働を安定化させるためには、システム機器を「冗長構成」にすることです。システム設備の二重化です。

 

 仮に1台のサーバーに故障が発生しても、複数台のサーバー群で分散処理を行う冗長構成であれば、別サーバーで処理を継続することができるので、システムダウンを回避できます。二重化するのでコストはかかりますが、基盤となる重要なシステムならば検討したい対策です。また、冗長化とまでいかなくても万が一システムダウンした際に、短時間で復旧できるバックアップの仕組みを構築しておくことも有力な対策です。

 

 “操作ミス”は人為的なミスです。ユーザーの通常使用の状況下では、特に誤入力や誤操作は頻繁に起こります。運用マニュアルの整備や担当者への教育研修だけでは、これを完全に防ぐことはできません。ゆえに、あらかじめ想定できるシステムダウンを起こすような重大な操作に対しては、操作ミスを受け付けないシステム制御機能を実装すべきです。

 

 どちらかと言えば、操作ミスの問題は、ユーザーが想定外のイレギュラーな操作・処理をした場合やシステム管理者が滅多に行わない特別な操作をした場合にあります。これらすべてに対してシステム制御を行うことは現実的ではありません。

 

 次善の予防策としては、システム構築の要件定義・設計プロセスの段階で、細かな部分までシステム利用者の入力操作や実作業の流れを意識して丁寧にシステムを作り込むことです。例えば、ユーザビリティの面では順列的な入力項目の並び、文字フォントサイズの拡大、ラジオボタンの設置など、入力画面に誤入力軽減につながる工夫を施すことができます。

 

 一番やっかいなのが“バグ”の発現です。何をキッカケにして表出するかわかりません。これもゼロに近づけるためには、システム構築時のテストプロセスの品質・量を充実させる以外にありません。通常の運用テストでは、どうしても定型業務の確認に終始しています。これも大事なことですが、潜在的なバグを発見するためには、定型以外の例外処理テストや極(キワ)テストを徹底的に行う必要があります。

 

 例外処理テストとは、いったん登録した内容の取消しや変更など発生頻度は高くないが起こる可能性があるイレギュラー処理の検証です。極テストとは、システム入力範囲の極小値・極大値を入力して仕様どおりシステムが機能するか、あるいは、想定量より多いデータ量を流してシステムに負荷をかけても安定稼働するかなどシステムに極端な使用を試みることです。

 

 当然テストを充実させれば、システム開発の時間とコストが余計にかかります。実際のプロジェクトでは予算も開発期間もギリギリなので、テスト計画は最低限の内容になりやすいです。そのうえ、何かアクシデントがあって開発が遅れれば、稼働日はずらさずにテスト期間が削られることになります。

 

 テストは運用時のシステムの失敗リスクを低減します。「まずは本稼働を優先して、稼働後にバグが見つかればその時に対応すれば良い」という発想は大変危険です。経営者はシステムに内在する企業を脅かすリスクに注意を払うべきです。システム構築の成功は稼働だけではありません。事前のシステム構築計画段階では、テスト工程に十分余裕を持った予算と期間を確保しておくことが重要です。

 

システム運用段階の失敗と要因の関連図

 

システム構築段階の失敗と要因

 「システムの失敗」と言っても、その種類はさまざまです。人によってもその内容は違います。ただ単に“システムトラブル”をシステムの失敗とする人もいれば、システム利用者のシステム操作や機能に対する“不満・ストレス”を失敗と呼ぶ人もいます。ここでは、システム構築段階に絞ってシステムの失敗と要因を整理していきます。

 

システム構築時の失敗事象

 システム開発は、次期システム構築プロジェクトを社内に立ち上げて、開発業者や製品(パッケージソフト)を選定し、長い期間をかけてプロジェクトを進めます。しかし、何らかの事情やトラブル続出でシステム完成の見込みが立たず、プロジェクトを途中で断念するようなことがあったら、これは明らかにシステム構築の失敗です。

 

 プロジェクト中止は、システム開発の最悪の結果と言えます。プロジェクトの中止は滅多に起こることはありませんが、決して少なくはありません。発注企業がシステム開発を断念して、システムベンダーを訴える裁判記事が雑誌にたびたび掲載されています。

 

 また、プロジェクト期間中に、システム仕様の見込み違いで一度確定した設計作業をやり直したり、すでに開発に着手しているのにも関わらず機能修正や追加開発したりすることは、頻繁に起こります。手戻りや追加作業が度重なると、当初計画よりプロジェクトの予算はオーバーし、場合によっては完成が期日に間に合わずシステムの本稼働を延期せざるを得なくなってしまいます。最終的に新システムを稼働できたとしても、大幅な予算超過や稼働遅延すればシステム構築の失敗になります。

 

 システム構築時の失敗事象は“プロジェクト中止”、“予算超過”、“稼働遅延”の3つですが、プロジェクト中止と予算超過、稼働遅延との間には因果関係が成立しています。予算超過と稼働遅延が拡大してプロジェクトが収拾つかなくなったことにより、やむを得ずプロジェクト中止の決断に至ります。

 

 

システム構築プロセスと失敗要因

 システム構築には“要件定義”、“設計”、“開発”、“テスト”の4つの工程があります。システム構築時の失敗の要因についてプロセスごとに検討してみましょう。

 

 “要件定義”は、経営や業務のやりたいことを漏れなく洗い出してシステムに反映させる作業です。要件定義があいまいであったり、いい加減であったりすると、システムが完成してもユーザーにとって大概使えないシステムになります。そのため、要件定義の検討不足はシステム構築にとって致命的な問題です。

 

 要件定義の作成には、経営・業務・ITの総合的知識と構想力を必要とします。必要機能を取りこぼさない想定力も大切です。要件定義は非常に難易度が高い作業であり、大規模開発であればあるほど困難を伴います。実際の要件定義は企業だけでは行わず、システム会社の有償支援を仰ぐケースが大半です。その際、システム会社によるサポートが質量ともに十分でなければ、品質の悪いものになってしまいます。

 

 “設計”は、ソフトウェアの仕様を具体的に決めていく作業です。設計には基本設計(概要設計)、詳細設計があります。設計作業は要件定義どおりに正しく機能できる設計になっていれば問題ありませんが、システムエンジニア(設計者)の設計ミスで設計内容に機能上の不具合があったり、要件定義とは異なる仕様で設計されていて、企業側の確認不足でそれがそのまま開発されたりすることがあります。

 

 “開発”は、実際にプログラムをつくる作業です。プログラマー一人ひとりが相当なプログラム量を書くので、ヒューマンエラーが起きてしまいます。これをバグと言います。バグを次工程のテストで発見・修正できなければ、システムの潜在的な脅威になります。なお、近年のプログラム開発では、優れた開発支援ツールが活用されており、バグの発生は大幅に軽減されています。

 

 “テスト”は、完成したプログラムやシステムを検証する作業です。テストには、開発会社が行うシステムテスト(単体テスト・結合テスト・総合テスト)と企業が本番を想定して行う運用テストがあります。これらのテストが足りないと、システム稼働後にバグが顕在化してシステムが誤作動したり、稼働前には想定できなかったシステム機能範囲外の業務処理がでてきたりします。十分なテストを実施するためには、テスト計画でテスト項目の品質と量が十分に確保されていなければなりません。

 

 発注企業とシステム会社に分けて、システム構築プロセスと失敗要因の関係をまとめると、次表のとおりです。

 

 システム構築は4工程ありますが、“設計”、“開発”、“テスト”の3プロセスの目的は、“要件定義”を正しくシステム化することとその検証にすぎません。システム構築時の失敗要因を突き詰めていけば、“要件定義”プロセスが問題の発端になります。

トップページ > 2015年 > 2月

ページの先頭へ ページの先頭へ戻る


特定商取引法に基づく表記

Copyright © Mitsuru Nakagawa CPA office