動くプログラムを提供するために

動くプログラムを提供するために

アジャイルの重要な考え方の1つに「常に動くプログラムを提供する」ことがあげられます。「絵に描いたもち」は不要なのです。動くプログラムがあれば、それを元に、ステークホルダーからのフィードバックを得て、開発に生かすこともできます。

動くプラグラムを安定して提供するためには、それなりの施策が必要です。Eclipse Wayでは“継続した統合（Continuous Integration）”を1つのプラクティスとして掲げています。

Jazz.netで行われているほどの大規模な開発になると、全体を統合したビルドを一発で成功させることは容易ではなくなります。そこで、Jazz.netではチームの共有スペースであるストリームと個人専用のリポジトリー・ワークスペースというRTCの提供する概念を利用し、ビルドを階層化することによって、安定したプログラムの提供を実現しています。オペレーション的には以下のようなものになります。

1. 開発者は個人のリポジトリー・ワークスペースに自分の変更セットをチェックイン
2. 安定した段階で個人の変更セットをチームのストリームに提出
3. チームのストリームでビルド、テスト
4. 週1回チーム・ストリームから統合ストリームに提出、ビルド、テスト

よく行われることの1つに、「パーソナル・ビルド」という機能があります（図3）。これは、上記の1.の段階で、個人のワークスペースにあるファイルを使って、本番のビルドと同じ環境でビルドを流すという機能です。これを行うことによって、2．で提出する変更セットを含んだ形でテストを流すこともできるので、上位のビルドの安定性がさらに増すことになります。

★RTCの使い方について参照
　IBMの技術情報サイトdeveloperWorksでは、RTCの使い方をステップbyステップで解説した記事があります（「はじめて使うJazz」http://www.ibm.com/developerworks/jp/offers/cz/library/cz11/）。ツール機能の詳細に関心のある方はぜひこちらも参照してください。

おわりに

紙面の都合上、細かいことは書けませんでしたが、アジャイル開発と、プラクティス集としてのEclipse Way、それを支えるツールとしてのJazz.netにおける大規模開発の紹介を4回に亘って行ってきました。

アジャイルという言葉が登場してからだいぶ時間がたちますが、RTCのようなツールの登場により、大規模でしかも分散した環境におけるアジャイルの適用も行われ始めているのがご理解いただけたでしょうか。もちろん、RTCのようなツールは大規模開発のためだけのツールではありません。アジャイルの良い点と、企業による開発にとって必要な管理を両方実現するためにもツールは必要だと考えています。

Jazz.net上での開発のように大規模なアジャイル開発の現場が、無法地帯でもがんじがらめでもなく、安心感があり心地よい管理が実現された開発スタイルになる可能性があるということを、少しでもお伝えできたなら幸いです。