トラブルへの対応には多くの困難が伴います。プロダクション機の情報が取得できず原因追及に着手できない，発生条件が特定できない，予想もしない個所のコードに問題がある，などなど。くだらないミスが原因であることがほとんどですが，設計時の考慮不足・知識不足によりもたらされるものもあります。今回は，筆者がこれまで体験したトラブルからいくつか「何が起こったのか」「⁠どう対応したのか」を具体的に紹介し，考察します。

トラブルと真正面から向き合う＋調べる

障害発生時にすべきこととは

ソフトウェア開発においてバグや作業ミスによるトラブルはつきものです。トラブルに遭遇したときは焦ってしまいがちですが，まず落ち着くこと。浮足立っているとよけいに事態を悪化させてしまいかねません。そして何より誠意を持って対応するというのが大切です。関係各所に連絡を取り，回避策があれば暫定的に適用していただき，データが壊れている場合，直せるものは直し，ダメなら業務側での再作成をお願いする。そのうえで，できるだけ早期にバグフィクス版をリリース，システムを復旧させなければなりません。

［事例1］納品先で固まるプログラム

新人のころ，周辺機器からシリアルポート経由でデータを受信し処理するプログラムを作成する仕事をしました。納品日，お客様の環境にインストールして動かしたところ，プログラムがハングアップして応答しなくなってしまいました。

会社の開発マシンでは問題なく動いていたので非常に焦りました。お客様にお詫びして検収を延ばしてもらい，会社に引き返して必死にプログラムを見直しました。すると，データ受信処理で固定バイトずつデータを読み出しており，指定バイト数のデータが読み取れなかった場合の考慮がないことに気づきました。そこで，読み出しのたびにバイト数を保持して，指定バイト数に達したらデータを処理（注1）するように修正しました（図1⁠）⁠。

お客様と同一機種のマシンがなかったので，バグフィクスの確証は持てなかったのですが，翌朝一番に訪問して動作を確認し，無事検収いただくことができました。経験が浅い筆者には入力待ちによるブロッキングの可能性を想像できていませんでした。

開発環境と実行環境の差でプログラムが動作しないというのはよくあります。サーバサイドのプログラムでは，本番機（あるいは本番機相当のステージング環境）でリハーサルを行うのは常識になっていますが，特定のマシンがターゲットの場合，開発時に調達するか，お客様に借りるなどして検証機会を設けたいものです。

注1）

バッファリングという処理です。

［事例2］起動しないWeb App Server

筆者がかかわっていた業務アプリ開発現場での話です。Webアプリケーションサーバが起動途中にクラッシュしてしまうという現象が何日も解決できず，プロダクション機の構築担当チームが途方に暮れていました。筆者ら開発者も支援に入りましたが，はじめて使用するプロダクトというのもあってログを見ても原因がわかりません。スケジュール的に待てない状況だったので，プロダクト製造元のトラブルシュート専門技術者が召喚され，クラッシュ時のメモリダンプを解析しました。それでも原因特定できません。そこで，あらためて全員でパラメータシート（注2）と設定ファイルの項目をひとつひとつ見比べていったところ，ある設定値が間違っていることに気づきました。ケアレスミスによる大幅な時間ロスでした（図2⁠）⁠。そして，製品を疑うよりもまずは自分たちのミスを疑えという典型事例でもありました。

注2）

同時接続数やトランザクション量などから推奨されるサーバの設定値を記した表。

［事例3］終わらない移行作業で負け試合

とあるバッチ処理を新方式に移行する作業をしていました。メインフレームから送られてきた固定長の販売データをRDBに格納します。新規開発したバッチプログラムを新規プロダクション機にデプロイし，数ヵ月分の販売データを投入，作業が完了したらお客様がデータを確認しリリース判定をします。金曜日の晩から作業を開始，土曜日にデータ確認，日曜日は予備日です。失敗したらリリースを延期して翌週末に再チャレンジ。思ったより処理時間がかかり，土曜昼過ぎまでかかって半分ぐらいのデータをローディング。お客様も週末返上で確認しています。最後の数ヵ月分の数字が合わないと，土曜の夕方に連絡が。土曜の泊まりを覚悟します。プログラムを見直し，数ヵ月分を再ローディング，日曜の昼に再確認してもらいましたが，まだ合わない個所がありました。もうこの週の移行は無理なのですが，日曜深夜までデータ調査とプログラム修正・データローディングを繰り返し，月曜朝3日ぶりに自宅にたどり着きました。翌週末も泊り込みでようやく移行終了（図3⁠）⁠。

なぜ，このような負け試合になってしまったのでしょうか。じつは，筆者らはお客様が見ている最終の帳票を見ていませんでした。お客様には作業手順，データ処理方式を提示し事前合意していたのですが，最終結果をどのようなビューで見るのかという確認はしていなかったのです。結局，日次処理の計算式にいくつかの仕様齟齬（そご）があったのですが，お客様から指摘を受ける機会のないまま，設計・実装・移行が進んでいたのです。

処理方式だけでなく，エンドユーザが確認するアウトプットを開発者も確認できるように調整することは重要です。そうしないと隠れた仕様に気づかないまま進むリスクがあります。

旧システムと新システムの出力の差異はよくトラブルになります。旧システムの実装を確認せずに進めると，端数処理や計算式の違いが大幅な差異となることが多いのです。

［事例4］突如，激遅になったOLAP

業務システムに負荷をかけず，自由自在にデータを取り出し意思決定をすることができる便利なOLAPシステム。業務データの形式が変更されると，当然OLAPのデータ形式も変更する必要があります。ある商品のコード体系が数字から英数字に変更になりました。そこで，OLAP側の定義も追従して修正，データの取り込みを終え，変更作業終了しました（図4⁠）⁠。

翌日から，OLAPから結果が返ってこないというクレームがユーザから続々と。これまで長くても数十秒で取得できていた問い合わせ結果が，数分から数十分待ってやっと返ってくる状態です。業務が止まってしまうので，本番機は修正前の状態に戻し，ステージング 環境で性能を調査。OLAP製品の仕様書やマニュアルを見てもコード体系とパフォーマンスの記載はなく，メーカに問い合わせても数字→英数字のコード変更で遅くなることはあり得ないとのこと。データの再ローディングとかパーティション見直しなど，いろいろやっても復旧せず。そのOLAP製品を提案したのは我々だったので，製品開発担当者を召喚してもらいました。件（くだん）の担当者は「その修正で遅 くなるはずがない。元から遅かったんじゃないのか」などと驚愕の発言をして，その場を凍りつかせ，お客様の逆鱗に触れてしまいました（ホントに人間性を疑います⁠）⁠。我々は針の筵（むしろ）のような状況で調査を続行。試しに変更されたコードのデータをソートして投入してみたところ，これまで通りの応答時間で結果が返ってくるではありませんか。2日かかってようやく解決，新鮮なデータでOLAPを使ってもらえるようになりました。

製品選定，方式検討のときには見えていないことはたくさんあります。アンドキュメンテッドな製品の仕様，ふるまいに泣かされることもあるのです。