ソフト開発監査チェックリスト（１０）保守性要件管理技術
要件管理チェックリストの３つ目は保守性です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では②要件管理の中の構成管理の個々の項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般）の記事に載っていますので、そちらをご覧下さい）
保守性では故障が起きた時の対応についての機能をチェックします
保守という言葉は故障が起きた時の修理にも使いますが、故障が起きないようにする点検する時にも使います。そして修理も点検も形のある製品を売るのではなくて保守という名前のサービスを提供する事です。装置や機器を販売したメーカは、販売した後にその装置や機器が使われている期間は、保守サービスを提供するのが普通です。
ところで少しは話がそれますがサービスという物は本来は有償です。サービスという言葉は日本人は無償で提供される物と考える人も多いのですが、サービスとは対価を支払って受け取るなんらかの活動なので、本来は有償なのです。ですので、保守サービスも本来は有償です。
ただし、販売して半年や１年で故障してしまってはあまりにも品質が悪い製品を売った事になって、メーカとしての信頼が無くなってしまいます。 ですので普通は１年程度の無償保証期間というのが設けてあって、この期間に問題が発生したら無償で保守サービスつまりや修理や代替品の提供を受ける事ができます。
そしてこの保守サービスを提供するために、装置や機器には予め保守のための機能が組み込まれています。故障した事をLEDで示したり、メーカの保守員が故障個所を診断するための調査用の機器をつないで内部を調べたりできるのは、装置や機器に保守機能が組み込まれているからです。
このような、装置や機器が持つ保守機能が要求仕様書にどのように書かれているかを確認するのが、保守性に関するチェック項目です。項目番号が SA- で始まる５項目ですので、順にみていきましょう。
【項目番号：SA-01】
装置や機器に組み込む保守の機能には、いろいろな種類があります。そしてどの保守機能も、その保守機能を使った保守サービスと一体となって使われます。例えば、メーカのサービス員が修理の現場で交換する部品を選ぶために使ったり、最近ではメーカの保守センターからインターネット経由で装置や機器の故障の状態を調べたりもします。このように、保守機能はそれを使う保守サービスの形態によって必要な機能が変わるので、まずは保守機能についての基本方針が要求仕様書に書かれているかを確認します。
【項目番号：SA-02】
保守機能の中で一番よく使うのが、装置や機器の故障個所を調べたり故障の原因を調べたりする機能です。装置が動作していた時の動きや故障の予兆などは、ログという名前で呼ばれるデータとして装置や機器に記録されています。どんなログデータを記録するのか、そのログ情報はどこに記録するのか、記録したログデータはどうやって取り出すのか、等の具体的なログ機能について、要求仕様書に書かれているかという点に注意して確認します。
【項目番号：SA-03】
保守サービスの対象はハードとソフトの両方を含みます。ハードの保守は多くの場合は故障品の修理か良品との交換です。最近の電子機器のハードは微細化と高集積化が進んだ結果、昔のように部品を交換して修理をする事はなくなり、ほとんどがモジュールと呼ぶ部品単位での交換です。
一方でソフトの場合には、まず原因となっているバグを見つけ出し、そのバグを修正したソフトを試作して、その試作したソフトで問題が解決される事を確かめて、最終的には市場の製品に搭載されているソフトをバグ修正版の物に置き換えていきます。
インターネットにつながっている装置や機器なら、インターネット経由で最新場のソフトウに置き換える事も可能ですので、最近の装置や機器ではソフトのバージョンアップ機能がついていて当然という状況になってきました。しかし、これらのソフトの保守を提供するには、ソフトの開発の期間と同等の開発組織を維持しておく必要があり、メーカとしてはかなりのコストがかかります。
どこまでのソフトの保守サービスの提供を想定しているのか、その内容によってソフトのリリース後に何年も場合によっては十何年も、開発組織を維持する事が必要になります。開発後に必要な保守のための要求仕様にあたるのですが、製品の要求仕様書にはソフトのリリース後の保守サービスとして何が必要となるか、具体的に書いてある必要があります。そのような内容が要求仕様書に書かれているか、とう点に注意して確認していきます。
【項目番号：SA-04】
装置や機器に搭載するソフトを一式まるごと他社に開発委託をした場合には、保守も丸ごと開拓委託先に業務依頼をする事になるので判り易いです。しかし多くの場合は、開発委託先にはソフトの一部分の開発やテストについて業務を委託する事のほうが多いです。一部は自社で開発し、一部をA社に他の一部をＢ社に開発を委託するという形態はよく在ります。
このような時には、リリースしたソフトウが市場で問題を起こした時の責任分界点を明確にしておく必要があります。不具合の原因を作りこんだのがA社ならA社が、Ｂ社ならＢ社が、自社なら自社が、調査と対策を行う事になります。この時に一番大切なのが、不具合の原因が何処にあるのかを判断する方法です。
不具合の原因つまりはその不具合についての責任がどの会社にあるのか、責任の境目の事を責任分界点と呼びます。この責任分界点として何を採用するのかは、要求仕様書の大切な項目です。 責任分界点が明確に要求仕様書に書いてあるか、という点に注意して確認していきます。
【項目番号：SA-05】
保守サービスの提供には様々な費用が掛かります。定期保守等の将来の故障を予防するための費用は作業内容も明確なので判り易く、費用をどこから出すのかもはっきりしています。
ところが、市場で問題が発生してその対策に費用が掛かった場合、例えばエンドユーザ宅から装置を回収したり、問題とその対策のために新たにコールセンターを設置したりすると、高額な費用が発生します。これらの保守費用は、市場で大きな問題が発生した時に初めて、どんな費用がどれくらいの金額必要になるのかが判ります。
ところで、これらの保守に掛かる費用は誰が支払うのでしょうか？ その不具合の問題を引き起こした会社が負担するのが当然なのでしょうか？ その原因が開発委託先が作ったソフトのバグだった場合、装置の回収費用やコールセンターの設置費用も開発委託先が支払ってくれるのでしょうか？ 残念ながら、開発委託先との契約書等の文書にそのように明確に書いてない限り、開発委託先はそのような費用を支払ってくれません。
そのような契約になっていなければ支払う義務は無いのです。全ての商取引は契約がベースで、その契約に書いていない事に対する責任は負いません。ですので、このような保守に必要な費用のどこまでを開発委託先に払ってもらうかを、要求仕様書で明確に書いて、その内容について開発委託先とよく相談して、合意した結果を保守契約書として締結しておく事が必要です。そのような事が要求仕様書にちゃんと書いてあるか、という点に注意して確認を行います。
保守性の次はセキュリティです
保守性の確認の次はセキュリティについての確認項目について、次の記事で紹介します。