アプリの寿命について

なんか書いてて昨日のがまとまらなくなってきたので
それはそのまま残して書き直し
んで、Webに絞らず全体アプリケーションまで広げてしまおう、うん
勝手に前提覆すなという苦情は粗品を沿えてお願いします
うーん、文章力欲しいな


アプリケーションに寿命を定められるか、という点については
かなり難しい問題となると思う
Y2K問題のようにある段階で確実に動かなくなってしまうと分かっていれば
発注側もなんとかしようと考えるのだが
100％満足でなくとも動くのであれば使おうと考えられてしまう場合は少なくない
可能な限り出費を減らしたい、もしくは変化を嫌う心理が働くのだろう


もちろんプログラムの中にある日を迎えたら止まるように仕込むことは可能である
しかし、設計段階でそんなもの組み込もうとしても承認が降りるわけもなく
黙って仕込むというのはそれこそモラルに反する行為である
ましてや止まったり、そこまででなくても警告を常時出すような作りをしても
困るのはアプリを使っている現場であって発注者でない
これをしても改善どころか現場と発注者が組み合って製作者に苦情を出すだけである


ならば、「保証期限」「保守期限」を事前に定めて
そこから先も使いつづけるのであれば、何かあっても対応はしませんよ
何か損失が発生しても製作者の責任ではないですよ、と事前に定めるのが上策と思われる
感覚としては電化製品の保証期限と同じだ
期限から先を使うかどうかについては、使っている側に委ねてしまうのだ
また、期限中の段階で改良が発生した場合でも
ここで期限の見直しをするか否かを毎度問うと良いと思う
当然見直すに当たりテスト項目をやり直すコストが発生するのできっちりその分は払ってもらう
払えないなら改良はするけど、アプリの保証期限は延びませんと言うだけだ


期限後になんとかしろと言われたなら、新規で作るなり、既存の物ベースに作り直しするなりである
期限切れ期間が発生し、その間に問題が発生しても製作者の責任は何もない


電化製品分野などでは当たり前に行われているこういったことを
ソフト分野でも広げて行く必要あるんじゃないかな
そうしないとPCとアプリはいついかなる状態でも私の頭の中の都合を
読み取って動いてくれると考えてるオヤジがいつまで経っても消えなくなる
まあもっとタチ悪いのは
往年のメインフレーマー＋COBOLerが発注側だったりする場合ですが
（昔はできたとか、当時の手法押し付けてきたりとか、過去の自慢とかね
そんな腐りきったチーズは食えん）


ま、その前に夢のIT産業という幻想を粉々にする方が先かな



昨日の日記にアドレス載せたため
高木浩光さんの日記からいっぱい人が見に来ている
正直見る方が見る方なのでドキドキものです
この考えが絶対だとは思いませんし、著名な方々から見れば稚拙だと思うけど
今日考えられることはこの程度だったと残す意味でも書いているし
これを礎にして、明日はどのくらいのことが書けるようになるかという意味でも
書いています
来年くらいに見直したら「恥ずかしいこと書いてたなー」と思えれたら自分の中で及第点です



さて、壊れたサーバーの稼動命日が出ました
昨日から今日のログの進み具合から、ログの進行速度を出して計算すると
本日17時現在で残り2094.7時間、87日と1/4日が彼の残り寿命
日によってログの進み具合も違うし、止めればその分延命ですが
大雑把に見ても梅雨〜初夏くらいかな
あの桜が全部散ったら彼の命が終わるという演出はちょっと無理っぽい