保守・改訂、よいシステムとは、保守の頻出、保守の困難性
情報システムは、稼働後にいろいろな理由により保守改訂が必要になります。
・欠陥対処
テスト段階で発見できなかった欠陥が、稼働後に発見される
利用度の増加、データ量の増加による処理時間の増大
・改善要求
使いやすさなど非機能要件の向上の要請
利用レベルの向上による、新機能追加の要請
・IT環境の変化
レガシー環境→オープン環境→Web環境などの変化
旧版OSやERPパッケージなどのベンダサポートの打切り
・経営環境の変化
法律・基準の改正
新規事業や業務改革など経営戦略への対応
仕事の仕方は経営環境に大きく影響を受けます。日常的な仕事は情報システムを利用して行われています。そのため、情報システムは経営環境に合致したものでなければなりません。経営環境が変化すれば、情報システムを改訂する必要が生じます。しかも、企業競争が厳しいので、短期間で対応することが求められます。
ところが、情報システムの改訂はますます頻繁に発生し、しかも対応を困難にしています(例示)。
本来、情報システムは経営戦略実現を容易にすることが目的なはずなのに、情報システムの遅れが経営戦略の実現を遅らせていることが多いのです。
1990年代末には「西暦2000年問題」が深刻な社会問題にまでなりました。たとえば1998年を98のように下2桁で表現する慣習がありますが、2000年では00になりますので、コンピュータはそれを2000年ではなく1900年と解釈してしまう危険があります。それを未然に防止するには、プログラムを調べて年を示す項目を2桁から4桁に変更すればよいのですが、それだけのために、平均的な大企業では、数年の年月と数億円の費用を必要としたのです。そのように、システムは巨大化・複雑化しているのです。
一般的に、情報システムの開発と運用は異なるグループが担当しています。システムの運用段階では、システムが安定して稼働することが求められますので、運用グループは、せっかく安定稼働している現行システムに手を加えることを嫌います。面倒なだけでなく、思わぬトラブルが発生するのを恐れるからです。
それで、両グループが互いに他のグループの立場を理解して協力することが必要になります。これをDevOps=Development (開発) + Operations (運用) といいます。
単に精神的な協力ではなく、安心して容易に手を加えることができるシステムにすることが重要になります。
Google社が提唱したシステム管理とサービス運用の方法論。>DevOpsでは、開発グループと運用グループの協力の重要性を示したのに対して、SREはその具体的な行動を示したものだといえます。
信頼性を高める技術というより、信頼性を制御する技術です。
ユーザーが利用しながらも変更を続けていくような情報システムが対象になります。
多様な理由により、システムは改訂は必然的ですが、改訂作業により予期せぬエラーが発生が発生します。それを極度に抑えるには大きな時間や費用がかかります。そのバランスをとるためには、適切な
・SLI(Service Level Indicator)サービスの信頼性レベルの指標
・SLO(Service Level Objective)指標に対する目標値
を明確に設定し、目標を下回らなければリスクが生じるのは仕方ばない、過剰な対応を防ごうという考え方になります。
SREは、適切なSLI/SLOを設定し管理する方法論です。SLIとSLOにより、信頼性の予算(バジェット)を期間内にどれだけ消費したかを計測しておき、予算の残量に応じて、どれだけリスクを取って変更してよいかを定量的に判断できます。このような仕組みを、エラーバジェットといいます。
トイル(toil)とは、サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするものです。SREでは、ソフトウェアエンジニアリングやシステムエンジニアリングを活用して、トイル作業を50%以下にするのだとしています。
保守改訂作業が増大しており、しかもその作業はベテランでないとできません。そのため、IT部門は、新規開発のための作業が十分に行えない状況になっています。情報システム部門はシステム開発だけでなく、経営戦略と情報技術の統合などの付加価値の高い任務が期待されていますが、保守改訂にベテランが張り付いている状態ではそれも困難です。
保守改訂によりIT部門が硬直化して本来の業務ができなくなる状況を回避することが重要な課題ですが、既存のシステムを容易に保守改訂する効果的な方法はないので、システム設計の段階から、将来の改訂が容易に行えるように設計することが大切です。システムを開発するのは1回だけですが、保守改訂は何度も行なわれます。すなわち、「よいシステム」とは「保守・改訂を容易にできること」であるといっても過言ではありません。
ソフトウェアの生産性が低いことが、ITの効果的な活用を妨げていることは、1960年代末頃でも指摘されておりソフトウェア・クライシスといわれました。それを解決するために、ソフトウェア工学が進みました。部品化・再利用や、各種のシステム開発の方法論は、ソフトウェア工学の主要な分野です(それらの説明)。
「ソフトウェア・クライシス」(Software Crisis)が初めて使われたのは、1968年のNATOによる「ソフトウェアエンジニアリング・コンファレンス」だそうだ。予算超過、納期遅れ、品質低下などが頻繁に発生していることの危機感から生まれた言葉である。
この認識からソフトウェア工学が進んだ。1972年にはダイクストラがプログラミングをわかりやすく品質をよくすることの重要性を指摘した。そのなかでの「GOTO命令をなくせ」が注目された。
プログラマが不足していることが問題になり、日本では1987年には通商産業省(現経済産業省)が「2000年にはプログラマが97万人不足する」と予測した。しかしその後は、プログラマの不足ではなく、上流工程やプロジェクトマネジメントでの人材不足がいわれるようになってきた。
参照:
玉置 彰宏「ソフトウェア工学の勧め」2004年