増え続けるExcelVBAシステム改修ご相談、対応可否の話

社内の内製化により開発されたExcelマクロシステムについて、「改修相談」、「保守相談」が増加しました。

定年退職、転職、異動など、理由は様々ですが、プログラムを作った人がいなくなるという点から、「万が一の不具合に保険をかけたい」といった背景があるためです。

みなさん、こんにちは。セルネッツ竹本です。

今回のテーマは、「VBAプログラム改修ご相談」をいただいた際の「対応可否」判断までの流れをお話ししたいと思います。

◆受託可否を判断する目安とは?

システム開発会社にとって、お仕事のご相談、ご依頼は無条件で嬉しいものですが、「改修相談」となると、いったん慎重になるのが常です。

それは何故なのか。たいへん光栄であることですが、いくつかの不安要素があるためなのです。

<受託リスクとなり得るポイント>

例えば、既存プログラムの一部を改修し、無事に納品にいたったが、「不具合が見つかった」ケースです。

まずは事象を確認することが先決ですが、バグは、大きくわけて3種類あります。

1.既知のバグ

2.潜在バグ

3.未知のバグ

ご指摘の事象が、「バグ」と判断された場合、その責任が誰にあるのか?

といった責任所在をめぐる問題に発展するケースもあるため、「責任の切り分け」がしっかり出来ていないといけません。

◆どう線引きするのか?果たしてできるのか?

前述の3種類バグですが、お客様が認識している不具合もあれば、バグがあっても放置されているケースもあります。

(バグをバグと認識できていない)。

さらには、まだ知られざるバグが潜んでいるかも知れない。

こんなお話をすると「改修のリスク」が大きいことがわかるかと思いますが、不具合発生の連絡を受けた以上は、改修した側に問題がないとしても、「それを理論的に証明するまでサポートが続く」ということにもなるのです。

◆改修の可否判断は、既存ソース分析後、動作保証ができるかどうかで決まる

既存ソースの一部でも全体に影響を及ぼすケースがあります。

そうならないために、通常、改修依頼の場合は、必ず以下の工程が必要になります。

1.改修箇所を特定
2.改修方法を適用(プログラム修正)
3.それによる影響がないかどうか影響調査

その為には、現行プログラム仕様を理解することも大切な作業の一つになります。

それらを経て、不安を抱えながら、開発を行ってゆくことは受託料金とは異なる次元で考えなくてはなりません。

◆決め手は、やっぱり「可読性」と「シンプルコーディング」で判断

これまで17年におよび、ExcelVBAプログラムソースを見てきましたが、記述は2つに分かれます。

【◯】マクロ記録が多い書き方(恐らくVBA初心者によるもの)
【✕】Excel機能に頼らず、エンジニアの技術によって書いたコード

この場合、1.は受託が可能です。大量ソースでも問題ありません。

が、2.は弊社ではリスクが上回ると判断から、新規での開発提案となります。

但し、現実的には、お客様が困っていることには変わりがありませんので、何らかの代替提案はさせていただき、不安要素を除去することは可能です。

VBAソースは、やはりExcel機能を併用し、シンプルに記述することをオススメいたします。