日本の開発現場にたちはだかる課題
ソフトウェア開発の生産性向上は、企業にとってビジネスの業績を左右する課題だ。それが自社の製品や業務システムであれ、顧客への提供サービスや受注システムであれ、開発の効率、品質を向上させ、手戻りを減少させることはビジネス上の競争力を格段に優位にするからだ。
しかしながら実態は厳しい。JUAS（日本情報システム・ユーザー協会）の調査によると、500人月以上のシステム開発プロジェクトの場合、品質に対して不満と答えた顧客は31%。4割以上のプロジェクトが納期遅れ、設計仕様の変更による手戻りなどが増大しているというのが現状である。またIT能力の人員の能力の充足度に対しては74%が「不足している」と答えている。
「これは決して現場のIT部門の技術レベルの低下が原因ではない。むしろ技術ではなく業務知識や提案力、不況によるコスト削減の圧力や短納期化などといった厳しい環境要因による。こうした課題を乗り越えるための方法が求められている」―こう語るのは、IBMのRational事業部の熱海英樹氏である。
コラボレーション基盤としてのCLMはALMの進化形
こうした背景もあって、ここ最近日本でも「アジャイル開発手法」が注目されている。従来のウォーターフォール型の開発ではなく、迅速かつ柔軟にチーム・組織で開発を進めるアジャイル開発は、IBMの社内のソフトウェア開発プロジェクトでも近年積極的に導入され、確実な成果を上げているという。IBMはグループ全体の取り組みとして、開発資産（アセット）の再利用を促し、廃棄コードや作業の手戻りを4.5%削減し、さらにメンテナンスコストを300ミリオンドル削減することで、一人あたりの売上高を純利益ベースで15%向上させた。IBM Rationalのアジャイル/反復プロジェクトは、2006年には5%であったが、2011年には85%に達している。今回発表されたCollaborative Lifecycle Management（以下CLM）には、こうしたIBM Rationalのアジャイル開発などの変革への取り組みから得た知見が投入されている。
CLMとは、ひとことで言えば「開発を協調しておこなうための環境」であり、要求、設計、実装、配置・運用といったそれぞれのプロセスでの役割、情報、成果物の結び付けを強化するための基盤である。しかし、CLMというコンセプトそのものは、まだ一般に馴染みがない。
近いソリューションとしては、ALM（Application Lifecycle Management）というものがあり、こちらは徐々に浸透してきている。
ALMもまた、ソフトウェア開発における反復サイクルにおける人、情報、プロセスの流れを操ることを目的に、開発・実装・テスト・配置の各フェーズでの開発の成果物を一元的に管理するものである。
ALMは、開発の成果物やビルドを管理するリポジトリやドキュメント管理ツールとして利用されていて、大規模で複雑な開発案件では成果をあげている。CLMとはこのALMの「進化形」であるともいえる。
ALMは、各工程や組織、部門、役割ごとに分断されてしまい、組織間の協調がなかなか難しい。CLMはこうした開発成果物の一元管理を前提としながらも、複数の異なる組織、拠点、役割を横断した開発を前提としており、サイロ化した開発の壁を超えることを目的にしている。ではCLMは従来のALMのような文書管理型の開発基盤に、グループウェアのようなコラボレーションツールを連携させただけのものなのか。答えはそうではない。
ソフトウェア開発を成功に導くための5つのプラクティス
熱海氏が今回のセッションで強調したのは、「CLMは単なるツールの組み合わせではなく、ビジネスと開発の間を取り持つ、プラクティス=実践方法として理解してほしい」ということだ。
IBM Rationalといえば、RUP（Rational Unified Process）などに代表される、開発プロセスの方法論やフレームワークの先駆的な提唱者というイメージがある。
今回のCLMでも、熱海氏は実践のガイドラインとして「ソフトウェア開発を成功に導くための５つのプラクティス」を紹介した。それは次の5つの項目である。
そして、これらの適用シナリオとして、Innovate2011のセッションではデモがおこなわれた。
チーム・組織の開発生産性を高めるためには、ゴールとプロセスの共有が必要である。たとえば、自分が作っているものの目的は何か、チームとしてどのように動いているのか、成果は貢献できているのか。こうした「共有」のための努力が、ともすれば自己目的化してしまうことも多い。
たとえば、進捗を確認するために会議をおこなう。その会議資料やメンバー共有のための様々なドキュメントのために残業をする、などという事態が発生する。「こうした労力によって実際に得られる情報の共有は事後的にすぎない」と、熱海氏は指摘する。
熱海氏の紹介を受けて登壇したRational事業部の熊田貴之氏と金元隆志氏によるデモでは、開発チームと品質管理チームやテストメンバーとの協調や、開発スタッフとその指導にかかわる上司とのやりとり、さらには要求定義をするメンバーのその要求のオーナーであるビジネス側との連携などの方法が紹介された。
例えば、開発のメンバーが今日とりかかる作業を特定するためにダッシュボードを見る。そこでは自分の開発の管理画面から、さらに上位にある要求やその開発を必要とするビジネスの要件まで遡及することができる。
開発者は作業の指示だけでは読み取れない、要求の真意とコンテキスト（文脈）を理解した上で開発をおこなう。
両氏のデモでは、開発と品質の協調のシナリオとして、実装途中で、関連する他のメンバーに協力を依頼し、ユニットテスト用のデータを受け取るなどの工程をブラウザ画面のダッシュボードでスムーズにおこなうデモが紹介された。これらは先に述べられた「リアルタイムプランニング」「開発インテリジェンス」「継続改善」のシナリオである。
また別のシナリオでは、各工程での開発メンバーがダッシュボードで成果物を管理していく中で、プロジェクトを横断的にみているプロジェクト・マネージャーが成果物に対する評価、意見を述べる。ここで重要なことは、携わるメンバーが「同じデータ」を見ながら、その場で改善を施し、リーダーがリアルタイムに意思決定をおこない調整していくことで開発と成果物の乖離の最小限化と手戻りの抑制である。
またメンバー間のこうした気づき、意見、会話はチャットやメッセージ機能によっておこなわれるが、その記録も最終的に成果物と一緒に管理され、後で遡ることができる。これによって、仕様書や議事録、メールログなどをばらばらにたどるだけでは把握できない仕様や要求の真意を改善・継承することが可能だ。こうした流れが「ライフサイクルでのトレーサビリティ」「コンテキストに応じたコラボレーション」の一例である。
CLMの製品構成
これらのCMSのコラボレーション環境はすべてhttpsを介したブラウザの環境で提供される。実際に米国では、製造業や金融系の大規模かつグローバルな開発体制での導入成功事例がある。今後は請負先を含めた企業間や、外部委託などの異なる企業間での共同開発などでも適用されることで、「企業の壁を超えた」開発の可能性まで視野に入ってくる。
こうしたCLMのRationalの製品は、要求管理とドキュメント管理の環境ツール「Rational Requirement Composer」（RRC)、チームコラボレーションの環境ツール「Rational Team Concert」（RTC)、品質管理のリポジトリ環境「Rational Quality Manager」（RQM)を統合した環境として提供される。特長としては、個々の機能が連携する「スター型」でなく、Rational の統合開発環境基盤である「Jazz」を中核にした「ハブ型」であることだ。
今回のCLMの提唱は、構成・変更管理、品質管理、要求管理といった開発環境を、協調開発というコンセプトでまとめあげたものとして意欲的なものだ。ソフトウェア開発の現場の制約として立ちはだかる3つの壁、「役割、プロセス、ツールによる分断」「開発に強いられる状況の不透明さ」「分散/仮想チームによるコミュニケーション不足」を乗り越える試みとして、成果が期待されるところである。
