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

3) REST Architecture

1）2）の仕掛けからあきらかなように、ツールの側はRESTアーキテクチャを採用することを推進しています。 オフショアでよく見られる、 開発拠点の分散と、複数の協力会社とによる開発体制では、ソフトウエア開発の過程で扱われる情報や成果物を、

・どこに、どんな形態で
・どのツールに管理しているか
を理解し、連携方法を検討したり、場合によってツール環境を一気に置き換える
･･･なんてことに時間とコストをかけざる得ない状況が、事実としてありました。

しかし、開発組織とはいえ、経営層からの要求は、厳しさをますばかりです。開発コストの劇的削減や、競争力確保のためのM&Aを行い、 従来よりも早いサイクルでの製品投入を求められている現実からすると、開発という本業のための準備期間でしかないツール統合に、 多くの時間とコストをかけられないのが現実です。

ここから生まれた発想が、「ライフサイクル全般の情報を取り扱うために、専門的な複数のツールを統合する」という従来の見方ではなく、 「ライフサイクル全般の情報は、ネット上の適切な場所に（リソースとして）存在するので、必要に応じてそれを照会する」という見方です。

ある意味、実装に使われているツールの詳細を隠ぺいし、それが存在する場所を隠ぺいし…と、ここまで書けばおわかりのように、 かなりクラウドを意識した利用モデルを想定しているのです。

これを実現するためにRESTアーキテクチャ採用を推進しているのです。

そしてマネジメントと開発者の話にもどる…

冒頭に振り返ったように、コラボラティブの要素のひとつは、“リアルタイム性”です。これまでのALMは良くも悪くも “情報の共有“に焦点をあて、「管理対象であるデータの正確性」と「工程をまたがった情報関連の完全性」を重視してきました。

「いまそこにある一群のデータのとその関係性の完成度をいかに高めるか？」というのが、ALMへの投資を検討する際の主要な論点であり、 これはいわば “静的”側面を重視したアプローチと言えます。

それに対して、IBMが推進している“ツールによるコラボレーション”とは、共有された情報やそれによって表現されるプロジェクトの文脈を積極的に活用し、 「個々人の作業の効率化」だけでなく「開発」におけるチームメンバー間のダイナミクス（“情報や作業内容の交換”や、 “それを踏まえ文脈を共有することでより質の高い議論をする”といった協調的なアクション）をどう加速するかに重点を置いています。 これまでの情報共有を“静的”と置くなら、プロジェク トの“動的”側面に課題あり、として、解決しようと試みているのです。

特にマネジメントに着目してみると、いかなアジャイルとは言っても、コスト・予算・期間の制約をマネージするマネジメント層が不必要なわけではありませ ん。 マネジメントが現場の状況を把握し、それに対して適切なタイミングで、適切な支援をする…しかも、同じプロジェクトルームにいるメンバーに対してだけでなく、 遠く海の向こうの海外拠点で働くチームの状況を把握しなければならない。

OSLCが推進しているアーキテクチャは、“RESTful”と書いてしまえばとても技術マニアっぽい議論に聞こえますが、それが実現したいことは、 「開発チームのいまの状態は、実はネットにそのまま記録されている」という環境を提供することで、マネジメント、そしてもちろん開発メンバーも含めたプロジェクト全体で、 バーチャルなプロジェクトルームを作ることなのです。

■最後に

開発ツールの動向…といいつつ、今後の開発スタイルの変化を見据えてあるべきものを提示しようという意識が頭の隅にあったので、 機能の細かい話をご期待の方にはもうしわけなかったかな、と思います。が、そんな皆さまには弊社の宣伝サイトやYouTubeを見ていただくと、 めまいがするくらい情報が載ってますので、そちらも併せてご覧ください。

ツールというとともすると機能の比較表作りに明け暮れるという姿が、お客さま担当者にも弊社の人間にも見受けられます。それも大事ですが、 それ以前、ま ず自分たちの「阻害要因」を把握する、というちょっと回り道をしてはどうでしょうか？

…ということで、4回にわたりお付き合いいただきありがとうございました。