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

3つの視点（1）チーム・組織編成という視点

　アジャイル開発を導入しようとしているお客さまが共通して抱く疑問の1つにチーム編成があります。彼らの考え方の共通するバックグラウンドは次の2点です。
・オフショア先との役割モデルは、工程分担に基づく。国内拠点は要求管理や設計、海外拠点は実装・テストといった、いわゆる上流工程か下流工程かによって分かれる。
・アジャイルは少人数（数人程度）では有効かもしれないが、開発人員が増えたらどうするのか？→“人数が増える＝チームが大きくなる”という発想がある。

　Eclipse Wayでのチーム編成の基本は、次の2点に集約できます。
・1チーム当たりの人数は、10人前後とする。プロジェクト規模が大きくなった場合は、チームの人数を増やすのではなくチームの数を増やす。
・チーム編成の単位は、担当するコンポーネントの単位とする。

“チーム＝構築する単位”で、コミュニケーション・エラーを防ぐ

　図2の右側では、本稿執筆時点(2009年4月6日)におけるJazzプロジェクトのチーム編成を見ることができます（※図2は以下のURLで参照できます。：https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.dashboard.viewDashboard）。

　この画面は、プロジェクトの状況を可視化するダッシュボード機能のトップ画面です。時間があったら、あちこちクリックしてどんな情報が参照できるかご覧になってみてください。

　上記のJazz.netサイトでチーム名のところをダブルクリックすると、チームの構成メンバーがリストアップされますが、だいたい数人～十数人でチームが構成されています。

　チームが大人数になり分散するということは、それだけでコミュニケーション・エラーが発生する原因となり得ます。分散開発でのアジャイル導入では、「アジャイルのメリットを得られるチームの規模感をいかに維持するか」が1つのポイントであり、それに対する技術的な解決策の1つが、“チーム＝構築する単位”とすることです。これが、プラクティスの2つ「コンポーネント中心」「APIファースト（APIをまず決める）」につながります。

　コンポーネント化されたアーキテクチャを採用し、チームと構築対象となるコンポーネントとをマッピングすることで、チームの作業範囲を決めることができます。「APIファースト」により、APIに対して“実装を提供する側”と“利用する側”とでチームを分離して並行開発が可能となります。APIが変更されない限りは、お互いに相手を意識せず独立して作業することができます。

　ちなみに、Rational Team ConcertはEclipseプラットホーム上のプラグインとして機能を開発していますが、そのベースとなるアーキテクチャはOSGi Alliance（OSGi：Open Service Gateway initiative：http://www.osgi.org）で規定されたサービスプラットホームに基づきます。この仕様のEclipse実装であるEquinox（http://www.eclipse.org/equinox/）を採用しています。

　このように、オープンな規格に基づいたアーキテクチャを採用することで、単品のシステムとして安定したアーキテクチャの上で機能を実装できるとともに、ほかのシステムとの連携をより実現しやすくしています。