1) Uniform Access

従来の開発環境であれば、共有される情報形態の、多くが、“テキスト形式”であり、それらがデータベースに格納されてきました。ツール間の情報の連携は各ツールベンダーが独自に提供するAPI経由でのみ実現できました。これは、既存の環境に異なるベンダーのツールを組み入れようとする場合の障害になることも珍しくありません。

しかし、プロジェクトの中で取り扱われる情報は、多様化しています。アプリケーションで利用するマルチメディアデータは言うに及ばず、仕様を検討する場でスクリーンショットがあったり、トレーニングマニュアルがE-ラーニングになっていたり等々。

また、情報の活用手段も多様化しています。各ツール専用のクライアントで利用できればいいだけではなく、ブラウザ経由で情報を照会したり、場合によっては、チャットやAtomのフィード、メールで情報そのものを飛ばしたい…。

RESTの特徴のひとつであるUniform Accessでは、ポイント先がどこであれ（どんなツールであれ）、またそのデータの形式が何であれ、たったひとつの表現形式（よく例に出るのは、 HTTPでGET,POST…ってやつですね）でのアクセスを実現しようとするものです。

これはアプリケーション自身の表現力だけでなく、開発者を支援するツールが今後よりよい形で開発者を支援するために採用を進めるかもしれないさまざまなデータを取り扱えるための、技術基盤と必要となります。

2) Common Data Format

有償無償さらにはオープンソースまで含めて、最近の開発者は、多くの開発ツールを使うことができるようになりました。たくさんあるとはいっても、たいがいは何らかの技術領域、例えば“要求管理”“変更管理”等の領域に分類することができます。

ベンダーの視点では、自社の要求管理ツールと変更管理ツールで情報の連携ができるのがあたり前になっています。問題は、異なるベンダー間のツール、あるいは異なるプロジェクトで、基本データ構造が異なることがほとんどだということです。

例えば、以下のようなことが実際に起こります。

・A社の要求管理ツールに管理されている「ソフトウエア要求項目」と、B社の変更管理ツールで管理されている「機能変更依頼」とを連携させようとしても、そもそも情報間関連づけのモデルが違うので、連携できない。異なるベンダーのツールが混在すると、同じ作業をするのに、操作法が微妙に異なる。職場異動になって違うプロジェクトに入ると、その中のツールの使用法が以前と異なり、開発者にとって効率低下の要因になる。

・あるプロジェクトではA社の障害管理ツールを使い、別なプロジェクトではオープンソースのツールを使っている。PMOとしては、全プロジェクト横断で品質情報として管理したいのに、管理される情報の形態やその処理の仕方が異なるので、比較検討ができない。また、それを実現しようと思うと基本的なモデルのすり合わせ等から始めなければならない（図2参照）。

OSLCでは、各技術領域にわたって、ソフトウエアで処理することを前提に、「共通項として扱えるデータ」と「それに加える拡張部分の取り扱い方」に関する標準を決めようとしています。いま、俎上（そじょう）に上っている、技術領域の代表的なものを何点か挙げておきましょう。

・要求管理
・変更管理
・プロダクトライフサイクル管理
・品質管理
・アセット管理
等々。

3) REST Architecture