舞い込んでくるIT系ニュースにこんなものがありました。

この道半世紀以上の私ですが、ソフトウェアの劣化とは初めて聞く言葉です。無機質だし、摺動部分はないというかそもそも物理的なものではないソフトウェアなのに、それが劣化するとは？？？？　概要をそのまま紹介すると･･･

アーキテクチャ（要求仕様）を基軸とせず、その製品ライフサイクルの中で修正や機能追加を重ねたソースコードは、開発者の認識よりも短い期間で急速に複雑化し、開発者が理解しづらいソースコードになるために開発効率が悪化しがちだ。さらに追加作業の中で不具合を作り込んでしまいやすい品質になってしまう。これが「ソフトウェアの劣化」だ。このソフトウェアの劣化が進むと、保守／拡張／再利用が時間の経過とともに困難になり、最悪の場合、不可能になってしまう。

これを見て分かったのは、この文章を書いた人（会社？）は、システム構築（企画・設計・開発・検査・保守）の実務経験が少ないということです。言葉尻を捉えているかもしれませんが、一人歩きをする文章を正確に書けない会社・人ではいけません。この文章を吟味します。

❝要求仕様を基軸とせず❞

とはどういうことなのか？そもそも、仕様を踏襲しない改廃変更・エンハンスはあるのか？　一般的には、法律が変わった／新たな法律ができた、経営環境が激変した、経営者の方針がガラリと変わった等という、システム設計の段階では想定できなかったことが起きる以外にはないでしょう。

❝修正や機能追加を重ねたソースコードは、開発者の認識よりも短い期間で急速に複雑化❞

開発者の予想していた改廃変更、新機能の必要な事態が、予想よりも早く来てしまった･･･システムの仕様を決めて設計フェーズに入る前までに想定していたシステムに組み込むべき機能（仕様）が、上述のような法律、経営判断の激変で変わらざるを得ないという事態が、システム稼働後に予想しないほどの早さで来ることはそうないでしょう。そうとしたら、明らかに仕様を作る際の検討不足、見通しの甘さです。仕様のレビューをしなかったのか、おざなりのレビューで済ませていたのではないかと思います。システム設計者の能力の問題かもしれません。それを補うツールを開発し、売り込むセミナを企画したというこの会社のシステム設計の技術・経験のレベルを疑います。

❝開発者が理解しづらいソースコードになるために開発効率が悪化❞

どの様な規模のシステムを設計・開発することを対象にしているのか分かりませんが、大手SIベンダはもちろん、中小のSIベンダでも、一定のコーディング規範を持っています。OSの設計時にも標準コーディング規範があり、これに準じて開発をしていました。屋上屋を重ねているうちに開発者自身も全体像がつかめず、改廃変更した際に影響を及ぼすヵ所の把握が完全にはできないという五里霧中のような状態になるようでは、そのシステムの信頼性（品質）は地に落ちます。そうならないように、コーディング規範があります。『開発者が理解しづらいソースコードになる』という事態を招くような作り方をする開発組織／人には、システム開発を任せることはできません。これをツールで改善できるという提案ですが、ツールはあくまでもツール、与えられた仕様（機能）をソースコードに落とすか、ツール管理下で動かすのかしかできません。大本の仕様の確からしさまで保証するものではありません。

❝追加作業の中で不具合を作り込んでしまいやすい品質に❞

『作り込んでしまいやすい』とはどんなことなのか分かりかねますが、その様なモノの作り方をしていること自体がアウトです。屋上屋を重ねるようなモノ作りをするような体質のところにはないと思いますが、俗に接続仕様書と呼ばれる設計ドキュメントがしっかり書かれていれば、その様なことはありません。既存コードの変更、新規コードの追加の際、それを行うことで、どこにどのような影響が出るのか、チェックすべきなのかを十分に調べないまま追加変更削除をすれば、当然品質は下がります。というか、コードの改変による既存機能への影響がないことを確認できるテストを行えば、機能の改廃変更新規追加の際に不具合を作り込んでしまうようことにはなりません。それをツールでカバーするということをアピールするなら、そのツールがテストするテスト項目はどの様に作るのかを知りたいものです。OSの場合は、改廃変更新規追加によって、既存機能に影響を及ぼす事故をデグレートと呼んでいましたが、これはソフトウェア技術者としては、最も不名誉なことです。OSでなくても通常の業務アプリケーションでも同じことです。もちろん、これをツールで避けて通ることなどできません。

❝劣化が進むと、保守／拡張／再利用が、時間の経過とともに困難になり、最悪の場合不可能になってしまう❞

彼らいう劣化とは、仕様の追加変更が発生した際、それを今稼働しているシステムに反映しないと、実態を捉えないシステムになってしまうということのようです。タイムリでデグレートを起こさない確実な反映は、彼らの会社のツールを使えば簡単にできる･･･そんなツールはないでしょうね。彼らの開発支援ツールを使って作られたシステムなら、それが可能ということかもしれませんが、接続仕様書を始めとする仕様を記述した設計ドキュメントはどうするのでしょう？それもツールの機能として持っている？上流工程から下流工程まで全ての開発プロセスを管理CASEツールなのか？

ソフトウェア技術者としての基本的な素養、技術を身に着けずに、ツールに頼ることは、その人の成長を止めてしまうことになります。

※質問はosugisama@gmail.comにどうぞ！
※本ブログの内容を全部、あるいは一部を無断で転載、流用することを禁じます。

ソフトウェアの劣化･･･????