レイズソフトウェア

「ソフトウェアライフサイクル」というメタファー

はてなブックマーク
2011/05/13 06:05:05

「ソフトウェアライフサイクル」って言葉、聞いたことありますか? システム開発をやっていたら絶対に聞いたことがあると思うのですけれど、 この言葉の詳しい意味をご存知でしょうか。

私はこの言葉について、誰かから詳しく聞いたという記憶がありません(覚えていないだけかもしれませんが)。 調べてみた限りでも、さらっと書いてあるものばかりで、深く言及しているものはほとんど見つけられませんでした。 もしかすると誰も書く必要がないほど当たり前のことなのかもしれません。

ですが、私は最近になってこの言葉の意味が良く理解できるようになってきました。 ということで少し書いてみようかと思います。 いままではなんとなく理解した気になっていたというのが正しいのです。 いまさらかと言われれば、まぁその通りなのかもしれません。

ライフサイクルとは

まずはその元になる「ライフサイクル」という言葉自体の意味について簡単に説明。

誕生 → 成長 → 老化 → 死

を繰り返すこと。
生命の循環、つまりライフサイクル。

この考え方をソフトウェアの開発工程にあてはめたものが「ソフトウェアライフサイクル」。

ソフトウェアの誕生

まずは「誕生」させないことには話が始まらないのですが、
「誕生」と一言で言っても、いくつかパターンがあるように思えます。

おおまかに分けてみると

  • 全く何もないところから生まれる「新規開発」
  • 既存のシステムを新システムに切り替える「リニューアル」
  • 別々のシステムを1つのシステムにまとめる「統合」

の3種類に分類できるのではないでしょうか。

これらの状況は似ているようで異なるのですよね。 「新規開発」の場合は「既存のシステムが存在しないこと(流用できない)」が問題となり、 「リニューアル」の場合は「既存のシステムが存在すること(整合性を取らねばならない)」が問題となり、 「統合」の場合は「既存のシステムが "複数" 存在すること(もっと整合性を取らねばならない)」が問題となるため、 それぞれ別のスキルが必要になるのですよね。

一般的にシステム開発と呼ばれるのは、これらの状況のことを指すことが多いのではないでしょうか。

ソフトウェアの成長と老化

いわゆる保守フェーズ。

バグを取ったり、使いやすいよう修正したり、機能を追加したりといったことです。 目立たない行程ですが、とても大切な工程です。 システムというのは、作ったら「はい、それでおしまい」ということではなく、経営状況などに合わせて変化させる必要が出てきます(例え、どんなに開発時に考慮していたとしてもです)。 システムは、作ることが目的ではなく、使うことが目的であるため、動作する状況を常に保つことはとても大切なことなのです。

ですが、この保守作業は続ければ続けるほど徐々に難しくなっていく傾向があります。

保守の難しさ

現実的に言って、作成した人がそのまま保守することはまれです。 おそらく別の専門の保守担当者が作業を行うことになります。 そうなれば仕様書は重要な情報連携手段となりますが、 その仕様書を最新の状態に維持するのは困難です。 そしてプログラムは書くことより、読むことの方が難しい。 担当者が退職し、誰も仕様を知らない、仕様書は古く使い物にならず、 頼れるのはソースコードだけ…という状況は決して珍しくありません。 また、検証作業もタダではありません。 修正による影響範囲が広くなれば、その分の検証作業も増えていくのです。 根本的な解決策を取ることができず、その場限りの応急処置的な修正作業が増えていきます。 そして、いずれ誰も保守できない状況がやってくるのです。

かの有名な古典中の古典「人月の神話」には、こう書かれています。

そこで、レーマンとベラディは、統計力学的モデルからプログラミングシステムにとってより一般的な、 全人類の経験で裏付けられている結論に帰着した。 パスカルは言った。「物事は常に最初が最高の状態である」。

おしなべて修正というものは、構造を破壊し、システムのエントロピーと混乱を増加させる傾向がある。

プログラムメンテナンスはエントロピーが増加する過程であり、 どんなに器用に行っても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。

実際問題としてシステムは永久に使用できるものではない。真新しい、根底からの再デザインが必要なのだ。

ソフトウェアの死

ソフトウェアは保守できなくなった時や、 時代に合わなくなったときにその役目を終え、 使用されなくなった(使用できなくなった)ときに死ぬのです。 ウィルスに侵されたり、脆弱性を突かれて個人情報がダダ漏れで即死というパターンもあります。

「死」は「誕生」につながる

誰も保守できなくなったらどうするのか。
「現状維持」か「破棄」か「別のシステムに乗り換える」か「リニューアル」か。
「リニューアル」を選択すれば、それが新たなシステムの「誕生」に繋がります。

「リニューアル」を選択する場合、 実際には保守できなくなる予兆があるので、保守作業を続けつつ、 リニューアル作業を並行して行うことになるでしょう。 まぁ大抵、その作業を担当するのは別の担当者です。 別の会社の担当者ということも不思議ではありません。

さて、保守できないシステムの仕様を、その担当者に正しく伝えることができるでしょうか。 万全を期すためには「事前の準備(出産準備)」をしっかりと行っておくことが大切です。 正しく伝えることができなかった場合に待っている結果は。。。

参考文献