ソフトウェア保守とは何か?①


私は現在、あるソフトウェアを保守する立場にあるのですが、

クライアントの関係で詳しくは書けないものの、最近は様々なトラブルに見舞われいっぱいいっぱいになっていました。

自分のミスも絡みこのような事態に陥ったため、かなりの自己嫌悪に苛まれもしましたが、改めて『ソフトウェアの保守とは何か?』『ソフトウェアを保守するためのベストプラクティスは何か?』を考える良い機会になったと思います。

まず、『ソフトウェア保守とは何か?』をWikipediaより

ソフトウェア保守はその動機により細分できる。JIS X 0161:2008には、次の区分が定義されている。

適応保守(adaptive maintenance)
変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の引渡し後の修正。
是正保守(corrective maintenance)
発見された問題を訂正するために行うソフトウェア製品の引渡し後の受身の修正。いわゆるバグ修正。
緊急保守(emergency maintenance)
是正保守実施までシステム運用を確保するための、計画外で行われる一時的な修正。
完全化保守(perfective maintenance)
潜在的な欠陥が故障として現れる前に検出し訂正するために行う、引渡し後のソフトウェア製品の修正。
予防保守(preventive maintenance)
引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正。
私がこれまで行っていたのは上記でいう『適応保守』『適正保守』『緊急保守』の三種類。たぶん保守作業と言えばこの3種類が一般的なのではないでしょうか?私の場合、これらの保守作業をしている時間以外は別の業務をしていました。
さて、これらの保守作業のみを対象としている場合に私自身がぶち当たった問題点を挙げてみます。
  • 一通り設計書やコードを見てはいたが、結局バグ対応や追加仕様対応した部分しか詳細を理解できていなかった
  • バグ対応や追加仕様対応をするたびに影響範囲を見極めテストを行う作業はきちんと影響範囲を見極めているのか常に不安だった。
  • コードとコード内のコメント、さらに設計などのドキュメントにも乖離があり、さらに理解を困難にさせた。
  • 普段のバグ修正や仕様追加の場合はその場所の仕様さえ理解すればよかったのが、OS変更などで全体をテストする必要がある場合はやはり全体の理解が求められる。
  • バグ対応や追加仕様対応の機会はそれほど頻繁にあるわけではない。そのため、リリース作業は常に最大の緊張感で不安になる。
  • バグ対応は仕方なくやる。追加仕様対応はできるだけ避けたい。。。そんな気分が常にある。コード自体が汚い、読みにくいなどが原因だと思っていたが、最近はコードがいくらきれいに書けていてもそう思うのではと考えています。

正直、このような仕事の仕方ではプレッシャーがかかり、よい仕事ができるはずもないですよね。

では、どうすればよいのだろうか?・・・次回考えてみたいと思います。

2件のコメント

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です