タイトル-ITコラム
IT購入時点で整理すること 〜車と注文住宅を買う時に同じやり方でいいのでしょうか〜 有限会社ASTコンサルタント ITコーディネータ 大澤  昌
IT購入時点で整理すること 〜車と注文住宅を買う時に同じやり方でいいのでしょうか〜 有限会社ASTコンサルタント ITコーディネータ 大澤  昌

 前回の4月号で、「IT購入時点で整理すること」が書かれていますので、今月号は、発注者の立場でITの購入を決定した後の、「システム開発時の注意点」を書いてみます。

 システムを開発し始めますと種々のトラブルに遭遇します。いくつものトラブルを克服して、開発も最終段階に入ってきた時点で「部分的なテスト」と「総合的なテスト」を実施することになるのですが、この準備が大変やっかいです。
 たとえば、販売管理のシステムを開発して日次の集計がOKとなり、次に締め日にお客様への請求書も出す段階のテストを行うことになりました。
 月末締めのお客様ばかりとは限りません。仮に20日締めのお客様が数件あった場合、その全ての請求書が正しく発行されるか確認をしなくてはなりません。更に、月末締めの請求書に20日締めのお客様の分が発行されないようになっているか確認しなくてはなりません。その場合、20日以降の売り上げデータをきちんと用意しておかないといけません。というのは、その月にお取引が1件も無い場合は請求書を印刷しても無駄ですので、そのお客様への請求書そのものを印刷しないというルールを作って運用する場合があります。そのルールを採用する場合、本当に打ち出されなくても良いケースなのか十分に検証されなくてはなりません。前月の売掛金の入金が遅れている場合は当該月に1件も売り上げが無くとも売掛金の残高が0円でない限り請求書を出す必要があります。請求書の発行という基本的な商取引の場合、ミスは許されません。可能な限り、事前に種々のケースを考慮してテストをすることが重要です。

 テストが1回で成功しないケースを考慮して、テスト予備日をあらかじめ設けておきましょう。特に月末、月初の場合、多くの企業では忙しい最中にテストを行うことになりますから、できるだけ、月末、月初を避けてテスト日を設定することが大事です。もしくは、予備テストを十分に行い、月末、月初でのテストを短時間で済ませられれば、ユーザーの信頼を勝ち取ることができるでしょう。最悪の場合を想定して、翌月に再度テストを行ってもスケジュールに支障が無いように事前に予定を組むことも大事になります。
 テストはシステム開発でも後半に位置するので、開発が後ろにずれ込んだ場合、当初予定したテスト期間を確保できないケースが出てきますが、テストを簡略化するのはお勧めできません。机上リハーサルで十分信頼性が確保されているからと、実機テストを省略したり簡略化したりすることは、後日に問題が起こる可能性を孕んでいます。「ツケ」は必ず回ってきますのでテストの期間は十分な余裕を持って設定してください。

 平成18年12月1日午前0時に首都圏のJRで正規のスイカ定期券を、ある特定のメーカー製の自動改札機が認識できないというトラブルが発生しました。急遽、自動改札を全部開いて運用するという事態が発生しました。幸い午前5時にはトラブルの原因が突き止められ復旧しましたが、これがラッシュ時に発生したらと思うとゾッとします。
 残念ながら、トラブルは起こってしまうものです。初期においてはオペレーターの操作ミスも頻繁に発生します。入念な準備と平行して、ヘルプデスクを設置したり、説明要員を確保したりすることも大事だと思います。

(2007年5月 vol.310)