以前に開発した成果を利用することにより、ソフトウェアを開発する手法のことです。
ソフトウェア開発に必要とされる知識、プログラムやデータを、 何らかの形でパターン化・標準化・部品化することにより、 繰り返し利用できるようにします。
いちばん確実に開発を早くする方法は、書かないことです。 既にあるものを使えば、作る時間も、テストする時間も、直す時間も要りません。
| 対象 | 例 |
|---|---|
| 開発プロセス | 標準的な進め方、成果物の様式、チェックリスト |
| 開発環境 | ビルドの仕組み、テスト環境、開発ツールの構成 |
| 設計仕様 | 設計パターン、アーキテクチャ、過去の設計書 |
| パッケージプログラム | 市販の業務パッケージ |
| プログラム部品 | ライブラリ、モジュール、クラス |
| 個別応用プログラム | 他システム向けに作ったものを流用 |
| テストデータ | 試験用のデータ一式、テストケース |
再利用はコードだけの話ではありません。 むしろ効果が大きいのは設計仕様や開発プロセスの再利用です。 「この種の問題は、こう設計するとうまくいく」という知識が組織に蓄積されると、 毎回ゼロから考えなくて済みます。
| 効果 | なぜそうなるか |
|---|---|
| 生産性の向上 | 作る量そのものが減る |
| 品質の向上 | 既に使われ、誤りが取り除かれた部品を使うため |
| 期間の短縮 | 設計・実装・テストが省ける |
| 保守性の向上 | 共通部分が 1 か所にまとまる。直す場所が減る |
| 技術の伝承 | 熟練者の設計が部品という形で残る |
品質の向上は見落とされがちですが重要です。 新しく書いたコードには必ず誤りが混じります。 何度も使われた部品は、そのぶん誤りが洗い出されています。
手順 2 が要です。 「全社で共通」にすると、どの部署にも合わない中途半端な部品になりがちです。 逆に「チーム内だけ」にすると、同じものが社内のあちこちで作られます。 どの範囲で共有するかは、技術ではなく組織の判断です。
効果がこれだけ明らかなのに、再利用は思ったほど進みません。理由があります。
| 課題 | 中身 |
|---|---|
| 見つからない | 部品があっても検索できない。分類・命名・説明が整っていないと、 探すより作るほうが早くなる |
| 信用できない | 中身が分からない部品は怖くて使えない。 仕様書・テスト結果・実績がないと採用されない |
| ぴったり合わない | 少し違うので改造する。改造すると、もとの部品と枝分かれして 保守の手間が倍になる |
| 作る側に得がない | 再利用できる部品を作るには、目先の仕事より手間がかかる。 その手間を評価する仕組みがないと、誰も作らない |
| 維持されない | 部品も直し続けなければ古くなる。誰が面倒を見るのかが決まっていない |
再利用は、技術の問題であると同時に組織の問題です。
これらが無いまま「再利用しよう」と号令をかけても、まず定着しません。 再利用を支える体制そのものを設計することが要ります。
近年は、社内の部品ライブラリよりも、 公開されたライブラリやサービスを使う形が主流になりました。 仕組みは変わりましたが、課題は同じです。 「見つかるか」「信用できるか」「維持されるか」── 外部の部品を使うときも、この 3 つを確かめる必要があります。