HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第122号(2010年9月15日発行) 現場の声編「本当にソフトウェアは劣化しないのか?」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第122号(2010年9月15日発行)

現場の声編

「本当にソフトウェアは劣化しないのか?」

1. はじめに

一般的に、ソフトウェアは劣化しないと考えられていると思います。
これは、”一度完成されたソフトウェア”は劣化しないという、暗黙の条件がついているのではないか?と私は考えています。
そこで、今回は、本当にソフトウェアは劣化しないのか?という話を取り上げてみたいと思います。

2. ソフトウェアの特性

基本的なところから始めると、ソフトウェアはハードウェア上で逐次実行される命令の処理手順を表現したもの(プログラム)です。もっというと、電気的にON/OFFするかの情報を並べたものでしかありません。物理的に存在しないものであるため、劣化しないのは当然といえば当然です。
また、ソフトウェアは、この命令の処理手順を変えるだけで、いくつもの処理や仕様を実現できます。
更に、ソフトウェアのコピーは一瞬でできてしまいます。ハードウェアで全く同じものをもう一台作ろうとした場合にかかるコストと比べるまでもありません。
このような理由から、ソフトウェアの重要度が高くなってきた歴史は、疑う余地はないと思います。
そして、今ではソフトウェアがないシステムなどありえない時代になりました。つまり、ソフトウェアがあって当然の時代です。

そして、そのソフトウェアで実現されているシステムに新しい機能を追加したい、または、機能の変更を入れたいなどの要求が当然のように発生します。
その度に、既にあるソフトウェアは改造され派生していきます。ハードウェアに大幅な変更がないのに、追加や変更の度に、一からソフトウェアを開発することなど、コスト、納期的に考えて基本的にはありえません。そして、システムが大規模になればなるほど、その傾向は顕著です。
そのため、「ソフトウェアは改造されることを暗黙の前提として持っている」、というのもソフトウェアの特性のひとつだと私は考えています。

そして、ソフトウェアは改造されるものだという前提に立つと、冒頭で示した、”一度完成されたソフトウェア”というのは、そのままの状態で使い続けられることはほとんどない、といえると思います。そして、現実もその通りです。私自身、改造されないソフトウェアというのは、使われなくなったソフトウェアしか知りません。

今回私がお話するのは「ソフトウェアは物理的には劣化しないが、改造を前提にすると劣化しないとは言い切れないのではないか?」ということです。

3. 改造を繰り返すとどうなるのか

ソフトウェアの改造が行われるとどうなるのでしょうか?通常は、一度や二度の小さな変更なら問題が発生する可能性は低いと思います。
しかし、その改造が何度も繰り返されたり、繰り返されずとも長期間を経て改造されたり、もしくは、大規模な改造が行われたりすると、いろいろな問題がでてきます。

3-1. 設計と実装の乖離

最初に発生しやすいのが、設計と実装の乖離です。
ソフトウェア開発では一般的に、最初に設計書を作成し、その設計書をもとにプログラムを実装していきます。
しかし、改造や修正が発生すると、プログラムの変更に設計書の変更が追いつかなくなる時があります。
この要因としては、障害発生時などはプログラムの修正が優先されることが多く、かつ最終成果物はプログラムのため、ドキュメントへの反映を忘れてしまっていること。
それ以外には、そもそも設計書更新分を見積もりに含んでいない、または、設計書更新作業が改造の見積価格内に収まらない、もしくは、お客様から設計書は不要と言われたなどがありえます。

設計と実装の乖離
図1. 設計と実装の乖離

設計書には、設計思想や実装制限などいろいろな情報が含まれています。しかし、プログラムの改造だけが繰り返されると、その設計情報が更新されなくなり、最終的にはソースを見なければ、何も分からないという状態に陥ります。
ところが、設計思想や実装制限などはプログラムだけからすべて読み取るのは不可能に近いため、そこで重要な設計情報が喪失されることになります。
この状態になると、結局ソースを見なければ何も分からないので、次の改造における見積もりを誤り、その変更による影響範囲の見極めを誤り、最終的にプログラムの品質低下だけでなく、コスト、納期すべてに悪影響を与えます。これが、設計と実装の乖離による問題です。

ところで、いうまでもなく、設計書が完全にプログラムと一致しているということはありません。設計書は、自然言語で記述されるのに対して、プログラムはプログラミング言語で記述されます。そのため、設計書には曖昧さが含まれていたり、人によって解釈が違うため完全なものではないかもしれません。しかし、仮に完全な設計書を書いたとしたら、それは、実はプログラムが出来上がってしまうというのは、容易に想像がつくでしょう。

よって、いろいろなモデリング手法や設計手法を駆使し、必要十分な設計書にまとめ上げ、継続して更新していくプロセスが重要になってきます。尚、当社ではISO9001の取り組みなどによって、このプロセスの改善に向けて取り組んでいる最中です。

3-2. スパゲッティ化

次に、発生しやすいのがソースコードのスパゲッティ化です。

スパゲッティ化
図2. スパゲッティ化

プログラムは通常階層的に作成されるのが理想です。なぜなら、規模が大きくになるにつれ、対象を階層的なピラミッド構造にして分割しなければ、論理的な思考や組み合わせが人間には難しいからです。
しかし、本来は、プログラムは階層的な構造であるべきですが、いろいろな要因により階層的に作られていないことがあります。例えば、設計をきちんとしていなかった、したつもりだったが不十分だった、もっと悪いのは設計をせずいきなりコーディングし始めたなど。別の要因としては、ハードウェアの制限によって階層的な作りでは処理速度やメモリに問題がある、プロトタイププログラムだったためとりあえず動けばよいプログラムだった、小さなシステムのため階層化するコストメリットがなかった、または、短納期で階層設計をする時間がなかった、など、いろいろな要因があります。
それでも、ほとんどの小規模なシステムでは完成させることができるでしょう。

しかし、階層化されていないソフトウェアの問題がでてくるのは、次の改造からです。
統一された設計構造ではないソフトウェアは、次に改造するときも(悪い意味で)自由に改造が可能です。それはそれで、構造をすべて完全に把握している人が担当する場合には、階層化という制限がない分、容易に対応できる人もいるかもしれません。
しかし、通常は同じ人でも時間が経てば忘れるでしょうし、何より次も同じ人が作るとは限りません。

そして、構造を把握できる人がいなくなり、改造がままならない状態になった時に、プログラムはスパゲッティ化したと言われます。
それでも、一から作り直すリスクを取って改造をすることは、ほとんどありません。なぜなら、改造をしたらどこに問題が発生するかなど、この状態になったら誰にも分からないからです。そして、改造できない理由が誰にもきちんと説明できないからです。
それでも担当者は必死にコストを犠牲に頑張って改造を続けますが、いつの日か誰がどう頑張ってもコスト、品質、納期すべてを満たせなくなる時が来ます。これがスパゲッティ化による問題です。

3-3. 設計構造の限界

そして、設計と実装の乖離とスパゲッティ化をなんとか回避したとしても発生しうるのが、設計構造の限界です。

例えば、既存システムに小規模な改造が発生したとします。その時、既存プログラムの構造がもう少し違っていたらもっと簡単に対応できる、または将来的には今構造を変えておいたほうがよいだろうというケースがよくあります。
しかし、その構造を変えてしまうと今回の改造には関係ない個所での変更が必要となってしまう、または、その変更をすると影響範囲が広くなってしまうということから、今の構造を変えずに局所的な対応で実装するということがよくあります。
これは、品質、コスト、納期で考えれば、間違っているわけではありません。
それに、今回の改造には関係がなく、将来あるかないか分からない対応のために、費用や納期が掛かることを理解してくれる人は誰もいません(私がプロジェクトマネージャーの立場でもそれ相当の理由がないと認めません)。

設計構造の限界
図3. 設計構造の限界

最初の改造のうちはほとんど問題がないのですが、改造を繰り返す度に、どんどんソースが肥大化してしまいます。具体的には、関数やクラスやファイルなどです。
最初は適切な単位で分割されていたプログラムが、影響範囲を減らすための局所的な対応によって、扱える許容量を超えてしまい、結果的にその対応が、今後の変更の影響範囲を広げてしまうということが発生します。
これは機能の追加や変更だけではありません。昔は使っていた機能だが今は使わなくなってしまった機能などもあると思います。それらを削除するにも、削除による影響範囲の見極めが必要ということから、そのまま残してあるケースがほとんどだと思います。これも肥大化の要因の一つです。

更には、開発する製品によっては、機種によって機能を変えるものが存在します。それらは通常プログラムのコンパイルスイッチ(※1)で切り替えることが多いですが、これも、肥大化の要因の一つです。
そして、この肥大化はさらに設計と実装の乖離と、スパゲッティ化の要因ともなり、更に状況を悪化させることにもつながります。

そして、ある時、当初の設計構造を大幅に変えなければ、要求を実現できない改造が発生します。途中で少しずつ構造を変えていっていれば、大幅な構造変更にはならなかった可能性はあるかもしれませんが、そんなことは誰にも分かりません。
そして、最終的にそこまで大幅な改造をしなければならないのだったら、新規に作り直したほうがよいだろうという結論にいたります。これが、設計構造の限界の問題です。

4. まとめ

ここまで、ソフトウェアの改造を繰り返すことによる3つの弊害について書いてみました。
それらから、私は今回のテーマに対して実体験や参考文献から「ソフトウェアは物理的には劣化しないが、ソフトウェアは改造によって劣化する」という答えを出しています。
いろいろな考え方があるので、この答えの是非を問うつもりはありませんが、実際このような問題があるのも事実です。
そして、ソースの中身を把握していない多くの開発関係者は、実際このような問題が現場で発生すると、「急にそんなこと言われても困る!」と感じられているのも事実だと思います。

答えはまだありませんが、今回このソフテックだよりを書いて、これからもこの劣化の改善に向けて、常に正面から真剣に向き合っていかなければならないと考えされた今日このごろです。

(H.K.)

[参考文献]

「組み込みソフトウェア開発のためのリバースモデリング」

編著者:
SESSAME WG2
出版年:
2007/3/16
出版社:
翔泳社
[注釈]
※1
コンパイル対象のソースを切り替える設定。デバッグ用に、デバッグ時にのみ動く機能などを組み込む場合などにも使われます。

関連ページへのリンク

関連するソフテックだより