コードジンのヘッダーが入ります
<title>Developers Summit 2009</title>
<link href="//cz-cdn.shoeisha.jp/static/devsumi/2009/css/special.css" rel="stylesheet" type="text/css" />
<div class="wrapper">
<div class="title">
				<img src="//cz-cdn.shoeisha.jp/static/devsumi/2009/image/special/title.gif" />
  </div>

			<h1><span>日本オラクル株式会社</span></h1>
            <h2>【13-D-4】アナタのアプリ性能改善の秘訣、オラクルが教えます！
			<div class="name">システム事業統括本部
System & Application Managementビジネス推進本部
セールスディレクター<br />
<strong>山岡 英明</strong></div>
            </h2>
			
            
            
<div class="read">
				<img class="image" src="//cz-cdn.shoeisha.jp/static/devsumi/2009/image/report/15.jpg" />開発の効率化が進む一方、テストの効率化は遅れている。適切なテストの実施により予防コスト、評価コストなどを削減できるが、中でもWebシステムの性能障害による失敗コストの額が大きい。性能（品質）の改善は、上流工程に戻らなければ不可能な場合もあるからだ。過去10年、500回の性能検証を行ってきた山岡英明氏の講演は、開発におけるテストの重要性を強調し、実際のテストにおけるポイントを解説するものとなった。
</div>
                
<div class="clear"><hr />
  </div>
            <div class="block">
			
			
			  <h3>なぜ性能問題を開発プロセス全体で考えることが必要なのか</h3>

              <p>デブサミ2008でエンピレックス社の副社長として負荷テストをテーマに講演した山岡英明氏が、同社のWebアプリケーションテスト・ソフトウェア部門をオラクルが買収したことに伴い移籍。今年は日本オラクルのSystem &amp; Application Managementビジネス推進本部セールスディレクターとして登壇した。</p>
              <p>現在の厳しい経済環境の中で、システムの開発コスト、運用コストの削減が強く求められている。過去10年、開発プロセスの効率化開発資産の再利用、標準化など開発の効率化が進んできた。山岡氏は「しかしその一方で、テスト工数は減るどころか増加を続けている」と指摘する。なぜなら既存システムの1％の修正でも他のシステムに影響する可能性があるのならば、テストは100%行う必要があるからだ。さらに開発とは異なりテストの効率化は進んでいない。テストが複雑になり、開発初期段階のテストが維持できず、アプリケーションを継続発展させて品質を維持することが困難になっている。</p>
              <p>そこで、これからのコスト削減で注目すべきはテストだ。まず、開発プロジェクトにおいて、テストの管理がほとんど行われていない現状が問題だ。その背景には現場を信頼する日本の文化があり、これまではそれなりの成果を上げてきた。しかし、開発が大規模になりオフショア化が進むと、テストもマネジメントが必要になる。またテストの工数が増大する中、可能な限りテストを自動化する必要がある。</p>
              <p>そして山岡氏は、Webシステムでは性能管理によるサービス向上のためのテストが最も重要と指摘した。なぜなら、テスト関連のコストで最も多額になりやすいのが性能の問題による失敗コストだからだ。不具合を開発チームが指摘された場合、まず問題になるのは再現方法だろう。ところが山岡氏の行ってきた過去500程度のWebシステムの性能検証では、実運用ではほぼ100％再現できなかったという。そのため原因を探るのに大きな手間がかかり、修正コストが他の不具合の100倍のケースもあった。</p>
              <p>性能検証のために行われるのが負荷テストだ。今のWebシステムはクロスベンダーで前例が無い様々なものが作られており、特に性能に関して積算などによる事前見積もりはあてにならない。そこで実際にシステムに負荷をかけてテストを行う訳だが、数万人によるアクセスを人力で行うのは不可能であり、オラクルなどの負荷ツールを使うことになる。ツールによりシステムへのアクセス数を増やしていくと、ある時点で限界点に達し、ボトルネックが発生する。山岡氏の経験では99％問題が発生していることから「負荷テストは○か×かのチェックではなく、必ず×になるという前提で、チューニングやプログラム修正を考えながら行う必要がある」と語る。</p>
              <p>また初めの負荷テストでは情報を取得しすぎないことがポイントだ。ページの応答時間やCPUとメモリー、DBではディスクのI/O程度に絞り込む。一定以上テスト関連スキルがあれば、それだけで問題箇所を推定することができる。それからマクロの世界からミクロの世界に入っていけばいい。</p>
              <p>ただ、テストの結果2分かかると判明した応答時間を10秒に短縮するのは、チューニングでは不可能に近い。そこで要件の段階から性能に着目し、各要件とテストを紐付けする必要がある。</p>
              <p>そして山岡氏がポイントとしたのが「負荷試験はチームで行う」ことだ。チームはインフラ担当者とアプリケーション開発者、そして基本的な結果グラフを見て問題点を指摘できる人などで構成する。なぜなら負荷テストによるボトルネックの再現を開発サイドで行うのは難しい。問題発生を各担当者が同時に確認し、その場で原因を推定することが望ましいからだ。</p>
              <p>オラクルは、e-TEST suiteでWeb負荷テストの国内トップベンダーだったエンピレックスの同事業統合により、この分野における高い実績とノウハウを継承した。山岡氏は、性能の最適化を図るためにはチームによる負荷テストを何回できるかがキーポイントと強調して今年のセッションを閉じた。</p>
              <div class="centerimg">
                <div class="caption">図1：開発の初期段階から性能テストを計画</div>
                <img border="0" src="//cz-cdn.shoeisha.jp/static/devsumi/2009/image/report/13-D-4.gif"/> </div>
  </div>
  <div class="inquiry"><strong>問い合わせ先</strong><br />
日本オラクル株式会社<br />
〒107-0061<br />
東京都港区北青山2-5-8 <br />
オラクル青山センター<br />
TEL: 「Oracle Direct」 0120-155-096<br />
URL: http://www.oracle.com/lang/jp/corporate/contact.html  </div>
  <div class="bo"><a href="/devsumi/2009/report/"><img alt="戻る" border="0" src="//cz-cdn.shoeisha.jp/static/devsumi/2009/image/special/bo.gif" /></a></div>
 <div class="bo"><a href="/devsumi/2009/" target="_blank"><img border="0" src="//cz-cdn.shoeisha.jp/static/devsumi/2009/image/special/bo_devsum.gif" /></a></div>
</div>
コードジンのフッターが入ります