アジャイル開発「統一プロセス（UP）」を知る
初めてのアジャイル開発 〜スクラム、XP、UP、Evoで学ぶ反復型開発の進め方〜
―――――――――――――――
――――アジャイル開発――――
―――――――――――――――
どの程度の人物かを知るには、その人にとって
何の特にもならない人をどう扱うかを見ればよい
―サミュエル・ジョンソン
アジャイル開発「統一プロセス（UP）」について知る。
僕の勤める現場では、実際には、前回書いた「スクラム」と
今回の「エクストリーム・プログラミング」を組み合わせているため、
統一プロセス(UP)は取り入れていないが、スクラムのプラクティスと一致する部分が多く、また、ほとんどのXPのプラクティスはUPのプラクティスと矛盾せず、XPのプラクティスの多くは非常に重要なUPプロジェクトに適用することができるという面もあり、知識として吸収しておく。
以下はアウトプットである。
統一プロセス(Unified Process : UP)は、良く知られた反復型プロセスフレームワークで、その詳細版であるラショナル統一プロセス(RUP)の名が特に有名である。以下にあげるいくつかのキープラクティスやガイドラインは、UPの精神を良く表している。
・短いタイムボックスを設定したイテレーションで開発を行う。
・リスクや価値の高い要素（中核となるアーキテクチャなど）を初期のイテレーションで開発し、なるべく既存コンポーネントを再利用する。
・顧客に確実に価値を提供する。
・プロジェクトの初期の変化に順応する。
・一つのチームとして一緒に働く。
UPでは、イテレーションを４つのフェーズに体系化している。推敲フェーズのイテレーションではリスクの高い中核アーキテクチャのプログラミングを重視し、作成フェーズのイテレーションでは残りの部分を構築する。
――――――――
―――目次―――
――――――――
●手法の概要
●概論
●ライフサイクル
●基本プラクティス
●UPのガイドライン
●六つのベストプラクティス
●作業成果物
●その他のプラクティスおよび価値
●価値
●定義された重量級のプロセスとしてのUPとアジャイルなUPアプローチ
●ウォーターフォールの考え方を重ね合わせること
●その他の良くある誤解
●プロセスの組み合わせ
●採用戦略
●現実と幻想
●長所および「その他」
――――――――
―――内容―――
――――――――
●手法の概要
タイムボックスを使ったイテレーションの期間は2〜6週間を奨励している。
普及している他のIID手法と比べてUPに顕著な特質は、非常に形式的なやり方や詳細なドキュメントを「オプション」として位置づけ、それらの取り入れ方次第で、儀式度を高くも低くも設定できることである。良く誤解されるが、実は、UPは儀式度を比較的軽くするよう勧めている。それでも一般的には、推奨しているドキュメントやモデリング作業は、XPよりも多い。UPは、さまざまな不測の事態に備えて、約50種類のオプションの作業成果物を提供している。
UPは、失敗してもせいぜい快適さが失われる程度の小さな３人プロジェクトにも、何百人もの開発者が参加する生命にかかわるシステムにも適用することが出来る。
●概論
UPは、反復型プロセスフレームワークである。
UPはどちらかというとプロセス定義を重視しており、本書で説明している他の反復型プロセスよりも大掛かりで広い範囲を扱っている。
UPでは、約50種類のオプションの（ソフトウエア以外の）成果物（作業成果物）が定義されている。たとえば、開発構想書である。個別のプロジェクトでどれだけの成果物を作成するかは自由で、「少ないほうが良い」というのが指標となるルールである。ただし、開発構想書やリスクリストなど、いくつかの作業成果物はいつも作成することを勧めている。UPの作業成果物は、必ずしもコンピュータで作成したドキュメントである必要はなく、「情報そのもの」であることに気をつけてほしい。たとえば、リスクリストはプロジェクトルームの壁に貼るポスターとして作成しても良い。
作業成果物は、「要求」などの作業分野（discipline）ごとに整理される。作業分野とはソフトウエアプロジェクトにおける考慮事項や作業の主な領域を定義したものである。
UPは、プロジェクトのたびにカスタマイズする必要がある。独自にカスタマイズして出来上がったものをプロジェクトの開発個別定義書と呼ぶ。一般に、「少ないほうが良い」という指針があり、開発個別定義書には、プロジェクトのリスクに対処し目標を達成するために必要な最小限の作業成果物だけを含めるよう推奨している。
●ライフサイクル
１．方向付けフェーズ
作業には、短期の要求ワークショップ、要求の１０％の詳細定義（アーキテクチャ上、最も影響が大きいもの）、概要レベル要求の「トップ１０」リストの作成、プロジェクトの開発構想書および開発企画書の第１版の作成などがある。このフェーズが長くなるのは、たいてい仕様や計画を事前に詰めすぎている兆候である。２，３日程度の短い期間で終わらせるのが理想である。
２．推敲フェーズ
まず、アーキテクチャの視点から見て重要な中核要素を、短期間のタイムボックスに設定されたイテレーションのなかでプログラミングし、テストする。その結果、フェーズの終わりには、ある程度信頼できる計画と見積もりが可能になる。つまり、このフェーズでは、要求や設計モデリングだけではなく、「プログラミング」作業も行うことになる。推敲フェーズは発見と創造のステップであり、フェーズ終了時には、反復型・進化型のプロセスを通じてシステムの中核部分と要求のほとんどの部分が安定する。
３．作成フェーズ
推敲フェーズで固められた基礎の上に、残りのシステムを短いイテレーションで構築する。要求はまだ変更される可能性があるが、システムに大幅な影響を与えうる新たな要求は、すでに推敲フェーズで引き出し、発見できていれば理想的である。そのほかの作業には、アルファテスト、パフォーマンスチューニング、ドキュメントの作成（ユーザー向けマニュアルなど）がある。
４．移行フェーズ
システムが最終的に導入される。まず、リリース候補を公開し、レビューとフィードバックを受ける。これは複数のイテレーションで行ってもよい。最後に導入を行う。導入では、さまざまな経路での配布、教育、旧システムとの並行稼動、データ移行などを必要に応じて行う。
UPでは、プロジェクト内にあるいくつかのマイルストーン目標で上記のフェーズの境界を定義する。これらはバリー･ベームの研究に基づいている。ベームは、方向付けが終了する時点を「ライフサイクルの目標(Life Cycle Objectives : LCO) マイルストーン」と読んでいる。推敲の終了時は「ライフサイクルアーキテクチャ(Life Cycle Architecture : LCA) マイルストーン」である。フェーズごとに複数のイテレーションが行われる。
●基本プラクティス
UPのプロジェクトであると言うには、少なくとも以下の条件を満たす必要があるだろう。
・UPのガイドラインおよびベストプラクティスに従っていること。
・開発構想書やリスクリストなどは、少なくとも2、3のUPの成果物を作成していること。
他の名前や従来使っていた名前ではなく、UPの作業成果物名を使用していること。これは共通の用語を定着させるためである。
・方向付け、推敲、作成、移行の各目標に合わせて、イテレーションやマイルストーンの目標を設定していること。
●UPのガイドライン
これはUP/RUPプロジェクトを継続させるための基本姿勢である。
・早い段階から継続的にリスクをやっつけること。そうでなければリスクにやっつけられてしまう。
・早いうちから頻繁に価値のあるものを顧客に提供すること。
・初期のイテレーションでは、仕様やドキュメント類ではなく、実行可能なソフトウエアの開発に注力すること。
・プロジェクトの早い段階で変化に適応すること。早期の開発、数回にわたる要求ワークショップの開催、変更管理ツールの利用などを通じて、変化を引き起こしてマネジメントする。
・実行可能なアーキテクチャを早い段階でベースラインとして仕上げること。
・コンポーネント指向のアーキテクチャを目指し、既存のコンポーネントを再利用すること。
・一つのチームとして協調して作業を進めること（たとえば機能をまたがったチームなど）。
・品質とは日々の生活の中にあるもので、後で付け足すものではない。
●六つのベストプラクティス
UPは六つのベストプラクティスだけを指すわけではないが、これらは最低限、注意しなければならない重要なものである。UPを採用する場合には、以下に挙げるプラクティスを理解し、その大部分あるいはすべてをプロジェクトに適用しなければならない。
１．UPのプラクティスの中で最も重要なのは、２週間から６週間（推奨）のタイムボックス化されたイテレーションによって開発すると言うことである。つまり、ウォーターフォールのライフサイクルを適用したり、最初に要求分析を完全に終わらせようとしたりするべきではない。他の反復型ライフサイクルを推奨する開発手法と同様に、最も重要な要求をまず理解し、その部分から早期にプログラミングに取り掛かるべできある。要求や設計は、プログラミング作業からフィードバックや適応を元に改善するべきであって、事前に大規模な要求分析を行ったり推敲をもとに「Power Pointのアーキテクチャ」を作ろうとしたりするべきではない。
２．重視すべきことは、ハイリスクまたは重要な要素から開発すること、中核アーキテクチャを初期のイテレーションで構築すること、（規模の大小を問わず）既存のコンポーネントを再利用して新規のコードや欠陥を減らそうと努力することである。
３．継続的に品質を検証すべし。早い段階から頻繁にテストを行うこと。実際には、イテレーションごとにすべてのソフトウエアを統合しテストする（単体テスト、システムテスト、負荷テスト）。このベストプラクティスには、XPで奨励されている「テスト駆動開発」や「継続した結合」といった技法を含んでいる。そして、これはコード以外のことにも言える。定期的にチームミーティングを行い、さまざまな作業について評価することで、使いやすさや、コード以外の成果物（要求など）の品質、プロセス自体についても早い段階で検証すべきである。
４．イテレーションでプログラミングを始める前に、少しでも視覚的なモデリングを行うべきである。たとえば、１時間ホワイトボードに向かって絵を書き、低レベルのコードの詳細は無視して、創造的な設計概念について検討し、議論するなどである。このスケッチは業界標準の統一モデリング言語（UML）に完全に準拠する必要はない。そして、複数の視覚的なモデルを平行して作成する、デジタルカメラを使って絵の写真をとる、といったアジャイルモデリングで推奨されているプラクティスは、このベストプラクティスに適用することが出来る。あるいは、CASEツールを用いても良い。
５．洗練された方法で「発見」「整理」「追跡」することで、要求を管理すべし。事前に大規模な分析を行うのではなく、反復的、インクリメンタルに要求を発見･改良する。ツールを使って、リスク、優先度、状態（新規、割り当て済みなど）といった属性や、他の要求との依存関係をもとに要求を整理し、分析しやすくする。一人の人がすべての要求を認識し、判断を下すことが難しい大規模プロジェクトの場合には、ツールを使うと良い。ツールを使うことで、要求の状態を追跡でき、何が終了し、何が作業中かなどを知ることが出来る。
６．規律のある構成管理およびバージョン管理、変更依頼の手順、各イテレーションの最後にリリースをベースライン化するなどによって、変更を管理すべし。
●作業成果物
作業成果物は全部で50種類ほどある。UPの作業成果物に関して何よりも重要なのは以下の点である。
・不当な批判？――UPは、他のIID手法と比較して作業成果物が多すぎると批判されることがある。しかし、UPのリストを見渡すと、「リリースノート」や「部品表」「トレーニング教材」などの作業成果物も含まれている。これらの作業成果物は、どのような手法を使っている場合にも、たいてい作成するものである。UPはそれを明示していて、（たとえば）XPやスクラムは、明示していないと言うだけである。さらに、これらを作成するかどうかはどれも任意である。
・共通の語彙――大規模な組織、特に開発者が数百人にのぼったり複数のオフィスに分散したりする組織では、作業成果物の用語（「開発構想書」「ソフトウエアアーキテクチャ定義書」など）を共通にしておくと役に立つ。
・情報そのもの――UPに定義された成果物は、具体的な電子ドキュメントではなく情報そのものである(RUP製品では文書テンプレートの例を提供しているが)。「リスクリスト」は壁に貼るポスターとして作成してもいいし、「ソフトウエアアーキテクチャ定義書」はビデオでもいい。「設計モデル」はホワイトボードにUML風の絵を書いてデジタルカメラに写したものでもかまわない。
●その他のプラクティスおよび価値
・プラクティスの取り込み――UPはIIDプロセスを幅広く一般化して定義したものである。そして、数多くの詳細なプラクティスも定義、推奨されており、それらはUPで「独自に」定義されていたり、他の手法から採用されたものなどがある（XPのテスティングやスクラムミーティングなど）。反対に、XPの「テスト駆動開発」など多くのプラクティスは、UPの「継続的に品質を検証すべし」などのプラクティスを特化したもの、あるいはそのバリエーションである。
・ユースケース駆動――UPでは、機能要求を収集するのに必ずしもユースケースを適用する必要はない。機能リストを使ったユーザー機能駆動型開発を行ったりすることも可能である。ただし、問題領域にユースケースが適しているなら、UPではそれを使うことを推奨している。その場合、ユースケースのシナリオをベースにイテレーションを構成し、アーキテクチャ的に最も重要で、リスクが高く、ビジネス上の価値の高いシナリオに早期に取り組むよう推奨している。つまり、ユースケースを中心に反復型開発と受け入れてストが進むわけである。
●価値
XPやスクラムとは対照的に、UPではベースとなる価値が明示されていないが、推測することは出来る。XPの価値が人やコミュニケーションの品質を重視しているのに対して、UPの価値は人よりもプロジェクトを中心としたものになっている。UPの価値には、以下のようなものがある。
・UPのガイドラインとベストプラクティスを適用することが重要である。UPの価値の中には、ここから論理的に導き出されるものがある。たとえば、ウォーターフォールよりも反復型のほうが優れている、中核アーキテクチャを構築すべき、変更管理は公式に行うべきだ、などである。
・リスクと価値を中心に進めるべきである。
・利害関係者の本当のニーズを要約した、プロジェクトの明確なビジョンを（UPの開発構想書という作業成果物に）定義することが重要である。
・ベストプラクティスに従いながらも、各プロジェクト独自のニーズに合わせてUPのプロセスをカスタマイズすることが非常に重要である。また、価値をもたらす最小限の作業成果物に限るようカスタマイズするべきである。
・作業や、作成する成果物、個人やチームのタスクについて、指針となるプロセスをしっかりと定義しておくことが望まれる。
●定義された重量級のプロセスとしてのUPとアジャイルなUPアプローチ
標準的なアジャイル手法と比べて、UPで論点となるのが、この最後の価値である。アジャイルプロセスのコミュニティの中には、UPのような明確に定義されたプロセスはあまりに「重量級」だとして、それが有効だと言う考えを無造作に片付けてしまう人がいる。
まず、UPの創始者は、このプロセスが厳格な重量級の方法で適用あるいは採用されることを意図していない。彼らは、経験を積んだ実践的なソフトウエア開発者であり、シンプルさやアジャイルさも高く評価していた。彼らは、UPとは必要なものを選ぶための選択肢を集めたものであり、その精神とベストプラクティスを採用してさえいればよいと考えていた。
コーバーンはこの問題について別の見方をしている。彼は、ある事柄について学ぶときに、人がどう振る舞い、耳を傾けるかを、成熟の段階によって３つのレベルに分類した。（１）従うレベル、（２）取り外すレベル、（３）流れるレベルの３つである。彼はこれをソフトウエア手法の文献や手引きに関連付け、「共通のプロジェクトルームで仕事をし、４週間ごとに利用可能なソフトウエアを導入する」というようなレベル３にあたる簡潔な助言は、「流れるレベル」の熟練者には向いているかもしれないが、未熟な「従うレベル」の開発者には向いていないと指摘している。
UPの詳細に定義されたプロセスは、主にレベル１人向けであり、その場合には学習のためにいくらか役に立つし、品質保証のチェックリストにもまる。
レベル２および３の開発者の場合は、UPで規定・定義されていることのうち、たとえばどのタスクをどの順序で行うかなどを無視しても差し支えない。そしてもっと単純に、経験的なプロセスの考え方でチームを創造的に判断して、作成するUPの作業成果物を選択し、ベストプラクティスを適用していくべきだろう。
●ウォーターフォールの考え方を重ね合わせること
UPに関する大きな誤解の中で最も良くありがちで、これを見れば、UPの「専門家」が実は専門家でないことが簡単に見破れる。それは、４つのフェーズをウォーターフォールのフェーズ（要求、設計、実装、テスト）と同じように説明することである。
１．方向付け―要求分析、詳細仕様
２．推敲―より詳細な要求分析、モデリング、設計作業
３．作成―設計のプログラミング
４．移行―テスト
このようにUPのフェーズを不正確に説明するのは、もっともよく見られる誤解をしている証拠である。
●その他の良くある誤解
・イテレーションが長すぎる
数ヶ月にわたるイテレーションを定義するのは、たいてい誤解である。UPで推奨されているイテレーションの長さは、数百人の人々と数多くのサブチームから構成されるような非常に規模の大きいプロジェクトの場合を除いて、２週間から６週間である。
・イテレーションでタイムボックスが使われていない
もともと予定した期間内に目標が達成できそうにない場合に、イテレーションの期間を延長するのは考え違いである。熟練した専門家であれば、イテレーションの目標を削るか簡単にする。
・イテレーションの最後に必ず製品リリースが作成される
イテレーションの終わりには必ず製品リリースを作成しなければならないと考えるのは誤解である。それは可能であるが（特に保守段階では）、製品がリリースされるまでに数回のイテレーションが必要になることのほうが普通である。
・推敲フェーズの目標は使い捨てのプロトタイプを作成することである
UPで（通常は方向付けフェーズで）プロトタイプを作成するのはまったく問題ないが、推敲フェーズの目標は使い捨てのプロトタイプではなく、最終的なシステムに含める製品の一部を作成することである。
・開発個別定義書が複雑すぎる、作業成果物が多すぎる
もっと少なくても十分なのに、何十ものUP作業成果物を開発個別定義書に定義するのは考え違いである。「少ないほうがよい」というのが指針である。
・予測型計画
プロジェクトが開始してすぐに、この先の期間の長いプロジェクトでイテレーションを行う回数と、イテレーションの長さ、各イテレーションの長さ、各イテレーションで行う作業について、綿密な計画を立てようとするのは、間違った考え方である。
・チームは大量のモデリングやUMLの図の作成を行い、CASEツールを使わないければならない
UPにはいくつかのオプションのモデルが含まれている。その多くはUMLを適用してプログラミングの前に設計を図示する機会を提供するものである。これらはあくまでオプションであり、事前に設計図を少し作成するだけで（あるいはまったく作成しなくても）ソフトウエアをうまく容易に作成できるのであれば、そうすればよい。UPにおけるモデリングやUMLの図の作成は、複雑さや創造性に対応するための手段であって、それ以上ではない。また、UPプロジェクトでは、モデリングをするときに必ずしもCASEツールやUML描画ツールを使う必要はない。最も簡単なツール（ホワイトボードに図を手書きしてデジタルカメラで写すなど）を推奨するアジャイルモデリングのアプローチを採用しても、まったく問題ない。
・多くのツールが必要である
UPプロジェクトでは、多くのソフトウエアツールを使う必要があると考えるのは誤解である。それどころか、紙のカードや壁に貼ったポスター、ホワイトボードなど「ローテク、ハイタッチ」のツールに、CSVとAnthill（継続した結合のため）、Bugzilla(問題および欠陥追跡のため)を少し使えば行うことが出来る。
・推敲フェーズが終わる前にソフトウエアアーキテクチャ定義書が「完成」する
UPのソフトウエアアーキテクチャ定義書は、理解促進のためにアーキテクチャのおおよその考え方とその理由を要約したものである。最終的なソフトウエアーアーキテクチャ定義書を推敲が終わる前に作成するのは間違いである。UPでは、イテレーションごとに、プログラミングとテストを繰り返して知識に基づいた仮説を検証し、アーキテクチャを発展させる。アーキテクチャは、推敲フェーズの終わり、つまり多くのプログラミングを行って検証した後にならないと安定しない。アーキテクチャを要約したソフトウエアアーキテクチャ定義書は、推敲フェーズが終わるまでは完成しないのである。
・正式なUPの作業成果物やフェーズ名に従っていない
UPの目的の一つは、組織の内外を問わずUPに則っているチームが共通して使えるような、作業成果物や主要なライフサイクルフェーズに関する共通の用語を作り上げることである。
●プロセスの組み合わせ
・UP+Evo
UPは特にソフトウエア開発を対象としており、通常は製品を納品する前に複数回のイテレーションを行うようなプロジェクトに適用する。そのため、UPはEvoのバックルームの開発作業に適用できるかもしれない。しかし、Evoの非常に頻度の高い進化型出荷とプロジェクトマネジメントスタイルは、UPとまったく同じ考え方ではない。ただし、どちらも早い段階でリスクを明らかにし、軽減することを重視している。UPには要求を表すための独自の作業成果物やアプローチが含まれている。Evoが測定を重視していることはUPにうまく適合する、受け入れ可能である。UPのイテレーションの期間は２〜６週間だが、これはEvoに反している。長すぎるからである。
・UP+スクラム
スクラムのプラクティスは、UPのプラクティスと一致する。スクラムのプロダクトバックログはUPのプロジェクト計画書の一部として取り入れることができ、スプリントバックログはUPの反復計画書として使うことが出来る。矛盾が起きるとしたら、UPではオプションではあるものの作業が予め定義されている点である。UPには、これらのオプションの作業の順序が示されている。
・UP+XP
ほとんどのXPのプラクティスはUPのプラクティスと矛盾せず、XPのプラクティスの多くは非常に重要なUPプロジェクトに適用することが出来る。たとえば、テスト駆動開発はUPの「継続的に品質を検証すべし」というベストプラクティスを特化したものである。UPの作業成果物はどれも作成するかどうかが任意なので、XPがモデルとドキュメントを最低限にするよう奨励していることを考えると、この２つの手法が基本的に併用できないと決めてかかるのは間違いである。
しかし、UPプロジェクトにXPのプラクティスを一部取り入れる場合には、概念的に整合する可能性があるが、逆は真ではない。スタイルや重点に違いがあるためである。
たとえば、UPプロジェクトでは、イテレーションの長さが２週間だった場合、イテレーションの初期に半日かけて「ホワイトボードの前で」設計概念について絵を書き、検討して（視覚的なモデリング）、その後プログラミングに取り掛かるのは、許容範囲だと考えられる。XPでは、プログラミング前に費やしてよいと考えられるのはせいぜい１０分から２０分程度である。
もう一つ異なるのは、初期のイテレーションの目標である。UPの目標は、技術的・政治的リスク、顧客満足などといった高いリスクを明らかにし、低減することである。XPでもこれを目標にすることはあるが、主な原則として明示してはいない。
３つ目の違いは、要求しように関することである。UPでは比較的詳細な仕様を（一連のイテレーションを通してインクリメンタルに）作成することを許容し、サポートしている。これはオンサイトの顧客がいないと想定してのことである。UPの仕様は、ユースケースモデルと補足しようの形をとる。
●採用戦略
最初のプロジェクトでは、経験を積んだ手法の専門家に指導してもらうことを勧める。UPを採用とは、反復型、インクリメンタル、適応型で行うことである。
UPを採用する最も良い方法は、古い馬に新しい服を着せるのではなく、新しい考え方や用語を少しずつ取り入れることなのである。
UPにはプラクティスの選択肢が多数含まれている。そのため（ソフトウエア工学があまり成熟していない文化の場合には）初期のイテレーションでは簡単なところからはじめ、後のイテレーションになるにつれてプラクティスを追加するとよい。
●現実と幻想
先に触れたように、最も良く見られるのは、創始者が意図したとおりの反復型・適応型のやり方でUPが広く適用されているという幻想である。現実には、予測的なウォーターフォールの考え方のままUPを間違って適用し、事前に使用や計画を作成している組織やコンサルティング会社が、かなりの割合で存在する。
●長所および「その他」
※長所
・リスクおよび価値に基づいた優先順位に着目する。
・中核アーキテクチャを早期に構築することを重視し、可能なら既存のコンポーネントを利用する。
・インクリメンタルな進化型の要求および開発を行い、適応型の振る舞いをする。
・作業成果物がきちんと定義され、共通の用語が提供されている。
・ガイドラインとベストプラクティスがしっかりした基礎となっている。
・要求から構成管理まで、多くの作業分野について手引きが提供されている。
・他の手法とやり方を組み合わせやすい。
・カスタマイズしやすい。最低限の「軽い」バージョンが推奨されている。
・RUP製品では簡単に利用できる有益な助言や標準のプロジェクトテンプレートが提供されている。
・大規模なプロジェクトにも小規模なプロジェクトにも適用できることが実証されている。
・適切な場合にはユースケースを利用するよう奨励されている。
・広く採用されている。つまり、学習の場やコンサルティングを利用できる。
・多くの顧客と協力して作成され、多くのプロジェクトで改善されている。推測で作られてプロセスではない。
※その他
・詳細を定義している
・UPのフェーズは間違えてウォーターフォール式に適用されえることが多い。
・開発プラクティスを成功させ維持するための会社力学やコミュニケーションの側面にあまり注意が払われていない。この点はスクラムやXPとは異なる。
・RUP製品が原因で、定義された予測可能な開発プロセスを奨励しているような印象を、（意図せず）与えてしまうことがある。ソフトウエアは大量生産ではなく新製品の開発なのだから、これは誤りである。
