Eclipse Wayをひもとく（その1）

前回のおさらい

　前回は、分散開発にアジャイルのメリットを取り入れるために、考慮すべき代表的なポイントをリストアップした後で、実際に製品開発に適用されているプラクティス集としてEclipse Wayを取り上げました。連載の2回目と3回目は、このプラクティス集とこれが適用されている製品開発の様子を公開しているサイトJazz.net（http://jazz.net）を取り上げて、前回取り上げたさまざまな課題をどのように解決しているかを具体的に見ていくことにしましょう。

Eclipse Wayの構造

　図1は前回も提示したEclipse Wayのコンセプトを表した図です。Eclipse Wayを構成するプラクティスは、次の3つのグループに分けることができます。

・アジャイルで共通のプラクティス
　“継続した統合（Continuous Integration）”や“レトロスペクティブ（Retrospective：振り返り）”といった、アジャイルな開発の中で共通して行われているプラクティス群です。これ以外にもテスト駆動型開発など実践しているプラクティスはあるのですが、個々人の作業のプラクティスよりも、より大きな規模のチーム運営にとって必要なものを取り上げています。

・オープンソースで共通のプラクティス
　これは、オープンソースの開発をうまく運営していくためのプラクティスであり、オープンソースプロジェクトのEclipseプロジェクトでの経験から見いだされたものです。余談ですが、Jazz.netをスタートしたメンバーは多くがEclipseのメンバーでもあります。Eclipseは、開発者1人1人のデスクトップ上でさまざまなアプリケーションが同時に複数動いている状態を、1つのシェルの中に統合したいという欲求から始まった、“デスクトップの統合”を目指したプロジェクトです。それに対してJazzプロジェクトは、分散した拠点にいる開発者を結びつけたいという“チームの結びつき”を実現するプラットホームとして誕生した、という歴史があります。

・スケールアップのためのプラクティス
　前述2つのプラクティス集はどちらもチームや開発するシステムの規模感にはあまり左右されません。それに対して、より大きなチーム、より大きな規模のシステムを開発するためのプラクティス集が、これに当たります。

　この種のプロセスやプラクティス集を理解する際には、個々の構成要素を1つ1つ子細に見ていく以前に、そもそも何を目的にしているかを理解しておくことが重要です。そこで、以降では次の3つの視点から、Eclipse Wayの構成プラクティスを説明していきます。

（1）チーム・組織編成という視点
（2）プロジェクト計画と管理という視点
（3）要求管理という視点

　また、Jazz.netで公開されている情報を具体例として引用している箇所があります。URLを提示しておきますので、別ウィンドウで参照しながら読み進めていってください。

==============================
★Jazz.netを参照するために
　Jazz.netで実際に開発が進められているプロジェクトの情報を参照するには、あらかじめサイトに登録してJazz.netアカウントを取得する必要があります（登録サイトURL：https://jazz.net/pub/user/register.jsp）。現在では、3プロジェクトが登録されていますが、本連載では、“Rational Team Concert”を見ていきます。
==============================