リソース管理のポイント
また、アジャイルの導入において障害となっている点を洗い出すと、誰が何をしているのかを管理できるのかということに集約される。ただし、人の仕事をすべて管理することはアジャイルでなくても難しいことである。同じチームが同じ場所で、10名程度で作業していれば目が届くし、状況の把握やサポートもできる。しかし、規模が大きくなり分散した環境になってくると、誰が何をやっているのかが把握できなくなり、何が起こるかの予測もできなくなってしまう。
これを解決するためのポイントの一つは、チームがアジャイルのテクニックを駆使する上での阻害要因を排除していくことだ。そしてその条件は、これがTeam Concertのキモでもあるのだが、「おのおののチームの流儀を邪魔されないこと」、そして「作ったものを壊されないこと」が重要となる。とはいえ、チームが孤立した島国になってしまうと、お互いにコラボレーションすることができない。チームの独立性はある程度維持しながら、ちゃんと他のチームと協業できるよう作業を分担できる環境が必要となる。
もう一つのポイントは、リリースとビルドを考え直すことだ。共同作業ではソースコード管理システムのリポジトリがサーバにあり、Eclipseのクライアントからチェックイン、チェックアウトする。この際、個人ベースである一定のクオリティを出したうえで共有する場合は問題ないが、アジャイルの世界では実験的なコードを作って、よりよいものをマージしていきたいと考えるし、その場を楽しみながら作業しようとする傾向がある。
しかし、分散した環境ではこのようなことはできない。実験的なコードを書きたいが、共有部分には置きたくない。かといって自分のローカルに置いておくと、その情報は日の目を見ないし、作業に詰まったときに助けてもらえない。そこで、Team Concertのソースコード管理システムのエンジンでは、サーバのほかに「リポジトリワークスペース」という“サーバー上の個人用お砂箱”を作っている。見た目はクライアントのワークスペースなのだが、リポジトリとクライアントの間にレイヤを追加することで、離れた人に対して実験的なコードを共有領域を崩すことなく共有することが可能となる。後はチャットなどで差分を添付して相手に送れば、マージできる。
この方法によって、例えば状況を離れた相手に見て欲しいときに、相手のところで同じ環境を再現したり、一つの状況を離れた他のスタッフと共有し、それぞれが別のテストを同時に行うといったことも可能になる。分散開発ではリソース管理をしっかりやらないと、いつの間にかリソースが変わってしまう危険性がある。例えば完了基準をクリアしないとチェックインできないようにしたり、承認者の承認を得ないとチェックインできないようにするなど、リソースが崩れることをいかにブロックするかに重点を置く必要がある。
このように、アーキテクチャとチームをうまくつなげていくことで、規模が変わっても同じようにプロジェクトを進めていくことができる。また、無駄なことや付帯作業に発生するロスを最小限にするためにもリソースの管理は必要だ。さらには、スキルのばらつきは避けられないため、平均的な作業量を考えるよりは各マイルストーンやイテレーションの完了基準を明確にした方が良い。このような対策を行うことで、個々のチームが安心してチームワークに集中できる。分散環境では、このようなことが非常に大事になる。
