第４回　最初の大規模プロジェクト（その２：開発からサービス開始直後まで）

開発作業もけっして順調ではありませんでした。サブシステム間結合試験を開始した直後に「単体試験の机上レビューの徹底化」に黄信号が灯りました。机上レビューは観点を替えて３回実施するはずだったのに、時間がなくて机上レビューを２回しかできなかったグループ、３回実施したが肝心の観点が抜けていたグループなどがありました。早急に、該当のプログラムを再度チェックして追加レビューを計画し、サブシステム間試験と並行しながら徹夜で追加レビューを実施させました。これを見て、後続のプログラム開発担当者は、自ら各自の机上レビューの観点を見直し、サブシステム間試験の間隙を縫って机上レビューを繰り返し実施するようにりました。全体が自主的かつ前向きな雰囲気になり、今まで反対していたお客様の担当者も「机上レビュー手法」に文句を言わなくなりました。この「机上レビュー繰返し」の継続により、品質向上の底上げが可能との手応えを得ました。

しかし、本当の問題はこの先にあったのです。総合試験を開始するに当り、ユーザが使用している実端末約３０種類の内、６種類しか総合試験では使えないことが分りました。本システムでは端末制御を自前で開発していましたので、品質確保にとって致命的な問題でした。この当時の端末制御は、プロトコル、伝送速度、伝送制御手順、端末機能（割込み方式など）などが端末種類毎に異なり、いくら机上レビューで品質の底上げをしたとは言えバグを潰した保証は無く、実際の端末機で品質を確認することは常識でした。

もうひとつ問題がありました。新システムでは現行システムのハードウェアをレベルアップせずにソフトウェアだけを大幅に機能拡張するというプロジェクトだったので、性能が心配でした。しかし、肝心の負荷試験・性能試験用の開発環境（ハード）が用意できないことが判明したのです。こうした問題は当初よりある程度予想していたので、早い時期にお客様に「試験環境の充実」という要望をしていましたが、進展がなかったので次善の策として端末シミュレータによる試験を検討していました。しかし、端末シミュレータでは限界があったので困っていました。そこで本プロジェクト責任者の上司の方に、「試験環境充実」を要望しましたが、サービス開始を半年延期することになるために拒否されました。実情としてお客様の責任者の立場や他部門との調整や予算的処置など様々な課題があったようでした。

お客様からは「サービス開始まで未だ６ケ月もあるので、得意の机上レビューでバグを撲滅して下さい」と机上レビューに矛先を替えられてしまいました。更にその上の上役に要望に伺いたいという思いもありましたが、折角築いた責任者との関係を悪化することを恐れ、机上レビューや他の方法で出来る限り品質を向上することにしました。しかし、机上レビューには限界があり、サービスを開始できるレベルの品質を保証するのは困難でした。もはや、バグ発生後の対処策を用意するしか手がありませんでした。端末制御関係のバグはシステムダウンにつながるので、システムダウン後の対応処置を検討しました。システムダウンの起因の端末番号および発生したプログラム名をシステムダウン時にコンソールに印字出力し、システムダウン発生原因究明の早期化を促し、システム再開時に該当端末および該当プログラムの使用を禁止処置して、再度システムダウンを繰り返すことを防止する処置をとりました。（現行システムでは同じ原因でシステム再開後にシステムダウンを繰り返すトラブルが多かったのです）。

サービス開始日の前日ギリギリまで、現行システムのデータログを端末入力データに利用した試験ツールで、業務確認を通常日、月末日、年末、年度末などのパターンで実施しました。現行システムは全国６センターで稼動していたので、６センター分の業務処理を実施しました。総合試験の試験時間は、平日の深夜時間および休日の昼間時間・深夜時間可能に限定されていたので、移行試験と業務パターン試験をこなすのが精一杯でした。新システムへの移行処理は、ファイル関係が大幅に変更になったので移行試験および移行後の検証にかなりの時間を使いました。結局、負荷試験不足＆性能試験不足への対策としては、システムダウン発生時の仕掛けだけしか出来ませんでした。年末年始も殆ど全員出勤して品質向上に努めましたが、最後は神に命運を任せるしかありませんでした。こうして、サービス開始当日を迎えたのです。

サービス開始は、１月半ばの土曜日でした。前日夜からの移行作業も予定通りに進み、朝９時に新システムのオンライン業務を開始しました。午前中はシステムの状況は順調でトラブルが発生しなかったので、午後１時からお客様側の関係者が集まって、新システムのサービス開始のお祝いパーティを始めました。午後３時頃にシステムダウンが発生したので一瞬緊張しましたが、システムダウンの被害も軽微でかつ直ぐシステム再開したので問題にはなりませんでした。このシステムのサービス開始初日としては順調といえる初日だった様子で、殆どの関係者がこのシステムダウンを問題視していなかったようでした。こうして、祝賀パ－ティは新システムのサービス開始成功の雰囲気で夕方に終りました。

しかし、筆者およびお客様の責任者は心配していました。トラブルの発生状況からトラブルの原因が端末制御のバグだと予測出来たし、そこに不安を持っていたからでした。特に土曜日という端末負荷が低い日に発生したから余計に不安でした。土日を費やして、原因究明努力しましたが、バグ原因は突きとめられませんでした。

月曜日には、別の大きな問題が発覚しました。移行処理で一部の業務のバッチ処理データが喪失された不具合状態のまま新システムのバッチ処理が２日間走行した時点でトラブルが発覚し、先週の土曜日分（サービス開始日）のバッチ処理から順次、リカバリ処理を実施しました。サービス終了後のシステム停止以降からシステム開始までの深夜時間帯に、毎日リカバリ処理を実施して、バッチ処理データをリカバリ完了するまでに１週間を要しました。

この間にオンラインのシステムダウンが月曜日１回、火曜日２回、水曜日２回、木曜日２回と発生し続けました。水曜日に最初のシステムダウンの原因（バグ）が判明しました。端末からの割込み処理プログラムに特定の端末だけで発生するバグがあったのです。このバグ発生は明らかに恐れていた負荷試験の不足、端末機器の実端末試験不足を証明していました。メンバ全員の必死の努力が功を奏して、システムダウン８回の原因（バグ）が順次判明していきました。しかし、次の土曜日に１０時間におよぶシステム中断が発生しました。サービス開始から８日間で、オンラインシステムダウンが計１０回（６件のバグ）、バッチ処理の重大障害が１回（１件のバグ）という惨状でした。お客様の業務運用担当の多くの方から、品質の悪さを痛烈に非難されました。非常に不謹慎ではありますが、「天変地変が起こってシステム運用が長期間中断せざるを得なくなり、その間に品質向上をさせて欲しい」と心の中で願ったほど、惨めな思いをしました。「今後はこういう思いは絶対したくない」と心の底から思ったのもこの時でした。