障害対応とチューニングの危うい関係：システム開発プロジェクトの現場から（12）（2/2 ページ）
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
障害対応で、チューニング個所がバッサリ……
このようにチューニング自体はある程度順調に進んでいましたが、チューニング第1弾も後半に差し掛かったころ、困ったことが発生し始めていました。チューニングと並行してシステムテストも実施していたのですが、システムテストで判明した障害の対応によって、チューニングしたはずのSQLが遅くなってしまうという事態が起こっていたのです。
「このままではヤバイ気がする……」
当然ですが、オフショアの開発メンバーには決して悪気はなく、対応したSQLも間違っていないのです。障害対応で修正しているのですから。でも障害対応したソースを見てみると、チューニングしたところがバッサリとコメントアウト……。かなり切ない気分になりました。
確かに、チューニングを実施したことによってSQL文が長くなっている個所もありました。普通に結合して検索すればよいところを、あえてサブクエリにしたりしている個所もありました。しかし……。
「お願いだから、なぜこういうSQLにしたか聞いてー！」。私の悲痛な叫びも、なかなか開発メンバーには伝わりませんでした。
しかし、伝わらない理由も理解できました。障害対応をするには、チューニング前のSQLに実施した方が明らかに工数が少なくて済みそうなものも多数ありました。それに開発メンバーの行う単体・結合テストは、大量のデータが存在する環境では実施されず、そのSQLがどのくらい遅いのかという実感を持たせることもできていませんでした。もちろん、これはオフショア開発に限った話ではないですが……。
だからといって、このままイタチごっこのようなことをしていても生産的ではありません。そこで私は、当初立てた計画を少し変更することにしました。
「アプリケーション（SQL）チューニング第2弾はオフショアで！」
チューニング第2弾はオフショアで実施
チューニング第1弾でかなりノウハウが蓄積されていましたので、それをベースにチューニングマニュアルを作成しました。そしてチューニングを実施するメンバーをオフショアメンバーから4人ほど選出してもらいました。リーダークラスの、特にスキルの高いメンバーを選出してくれました。オフショアで使用するための大量データを投入した特別な環境も構築しました。
準備は万端整い、私は大連へ渡航しました。
大連に着いた私は、まず開発メンバー全員に対して、現状と今回の方針を説明しました。全員に現状を理解してほしかったですし、障害対応する際にはちょっとしたことで遅れが生じてしまうことを、サンプルを用いて実機で説明しました。フェイス・トゥ・フェイスで説明したこともあり、開発者も理解してくれたと思います。
続いてスケジュールやチューニング実施時のテスト方法などを説明し、実際にチューニングを実施しました。最初は、「速くならないです」といった声も聞かれましたが、一緒に考えながら進めていきました。そして、処理が速くなるのを体感できたときは、一緒に喜ぶことができました。オフショアメンバーがとてもうれしそうな顔をしていたのが印象的でした。
もともとスキルの高いメンバーのことです。私も安心して日本に帰ることができました。それ以降、障害対応で性能が悪くなることはほとんどなくなりました。
チューニングを進めながら、私は実はこんなことも思っていました。設計時にどれだけ気を付けていても、規約をどれだけ厳密にしていても、性能に関する問題が発生する確率はゼロにはならないのではないかと。今回に関しては多少、SQLの規約などが甘く、十分に反省していました。しかしどれだけ準備をしても、問題が発生することはきっとあるのでしょう……。
ともあれ、こうしてチューニングは完了し、ユーザーテストも開始され、その後システムは無事カットオーバーしました。
この経験を通して、私はさまざまなことを学びました。チューニングのノウハウや設計時の考慮点など、多くの技術的なことは大きな財産となりました。もし別の機会があれば紹介したいと思います。
ですが一番大きかったのは、やはり問題を共有することの大切さです。相手がオフショアであろうとなかろうと、問題を共有することは重要です。メンバーがきちんと問題を認識しないかぎり、うまく前には進めません。
今回、性能に関する問題を伝えた段階以前では、私とオフショアメンバーは違う方を向いていました。問題をきちんと共有したことで、私たちは同じ方を向くことができました。同じ方を向いて進むことができれば、進む速度は上がっていくのです。
最後に……。チューニングを一緒に実施したオフショアメンバーが、もしもほかのプロジェクトで同じような状況に遭遇したとき、今回の経験を基に活躍してくれれば、技術者としてとても幸せです。
筆者紹介
新楽清高
1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。
- 文書ドリブン開発 テスト文書編
- 文書ドリブン開発 詳細設計文書編
- 文書ドリブン開発 DB設計文書編
- 基本設計文書の質を下げる「4つの心理バイアス」
- 本当は楽しいドキュメント作成
- 新人（3年目）、プロジェクトで「忍耐」を学ぶ
- 新人、集合研修で「伝説」を作る
- 新人（3年目）、先輩デビューで「最悪の振る舞い」
- 新人、アーキテクチャチームで「運命の出会い」
- 1人チームで悩む新人。「この作業って意味あるの？」
- 現場デビューのお供はビジュアル多用の報告書
- 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 「バッファ込み」の工数がスケジュール遅延の原因
- 運用って、あまりいいイメージはなかったけれど
- 最強チームで挑んだ、「40時間でデータ移行」の壁
- 障害対応とチューニングの危うい関係
- オフショアなんて、怖くない
- 3プロジェクト同時にリード！ どう乗り切る？
- この案件、ぜひ新しいテクノロジでやりましょう！
- 初めてのトラブル対応。これで直ると思ったのに！
- 「できるか！」な設計書に、どう立ち向かう？
- 専門用語で「カッコよく」話すのは簡単だけど
- メンバーとの仕様打ち合わせは海を越えて
- 定まらない要件、ユーザーからのむちゃな要求
- 未経験のデータベース構築に挑戦
- セットアップ全国行脚で九州弁に大苦戦
- 試行錯誤で分かったスパゲッティコード撃退法
Copyright © ITmedia, Inc. All Rights Reserved.