CodeZine(コードジン)

特集ページ一覧

第1回 RUPはどこに消えたのか?

“アジャイル”の次へ:IBMの開発プロセス戦略の今(1)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/03/12 13:00

目次

変わり続けるRUP

 さて、このような努力の甲斐あって、RUPは中・大規模プロジェクト向けの開発プロセスとして広く認知いただけるようになりました。しかし、このRUPも急速に変化してきました。そこには、「開発プロセス、かくあるべし」の思想を見て取ることができます(図2)。

図2 変わり続けるRUP
図2 変わり続けるRUP

1)オープンソース・コミュニティへの寄贈

 1つはオープンソース・コミュニティや標準化活動への技術提供です。 

 2000年代半ば、IBMは、RUPをベースに2つの活動を行います。1つは、Eclipse Foundationに対し、プロセスフレームワークを定義するプロジェクトを提案します。これが、Eclipse Process Framework(EPF)です。この際に、RUPの軽量化バージョンであるOpenUP(オープンナップ)と、プロセスを編集するツールEPF Composerを寄贈します。

 2つめは、 UMLの標準化団体で知られるOMGに対する、プロセスのメタモデル定義の提案です。これは、Software Process Engineering Metamodel(SPEM)として採択されています。

 この2つは何を意味しているのでしょうか? RUPを唯一無二の開発プロセスとするため(世界征服)? いえいえ、違います。この2つによって次のことが可能になります。

  • プロセスメタモデルによって、「そもそもプロセスを構成する要素とはなにか?」を、企業内のローカルルールを越えて、揃えることができる
  • プロセスフレームワークによって、特定の開発技法への依存性を下げた「進め方の大枠」を扱えるようになる。

 開発対象の複雑さが増し、採用される技術やアーキテクチャも多様化すると、単一のメソドロジーやプロセスでカバーすることが自体が非現実的になります。しかし、開発対象が替わり、メソドロジーが変わるたびに、プロジェクトとして取るべきアクションや成果物が一からすべて変わっているようでは、オーバーヘッドばかりで効率化もなにもありません。オフショアに見られるように、開発体制自体がグローバル化し、さまざまな企業が共同開発を進めるようになると、これらの問題は無視できません。

 プロセスメタモデルとプロセスフレームワークを組み合わせることで、メソドロジーの差異から少し距離を置いた組織やチームの規範を設定できるようになるのです。

2)プラクティスのライブラリ化

 いまでも誤解されている方がいらっしゃいますが、RUPは、完成型のプロセスではなく、カスタマイズを前提したプロセスのテンプレートです(とはいいつつ、結構な情報量が入っているのですが^^;)。当初は、HTML形式のドキュメント集でしたから、カスタマイズする場合は、HTMLを直接編集するか、別に文書をおこすのが常でした(中にはFlashで、まったく同じ見た目を作られたお客様もいましたな)。

 しかし、EJBやらSOAやら.NETやら、果てはSAPのようなパッケージ主体の開発やらと、さまざまなバリエーションが派生しうることを考えると、カスタマイズの作業そのものが大変になり、プロジェクトに適切なプロセスの準備に時間がかかりすぎるようになりました。

 現在のRationalのプロセスでは、特定の技術領域や開発工程に関するノウハウを、ライブラリ化して、編集ツールでそれらを組み合わせて最終版のプロセス記述を整形するというアプローチを取っています。前述のEPFは、まさにこのアプローチのオープンソース実装です。新しい技法が出てくれば、そのメソドロジーをメソッドコンテンツと呼ばれる形式で定義してライブラリに追加し、メソッドコンテンツ同士を組み合わせる…そんな流れで短期間でプロセスの拡張が実現できるのです(図3)。

図3 モジュール化されたコンテンツ
図3 モジュール化されたコンテンツ

 開発プロセスはそれを決めることがゴールではありません。プロジェクトに適用して効果がでて始めて意味があります。クイックに定義し、現場に適用し、その結果や状況の変化に応じて、適切な修正を施し、再度現場に適用し…プロセスを適用し改善するという活動そのものが反復的である、という考えが根底にあります。

 そしてこのサイクルを短期間で軌道に乗せるためには、学習時間をいかがに少なくするか?が重要です。オープンソース化されたプロセス・メタモデルやプロセス・フレームワークは、「プロセスの基本的な構造」を組織の壁を越えて共有知化することを可能にします。

 あらかじめ各種の技法がライブラリ化されていることで、特定のプロジェクトに最適化されたプロセスを短期間で定義することができます。

 これらの要素は、「開発プロセスはプロジェクトに最適なモノを用意し適用すべき」というビジョンの表れであり、その目指すところは、開発プロセス適用&改善サイクルのスピードアップに他ならないのです。

 ちなみに、現在のRUPはメタモデルとしてSPEM2を採用し、OpenUPを拡張する形で再構成されています。併せて、EPF Composerの機能強化版を製品(Rational Method Composer)としてリリースしています。

関連リンク

  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:“アジャイル”の次へ:IBMの開発プロセス戦略の今

著者プロフィール

  • 藤井 智弘(フジイ トモヒロ)

    日本アイビーエム株式会社 ソフトウェア開発研究所 Rationalエマージング・ビジネス・サービス。ソフト開発ってホントはもっとおもしろかったはず!という思いのもとで、”管理管理!”でも”開発者の自由!”でもなく、その程よいバランスこそが解と、啓蒙活動...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5