戻る

既存資産の再利用

Revised: 2004-12-12

人が携わる活動において、技術や業務や経験などの個人が持つ知識にはばらつきがあります。例えば、人が交代するとき、前任者は後任への引継ぎ資料を作るでしょうが、技術的な引継ぎ資料が、後任者が過去に経験したパターンを含むのであれば、引継ぎはスムースに進むでしょう。また、キーパーソンに関する個人的な印象、企業風土、業務、トラブル事例、想定問答などの暗黙知を共有しやすくするためにも、再利用可能な資産（アセット）の再利用は重要です。

再利用のメリット

再利用しないことで、納期が遅れ、コストが超過し、品質は低下します。直接的なデメリットは、次のようなものが挙げられます。

アセットの再利用は、コスト削減だけではなく、品質向上の面でも、非常に重要です。資産が正しく管理されていれば、次のようなメリットが見込めます。

例えば、インシデントが正しくログされ管理されていれば、インシデント発生時に、過去のレコードを照会することで、実績のある正しい手順で回復可能かもしれません。問題管理でも同様で、修正コードと根本原因が正しく管理されていないと、同じ根本原因の様々な事象に対して、同じように解析を繰り返さなければならないかもしれません。

H/W, S/W 製品は再利用可能な資産の典型的なものです。例えば、HTTP や FTP のようなプロトコルの実装は、決まりごとに従うので、一度開発してして保守することで、車輪を発明する愚を避けることができます。再利用可能資産は、究極的には製品であり、製品とアプリケーションの違いを考えることは、アセットの再利用のメリットを考える際の、モデルケースとなります。

再利用の罠

既存資産の再利用は、甘美な響きです。アセットは再利用すべきですが、その一方で、バッド・ケースもあります。代表的なものが、同じものに固執して、いつでも、いつまでも愚直に使い続けるというものです。

いつまでも同じものを使い続けていると、流行の恩恵を逃して辺鄙な技術領域に閉じこもりかねず、技術的に枯れてダメになってしまうかもしれません。いつでも同じものを採用していると、要件とのギャップが大きく、そのギャップを埋めるために多大な負荷を強いられるかもしれません。

大事なことは、技術的発展と流行に対する見識と、採用時のフィット＆ギャップの見極めです。

アセットは、使い続けることで古びて、正常なサービス提供の阻害要因となりかねません。例えば次のようなデメリットがあります。

また、適材適所を逸することで、プロジェクト進捗の阻害要因となりかねません。システムレベルの非機能要件であれ、業務に基づく機能要件であれ、アセットと要求仕様のフィット＆ギャップを実施して、フィットする部分が大きく、少ない労力でギャップを埋められるものを採用することが大事です。

代表的なアセット

横展開を勘案すべきアセットの特徴は、大学のレポートや試験の過去情報と同様です。先達のレポートに基づくことで、実績に基づき、検討が徐々に深まり、作り込まれていきます。アセットの再利用は、進化、発展のモデルに一致します。システム開発で勘案すべきアセットには、次のようなものがあります。

運用手順とインフラ設計
システム開発後の本番稼動段階では、運用手順とインフラ設計の一般化が有効です。例えば、複数のプロジェクト、複数のシステムが稼動しているとき、各々のシステムで、コードや修正パッチのレベル管理手順、ネットワークトポロジとマシンの配備、開発機から本番機へのライブラリ配布、バックアップ採取などの手順と環境などが挙げられます。これらは業務要件に依存しない、システムレベル、メンテナンスレベルの部分であり、差分や要件を前回の検討資料に基づいて毎回検討することで、検討は深まり、実運用段階での実績と練度が高まります。
プロセス
ソフトウェア開発の手法やプロセスは、再利用可能な資産です。既存の実績のある手法やプロセスを採用し、規範を定めて遵守することで、スキルや経験の横展開が計られ、品質、価格、納期を見通しやすくなり、進捗やコストを管理しやすくなります。代表的なプロセスは、ウォーターフォール型や反復型があります。代表的な手法は、IBM ADSG, Rational UP, XP などが挙げられます。インフラの運用／保守では、ITIL が注目されています。現場では、これらの細部や行間を個別に補って実施しているので、その部分を共通化することで、再利用可能な資産となります。
業務設計
理想的な状況では、同様の業務開発が続き、前回の設計資料や資産との差分に注目して、次回の設計を始められることです。例えば、ライブラリ配布手順やシェルなどのユーティリティや、フレームワークのカスタマイズ、サーバの初期設定パラメタなどが挙げられます。
デザインパターン（アンチパターン）
GoFによる23個のデザインパターンはあまりにも有名ですが、他にも、J2EEのデザインパターン、EA (Enterprise Architecture)のデザインパターンなどが提唱されています。これらの既存のデザインは、スキルのある人が十分な経験に基づいて開発したものであり、豊富な適用実績を持つ、信頼できる共有資産です。デザインパターンやフレームワークは、フィット＆ギャップを実施して、そのままでは使えないと評価しても、フィットした部分を真似られるというメリットもあります。
データ構造とアルゴリズム
デザインパターンに比べてより具体的で計算機科学的な古色蒼然とした観がありますが、それだけに実績豊富な成功事例の集積です。例えば、リンクリストに対する探索や整列のような汎用的なアルゴリズムであれば、知っていた方が行き詰ったときの抽斗が広がりますし、複数の解決策を比較検討するときの判断材料にもなります。
コーディング標準
多くの人が携わるアプリケーション開発で、コードの品質を高めるためには、コーディング規約を定めておくことがとても重要です。コードの読みやすさ、ドキュメント方法をはじめとして、成功事例をコード単位で共有化するためにも役に立ちます。社内／プロジェクト内で、規約を作ってそれに準拠することは、開発中も、その後のメンテナンスのためにも、効率と品質の観点で重要なことです。
フレームワーク
フレームワークには色々な意味が込められますが、ここでは、再利用可能コードの集積としてのJUnit、Apache Jakarta Struts, Cactus, Apache Commons Validator、Apache Logging Services Log4jなどのことです。ベンダー各社からも色々なフレームワーク製品がリリースされています。堅牢性という観点では、実戦配備されて再利用されることでさまざまな本番環境でテストされることの安定性と、フレームワークにのっとることで設計が標準化してバグを作りこみにくい／問題があれば発見しやすいというメリットが挙げられます。一方、初期／バージョンアップ時にはフレームワーク自身を習得する必要がある、サポートにばらつきがあるなどの問題もあります。特定のフレームワークを採用するのではなく、フィット＆ギャップを実施して要件にマッチしたフレームワークを選択する必要があります。
ライブラリ
JavaやC/C++などはライブラリ指向の言語です。言語仕様に、膨大な標準パッケージによるAPIを含めて、開発／実行環境だといえます。ベンダー各社からも多くの製品／サービスとしてリリースされています。
処理系
JAR単位でリリースされる処理系も再利用可能な資産の一つです。XML処理系のXerces, Xalanなどをはじめとして、暗号関連の処理系や文字コード変換の処理系など、これも多くの種類がベンダー各社からリリースされています。アプリケーション寄りになるほど、オープンソース製品の信頼性は向上するようです。例えば、フレームワークやライブラリは、一つのプロジェクト内で自力で実装するのに比べて、オープンソース製品の方が、テスト／品質の点で圧倒的に凌駕します。ミドルウェアになると、Apacheという偉大な例外がありますが、一般には高級なプロプライエタリ製品の方が高機能で安定しているようです。処理系はそれらの中間だといえます。実プロジェクトでの利用はためらわれることもあるかもしれませんが、要件とのフィット＆ギャップを実施するときには、オープンソース製品を検討対象に含める価値は十分にあります。

大事なことは、一人で悩まないということです。行き詰ったら、周りの人に相談すべきであり、実績を軽んじてはいけません。一人で解決しようとしてトリッキーな解決策に飛びつくと、特殊な運用を強いられたり、経験事例がなかったりと、あとで痛い目を見る可能性が大です。既存資産で利用可能なものを探して比較検討する必要があります。

戻る

Copyright 2004 SUGAI, Manabu. All rights reserved.
SEO [PR] !uO z[y[WJ Cu