2015年に出版した
『業務効率UP+収益力UP 中小企業のシステム改革』幻冬舎 (2015/9/18) より
書籍内のコンテンツをタイトルごとに公開いたします。
コンテンツの最後に、コンサルタントのコメントを追加しておりますので、合わせてご覧ください。
P.201～
第4章
「To Beモデル」のシステム構築＆改修で、業務効率・収益力を向上させる
ベンダーが悪いのか、ユーザーが悪いのか
Ａ社の側は認識していませんでしたが、今回の問題のきっかけとなったのは、長年Ａ社のシステムの保守管理を、ほぼ一人で担当してきたＢ社のシステムエンジニアの退職でした。
ＩＴシステムというものは、おおぜいで作りあげるものというイメージがありますが、全体を構成する部品に関しては一人で作ることが多いものです。そして、同じような動作をするプログラムであっても、書く人によってその中身は大きく異なります。
たとえば、プログラム言語が違えば、動作が同じでも、その中身はまったくの別物です。
それは「この先はどこに続いていますか？」という質問文を、日本語で言うのと、英語で言うのと、中国語で言うのとでは、発音も構文もまったく異なるのに似ています。
同じ言語を使っていても、プログラムの書き方には個人の癖がありますから、中身が異なることはよくあります。同じ日本語でも「この先はどこに続いていますか？」とも「この道を行くとどこに出ますか？」とも言えますし「こっちには何がある？」と聞くこともできます。
そのため、一般的には、他人の書いたプログラムを解析するのは大変だと言われています。
他人の書いたプログラムを直すくらいなら、自分で一から書いたほうが速いなどと言う方もいるくらいです。前置きが長くなってしまいましたが、Ｂ社のエンジニアの退職は、彼の担当してきたＡ社のシステムの中身をブラックボックス化してしまいました。Ａ社のシステムを引き継いだＢ社の新しい担当者は、長年パッチ（アップデートプログラム）をあてられ続けて、つぎはぎの度合いが激しいＡ社のシステムの動作を解析するのに、相当、苦労していたようです。Ａ社のシステムの不具合が多くなったのは、担当者の退職という、よんどころない事情も関係していたのです。
また、10年前に基本形が作られたまま、拡張を繰り返してきたＡ社のシステムは、木造のアパートのつもりで作り始めたのでそれなりの基礎工事しかしていなかったところに、無理やりコンクリートの高層ビルにまで改築を重ねたようなものでした。
ここまで大きくなることを最初に想定していなかったので、基本構造が悪く、何か一つ機能を追加するたびに、あちらをいじり、こちらをいじりで、とてもメンテナンスがしづらいものになっていました。
もちろん、仕様書も設計書もろくにありません。なぜならば、Ａ社の要求が「とにかく早く作ってくれ（直してくれ）」だったからです。設計書や仕様書を丁寧に書く時間を惜しんで、スピード重視で作業してきた結果が、現在の惨状につながっているのです。これは、スピードを最も重視することを両社合意のうえで進めてきたため、今さらそれを言っても仕方がありません。
仕事を引き継いだ担当者は、仕組みに慣れていないので、以前の担当者ほど迅速に改修ができないのも無理はありません。
基本設計から筋の通った構造ではなく、基本が木造アパートであるところを、つぎはぎで高層ビルに仕上げたシステムです。比喩で言うならば、直通のエレベーターも階段も通っておらず、階を上がるたびに階段を探してフロアを歩き回らなくてはならないような構造です。
動作スピードも改修スピードも速くなるはずがありませんし、ちょっと道に迷うとすぐにエラーになってしまいます。
ところが、そのような事情はＡ社には伝わっていませんでした。
木造アパートの頃は簡単に２階に上がれたのに、なぜ今は２階に上がるのに倍の時間がかかるのだとばかりに、クレームがＢ社に寄せられていました。
改修に改修を重ねてきたので、プログラムの動作の効率も悪く、それがＡ社の「だんだんと速度が遅くなってきた」という不満につながっていたのです。
Ｂ社から見れば「当たり前」なのですが、Ａ社の目には「昔は良い仕事をしていたＢ社が、最近は手を抜いて怠慢になってきている」と映っていたのかもしれません。
たしかに、通常の操作をしているだけなのに、急にダウンするようなシステムになっていました。
私どもの会社の通常のソリューションであれば、一から作り直したほうがよいと提案するようなしろものです。
しかし、基礎が不安定とはいえ、現在の外観は立派な高層ビルになっています。ここまで作りあげるのに費やした金額も半端なものではありません。10年間かけて投資してきたものを、新しく作るには10年分の投資金額と同レベルの費用が必要になります。Ａ社の規模の会社で、それだけのＩＴ投資費用を捻出するのはとうてい無理な相談でした。
ITコンサルタントのコメント（2023年5月12日）
本記事で取り上げた事例では、この問題を引き起こしたポイントとして大きくは以下2点があります。
（１）充分な基盤の無いシステムに対して計画性無く場当たり的にカスタマイズを繰り返してきたこと
（２）カスタマイズのドキュメントを作成してこなかったこと
性善説で考えれば、ベンダー（B社）はシステム開発のプロであるはずなので、（１）（２）がもたらす弊害は少なからず把握でき、対策をユーザー（A社）へ伝えるべきだったとも考えられます。
ですが、（２）はまだしも（１）を契約上謳うことは困難なため（「何か将来的なリスクが考えられる場合は事前に挙げること」などと抽象的に謳っても法的効力を持たせるのは難しいと考えられる）、ベンダーは契約上最低限の責務は果たしていた、ということになります。
そのため、ユーザーとしては自衛の策として、
（１）カスタマイズの内容が元々のシステムに対して無理のある内容となっていないかを常にベンダーに問う。ベンダーの説明に納得がいかない場合は第三者を入れる。
（２）カスタマイズを行う際は常にドキュメントを残すよう契約内容に盛り込む（納品物に明記する）
ということが必要でした。もちろんどちらについても人的、時間的、費用的なコストは増加することが多いですが、当事例のように「後の祭り」となってしまった場合に掛かるコストは計り知れません。
