分散チームのコラボレーション

分散チームのコラボレーション

　“チーム＝コンポーネント”とした場合、チームの作業がブラックボックス化してしまう可能性があります。また、チームに必要なスキルを持った人材が必ずアサインされる保証がないというのも現実もあります。むしろ、高い見識を持ったエンジニアは多くのチームに関与して、よい影響をもたらすことも期待できるはずです。このようなチームの相互作用を促進するために、必要に応じてチームのメンバー編成をコントロールしようというのがもう1つのプラクティス「ダイナミックなチーム」です。
伝統的な開発手法では、アナリスト、プログラマー、テスター等、専門性を重視した役割モデルを推進していました。それに対して、アジャイルの基本的な考え方は、“職能横断”です。個人の専門性は活かしながらも、必要に応じてほかのメンバーの作業をどんどん分担していきます。

　Jazzプロジェクトでも、1人の開発者が複数のチームにいろんな役割で関与しています。そこで、Jazzプロジェクトでの代表的な役割を見てみましょう。

・プロジェクト・マネジメント・コミッティ（Project Management Committee:PMC）
　このコミッティはリリースプランに責任を持ち、リリースされる機能の大枠となるテーマ（※これは後述の要求管理的視点で説明します）を決定します。
プロジェクト全体にかかわる意志決定をつかさどりますが、彼らが少人数で決めるのではありません。ファシリテーター、コーディネーターとして全員参加型の意志決定を推進します。

・コンポーネント・リード
　コンポーネント・リードは、コンポーネントの品質に責任を持ちます。ゴールを達成するためにチームの反復とテストプランに責任を持ちます。

・コントリビューター
　アジャイルチームのメンバーは、コード、テスト、デザイン等に責任を持つ多くの役割をこなします。まさに“職能横断”チームなのです。

プロジェクトのキモはフェース・トゥ・フェースで

　Jazzプロジェクトのメンバーは、自身が開発しているRational Team Concertを自分たちの開発環境として使っているユーザーでもあります。この製品のリポジトリにさまざまな情報を格納・共有することで、メンバーはプロジェクトの状況をリアルタイムで知ることができます（図3）。ソフトウエアによるサポートは、分散開発でのコミュニケーションエラーを排除するために必要な要件ですが、それだけでOKというわけではありません。このプロジェクトでは、さまざまな形態のコミュニケーションが取られます。

・分散型開発と言いつつも、リリースサイクルの最初では、フェース・トゥ・フェースのミーティング
・各コンポーネントチームは、スクラム（SCRUM）で言われるようなスタンドアップミーティングを毎日実施
・コンポーネントリードは、週次でミーティング。拠点がばらばらなので、電話会議等を使って行います。
・反復が終了した段階で、その反復の成果物をデモし、確認します。
・新しいコンポーネントを作ることを検討する場合は、フェース・トゥ・フェースのミーティング

　この例に見られるように、プロジェクトの方向性（リリース、コンポーネントの追加等）を決定するような“キモ”となるミーティングは、フェース・トゥ・フェースで行います。

　ポイントで“お互いの顔の見える”ミーティングを組み入れることで、より確実にプロジェクトのかじを取ることができているのです。

　次回は、残り2つの視点（プロジェクト計画と管理という視点、要求管理という視点）について解説していきましょう。