コスト負担の問題は、金額の多寡だけではなく、誰がそれを負担するか? という点の考慮も必要です。次の3つのパターンから考えていきましょう。
[1]単一プロジェクトの中で使われている“共有モジュール”を、何らかの理由で変更しなければならない場合
モジュールの開発者も利用者も同じプロジェクトですから、そのプロジェクトのコストの中で対応できるでしょう
[2]ある事業部門が同時期に複数のプロジェクトを進めている場合
どれかのプロジェクトの仕様に合わせて“共有モジュール”の仕様を変える必要がある場合はどうでしょうか。その変更内容が、それを利用している他のプロジェクトの仕様にどう影響を及ぼすか、その変更を受け入れるか否かという判断が必要になります。“共有モジュールを修正する”にとどまらず、“共有モジュールの修正に合わせて、変更要求を出していないプロジェクトでの変更”のコストも考えなければなりません。切った張ったの交渉がプロジェクトマネージャ間で行われるであろうことは想像に難くありません。しかし、それとて同じ事業部門であれば、事業部長の持っているより大枠の予算枠の中で、“大岡裁き”できるかもしれません。
[3]再利用がより広範囲に展開したとき
例えば、SOA化が進展してくると理想的な結果として、関連する他の事業部門や関連会社との間で、サービスを共有することがありえます。その場合、共有サービスの変更に対する妥当性やコスト負担は誰が判断するのでしょうか?
この疑問が意味するのは、再利用が進展した組織では、遅かれ早かれ個々のプロジェクトから離れた第三者的な意思決定機関が必要になるということです。
図2は、アセットベースド開発の想定する組織の概念を図に興したものです。アセットを利用して個々の開発案件を実践していくチーム(図の左側、アプリケーション・プロジェクトチーム)と、そのチームに提供するアセットの作成・維持・管理および再利用戦略を遂行するチーム(図の右側、アセット・マニュファクチャリングチーム)とのコラボレーションを想定して規定されたプロセスです。
Rationalが提供する開発プロセス「IBM Rational Unified Process」(通称RUP=ラップ)でターゲットされているのは、アプリケーション・プロジェクトチームのためのプロセスです。RUPは、オブジェクト指向技術を用い反復型でシステムを段階的に成長させていくプロセスであり、単一のプロジェクト(システム開発)において、取っ掛かりの業務分析から始まって、要求−設計−実装、そしてリリースされるまでの一連の考え方や作業手順をテンプレートとして規定したものです。オブジェクト指向技術自体がそもそも再利用を推奨していますから、アプリケーション・プロジェクトチームにおける設計や実装作業の中に再利用性を意識した記述はあります。
しかし、組織的な再利用のために、“アセット・マニュファクチャリングチームが何をすべきか?”という観点と、“再利用のための専任チームが存在することで、アプリケーション・プロジェクトチームの何が、どう変わるのか?”という観点が必要になってきました。これを規定したプロセスがアセットベースド開発プロセスです。既存のRUPに加えて、“組織的な再利用の仕組みとして考慮すべきこと”加味するものが、アセットベースド開発プロセスである、といい換えることもできるでしょう。
今回はアセットベース開発の前提となる再利用の現実や課題認識を説明しました。もちろん読者の皆さんの立場や作っているモノの種別によって異なる側面も多々あると思います。しかし、設計面での各論とは違い、考え方やアプローチについては、共通することも少なからずあることと思います。部分的にでも参考になるところがあれば、記事を書く甲斐もあろうというものです。
組織がアセットベースド開発に移行するためには、次のような課題に対して、何らかの答えを見出さねばなりません。
――などなど、テーマは多岐にわたりますが、編集部から止めろといわれるまで、アセットベースド開発のエッセンスをご紹介していきたいと思いますので、お付き合いください。
藤井 智弘(ふじい ともひろ)
日本アイ・ビー・エム株式会社 ソフトウェア事業Rationalテクニカルセールス
ソフト開発ってホントはもっとおもしろかったはず! という思いの下で、“管理管理!”でも“開発者の(行き過ぎた)自由!”でもなく、その程よいバランスこそが解と、啓蒙活動にいそしむ日々。もっとチャレンジしましょうよ!
Copyright © ITmedia, Inc. All Rights Reserved.