納品されたシステムに対する効果的な検収方法：企業システム戦略の基礎知識（9）（2/2 ページ）

[青島 弘幸，＠IT]

保守性──判断基準は「美しさ」と「シンプルさ」

　プログラムの保守性については、要求仕様書に明記しないのが普通である。そのためか、自社で保守しようとしても、どこがどうなっているのか分からないようなプログラムを納品する業者も少なくない。業者の品質検査でも、機能・性能について要求仕様を満足するかどうかを検査するが、保守性までは検査しないことが多い。　しかし、プログラムが保守しやすいかどうかは導入する企業にとって、重要な問題である。基幹の業務システムであればあるほど、事業環境の変化に合わせて長期にわたり、プログラムを保守していかなければならない。10年以上保守を繰り返し、使い続けられるシステムも珍しくない。このときに、保守性が悪くプログラムの改修コストが膨れ上がり、システムが生み出す利益を圧迫するようでは困る。さらに、保守性が悪いために、事業環境の変化にシステムを順応させることができず、経営の足手まといになるようでは本末転倒である。

　そのようなことにならないように、受け入れ検査の時点でプログラムをサンプリングし、ソースコードをひもとき、保守性の良しあしをチェックするのがよい。

　総合判断の基準は「美しさ」と「シンプルさ」である。これなら、プログラムについての専門知識は、ほとんど不要である。それでも、大抵の場合「美しい」プログラムは「シンプル」であり、品質や保守性も良いことが多い。まさにプログラムは「シンプル・イズ・ザ・ベスト」「ビューティフル・イズ・ザ・ベスト」である。逆に、パッと見で「汚い」プログラムは、それだけで「複雑」であり、品質も怪しく、保守性も悪いことが多い。

保守性の簡単なチェックポイント

• 1つの処理ブロックについて、20?30行で書かれているか
• 適宜に字下げをしてブロックの分かれ目が判別しやすくなっているか
• 字下げが、4段も5段も繰り下がっていないか
• 適切な個所に適切なコメントを記述しているか
• 意味不明な変数名やプログラム名を使用していないか
• 同じような記述が、あちこちに何度も出現していないか

　保守不能と思えるほど、迷路のようなプログラムを大量に納品されて途方に暮れる前に、特に初めての業者に対しては、最初に数本のプログラムを発注し、ソースコードを詳細に検査し、保守性に対するモラルや作業標準などの整備・順守状況を確認することをお勧めする。

　とにかく、保守性の悪いプログラムは、長期的には機能・性能が悪いプログラムよりもたちが悪い。保守性が良ければ、機能や性能は改善していけるが、保守性が悪いプログラムは、最悪の場合、捨てて作り直すしか手がなくなるのである。これほど、ムダな投資はない。

ドキュメント──トレーサビリティ確保のために

　ドキュメントがなくてもシステムは動く。しかし、納品物としてはプログラムと同様に重要なものである。1つには、要件定義や要求仕様が確実にプログラムに盛り込まれているか、その作業過程の結果としての設計書や試験報告書として。もう1つは、システムの運用保守に必要な情報源として。

　検査のポイントとしては、プログラムと同様「美しさ」と「シンプルさ」が総合的な判断基準となる。さらに、要件定義書や要求仕様書から、プログラムに至るまでのトレーサビリティが確保されていることが重要である。

　トレーサビリティが確保されていないと、要求事項が設計書とプログラムに確実に反映されているかどうかを確認することが困難であるばかりでなく、保守においても使いづらいものとなる。

　特に、保守においては、プログラムの保守性を補完するものであるので、プログラムとの関連性が不明確なようでは、結局、プログラムを解読しなければならなくなる。最悪の場合、どのプログラムを解読すれば良いのかさえも分からなければ、全体をしらみつぶしに調べるハメになる。

　個々のプログラムや設定の内容について技術的に詳細に記述しているだけでなく、プログラムの保管場所や設定内容の変更方法、システムの全体構成やプログラム間、データ間の関連がどうなっているのか、これらの基本的な情報も忘れずに記載されている必要がある。

瑕疵──どれを是正要求するかを検討する

　以上の検査の結果、要求事項に対して正しく作業されていない点については「瑕疵（かし）」として、業者に是正を要求する。すなわち「瑕疵」とは、欠陥のことである。この場合の是正作業に要する費用は、基本的にベンダの負担、すなわち無償となる。そのため、業者としては、瑕疵であることを簡単には認めない。場合によっては、瑕疵であることを発注側であるわれわれが証明しなければならないこともある。そのときに重要になってくるのが、要件定義書や要求仕様書の明確さや、設計書およびプログラムとのトレーサビリティである。

　また、受け入れ検査で発見できなかった瑕疵については、瑕疵担保期間内であれば検収後でも無償で是正を要求できる。発見した「瑕疵」および「瑕疵と思われる不具合」は、すべてリストアップし、優先順位を付しておく。この優先順位は、もちろん、システム構築の目的に照らして考える。ただし、この優先順位は絶対的なものではない。業者と調整のうえ、システム実用開始の遅れによる機会損失を考慮し、最終的にいつまでに是正するかを決定する。特に是正に時間を要するものは実用開始のために当面の代替案を考える。

　欠陥は、もちろん業者側の責任には違いないが、そのことにこだわって、すべての欠陥が是正されなければ検収しないという考え方では、本来のシステム構築の目的を達成できなくなる。今日のスピード経営において、100点満点主義を押し通していては、事業環境に対する機会損失によるリスクの方が大きい。是正が完全に処置されるころには、すでに市場競争から取り残されているのでは本末転倒である。ここは冷静にリスク評価をして妥当な線で、妥協するのが得策である。取りあえず、実用開始に必須の欠陥のみに絞って是正し、残りは実用開始してから是正するよう、後回しにしてはいかがだろうか？

　次回は、受け入れ検査におけるトラブル対策について見ていこう。

著者紹介

▼著者名　青島 弘幸（あおしま ひろゆき）

「企業システム戦略家」（企業システム戦略研究会代表）

日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者）

大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。

「システム構築駆け込み寺」を運営している。

メールアドレス：[e-mail]