なぜ出来損ないのシステムを使わなければならないのか

ソフトウェアやシステムのリプレース（再構築）や改造の引き合いを受けることがあります。そんな時、既存ソフトウェアあるいはシステムのソースコードを見るとげんなりすることがあります。

大手SIerが作ったもの…と言っても、中小企業が作ったものと大して違いはありません。違いがあるとすれば「規模」だけです。実際には大手SIerには開発者なんてのはほとんどいないからです。

大手SIerはマネジメントが中心で、開発そのものは外注（パートナー会社）に依頼しているため、時には中小企業の若手であったり、言語仕様もよくわかっていないプレエンジニアだったり、オフショアで動きもしないプログラムを送り付けてくる外国人…だったりすることもあるのです。なかには、新人に毛の生えた程度のエンジニア…と言うか、新人だっているかもしれません。

そういった人たちで開発して、大手SIerは中身もロクに確認できず、スケジュールも見ずにお金ばかり管理していると、プロジェクトが失敗しちゃうってケースがよく起こります。

で、そうやって出来上がってしまった出来損ないのシステムですが、長い時間をかけて作ったものだし、発注側としてもリリースしないと新規事業や新規業務が始まらなかったりするので、無碍にすることもできず、捨ててしまえばいいのに無理矢理使わざるを得ない…なんてことが起こってしまうのが世の常です。

そのためだけに10億、100億なんてお金を支払うのかと思うと、自分が支払う側だったとしたらうんざりします。公共セクターの場合、その予算はみなさんが支払っている税金…ということになります。

　

そうなってしまうのは発注側の担当者のメンツを守るためであったり、現場の苦労を上役が理解していないためであったり、といった様々な理由があると思いますが、実は会計的な意味から「出来損ないでも、ゴミのようなものでも、どうしても使わなければならない」という理由が隠れています。

上に書いた「出来損ないのシステムを無理矢理使わなければならない会計的な理由」とは、そのシステムを使わない場合は「減損処理」をしなければならないということです。

たとえば、そのシステム開発に１億円を投じた場合。

そのまま使っていけば、その１億円はソフトウエアという種類の『固定資産』になり、１億円を５年間に分けて、１年当たり2000万円づつ償却していきます。1年あたりの会計上の費用は2000万円です。

しかし、その出来損ないのシステムを「使わずに捨てる」と決断した場合、開発にかけた1億円は、即"損失"になります。つまり、開発が終わった年の会計上の費用は１億円になるわけです。

そうすると、その判断の違いによって、初年度に差し引き8000万円分のマイナス差額が出るわけです。そして、その会社がよほど黒字を出していれば「使わずに捨てる」という決断もできるでしょうが、この8000万円のせいで黒字だった会社の収支が赤字に転落するような事態になったとしたら。

もし上場企業だったなら、モノ言う投資家たちの攻撃の対象にされかねません。経営側としては、何としても黒字に見せたいので

　「作った以上は、ゴミでも、使えなくても、とにかく無理矢理使え！！」

と号令をかけることになります。会社の成績を良く見せ、対外的に調子がいいように誤認してもらうためには、できてしまった出来損ないのシステムでも捨てられず、使わざるを得ないことになるわけです。

実際、ある大炎上のトラブルプロジェクト…を俯瞰してみていた時があって、そのシステムがリリースされた後の保守・運用を受注するとかしないとかってことがあったんです。その提案書を書くって話に参加する中で、炎上中のプロジェクトとのやり取りや、当時の２ちゃんねるで書き込まれていた現場の担当者かな？たちの悲痛な叫びを目の当たりにしてました。

100億もかけてつくったものとはいえ、現場では「こんなもの使えない」「業務に必要な管理ができない」って声があったにもかかわらず、お偉いさんの

　「『使えない使えない』という声を聞くが、
　　そんなものは慣れればなんてことはない」

の一喝で無理やり導入が進んだ…と言う話を聞いて、唖然としました。本当にあるんだ、的な。結局その使えないシステムを納期から半年ほど遅れてリリースしてたんですよね。

後日談ですが、半年ほど経過したころ、保守・運用を見事受注して、事前のソース解析を少し手伝いましたが、プログラム言語の特性を真っ向からガン無視して、無秩序なコードを見たときには、さすがに発狂しそうになりました。

　「だったら、使ってることにして実際には使わなければいいじゃん！」

と思うかもしれません。が、それは通用しません。

実際には使っていないのに固定資産に計上していると、監査で引っかかります。会計士は、そういう「ホントは使ってない固定資産」が発生しがちだということを監査の基礎知識として知っています。なので、固定資産が本当に存在して、本当に使っているかどうかということは必ず一つ一つチェックします。

最近では監査法人がエンジニアを雇って、システムの内部まで確認して監査するということが普通に行われているので、その過程でバレてしまうこともままあるでしょう。

そんな理由があって、出来損ないのシステムであっても、捨てたくても捨てられないため、いずれ来たるリプレース（再構築）や部分改造で、中身がひどいソースコードを見せられることになるのです。

元がトラブルを起こすプロジェクトが作ったもの、トラブルの集大成なわけですから、そんなものを流用すれば、ちょっとした改修・改造のプロジェクトでも、意図しないトラブルを起こしてしまう可能性がついて回るわけです。

そういったソフトウェア開発案件は、もう受注した瞬間からデスマーチの匂いがプンプンします。受注前に調査すると言うことはあまりないでしょうから、たいしたリスクヘッジは取れず、担当するエンジニアたちは、最初から疲弊することを余儀なくされるのです。

チャンスがあるならば、既存システムのリプレースや改造の場合は、受注前に前プロジェクトはどうだったのか、腹を割って聞くようにしましょう。

もし、前プロジェクトが酷い様相だった場合は、既存リソースの使いまわしは逆に危険です。通常のリプレースや改造の場合は、既存リソースを使うことでコスト低減を図れますが、前プロジェクトがトラブルやそれに近いプロジェクトだった場合、その結果使われているソフトウェアやシステムは、利用者たちの血のにじむ苦労の末に奇跡的に動いているのであって、それをそのまま再利用することなんてあってはならないのです。

ほぼ100%、新規で作りなおした方がＱ(品質)、Ｃ(コスト)、Ｄ(納期)すべてにおいて、安心・安全なプロジェクト活動が保証されることでしょう。