Java開発の問題解決を助ける（3）
チームと戦略で問題解決力を高める

サン・マイクロシステムズ
岡崎 隆之
2005/9/10

　第1回ではブレークポイントの基本的な使い方、第2回ではメモリリークとパフォーマンスボトルネックの解決方法を学びました。最終回は、問題解決を円滑に行うための準備や心構えを紹介しましょう。

問題解決力を高めるには

　第1回、第2回を通していくつかの問題解決方法をご紹介したとおり、問題解決の方法はそれぞれ問題のタイプごとにいくつもの解決方法があり、その問題のタイプによってそれぞれ最適な解決方法も異なります。

　最適な解決方法を見つけたり、その解決方法に従って円滑に問題を解決するためにはそれなりに経験やスキルが必要ですが、それ以上に重要となるのが充分な事前の準備です。

　ではどのような準備をしていけばよいかを紹介していきます。

■システム全体を把握し、体系的に問題解決に取り組む

　問題はシステムを構成するさまざまな部分で発生します。直面した問題をうまく整理し、問題の原因部分をうまく切り分けていく必要があります。問題をうまく整理していくには、システム全体を把握するための体系的な理解が必要です。ここではシステム全体を図式化し問題を分析する方法を紹介します。

　下図はサン・マイクロシステムズの開発手法であるSunToneアーキテクチャメソドロジで使用されるフレームワークを現した図で、「Cube」と呼ばれているものです。

図1　SunToneアーキテクチャメソドロジのフレームワーク“Cube”

　この図は特にサン・マイクロシステムズ特有の製品や技術に依存するものではなく、一般的なアプリケーションであれば分析や設計にうまく利用することができます。このCubeではアプリケーションを3次元的な側面から観察します。 このようなシステム全体を見渡すことのできる視点はシステムの規模や 複雑性が増すにつれ重要になってきます。

　手前の縦のスタックはレイヤと呼ばれ次のレイヤで構成されています。

• アプリケーション
  
• 仮想プラットホーム（Java EEなどの標準APIやフレームワークなど）
  
• 上層プラットホーム（アプリケーションサーバなど）
  
• 低層プラットホーム（OSなど）
  
• ハードウエア
  

　上面のスタックはティアと呼ばれサービスを機能ごとに区分けしたものです。このティアはJava EEでのアプリケーション構築におけるベストプラクティスとしてよく知られているマルチティア・アーキテクチャと同じです。

• クライアント（Webブラウザやリッチクライアントなど）
  
• プレゼンテーション（JSPやServletなど）
  
• ビジネス（ビジネスロジックやトランザクション制御など）
  
• インテグレーション（データアクセスオブジェクトやJMSなど）
  
• リソース（データベースシステムなど）
  

　右側面はそれぞれのティア・レイヤについての品質を定めたものです。この図では5つの品質項目が挙げられていますが、実際にはもっと多くの項目がシステムの性質として挙げられることもあります。

　あるシステムでパフォーマンスやスケーラビリティ、メンテナンスの問題が出るのはシステム設計時にそれらの要件が明確にされていないことが原因であることが多く、システムのどの部分が問題を引き起こしているのかを特定するのに大きな時間がかかってしまいます。

　これからシステムを設計しようとしている場合にはそれらを明確にしていただき、問題解決または問題を引き起こさないよう準備し、すでにシステムが作成済みの場合には上記のような視点から分割してそれぞれのティアやレイヤについて品質がどのようになっているかを調査していくような準備をします。

チーム力を育て問題解決に取り組む環境を作り上げる

　ほとんどのシステム開発プロジェクトはチーム戦です。このため問題解決を円滑に行えるかどうかはチームの力に大きく左右されます。ではチームとして問題解決に取り組んでいくためにはどのようなことに気をつける必要があるかを紹介していきます。

■「魔女狩り」をしてはいけない

　問題の原因を作ってしまった人はただでさえ責任を感じているのに、さらに追い討ちをするように非難したり、問題を作ってしまった原因を追求するような「魔女狩り」をしてしまっているようなプロジェクトを見かけることがあります。

　これでは、問題を作ってしまった人は精神的に落ち込むばかりで、チームの問題解決能力は決して向上していきません。チームの問題解決能力を高めていくためには、気さくに問題点について話し合ったり、解決方法を相談できるような雰囲気を作っていくことが重要です。

■問題分析のための多角的な視点を身につける

　問題の原因を特定したり、問題を解決するにあたって必要なデータはシステムの構成情報やシステムログをはじめとしてさまざまなものがありますが、それらのデータから有意な情報を導き出せるかどうかによって円滑に問題解決ができるかどうかが変わってきます。

　そのような視点を効率よく身につけるためには、チーム内で問題を解決する際に、他の人がどのように問題を解決していくのか、なぜそのデータが重要であると判断しているのかを知ることが重要です。例えば、何か障害が発生した際にどのログのどの部分を見るのかを見るだけでも、その人がどういった原因を想定しているかが次第に分かってきます。

　こうしたログや現象の見方を蓄えておくことで、次に問題が発生した際にも効率よくデータが採取できるようになったり、より高度な分析ができるようになります。

　また会社や組織にそのようなノウハウがあまりないという場合には、オープンソースコミュニティなどの掲示板やメーリングリストを使用する方法があります。そういった掲示板やメーリングリストにある情報は特定の問題解決方法のみではなく、解決に至るプロセスがメールや掲示板の履歴として残っており、どのような視点で問題を解決してきたのかがよく分かります。

発生し得る問題に対処する長期的な戦略を持つ

　アプリケーションプログラムは一度完成した時点で終わりというわけではなく、さまざまな要因によって更新したり再構築しなければいけない場合があります。その要因の一例を次に示します。

• バグの発見および解決
• 仕様の変更
• セキュリティ上の問題による改変
• 法律の改正
• 使用していた製品のサポート期限終了
  

　ここで長期的な戦略として重要となるのが「使用していた製品のサポート期限終了」です。サポート期限の終了は商用の製品だけに限らず、オープンソースのソフトウエアにも同様に当てはまります。

　サポートが終了するということはその製品自体のバグ修正、セキュリティ上の問題の修正、法律改正への対応が行われないということで、その製品自体に問題があったとしてもサポート外であることを理由に製品自体が修正されることはほとんどありません。仮にオープンソースのソフトウエアであったとしても、自力でバグ修正のバックポート（上位バージョンで修正されているバグ修正を、該当バージョンに取り込み）や、セキュリティ上の問題を修正していくことは相当な労力を必要とするため現実的ではない場合がほとんどです。

　そういった観点から、解決不能な問題に直面する前に製品の次バージョンへの対応を視野に入れた長期的なアプリケーション製品のライフサイクルを考えておくというように、次バージョンへの移行を軽いフットワークでできるような戦略が必要になります。これはメーンフレームなどのプロプライエタリシステムが長いサポート期間を提供しているが、 コストが高いのに比べ、相対的にオープン系のシステムがサポート期間が短くコストが低いというトレードオフの関係にあることから、オープン系のシステムを採用した場合には必然的な選択といえます。

■仕様策定の動向に注意

　製品のサポート期間はその製品ごとにまちまちである場合がほとんどですが、Java SEやJava EEなどの仕様の動向を見ることで、それぞれの製品ごとのリリース間隔もおおよそ予測することができます。特にJava SEやJava EEがメジャーバージョンアップするタイミングで製品の新バージョンが発表されることが多く、このような主要な仕様策定の動きはそのまま製品のライフサイクルにも関係してきます。

　ではJava SEのこれまでのリリースとサポートのポリシーをみてみることにしましょう。Java SEはメジャーバージョンアップ版がリリースされると、その2世代前のJava SEがサポート終了サイクルに入ります。最近ではJava SE 5.0がリリースされたことによりJ2SE 1.3.xがサポート終了サイクルに入り、アナウンスから1年半後（2006年3月30日）に、サポートが終了されることがアナウンスされています。

　また、マイナーバージョンアップがリリースされるとその前のマイナーバージョンはアナウンスから6ヶ月でサポート終了となります。例えば、J2SE 1.4.1はJ2SE 1.4.2のリリースにより2005年1月にサポート終了となりました。その他Javaのサポート終了（EOL）ポリシーの詳細についてはJava Technology EOL Policy（英語）を参照してください。

図2　Java SEのサポート終了（EOL）ポリシー

　以前のJava SEやJava EEの仕様策定はfeature-driven（主要な仕様の完成を待ってバージョンアップ）でしたが、最近ではtime-driven（リリース時期に間に合いそうな仕様を取り込んでバージョンアップ）になってきているため、以前に比べて長期的な戦略を立てやすくなってきています。

　短い連載でしたが、これまでご紹介した通り、問題解決を円滑に行うためにはツールの使い方を知っておくことや、問題解決が円滑に行えるようなチーム作り、発生しうる問題を未然に防ぐための長期的な戦略といった準備作業を行っているかどうかが重要なポイントとなります。効率よく問題解決をできるかどうかは、経験やスキル以上にこうした準備作業が重要であるということを知っていただければ幸いです。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）