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

これからのプロセスのアプローチ：“開発プロセス”から“開発組織のためのプロセス”へ

　実はここまで、ずーっと「RUPは～」と書きながら、実は違和感を感じていました。前項で、プロセスの元ネタ集としてライブラリ（これを、IBM プラクティス・ライブラリと呼んでいます）があり、そこからコンテキストに応じたプロセスを生成するという話をしました。従来RUPと呼ばれたプロセスは、生成可能なプロセスの一つという位置づけに変わっています（これは、StandardRUPと呼ばれています。図4）。

図4　RUP以外にも多くのプロセス/プラクティス

　これらのプロセスは、いわば「モノを作るためのプロセス」です。新しいプロセスを採用する目的は、個々のプロジェクトの生産性や効率を高めることにありますが、これらの改善活動は本来一過性のものではありません。問題を把握し、分析し、仮説を立て対策をほどこし、結果を検証する…改善活動自身も反復的に行われるプロセスにほかなりません。

　「改善活動そのものをどう進めていくか」「改善されていることをどうやって把握するか」は、改善を推進する責任を持つ推進チームが頭を痛めるところでもあります。

　IBMプラクティスライブラリの守備範囲は、開発の改善活動自体を対象に拡大しています。図5）は「パフォーマンス測定プラクティス」の概念的な絵です。

図5　ビジネスゴールを実現するためのプラクティスの体系化

　あまたある開発プラクティスの中で、自分達はなにを選択すべきなのか、その効果を測る指標は何かを、過去多くのお客様のプロセス改善をお手伝いしてきた経験から体系化しています。

　これもまた、改善活動を短期間で立ち上げる工夫の一つです。

　そしてこれらをある程度の規模で実現するために、さまざまツールによるサポートを提供しています。プロセスやプラクティスをノウハウとするなら、各種のツールはそのノウハウの実行エンジンと言えます（図6）。

図6　「開発のためのプロセス」から、「開発組織のためのプロセス」へ

…そして再び、「RUPはどこに消えたのか」

　RUPは消えていません。技術動向やビジネス状況に合わせて進化しています。しかし、Rationalのプロセスを核とするソリューションは、単一のモノ作りプロジェクトを対象としたものから、改善をもくろむ組織全体をサポートするものへと、その守備範囲を広げています。今後の連載で、この実行エンジンの部分も含めて、プロセスを核としたソリューションの姿をご紹介していきます。次回は、アジャイルプロセスDAD（ディシプリンド・アジャイル・デリバリー）のお話です。おつきあいください。