利害関係者の優先度のバランス（Balance stakeholder priorities）

利害関係者の優先度のバランス（Balance stakeholder priorities）

ビジネスへの貢献が重視されることにより、開発者といえども「システムがビジネスの何を助けるのか？」ということに無頓着ではいられません。そこで重要になるのは、単に話を聞くのではなく、対立する利害をある仕様に落とし込むための手段をもち、評価の尺度を持つことです。

チーム横断のコラボレーション（Collaborate across teams）

各種の開発手法、オープンソースのフレームワーク、そして相互に関連する開発プロジェクトなどと、開発現場は気を抜くと混乱の極みとなります。環境の維持や開発成果物の再利用化、プロジェクトの側面支援（最近ではPMOとも呼ばれる）など、役割の異なる部隊の組織的な取り組みがなければ、規模の大きな案件が取り回せなくなりつつあります。この組織間のコラボレーションモデルが重要です。

 

反復的に価値を立証（Demonstrate value iteratively）

Rational Unified Processに限らず、反復開発の効能が認知されてきています（実践が今ひとつ少ないというのも事実ですが）。SOA環境で他システムとの連携が前提になると、データの意味論の違い、疎結合によるパフォーマンスなどの問題、運用形態にもとづくシステムデザインの差異の問題などと様々な技術的リスクが存在します。これまで以上に「早期のアーキテクチャ・リスクの解決」が求められるのです。

 

抽象度を高める（Elevate the level for abstraction）

コード開発を優先する開発スタイルは「動くモノが早く目に見える」ということで、開発者の安心感を醸成するという効果があります。

しかし、SOAの世界ではよりデザイン（全体アーキテクチャとの整合性やビジネスプロセスにおける個別システムの位置づけなど）が重要になります。ビジネスプロセスのシステム化によって、提供されるサービス実現手段としてのITシステムを異なる抽象度でモデル化し、それを共有することが重要です。
 

図3：抽象度で階層化されたモデル
（画像をクリックすると別ウィンドウに拡大図を表示します）

品質への継続的集中（Focus continuously on quality）

反復型開発では、短期間のウォーターフォール開発を反復することで、リスクを段階的に排除することを目的とします。言葉を換えれば、機能が限定されたシステムが「動くことを確認」することで、リスクが解決されたと確認します（これをデモンストレーションベースとも呼びます）。機能・非機能のテストを反復することで、デグレードなどが発生しないことをテスト結果という事実で繰り返し確認しつつ、新機能のテストを行う必要があります。

 

次回予告

Rational Unified Processにおける原則は、まさに原則であり、その具体的実践には、より詳細に規定されたプロセスとそれを支援するツールが必要です。全4回の予定でこの連載は進みます。全体像を詳細に語るのは不可能なので、あくまでも「テスト」を主軸に話を絞ります。