RUP の拡張: 戦略的再利用作業分野

再利用性とは、情報技術 ( IT ) 業界の「聖杯」の1つであり、めったに手に入れられるものではありません。多くの組織が再利用に失敗していますが、それは対象範囲を理解していないためです。見返りが得られるのはプロジェクト間の再利用であり、1 つのプロジェクト内の再利用ではありません。組織の多くは、最初の 2、3 のプロジェクト、ときには一番最初のプロジェクトで、まだプラスの結果が得られないうちに、早くもあきらめてしまいます。戦略的再利用とは、戦術的な利益ではなく、戦略的な利益を得る長期的な努力です。そのため、1 つのプロジェクトのニーズを超えて、組織全体のニーズに目を向けることが重要になります。そういうわけで、戦略的再利用はEUPの作業分野として含められました。その目的は組織が再利用を成功させるやり方を定義することです。ラショナル統一プロセス ( RUP ) を採用している場合でも、再利用を成功させることは可能です。会社の全体像を見さえすればよいのです。

では最初に、定義をしましょう。資産とは、プロジェクトの終了時点で手に入る、プロジェクト成果物です。確かな資産とは、十分なドキュメントが作成され、1つのプロジェクトの範囲を超えて一般化され、完全なテストが済んだものであり、使い方を示す例がいくつか付いていれば理想的です。このような特徴を持たない資産に比べると、確かな資産は再利用できる可能性がずっと高いものです。再利用可能な資産とは、最低でも 3 つの異なるプロジェクトチームによって、3 つの異なるプロジェクトで使用された、確かな資産のことです。再利用可能であると主張したところで、実際に再利用されるまでは本当に再利用可能であるとはいえません。再利用性は再利用する側が判断するものであって、作成した側が判断するものではないからです。

再利用とは、「車輪の再発明」をしない ( すでにあるものを一から作らない ) ことだとよく言われます。再利用に成功する最初のステップは、自由に選べる選択肢がいくつもあると理解することです。ソースコードや、コンポーネント、開発成果物、パターン、テンプレートのどれもが再利用可能です。

再利用はタダで手に入るものではありません。何かツールを使ったから、何か技術を使ったからというだけではやってきません。それよりも、再利用とは一生懸命行わなければならないものです。その様子が図 1 の戦略的再利用作業分野のワークフローに現れています。再利用で大切なのは、組織内でのオープンなコミュニケーションです。私たちの経験では、再利用計画を実施するうえで、通常はこれが失敗の大きな原因となっています。

2. 再利用計画を立案する

再利用のためには、積極的に計画を立て、予算を計上しなければなりません。再利用を成功させるための時間とリソースを割り当てる必要があります。自分の作業を一般化したり収穫したりする時間をしっかりと取らなければ、プロジェクトが押し寄せてきてその作業を脇に押しやってしまいます。重要なのは、組織内での再利用計画を立案し、実行することです。組織によってはこれが難しいこともよくあります。事前に再利用のためのコストがかさむため、最初のいくつかのプロジェクトに影響を与えるかもしれません。長期的な利益のためには、短期的な苦労を厭ってはなりません。

再利用計画には、組織の目標(エンタープライズアーキテクチャやポートフォリオ仕様に反映されるもの)と、再利用計画に資金をつぎ込んでそれに従おうという積極的な気持ちとが反映されていなければなりません。戦略的再利用を成功させる困難さは、いくら言っても誇張にはなりません。ほとんどの組織が失敗するのは、計画が複雑すぎたり、再利用チームに割り当てるメンバーが適切でなかったり、チームに十分なリソースを与えなかったりするからです。計画に含めなければならない重要な項目には次のものがあります。

3. 既存資産を収穫する

開発チームは毎日新しいものを構築しており、その一部は一般化して他のチームが再利用できる確かな資産にすることができます。これは、新しい技術や手法を取り入れたチームに特にあてはまります。たとえば、C# を最初に使うチームはおそらく有用なユーティリティクラスを開発するでしょうし、最初にユースケースを書くチームはユースケーステンプレートを作成するでしょう。ただし、その場合の欠点は、技術や手法を初めて使う人は「初心者の間違い」を犯すことが多く、作成したものが他の人と共有できるレベルになっていない可能性があることです。つまり、もっと後になるまで待ってからより質の高い資産を収穫するか、積極的に工数をつぎ込んで資産を一般化する必要があるということになります。私たちの経験では、たいていの場合は待つ方がよい選択肢です。その技術の経験を積み、他のチームでその資産が本当に必要かを判断するための時間が得られるからです。資産を一般化して再利用可能なものにするには、単一目的のものを開発するよりずっと工数がかかります。たとえば調査によると、再利用可能なコードを開発するには、単一目的のコードの 111% ～ 480% のコストがかかると言われています。

資産を一般化するにはかなりのスキルも必要です。再利用エンジニアは、その資産で使われている技術や手法だけでなく、実際にどう使われる可能性があるかまで知っておく必要があります。一般化を行うときには、適切な手引きに沿っていることを確認したり(「プロジェクトチームを支援する」を参照)、対象とする利用者に理解しやすくすることが必要です。また、資産を評価する必要もあります。コードがベースとなった資産なら単体テストをする必要がありますし、テンプレートなどコード以外の成果物は対象となる利用者と一緒にレビューする必要があります。簡明な概要ドキュメントも大切ですが、それよりずっと重要なのは、確かな成果物の適切な使い方を示す質のよい少数の例です。コードの場合は、単体テストで十分でしょう。テンプレートの場合は、それをもとに作成した実際のドキュメントの例を挙げるべきです(たとえば、ユースケースのテンプレートであれば、プロジェクトチームが記述した中から優れた 1、2 のユースケースを選び出してください)。図 2 は、既存資産を収穫するワークフローの詳細を示したものです。

資産を収穫する戦略には、大きく分けて次の4つがあります。

4. 外部資産を獲得する

自分の組織外で開発された膨大な数の資産を利用できる可能性があります。何年も前には「構築するより購入しよう」とアドバイスをしていました。しかし、オープンソースソフトウェア (OSS: Open Source Software) やその他の形態のフリーソフトウェアが現れてきたため、今は「構築するより購入しよう、購入するよりダウンロードして評価しよう」とアドバイスしています。外部資産としては、大きく分けて、OSS、その他のフリーウェア、市販パッケージ (COTS) 製品の3種類を検討するべきです。作業のほとんどは既存資産の収穫と同じです。おそらくはニーズを細かく満たすために外部資産をカスタマイズする必要が生じるからです。

要求事項の一覧表を作成し、それに照らして資産の候補を評価する必要があります。たとえば永続化フレームワークを探している場合、選択肢はいくつも見つかり、その中には自分のニーズを満たすものも満たさないものも含まれます。要求がはっきりしていなければ、どの候補が自分のニーズを満たしているか判断できないというリスクを冒すことになります。候補を評価する人たちが、自分たちに必要ですらない「とってもカッコいい」機能に気を取られたばかりに、数時間か数日で済むはずの調査に何ヶ月もかかる、というのを私たちは目にしてきました。

5. 資産を開発する

再利用のためだけに特別に資産を作ろうとするのは、できるだけ (できればまったく) 避けた方が賢明です。というのも、必要でないものを作ってしまうというリスクがあるからです。最初の 6 ヶ月をプロジェクトの残りの期間で「必要な」インフラストラクチャ作りに費やし、結果的には納品する前に中止されてしまったプロジェクトがどれくらいあることでしょう。再利用できそうな資産を作ったけれども、実際には一度も使われなかった例はどれくらいあるでしょう。資産を構築し、再利用したけれども、再利用する側ではその資産のほんの一部しか必要でなかったと言う例はどうでしょうか。要するに、明らかに必要だという証拠もなしに再利用するためのものを作る場合には、作り込みすぎてりソースを無駄にするリスクを負うことになります。ほとんどの場合は、具体的な使い方に合わせて作り、実際に必要になってから再利用できるように一般化するという方法で行った方がよいでしょう。

再利用のために何かを構築する場合には、次の 4 つの選択肢があります。

6. 資産を発展させる

再利用計画において見過ごされがちなのが、確かな資産を時間とともにどう発展させるかという問題です。再利用できる資産があった場合に、新しい要求を満たすためにその資産を発展させなければならなかったり、バグを修正しなければならなかったり、単にプラットフォームの新しいバージョンに移植しなければならなかったりします。これに関しては、次の 3 つの基本的な点を考慮する必要があります。

7. 資産を公表する

確かな資産を手に入れたら、その次には、再利用する側の人たちに使えるようにする必要があります。確かな資産が見つけにくければ、おそらく再利用してもらえません。再利用リポジトリを保守/サポートし、確かな資産をリポジトリに登録するのは、再利用記録係の責任です。再利用記録係の役割を担うのは、一般には再利用マネージャ、再利用エンジニア、エンタープライズ・アーキテクト、プロジェクトアーキテクトなどの上級職員です。再利用リポジトリの形式は、共有ディレクトリ、バージョン管理ツール、十分な機能を持った再利用リポジトリツールなど、いくつかあります。登録のための手順はツールによって様々です。私たちは、できるだけ簡潔にしておくよう勧めています。

確かな資産を登録したら、次は、使えるようになったことを伝える(場合によっては積極的に売り込む)番です。資産を検索できるというだけでは不十分です。メーリングリストや Web ページで告知することもできますが、私たちの経験では、その資産を使って成功したプロジェクトチームからの口コミが、成功のための鍵となることが多いようです。何かを行うのに「公式ルート」を使ったり非公式の人脈を活用したりするのと同じように、再利用可能な資産は、リポジトリを探して見つけることもあれば、友人から教えてもらうこともあります。再利用エンジニアは、皆に信頼される人になるべきです。

8. 資産を引退させる

再利用記録係の作業には、古いバージョンの資産を引退させることが含まれます。資産の新しいバージョンが再利用リポジトリに公開されていくと、古いバージョンを撤収するかどうかを決断しなければなりません。すべてをサポートすることはできないからです。再利用可能な資産の引退は、「終了勧告日」を決めておいて、その後はチームによるサポートをやめる ( つまり再利用チームではこれ以上のことはできないから、古いバージョンを使い続けるなら自分の責任で行わなければならない ) といった簡単な方法で行うこともできます。また、完全なシステムを撤収するときのように非常に複雑な場合もあります。フレームワークや共通アプリケーションアーキテクチャのような大規模な資産の場合には、特に複雑になります。

9. プロジェクトチームを支援する

再利用チームの第 1 の目的は、組織における再利用をサポートし、推進することです。そのためには、再利用リポジトリ内の確かな資産をできるだけ簡単に利用できるようにする必要があります。成功するために欠かせない要因は柔軟さです。忘れないでほしいのですが、再利用する側の人々は、それぞれに異なるニーズを持っています。Java 開発者は Java のコードやフレームワークに興味を持つでしょうし、ビジネス分析担当者はドキュメントテンプレートや既存のドメインモデルに、アーキテクトはアーキテクチャ案に、プロジェクトマネージャはプロジェクト計画テンプレートに興味を持つでしょう。

再利用エンジニアの仕事で重要なのは、プロジェクトチームと協力して、チームが効率的に再利用できるよう資産に手を加えることです。理想を言えば、この変更は、資産を適切に設定する程度のものであるべきです。しかし、場合によっては、資産をチームのニーズに合うように発展させる必要があります。それが資産を発展させる作業の目的です。

組織内の再利用を効果的にサポートする戦略には次のようなものがあります。

10. 再利用計画を測定する

再利用計画を立てたら、その目標を定義します。たとえば、品質を向上する、コストを削減する、製品化に要する時間を短縮する、などです。このような壮大な目標を立てるのは非常に簡単ですが、実際にそれを達成したと証明するのはそう簡単ではありません。ちゃんとした上級管理職チームなら、再利用計画への投資が効を奏したという証拠をほしがるはずです。またチーム自体も、作業がどれだけ効果的だったかを知るためのメトリクスを収集し、それをもとに自分たちの工数をかける部分を見直したいでしょう。そのためには、以下のようなメトリクスの収集を検討してください。

11. まとめ

ソースコードから、テンプレート、フレームワーク、アーキテクチャ全体まで、幅広い資産を再利用することが可能ですが、それを成功させるには、1つのプロジェクトの範囲を超えた見方をする必要があります。戦略的再利用作業分野では、システムをまたがった方法を取ることで、EUP プロジェクトの再利用水準を上げる方法を述べています。成功のためには、組織における再利用計画を立て、実施し、監視する必要があります。再利用できそうな確かな資産を獲得するには、内部資産を収穫する、外部資産をダウンロード/購入する、一から資産を開発するなど、いくつかの方法があります。再利用の作業はサポートしなければなりません。簡単に再利用できるようにするほど、再利用してもらえる可能性は高くなります。また、自分の作業が成功したかを測定して、再利用プロジェクトへの継続的な資金と経営陣のサポートを確保する必要もあります。