◆機能
まず検査すべきは、機能である。要件定義書や要求仕様書に記載されている要求機能が、正しく実現されていることを一通り確認する。この時、先の述べたトレーサビリティが確保されていれば、漏れなく、素早く検査を実施することが出来る。数ヶ月前に書いた要件定義書や要求仕様書が、何を書いているのか分からない、納品物との間でトレーサビリティが確保できない。こういったケースも少なくない。このような状況では、検査に手間取ることはもちろん、何を検査すれば良いのか、どこまで検査すれば良いのかも分からない。
不具合を発見した場合でも、それがプログラムの欠陥であるのか、そもそも要求事項から漏れていたのかさえも怪しくなってくる。実際に、ユーザの受入検査で、不具合だと指摘された事項でも、仕様書に遡って見ると、要求事項が漏れていたり、あるいは、最初からそういった動作を要求していることがある。要求仕様が不明確であると、この調査に時間がかかるが、なんとか仕様書上の記述箇所を探して、ユーザに説明すると、そのような要求をしていたこと、あるいは、要求していなかったことを「忘れて」いるのである。
人間の記憶とは、かくも不確かなものである。ゆえに、要件定義書や要求仕様書は、第三者への情報伝達手段だけでなく、将来の自分への情報伝達手段でもある。後から読み返したら、自分でも何を書いたのか忘れてしまって理解できないというようなことが、ないようにしておかなければならない。あくまで、要求文書に基づいて検査をし、不具合があればリストアップし、是正を要求する。
要求どおりに機能が実現されているかをチェックするのは当然であるが、要求していないことが実現されていないかも忘れずにチェックしたい。要求していないような機能が盛り込まれていることで、ムダなコンピュータ資源を浪費することもあるので、サービスとばかりに喜んでもいられない。不必要な機能は、取り外すように請求しよう。また、通常の処理機能だけでなく、例外処理やエラー処理についても漏れなく検査したい。こういった、機能は実際の業務でも発生する頻度が低いため、検査で発見しないと、実用開始後に数ヶ月、あるいは、数年後に突然、不具合を発生することもある。
さらには、意図しなていない使い方をしてみるという検査をすることで、信頼性や可用性もチェックすることができる。例えば、数値属性項目に文字を入力した場合、システムが停止することなく稼動を継続できるかどうか、適切な警告メッセージを表示するか、などを検査する。これまでにも、要求事項に無い操作をした場合、安易にシステムを停止してしまうような設計がなされているケースがあったが、これでは、技術者としてのモラルを問いたくなる。技術者ならば、利用者が想定外の操作をした場合でも、システムが停止することのないようにするか、被害が最小に抑えられるような安全サイドの設計をしていただきたいものだ。ちなみに、専門用語では、フェイルセイフ又は、フェイルソフトと言う。
その他、万一、システムが障害を発生した場合を想定して、どのくらいの被害に抑えるか、そして、簡単に復旧できるように設計されているかも検査する。要件定義などで、障害が発生しても業務を継続できることとした場合は、二重化などの設計が当然されているものであるが、そうでない場合であっても、復旧が簡単にできるか、どうかは重要な問題である。障害発生時に、自動的に入力データやトランザクションを退避保存し、データベースなどを障害発生前の状態に戻すような設計がされていれば良いが、そうなっていない場合は、全て手作業で復旧し、最悪の場合、再度データを入力しなおすハメになる。
自動車などのハードウェアは、納車時に、衝突検査してエア・バッグが確実に作動するかどうかをチェックすることは難しいが、システムでは、物理的に破壊や損傷して現状復帰できなくなる心配がないので、何度でも障害を発生させて、その時の動作を確認することができるのが良い。まして、ハードウェアに投資して二重化したような場合、肝心の障害発生時に処理が継続できないようでは、せっかくの投資が無駄になるので必ず確認すべきである。
一通り機能をチェックしたら、不具合事項に優先順位を付けて、いつまでに是正するかを業者と調整し、どのようなレベルで検収するかを確認する。基本的には、不具合は全て是正してから検収とするが、スケジュールが切迫しており、次の運用試験に進みたいというような場合は、重要項目のみを是正したら検収し、残りは、運用試験完了までに是正するというような取り決めをし、必ず、文書化した上で、検収する。
些細な不具合にこだわって、スケジュールを遅らせるよりは、ある程度妥協して検収したほうが得策である。正当な理由なくして故意に検収を遅らせると、法的な制裁を受ける恐れがあるが、些細な不具合の１件までもが「正当な理由」に当たるかどうかは常識的に判断する。自社の業務システムは、あくまで業務の道具（手段）であり、目的は、使ってナンボ（儲けること）である。業務上の利益貢献に対して影響の小さいような不具合は、後から是正しても遅くは無い。何も「完璧なシステム」を追求する必要など、どこにもない。最小の投資で、最大の効果を生むシステム構築では、このあたりを判断して割り切ることが肝要である。
コメント