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

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

テスト失敗、そして……

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

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

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

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

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

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

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

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

失敗から学べたこと

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

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

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

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

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

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

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

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

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

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

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー

• 文書ドリブン開発 テスト文書編
• 文書ドリブン開発 詳細設計文書編
• 文書ドリブン開発 DB設計文書編
• 基本設計文書の質を下げる「4つの心理バイアス」
• 本当は楽しいドキュメント作成
• 新人（3年目）、プロジェクトで「忍耐」を学ぶ
• 新人、集合研修で「伝説」を作る
• 新人（3年目）、先輩デビューで「最悪の振る舞い」
• 新人、アーキテクチャチームで「運命の出会い」
• 1人チームで悩む新人。「この作業って意味あるの？」
• 現場デビューのお供はビジュアル多用の報告書
• 大規模プロジェクトでは「同じ言葉を、同じ意味で」
• 「バッファ込み」の工数がスケジュール遅延の原因
• 運用って、あまりいいイメージはなかったけれど
• 最強チームで挑んだ、「40時間でデータ移行」の壁
• 障害対応とチューニングの危うい関係
• オフショアなんて、怖くない
• 3プロジェクト同時にリード！ どう乗り切る？
• この案件、ぜひ新しいテクノロジでやりましょう！
• 初めてのトラブル対応。これで直ると思ったのに！
• 「できるか！」な設計書に、どう立ち向かう？
• 専門用語で「カッコよく」話すのは簡単だけど
• メンバーとの仕様打ち合わせは海を越えて
• 定まらない要件、ユーザーからのむちゃな要求
• 未経験のデータベース構築に挑戦
• セットアップ全国行脚で九州弁に大苦戦
• 試行錯誤で分かったスパゲッティコード撃退法