陳腐化する技術とその後のシステム

技術に対する投資ってのは結構難しくて、常に投資し続けないと陳腐化は免れないけど、投資し続けること自体は意味がなかったりする。PCは欲しいときが買い時、というのとシステム投資ってのはあんまり話が変わらなかったりする。唯一違うのは、投資を決めた段階から出来上がるまでのタイムラグで陳腐化する可能性がある、ということ。
もうちょっと簡単な話としては、「これこれこういうシステムだからこれだけのディスクが必要だぜ。ディスク高いぜ…」⇒(1年後)「去年のディスク容量の見積もりと同じ値段で今年なら倍買えたぜ、なんでバックアップの抑制のためにこんなに工数かけてるんだ今…」みたいな。

今やっておけば500万円で済むような話が、上記理由により5年後には5000万円になってしまう、ということもあろう。それがどれくらいの額になるかはその時がやってこないとわからない。

今日のシステム延命は向こう5年の技術的負債(しかも高金利雪だるま) - サンフランシスコ出羽守手記(masayangの日記

しかし、今やった500万が10年後には5億円になっているかもしれないのである。しかし、5年後5000万でやったやつが10年後には50億円になっているかもしれないのである。
システムなんて、技術的に陳腐化しようが目的を為しえていればよいので、例えば勘定系システムの一番コアの部分なんて別にハードウェア更改以外しなくたってよかったりするんだけどOS乗せ変えなきゃならないのはベンダーの都合だよね、なんて思ったりもするけど。事業戦略のためのシステムなんかだったらむしろ更改じゃなくて刷新してしまえ、業務プロセスもそれに合わせて変えてしまえ、と思うんだけどさ。日本のシステム開発の一番の癌は、システムが既存の業務のためにある、という考えをどうしても導入される側が捨てきれないことだと思うんだよね。システム投資のかなりの部分を、既存の業務にフィットさせるための工数に費やしているけど、それって絶対戦略的なシステムにはなりえない。既存のシステムの自動化に過ぎないから、事務コスト削減にはなるかもしれないけど、費用対効果の面では微妙だし、ここで言われている雪だるま式負債をもっとも食らう箇所にもなる。


まあでも刷新しなきゃいけないのは技術者の頭の中だけどな。

今その辺にいる若者に、西暦2000年当時に設計された業務要件・システム要件・システム設計書とWindows 2000+IIS/ASPベースのシステムやLinux 2.2系+Apeche 1系+PHP 4ベースのシステムを渡して「じゃ、よろしく」と頼む場面を考えてみると良い。お手上げとなるのがオチだろう。そんな陳腐化したシステムを一から学ぶ酔狂な若者は珍しいはずだ。

今日のシステム延命は向こう5年の技術的負債(しかも高金利雪だるま) - サンフランシスコ出羽守手記(masayangの日記

10年前にこのあたりを最新のものとして作った技術者が、最新の技術をきちんと把握していれば、10年前の要件を現代のものとして練り直して刷新すべく、若者にバトンタッチすることなんて簡単なんだよ。でも、10年前の要件のまま、10年前の技術要素を元に考えて、更改案件として今のシステムを作ってしまう10年前の若者今ベテラン、であるならば、一生返せない負債が残る、ような気がする。でも、ホストの世界って、それを50年くらい繰り返してまだホストでやっている。陳腐化っていうと悪いみたいだけど、枯れたというと安心する気がする不思議。実はハードウェアとか仮想化の技術要素の大半は金より安心が欲しいバカありがたい客のおかげで陳腐どころかホストが一番進んでいるという事実。だけどその上に乗っている技術者?…単なる業務システム屋をここで言う技術者と呼ぶのかどうかはさておき…はそんなことはまったく意識せず古い設計手法と古い言語を使い続けているけどな。技術者いなくなったら捨てちまえばいいんだそんなシステム。

でもね、保険なんかが一番典型的なんだけど、一度売った商品は「対象者が全員解約するか全員死ぬまで」廃止できない=システムが残り続ける。日本人の律儀さが裏目に出ているようなものだ。でもさ、そういうのを捨ててしまえば、膨らんだ負債ごとシステムを捨ててしまうことはできなくはない。捨てられないから、金融システムの基幹系はそう簡単に刷新できないし、無駄なメンテコストが膨らんでいく。いや、捨てりゃいいんじゃないかな。お役所さえ面倒なことを言わなければね。

延命したければ延命すればよいんだよ。ただし、5年後にそのシステムが抱えた負債を丸々踏み倒すだけの覚悟は必要。経営者が技術的負債を返済しようと考えたそのときから技術者の地獄が始まるんだ。