IT業界の負の遺産！ ブラックすぎる事例紹介と、対処方法について検討してみた！

ITの世界で働いていると、よく「負の遺産」と呼ばれるものに出会います。

• 前任者が居なくなって、仕様を誰も知らないシステム
• ソースコードがグチャグチャで誰もメンテ出来ないシステム
• そもそもソースコードがないシステム
• 誰も使った事がないようなプログラム言語・ライブラリで作られている

など、様々な理由で「負の遺産」となってしまうシステムがあります。

今回は、私がこれまで出会った「負の遺産」の紹介と、「負の遺産」にならない為の考察をしてみたいと思います。

[事例１] 皆んなバラバラ・・・

Accessで作られたシステムの、プログラム修正を行う仕事を受けました。

なんで、仕様を知ってる開発元に仕事を依頼しないの？
と疑問に思いながら、いざ向き合ってみると・・・

• ユーザ持っている Access のプログラムバージョンがバラバラ（中のソースがバラバラ）
• テーブルの構造もバラバラ、画面の入力項目数もバラバラ
• 自分が使いやすいように、ユーザ自身がシステムを改造している

などなど・・・混沌とした状況でした。

開発元は “スケジュールの調整が難しい” と断ったみたいです。
おそらく、この状況を知ってて、仕事を受けなかったと思います (orz)

あー仕事受けちゃった・・・

もう、やるしかない。

でも、全てのファイルを修正しててら赤字になるので、

「プログラムを修正するAccessファイルを1つだけ選んて下さい」

と、お客に頼みました。

数日後、修正を行うファイルが提示されました・・・

しかし・・・ システムを自分で改造したユーザから

と怒号が入るなど、収集がつかなくなってしまいました。
結局、怒号男を含め、いくつかのファイをに修正するハメになりました…

原因 なぜ「負の遺産」となったのか

このシステムは私が関わった時点で、負の遺産化していた為、人から聞いた話ですが、以下の問題がありました。

• プログラムのバージョン管理をユーザ任せにしていた

プログラムの修正を行い、ユーザに修正版を配布する際、メールでAccessのファイルを送っていただけだった。
→ こんな配布の仕方では、面倒くさがりのユーザはきっと、修正版を適用しないでしょう…

• Accessのマクロでプログラムを作成していた

簡単なツールレベルのシステムだったので、Accessマクロで作っていた。
しかし、マクロはシステムを利用するユーザからも参照でき、編集も出来てしまうため、多少プログラムが触れる人であれば、簡単に改変出来てしまいます。

考察 どうすれば「負の遺産」とならなかったのか

• バージョン管理を適切に行う

これは当たり前ですが、バージョン管理を適切に行いましょう。

資産配布の仕組みを作って、最新バージョンのプログラムをユーザの端末に自動的にダンロード させる仕組みを作れば、ユーザの手間が省けて、さらにバージョン管理の問題も解消されます。

支店間で社内ネットワークが繋がっていないなど、↑の資産配布が難しい場合は、最新バージョンを使用していないユーザには、システムを起動できないように制御するプログラムを作成するなど、確実にユーザに最新版を使わせる方法をとれば、問題は解消されるでしょう。（別の不満が出そうですが…)

• プログラムの改変を出来なくする

システムを Webアプリケーションにして、ユーザはブラウザからアクセスするようにすれば、プログラムを改変される事は、よほど無いと思います。

しかし簡単なデータ集計ツールなどであれば、Accessマクロで作った方が、コストが安く済むため、そうはいかない場合があります。
この場合、Accessマクロにパスワードロックをかける等すれば、容易に改変する事は出来ない為、そういった対策をとりましょう。

ACCESS VBA (マクロ) にパスワードを設定する方法

[注意]
パスワードロックをかける場合、パスワードの管理をしっかりしましょう。
パスワードを紛失すると、プログラムの修正が出来ない「負の遺産」となってしまいます (笑)

[事例２] 改修費用が見積もれない…

次は、規模の大きいシステムを改修した時の話です。

このシステムの大半の画面に、簡単なチェック処理を追加することになりました。
単純に “画面数 (100画面) × 費用” で簡単に見積もれるハズが・・・

画面毎に全然プログラムの書き方が全然違う。

ヒドい場合は使っているフレームワークが違う。

など、意味不明な状況になっていました。

結局、うまくいかず、赤字案件になってしまいました (涙)

---

原因 なぜ「負の遺産」となったのか

• 開発時に下請け会社にまる投げしていた

中国へのオフシェアを含め、計4社に開発を発注していました。
とにかく、管理がずさんでした・・・

・確認するのは進捗のパーセンテージのみ

・中身のソースは確認していない

・スケジュール通り開発が進んでいるので OK

・少しテストしてみたら、割とちゃんと動いた

・なんか、このまま進めれば大丈夫そう！

という感じで、気がつけば納品の日を迎えていました。

しかし、安心したのもつかの間、蓋を開けると、とんでもない事になっていました。

急いで、開発方針に沿ってないと、各社に修正を依頼しましたが、

と言われ、揉めに揉めたけど、結局直してもらえませんでした。

結局、バラバラの作りのまま本番を迎えてしまい、簡単な修正でも改修費用が、膨大にかかるシステムを生み出してしまいました。

考察 どうすれば「負の遺産」とならなかったのか

• コードレビューを実施する

最低でも、開発者毎に2本はコードレビューをしましょう。
1本目で、開発方針通りにプログラムが作成されているかチェック
2本目て、指摘内容を理解し、正しい書き方を継続しているかチェック

• 情報共有をする

Slack 等のチャット形式で、簡単に質問できる環境を作ると、気軽に質問できて、さらに質問内容がメンバーに共有されて便利です。

ソースの管理についても、発注元が gitなどのソース管理環境を準備しましょう。
いつもで内容を確認出来るようにすると、問題を早く検知出来ます。

最後に

如何でしたでしょうか？
同じ経験をされた人も、いるのではないでしょうか？
今後はこの経験を生かして、「負の遺産」を生み出さないように、頑張りたいと思います。。。