第4回 開発チームの状態をネットに記録する

振り返りと反省

初回から3回にわたり、IBMが開発しているJazzテクノロジーのコンセプトとその背景から、これからの開発ツールに求められる要素を概観してきました。 「開発を阻害する要因を、開発ツールがどうとらえてきたか」という切り口で、“個人”に焦点をあてた効率化から、共有知の活用、 そして情報の共有化と進んできた流れはご理解いただけたかと思います。

前回、開発者同士のコラボレーションを軸に列挙したポイントは、要約してしまえば、「開発体制が拡大し、オフショア等の分散体制にならざるを得ない現実の中で、 小規模で実績を上げてきたアジャイルのアプローチを阻む“距離感”“時間感覚”を、ツールがカバーする」 というシナリオです。

これらは第2回で掲げた、以下の3つのポイント

1）形式・関係性についてより少ない制約で共有できること
2）“文脈”を保存し共有できること
3）リアルタイム性を高めること

が、開発者同士のコラボレーションという文脈の中で、より具体化されたインスタンスだとみることもできます。

さて、残るはマネジメントと開発者の間のコラボレーション…の話の前に、ちょっと寄り道をしておかなければなりません。

それは、“オープン・サービス・フォー・ライフサイクル・コラボレーション”の話です。

クラウドでのコラボレーションをサポートする。

オープン・サービス・フォー・ライフサイクル・コラボレーション（Open Services for Lifecycle Collaboration、以下OSLC)は、 ソフトウエア開発のライフサイクル全般にわたって開発メンバー間のコラボレーションを促進するための技術標準を策定しようとするイニシアティブです。 公式サイトは、こちらです（→http://open-services.net/html/Home.htmlです）。

公式サイトは関連情報てんこ盛りなので読み取るのは大変なのですが、技術的側面だけにしぼっていうと、 以下の3つに関して標準的なモデルを決めようとしています。

1) Uniform Access 2) Common Data Format 3) REST Architecture

…“3)”を読む前にわかった方もいるかもしれませんが、そう、RESTの話なのです。 「REST」あるいは「RESTful」という技術自体の解説は、本稿の趣旨にはあわない（私の手にも余る^^;）ので、関連記事を検索していただくとして、 開発ツールの文脈で置き換えて、次ページから紹介していきます。