ソフトウェアの「つくれば保守が増える問題」

なければ作ればいい。名言ですね。誰が言ったのでしょう。
リスクを考えたら何もつくれない。いやぁその通りです。
でも、後のことそろそろ考えませんか?

ソースコードを読むしかないと思わせるドキュメント。
意図の読み取れないコメントで構成されたソースコード。
ソースコードを読んでも全くわからない論理構造。

僕たちはどれだけ過去の遺産に苦しめられないといけないのでしょうか。
なぜ10年も20年も前の古い技術や古い思想のお守をさせられているのか。
もちろんユーザーの要求や環境が変化するからです。

今、僕は被害者ぶっていますが、自分のつくったソフトウェアに対する文句です。
僕のソフトウェアも10年選手が登場し始めました。

もうぶっちゃけます。
当時は丁寧に書いたつもりでしたが、今見るとソースコードもドキュメントもコメントも何を言ってるのかさっぱりわかりません。
毎日過去の自分に毒づいています。うへぇ。

とはいえ、自業自得と片付けるのはあまりに芸がない。
だって読みやすいドキュメントがあっても保守は辛いので。


現在われわれが使っている情報システムの多くは,平均で10年から15年前に開発されたものである.
こうしたプログラムは当時最良の設計やコーディングの技術を,
駆使して開発されたとしても(そんなこともない場合が多いのだが),
まだプログラムのサイズとメモリの大きさの関係が大きな問題だった頃につくられたものだ.
それから新しいプラットフォームに移植され,
マシンやオペレーティングシステムの変化に対応し,
新しいユーザーのニーズを満たすために改良されてきた.だがすべて,
全体的なアーキテクチャに大して十分な配慮をせずに行われたものである.
結果は何か.
貧弱なアーキテクチャ,貧弱な制御構造,貧弱なコーディング,
そして貧弱なドキュメントから構成されるソフトウェアシステムを使い続けなければならないということである.

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-より抜粋

1970年頃の言葉だそうです。今も昔もあまり変わりませんね。
今やメモリに関してまず大きな問題にはなりませんが、プラットフォームは当時にくらべ大幅に変化しています。
変化のスピードは1970年と比較になりません。

10年前といえば、丁度東日本大震災があったころ。
プラットフォームでいうと例えばOS。
Window7が登場してましたが、まだまだXPが主流です。
じきにWindows8が登場しますがあっという間に消されます。
Wikipedia – Microsoft Windows

携帯では、iPhone4が登場し世間ではスマホが爆発的に広がります。
OSをiOSに名称を変更しiOS4が中心でした。

Wikipedia – Microsoft Windows

出典 – 総務省

この10年、スマートフォンに引っ張られプラットフォーム界隈は汎用機も含め大きく様変わりしました。
言語やフレームワークも同様です。


メジャーなプラットフォームであればある程度の互換性はあります。
とはいえ、頻繁に更新がかかるので殺意がわきます。
OSが変わる度に古いソフトが動くかどうかの質問が飛んできます。
作った僕だって動くかどうかは動かしてみないとわかりません。
自分で確認してください(と言いたい)。

また、これまで主力で使ってきた.NetFrameworkを亡き者にしようとしている感も否めません。
何か考えておかないと・・・と言いつつ後回しにして忘れるやつ。
きっとサポート終了の文字が登場した瞬間大騒ぎしますね。
定年まで持ってくれないかなぁ。

Web界隈はInternet Exploreが2022年にサポート終了ですね。
とある国内大手企業は今でも社内サービスをInternet Exploreに頼っています。
阿鼻叫喚かもしれません。EdgeのIEモードで動くと良いですね。
うん、きっと動きますよ。いやぁ笑える。

Internet Explorer は Microsoft Edge へ – Windows 10 の Internet Explorer 11 デスクトップアプリは 2022 年 6 月 15 日にサポート終了

メジャーOSとメジャー言語の保守はまだ救いがあります。他にも転用できる可能性がありますので。
一方、諸般の事情でマイナーOS・マイナー言語を使わないといけないケース。
効率の悪い言語なので生産性は致命的。たまの改修ですが、改修が入ると莫大な工数とストレスがかかります。
それでいて転用できる技術は皆無。得られる成果も微々たるもの。
さらに言語名やOSを業務経歴書にも書けないという・・・。
替えが利かないので、ソフト自体はニッチの状態で残り続けます。


長く同じ場所にいると保守が増えます。
実はこの解決策を僕は見出せていません。

「つくれば保守が増える問題」

ビザンチン将軍問題・ナップザック問題・巡回セールスマン問題・囚人のジレンマ・・・
そして「つくれば保守が増える問題」。
ちょっとカッコいい問題名と並べてみました。

一般名称ではなく、今僕が適当につくっただけなのでお間違え無きよう。

消極的ですが僕が思いつく対策としては以下の三つ

  1. 会社をやめる
  2. 捨てる
  3. 押し付ける

今のところ1が一番現実的です。
2は、なかなか難しいですね。
ソフトウェアを捨てるかどうかを決めるのはユーザーです。
作り手の僕たちが決めるのはユーザーを捨てるかどうかです。
責任文化の日本では中々難しいでしょう。
3.は結局頼られるので時間はとられますしあまり手を離れていきません。

Microsoftやスティーブジョブズは古い資産を技術的負債と言いました。

僕たちは技術的負債と言ってユーザーを捨てられるほど力をもっていません。

そんなの無責任だ
と言われてしょぼんとなるのがオチでしょう。さて、どうしたものか。
誰か「つくれば保守が増える問題」で論文書けばよいと思います。

ソフトウェアの「つくれば保守が増える問題」

おわり

PR

コメント

コメントを残す

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