◆保守性
プログラムの保守性については、要求仕様書に明記しないのが普通である。ところが、後で自社で保守しようとしても、どこがどうなっているのか分からないようなプログラムを納品する業者も少なくない。これは先に述べたように、プログラムというものが個人の能力あるいは性格に依存しているからである。業者の品質検査でも、機能・性能について要求仕様を満足するかどうかを検査するが、保守性までは検査しないことが多い。それは、保守性を検査するには、プログラムのソースコードを目視検査しなければならないからで、これは非常にコストが掛かるからである。
機能・性能が要求仕様を満足すれば、とりあえず契約は履行したことになるので、そこまでコストを掛けては業者も利益を圧迫する。その為、プログラムが保守しやすく作られているか、どうかは個人任せになっており、リーダやマネージャも感知していないことが多い。中には、作業標準などが整備されており、内部レビューなどで標準に準拠してプログラムが作成されているか、どうかを検査している業者もいるが、極めてまれなケースで ある。
しかし、プログラムが保守しやすいか、どうかは導入する企業にとっては、重要な問題である。基幹の業務システムであればあるほど、長期に渡り事業環境の変化に合わせて、プログラムを保守していかなければならない。１０年以上保守を繰り返し、使い続けられているシステムも珍しくない。この時に、保守性が悪ければプログラムの改修コストが膨れ上がり、システムが生み出す利益を圧迫するようでは困る。さらに、保守性が悪いために、事業環境の変化にシステムを順応させることができず、経営の足手まといになるようでは本末転倒である。「動けばよい」というようなことでは、せっかく初期投資を抑えても、すぐに大掛かりな作り直しが必要になり「安物買いのゼニ失い」ということになりかねない。
そのようなことにならないように、受入検査の時点で、プログラムをサンプリングし、ソースコードを紐解き、保守性の良し悪しをチェックするのが良い。言語や内容にかかわらず、見やすくなっていれば、まずは合格点である。その主なチェックポイントを次に示す。
・一つの処理ブロックについて、２０～３０行で書かれているか
・適宜に字下げをしてブロックの分かれ目が判別し易くなっているか
・字下げが、４段も５段も繰り下がっていないか
・適切なヶ所に適切なコメントを記述しているか
・意味不明な変数名やプログラム名を使用していないか
・同じような記述が、あちこちに何度も出現していないか
総合判断の基準は「美しさ」と「シンプル」である。これなら、プログラムについての専門知識はいっさい不要である。それでも、大抵の場合「美しい」プログラムは、「シンプル」であり、品質や保守性も良いことが多い。まさにプログラムは「シンプル・イズ・ザ・ベスト」「ビューティフル・イズ・ザ・ベスト」である。逆に、パッと見で「汚い」プログラムは、それだけで「複雑」であり、品質も怪しく、保守性も悪いことが多い。
検査の結果、あまりにも酷い場合には、業者に書き直しを求めてみても良い。しかし、先に述べたように、契約上は機能・性能が満足していれば良いので、無償で快く書き直し てくれる業者は少ないかもしれないが、これは、その業者のモラルに頼るしかない。保守不可能に近いほど、迷路のようなプログラムを大量に納品されて途方にくれる前に、特に、初めての業者に対しては、最初、数本のプログラムを発注し、ソースコードを詳細に検査し、保守性に対するモラルや作業標準などの整備・遵守状況を確認することをお勧めする。
また、同じ業者であっても、実際に担当するチームが異なる場合は、人によってプログラムの作り方が変わって来るので、プログラムが数本完成したところで、ソースコードをチェックして問題があれば、早めにリーダに改善を申し入れるようにしたい。
とにかく、保守性の悪いプログラムは、長期的には機能・性能が悪いプログラムよりもたちが悪い。保守性が良ければ、機能や性能は改善して行けるが、保守性が悪いプログラムは、最悪の場合、捨てて作り直すしか手が無くなるのである。これほど、ムダな投資は無い。
コメント