メンテナンス不可能なシステムが与える純粋な損失

シェアする

ヨメレバCSS

老朽化ソフトウェアの技術的な負債、毎年12兆円の衝撃って記事を見て。

 システム屋なら「あー…」って察するに余りある内容ですが、他から見たらなんでそんな大事のように言われるか分からないところもあると思います。なので具体的な損失として何が発生するかを挙げてみました。

 件の記事では「老朽化した」とありますが、ぶっちゃけ出来たてのシステムでも普通に発生します。

スポンサーリンク
レクタングル (大)

本番障害が発生する

 いちばんわかりやすくて一番無駄なのは本番環境での障害とトラブル対応です。

 すでに表に出てしまったもので発生した障害は基本的に特急対応となりますし、調査や修正、対応の検討や再発防止策に割いた時間はそもそも障害が発生していなかったら(障害の形で発覚しなかったら)発生しなかった損失です。つまり利益になっていた部分です。

新機能の開発ができない/時間がかかる

 サービスとして続けていると、いろいろな事情で機能の追加や修正を行うことになります。

 それらは必要なことですが、メンテナンス可能なコードと不可能なコードではかかる労力とリスクが段違いになります。つまりコストが違います。

 ちょっとしたことにみえる修正も一週間かかったり、その部分に触れることを毛嫌いしたプログラマが別の(非効率だが気分的にはマシな)方法を取ったりします。

 プログラマの「ここは触りたくない」は直感的で根拠が薄く聞こえますが割と信頼度は高くて、後に本番障害となって告知されます。

誰も近寄らなくなる

 そもそも関わりたい人がいなくなります。

 そりゃもう仕事でやっているので、同等の実入りで楽な仕事があれば当然そちらを選びます。

 つまり採用コストが上昇し、それによって確保できる利益が減りサービス停止も見えてきます。

 中身については実際触ってみないとはっきりしたことはわかりませんが、とはいえ少し話を聞いた段階で「こいつやべーやつだな…」って直感は働きますし、優先度を下げるには十分です。(またはすぐ抜けるって手もあります)

メンテナンス不能なシステムにならないたった一つの方法

 これらの事象を回避するために絶対必要なことは開発スケジュールを開発者が要なだけ確保することに集約されるかなと思います。

 個別の要因としてはスキルや経験を持った人を雇う、CIツールを導入する、コードを綺麗に書くなどいろいろあると思いますが、それらを成すために必要なのが時間です。(それらのためにはお金も必要になってきますが、必要なだけの予算を用意するためにはやはり時間が重要かなと思います)

 時間によって取る手段も違ってきます。例えば時間がちゃんとあればきちんとクラスとメソッドを整備してテストを書いていく部分でも、「明日動かせ」っていわれたらコピペでもなんでもしてとりあえず動く感じにしますわ。

 そしてそれを運用していくときに、前者のコードは追加や修正も低コストで行うことができ、障害発生率も低いのでリソースをサービスの成長に多く使うことが出来ます。後者は修正するにしてもまずちゃんと動くように手を入れることが難しくて、そもそも発生した障害の対応に追われてサービスの成長にリソースは割けなくなっていきます。(それでも新機能を入れないと売り上げが落ちると言われて、雪だるま式に死んでいきます)

 この話はよくジェンガに例えたりします。ちゃんとしたシステムは、抜いたジェンガの穴をちゃんと塞いでいきますから、割と安心して積んでいけます。そうでないものはまあ下から抜くのも地獄、上に積むのも地獄。

 最初のうちはまだいいけど、最初のうちに対処しないと対応コストが跳ね上がっていく流れでもありますね。サービスが長期に運営されていく昨今では致命的です。

 そういうわけでジェンガにならないように進めていきたいとは思いますが、今の正解は既存システムに近寄らないor派遣またはSESで遠巻きに関わるかもしれませんね…

スポンサーリンク
レクタングル (大)

シェアする

フォローする

スポンサーリンク
レクタングル (大)