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

たかがツール、されどツールの分散開発

　ここまでは、3つの視点からEclipse Wayの狙いを取り上げてきましたが、それだけで分散開発チームの課題が解決できるわけではありません。第1回で、アジャイルをスケールアップするための考慮点をリストアップしました。そこに存在する課題をツールで解決できないか…それが、Rational Team Concert（以降RTC）の開発の動機付けになっています。このツールがターゲットにしている課題が何なのかをご紹介することで、“プラクティスのみの限界”を考える参考になればと思います。

・分散のロスをカバーする

　アジャイルのプロジェクトが少ないドキュメントで機能する理由の1つは、“情報が論理的には散逸していないから”であると筆者は考えます。“ホワイトボードに張られた付せん紙”や共有されたソース、そしてなにより1カ所に人がいることで、各人の頭の中に情報が格納されていてすぐに引き出すことができます。“手が届く狭い範囲にすべて存在する”のです。注意すべきは、これらの情報は単に“同意した事柄”だけでなく、同意に至る議論の過程もすべて含まれることです。

　分散開発では、「単一の場所に、議論の過程まで含むすべての情報が、管理されている状態」をリポジトリを使って疑似的に作る必要があります。RTCでは、チャットやフィード、Wikiの機能までリポジトリと連携することで、議論の過程も含めた情報の共有や、確実な配信・通知でコミュニケーションロスを排除していきます。

・透明度を高めてチームの文脈を共有する
　チームのメンバーが自発的に物事を判断して機能するためには、そもそも判断材料が必要です。所属するチームの役割、プロジェクトの状況（目標、進ちょく、作業負荷等）、関連するチームの状態等、文脈が異なれば、同じ課題に対しても下すべき判断が異なることがあります。リポジトリに情報をためるだけでなく、それを公開し透明度を高めることで、チームの文脈を共有することが、チームの自発性・自立性を高める第1歩です。

・プロセス適用の負荷を下げ、運用に乗せる
　“自由度を高める”と“無秩序”は表裏一体です。大規模（＝大人数）になれば、スキルのばらつきも出てきます。アジャイルの経験者とはいってもやり方はみな違うかも知れません。また、守らねばならぬ法的制約が存在するプロジェクトもあるでしょう。いかなアジャイルといえども、ある程度のルール作りは必要です。開発プロセスを考える際の一番の問題は、規定されたプロセスが運用に乗らない、ということです。

　・開発プロセスの規定を覚える
　・日々の作業で常にプロセスの規定を頭の片隅で意識する
　・自分の作業がプロセスにのっとっているかを、“自分で”チェックする

　これらの作業は開発者にとってかなりのストレスになります。

　RTCにはプロセス制御のエンジンが提供されており、開発プロセスで規定したルールを自動的にチェックしてくれます。

　例えば、プロジェクトのある時期、「ソースコードをチェックインするためにはコメント入力が必須」というルールを決めたとします。開発者がそれを忘れてチェックインを試みると、ツール側からアドバイスが現れます（図3）。違反の理由と対処法が提示されることで、開発者はスムーズに問題を解決できますし、ルールが徹底されます。このようにツールが自動化サポートによって、プロセス適用での開発者の負担を肩代わりしているのです。

　分散開発の課題に対処するためのプラクティス面とツール面からのアプローチを2回に分けてご紹介してきました。次回は、RTC開発メンバーによる実践をご紹介する予定です。