◆納品（誰が、いつ、どこに、何を、どのように）
システムが完成したら、納品してもらうのだが、これが結構、あいまいになっていることがある。特にソフトウェアは、物を購入するのと違いやっかいである。新しいハードウェアに、新しいソフトウェアを搭載して、システム一式を納品してもらう場合は、単純である。
ところが、開発マシンと本番マシンが異なり、すでに既存のシステムが稼動している本番マシンに、新たなソフトウェアを導入したり、更新したりする場合が問題となる。この場合の納品形態は、以下のようなケースがある。どれにするかは、自社の力量とコストを天秤にかけて選択しなければならない。さもないと、思ってもいなかった追加の出費が必要になる。
・業者は、完成したテスト済のソフトウェア一式をＣＤ－ＲＯＭなどで納品する。テストマシンへの導入及び本番マシンへの移行は、自社で行う。この場合、納品時期は実用開始から自社内作業を差し引いた時期に納品してもらわないと間に合わなくなる。このケースでは、業者に支払う導入・移行作業費用が不要になると共に、システムの動作環境を、自社でしっかり抑えることができる。動作環境を理解しておくことは、運用段階でのトラブル対応をする上で有効である。
・業者は、完成したテスト済のソフトウェア一式をＣＤ―ＲＯＭなどで納品するが、 テストマシンへの導入及び簡単な動作確認まで行う。本番マシンへの移行を自社で行う。この場合も、納品時期は実用開始から自社内作業を差し引いた時期に納品してもらわないと間に合わなくなる。さらに、業者側に現地作業が発生するため、導入作業費用と、出張旅費が発生する。このケースでは、稼働環境について詳しくない場合、テストマシンでの立上げに手間取ることがない。その反面、本番マシン移行時にスムーズに作業できるように、テストマシンへの導入時に環境設定など、業者に十分確認しておく必要がある。
・業者は、完成したテスト済のソフトウェア一式をＣＤ―ＲＯＭなどで納品するが、 本番マシンへの導入及び簡単な動作確認まで行う。この場合、納品時期は受入検証とリハーサルに間に合えば良い。しかし、業者側に現地作業が発生するため、導入及び移行作業費用と、出張旅費が発生する。多地点や遠隔地への導入作業となると出張旅費が膨大になる。また、本番マシンへの導入・移行作業は、既存システムがすでに稼動している場合、休日対応するとなると、さらに費用がアップする。このケースでは、本番マシンでの立上げまで、業者に任せられるので楽ではある。しかし、環境設定などを十分把握しておかないと、いざトラブルになった時に自社では手も足も出ないという事態に陥る危険がある。ドキュメントと実際の本番マシンでの設定が違っているような場合、導入を担当した業者の技術者に聞かないと分からないということにもなりかねない。
システムの納品物として、ハードウェア／ソフトウェアは当然であるが、その他に忘れてはならないのがドキュメントである。主なドキュメントには、以下のようなものがある。
・設計書（外部設計書、内部設計書、プログラム設計書等）
・試験計画／報告書（単体試験、統合試験、システム試験）
・マニュアル（プログラマーズマニュアル、ユーザーズマニュアル）
しかし、このドキュメント、結構、費用が掛かる。完璧な設計書を求めたりすると、ソフトウェアの制作費より、設計書の制作費のほうが高くついてしまう。その割に、膨大な設計書は、運用保守には役に立たなかったりする。そこで、おすすめなのが設計書と兼用の「プログラマーズマニュアル」である。内容は、あくまでプログラマが、システムを運用保守するために必要な情報を網羅するものである。ソースコードを読めば理解できるような情報は記載しない。それよりは、ソースコードがどこにあるかを明記しておく。また、トラブル発生時のリカバリ手順なども明記しておく。以下に、記載項目の例を示す。
・システム概要
・システム構成図
・ソフトウェア構造図
Ｊａｖａなどでは、ソースコードから構成図（クラス図）に自動で逆変換してくれる開発ツールが無償でインターネットからダウンロードできる。著者は、解析にオープンソースのEclipsとUMLプラグインを使用している。
・システムアーキテクチャ
・ソフトウェアコンポーネント一覧表
・外部インターフェース
・データファイル関連図
・ジョブネットワーク
・ディレクトリ構成
・環境設定ファイルの説明
・コンパイル方法と配備方法
・リカバリ手順
次に、試験報告書であるが、これも試験結果を確認できれば、あとは使用することのないものであるので、あまりお金を掛けてもしかたがない。できるだけ、簡素化してコストダウンしたほうが良い。例えば、試験中の処理結果画面のハードコピーにマーカなどして、綴じる程度で、体裁にはこだわならない。必要もないのに大量のダンプリストなどを納品されるのは困りものだ。そのような業者に限って、そのダンプリストの内容を確認せずにいる場合がある。あきらかに結果リストがおかしいことを示しているのに、試験結果良好といって納品してきた業者もある。確実に結果が要求と一致していることを確認した痕跡として、マーキングは必須である。
最後に、ユーザーズマニュアルを、納品物とするか否かであるが、これも、意見が分かれるところである。著者は、できるだけ自社で作るべきものと考えている。理由は、業者が作成するマニュアルは、システムの操作マニュアルであって、実際の業務では、そのまま使えないことが多い。そもそも、仕様書を作成したのであるから、それを流用し、業務プロセスに沿って、どの画面や帳票を使うのかを記述したほうが、業務担当者には親切だと考えるからだ。使えないような、分厚い操作マニュアルをお金を払って製作してもらうのはムダではないか。
コメント