EUP のベストプラクティス

By Scott W. Ambler

このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。

RUP の基礎には 6 つのベストプラクティスがあります。反復的に開発すべし、要求を管理すべし、コンポーネントアーキテクチャを使用すべし、ビジュアルにモデリングすべし (UML)、継続的に品質を検証すべし、変更を管理すべし、という 6 つで、これらは長年にわたる数多くのプロジェクトの経験から見つけ出されたものです。私たちは、核心部分の本質を捉えられるようにこのベストプラクティスの 2 つを書き直し、さらに 2、3 の プラクティスを追加して仕上げました。私たちが奨励するベストプラクティスは以下の通りです。

1. 反復的に開発すべし: 反復による開発を行うことで、プロジェクトは優先順位をもとにリスクに対処することができます。また、反復は期間が固定され、具体的な目標が決められているため、進捗を絶えず測定することができます。反復それぞれの最後にはプロジェクトの進み具合が知らされるため、利害関係者は、動くコードの実際の進捗をもとに、プロジェクトの残りの部分に対する現実的な予想を立てることができます。
2. 要求を管理すべし: 利害関係者のニーズを満たすシステムを納品するための鍵となるのは、システムに対する要求を明らかにし、管理することです。そのためには、要求を収集・文書化・保守し、変更を系統的に組み込み、場合によっては要求から設計へと追跡する必要があります。要求管理のプロセスの中には、非常にきっちりと定義されていて、たいていはかなりの工数や費用がかかるけれども、決定事項について正確かつ詳細な文書を作成できる、といったものもあれば、インデックスカードを使ったエクストリーム・プログラミング (XP) (Beck 2005)の計画ゲームのようにシンプルなものもあります。この 2 つは両極端ですが、その間に位置するものもあります。RUP はプロジェクトの厳密なニーズに合わせて仕立てることが可能ですし、そうするべきです。
3. 実証されたアーキテクチャ: RUP では「コンポーネントアーキテクチャを用いるべし」ということばを使っていますが、現実のところ、多くのアーキテクチャはコンポーネントベースではありません。たとえば、Web サービスもアーキテクチャの選択肢の1つですし、COBOL などの手続き型の言語もそうです。そして、これらの技術を扱えるように RUP を拡張するのは簡単です。本当のベストプラクティスは、構築対象のシステムに適したアーキテクチャを洗い出し、それからプロトタイプを作って実証することです。
4. モデリング: RUP では「ソフトウェアをビジュアルにモデリングすべし」ということばを使っていますが、現実には、ユースケースや、ビジネスルール仕様、 CRC (Class Responsibility Collaborator) カードといったモデルは本質的にビジュアルでありません。ユースケースを書くとはドキュメントを書くだけのことだと考えたくなるかもしれませんが、実際には人がシステムとどうやり取りするかをモデリングしているのです。モデリングをすることで、概念を描いてじっくり考えることができ、それを他の人と共有することができます。モデリングは、高性能な GUI ベースのソフトウェアアプリケーションを使って行うこともできれば、単にホワイトボードに絵を描いて行うこともできます。「アジャイルモデルのエッセンス」のホームページを覗いてみると、利用可能なモデルにはさまざまなものがあることがすぐに分かるでしょう。
5. 継続的に品質を検証すべし: テストは、最後にまとめて大きな工数をかけて行うのではなく、RUPプロジェクトの反復ごとに実施されます。品質を保証するとは、ソフトウェアが要求を満たしていると確認するためにテストすることだけではありません。利害関係者と一緒に、要求や設計やモックアップ (mockup) をレビューすることも、継続的な品質の検証に含まれます。早い段階でテストをして不具合を見つける方が、最後の段階で広範囲のテストをするより、ずっと効率的です。品質を確実にする効果的な方法としてテスト駆動開発 (test-driven development: TDD) という実装手法がありますが、これは、新しいビジネスコードを書く前に必ずテストを書いて、システムの回帰単体テストスイートが常に 100% できあがっているようにするという考え方によるものです。
6. 変更を管理すべし: ソフトウェア開発において変更は当然起きることです。プロジェクトを円滑に進め、競合に対して優位に立てる可能性のある変更を利用するには、変更を予期し、適切に対処しなければなりません。変更が起きると、文書、モデル、計画、テスト、コードなど、さまざまな成果物に影響が及びかねません。アジャイル主義者が言うように、影響を最低限に抑えるには、できるだけ身軽な旅をするとよいでしょう。
7. 協調的な開発: システムは人がチームとして開発するものであり、参加する人が効率的に協力しなければプロジェクト全体が失敗する危険があります。アジャイルソフトウェア開発コミュニティでは、協調的な開発をするための手法を明らかにし、促進するために、大きな努力をしてきています。主な手法には、ペアプログラミング ( 2人のメンバーが一緒にコードを作成する ) 、他の人と一緒にモデリングしよう ( 複数の人が別々に作業をするより、一緒にモデリングをした方が効果的だという考え方を促進する )、利害関係者の積極的な参加 ( プロジェクトの利害関係者は、タイミングよく情報の提供や決断を行ったり、開発作業自体に参加するべきだという考え方を促進する ) などがあります。
8. 開発後のことを考慮すべし: システムは、構築して稼動状態に導入するだけでなく、導入した後で運用やサポートをする必要があります。優れた開発者はこれを分かっていて、運用やサポートの専門家のニーズが満たされるよう、協調して仕事を進める必要があることを理解しています。さらに、システムが組織全体の中にうまく納まること、つまり、システムが全社共通の標準を反映していることを確認する必要があることを十分に理解しています。そのため、彼らの作るシステムは、既存のアーキテクチャやインフラストラクチャを利用し、決められた全社的なガイダンス ( 標準や指針 ) に沿ったものになります。
9. 動くソフトウェアを定期的に納品すべし: ソフトウェア開発プロジェクトが成功したかどうかを判断する第 1 の基準は、ユーザのニーズを満たす動くソフトウェアの納品であるべきです。効果的に開発を行うには、動くソフトウェアを少しずつ納品すること、残っている機能の中でもっとも優先順位の高いものを反復ごとに納品することです。
10. リスクを管理すべし: 効果的なプロジェクトチームは、リスクを明らかにし、発生したものを管理しようと努力します。必要に応じて、リスクを完全に軽減する場合もあれば、考え得る影響を少なくする場合もあります。