Web教材一覧システム調達

保守改訂を容易にすることの重要性

キーワード

保守・改訂、よいシステムとは、保守の頻出、保守の困難性


保守改訂の必然性

情報システムは、稼働後にいろいろな理由により保守改訂が必要になります。
 ・欠陥対処
    テスト段階で発見できなかった欠陥が、稼働後に発見される
    利用度の増加、データ量の増加による処理時間の増大
 ・改善要求
    使いやすさなど非機能要件の向上の要請
    利用レベルの向上による、新機能追加の要請
 ・IT環境の変化
    レガシー環境→オープン環境→Web環境などの変化
    旧版OSやERPパッケージなどのベンダサポートの打切り
 ・経営環境の変化
    法律・基準の改正
    新規事業や業務改革など経営戦略への対応

仕事の仕方は経営環境に大きく影響を受けます。日常的な仕事は情報システムを利用して行われています。そのため、情報システムは経営環境に合致したものでなければなりません。経営環境が変化すれば、情報システムを改訂する必要が生じます。しかも、企業競争が厳しいので、短期間で対応することが求められます。
 ところが、情報システムの改訂はますます頻繁に発生し、しかも対応を困難にしています(例示)

本来、情報システムは経営戦略実現を容易にすることが目的なはずなのに、情報システムの遅れが経営戦略の実現を遅らせていることが多いのです。

DevOpe

一般的に、情報システムの開発と運用は異なるグループが担当しています。システムの運用段階では、システムが安定して稼働することが求められますので、運用グループは、せっかく安定稼働している現行システムに手を加えることを嫌います。面倒なだけでなく、思わぬトラブルが発生するのを恐れるからです。
 それで、両グループが互いに他のグループの立場を理解して協力することが必要になります。これをDevOpe=Development (開発) + Operations (運用) といいます。
 単に精神的な協力ではなく、安心して容易に手を加えることができるシステムにすることが重要になります。

保守改訂の容易化

保守改訂作業が増大しており、しかもその作業はベテランでないとできません。そのため、IT部門は、新規開発のための作業が十分に行えない状況になっています。情報システム部門はシステム開発だけでなく、経営戦略と情報技術の統合などの付加価値の高い任務が期待されていますが、保守改訂にベテランが張り付いている状態ではそれも困難です。

保守改訂によりIT部門が硬直化して本来の業務ができなくなる状況を回避することが重要な課題ですが、既存のシステムを容易に保守改訂する効果的な方法はないので、システム設計の段階から、将来の改訂が容易に行えるように設計することが大切です。システムを開発するのは1回だけですが、保守改訂は何度も行なわれます。すなわち、「よいシステム」とは「保守・改訂を容易にできること」であるといっても過言ではありません。
 ソフトウェアの生産性が低いことが、ITの効果的な活用を妨げていることは、1960年代末頃でも指摘されておりソフトウェア・クライシスといわれました。それを解決するために、ソフトウェア工学が進みました。部品化・再利用や、各種のシステム開発の方法論は、ソフトウェア工学の主要な分野です(それらの説明)

「ソフトウェア・クライシス」(Software Crisis)が初めて使われたのは、1968年のNATOによる「ソフトウェアエンジニアリング・コンファレンス」だそうだ。予算超過、納期遅れ、品質低下などが頻繁に発生していることの危機感から生まれた言葉である。
 この認識からソフトウェア工学が進んだ。1972年にはダイクストラがプログラミングをわかりやすく品質をよくすることの重要性を指摘した。そのなかでの「GOTO命令をなくせ」が注目された。
 プログラマが不足していることが問題になり、日本では1987年には通商産業省(現経済産業省)が「2000年にはプログラマが97万人不足する」と予測した。しかしその後は、プログラマの不足ではなく、上流工程やプロジェクトマネジメントでの人材不足がいわれるようになってきた。
参照: 玉置 彰宏「ソフトウェア工学の勧め」2004年


理解度チェック: 正誤問題選択問題