初めてのトラブル対応。これで直ると思ったのに！：システム開発プロジェクトの現場から（8）（2/2 ページ）

テスト失敗、そして……

　テスト当日。はやる気持ちを抑えながらテストを行いました。しかし、そんな浮かれ気分もつかの間、結果は「少しは良くなったかもしれないが、ほとんど変わっていない」という、とてもショッキングなものだったのです。ORACLE MASTERを取得したばかりの私にとって、なんともプライドの傷つく結果でした。

　その後も、ロールバックセグメントのサイズ、ログバッファがどうのこうのといったことを試してみましたが、大した効果はありませんでした。けっこう自信を喪失し、途方に暮れていましたが、なんとか奮起し、もう1回最初からきちんと考え直してみることにしました。

　ニュートラルに考えてみると、新たな疑問がわいてきました。

　「バッチ処理が遅いということは、そのプログラムのどこかにボトルネックがあるんだろうか？ それとも一律で処理が遅くなっているのか？」

　そもそも私は、プログラムがどんな処理をしているかについて、詳細には確認していませんでした。担当者に再度聞いてみたところ、最初聞いていた「ハンディターミナルで読み取った棚卸しのデータをいったんPCに転送して、その転送されたテキストファイルの内容をデータベースに格納する」といったことよりも、明らかに複雑な処理をしていることが分かりました。

　そこで、バッチ処理内のSQLを発行している個所に、開始・終了時刻を出力するログを埋め込み、調査することにしました。すると……あっという間にボトルネックを見つけてしまいました。プログラム内で「削除してからインサートする」という処理をしていたのですが、そこが異常に遅かったのです。

　そのSQLを解析してみると、異常に遅かった理由も簡単に分かってしまいました。削除するときのキー情報に、インデックスが付いていなかったのです……。

　すぐにその項目にインデックスを付け、プログラムを再実行しました。結果、2000件の処理が数十秒で終わりました。そして私は、この長い長いトラブル対応に、ようやく終止符を打つことができました。

失敗から学べたこと

　このトラブル対応で私は、非常に貴重な経験、というか失敗をしました。そして以下のような教訓を得ました。

• 先入観・思い込みをなくせ！

　最初に聞いた担当者の話と表面的な事象だけで、私は「答え」を作成してしまいました。そのため詳細な情報について、担当者にヒアリングをしませんでした。これが失敗の原因です。

　「朝一番で実行すると5分ぐらいで終わるが、10時を過ぎると1時間以上かかることがある」という担当者の言葉から、「プログラムに問題がある」という可能性を完全に無視してしまい、バッチ処理の詳細な内容を調べることをしなかったのです。この思い込み・先入観がなければ、サーバ側・プログラム側の両方から可能性を探ることができたと思います。先入観によって本当の問題点を見逃がしてしまったのです。問題点をきちんと把握せずに、問題を解決できるはずがありません。

• 自分の得意な（もしくは興味のある）領域に逃げ込むな！

　ORACLE MASTERを取得したばかりの私は、自分はOracleの設定やチューニングが得意だと思い込んでいました。その技術力を試してみたいという欲求もありました。そのため無意識のうちに問題を自分の得意な領域に持ち込もうとし、視野を狭め、いろいろな可能性を消してしまいました。

　対応自体はロジカルに進めていたつもりです。「仮説立案」→「実行」→「検証」という具合に。でも、その前に自分自身の気持ち・思いをきちんとコントロールし、ニュートラルな状態をつくらないと、結局遠回りをしてしまうのだということを理解しました。

　自分がニュートラルな状態であったならば、必要な情報を担当者からヒアリングしたでしょうし、もっと事実を多く集めるための調査を行ったでしょう。

　必要な情報が多ければ仮説の確度は高まる。仮説の確度が高まれば問題を解決する可能性も高まる。そんなことを学びました。

　トラブル対応にはいろいろな学びがあります。皆さんも、トラブル対応には積極的に取り組んでみてください。仮説→実行→検証→解決！ となったときの気分は本当に最高です。