再利用の罠

再利用再利用と声高に叫んだプロジェクトほど失敗します。再利用しようとしてはいけません。手段が目的になってしまわないようにしましょう。

再利用しようとしてはいけない

再利用するのはいいことですが、再利用しようとしてはいけません。一見矛盾 しているようですが間違いではありません。再利用はしようとするものではな く、正しい分析や設計をすれば自動的にできてしまうものなのです。目的では なく結果なのです。

「再利用をしよう」とスローガンを掲げる人には「なぜそんなに再利用をした いのですか?」と聞いてみましょう。きっとなぜそんな当たり前の事を聞くん だとでも言うような顔をして少し返答に困り、こう言うでしょう。「だってプ ログラムコードを再利用できれば書く量が減るだろ?」と。

これこそプログラムコード至上主義です。今までに何度も言っているように、 コードなんてすぐ書けるのです。大変なのは設計であってプログラムコード書 きではありません。「今まで書いたプログラムコードを使い回そう」と思って いる人はきっと落し穴にはまります。

再利用する機会は多くない

オブジェクト指向を勉強したての人には、「これからは再利用の事も十分考え て設計しなくてはならない!」などと意気込む人が多くいます。こういう人は 自分のプロジェクトではできるだけ後の事を考えてあちこちを汎用に、再利用 できるように設計しようとします。

しかし、ちょっと待って下さい。それは本当に再利用されるでしょうか?プロ グラムコードの寿命はそんなに長いものではありません。FORTRANやCOBOLのコー ドが今では単なるお荷物扱いになっているように、再利用を考えて大事に設計 してもきっと再利用なんてしないでハードディスクの片隅に眠るだけになるで しょう。

再利用可能な設計にするには手間がかかります。そしてその手間は再利用しな いと報われません。そしてそんな機会は実は多くないのです。だから再利用再 利用とありもしない未来の事を考えるのはやめましょう。今このソフトをどう 設計すればいいかだけを考えるのです。そして後になって再利用したくなった ら必要な部分だけコピーして改造すればいいのです。その方が簡単でしょう?

ホワイトボックス化

再利用に関する問題は、「実は再利用されなくて無駄になるかもしれない」と いう心配だけではありません。「再利用可能な設計を!」と言っている段階で はどこに再利用するという具体的なターゲットが決まっていない事がほとん どあり、これが問題なのです。つまりどこに使われるかもわからないまま「ど こか別の場所に使うことを考えてソフトを作れ」というのです。そんな事でき るわけがないでしょう。

「再利用可能な設計をしよう」と言われたら、「どこに再利用できるように設 計するのですか?」と聞いてみましょう。もし具体的な場所が答えられるので あれば再利用の努力は少しは報われるでしょう。しかし特にどことは決まって いない事がほとんどです。「今具体的にどことは言えないけど、将来同じよう なソフトを作った時にできるだけ前のを再利用してラクできるように……」 という答えが返ってくるでしょう。

目標がないまま再利用性と汎用性だけを追求していくと、どんどん中身が薄く なっていってしまいます。どこでも通用するような当たり障りのない玉虫色の 発言からは内容や意味や主張がどんどん抜けていってしまうのと同じことです。 どこにでも再利用できる究極的に汎用なプログラムコードは何であるか知って いますか?答えは空のコードです。

具体例を挙げましょう。誰かがA市図書館の休館日をリストアップするモ ジュールを作ったとしましょう。こんなモジュールです。

指定された2つの日付の間にある休館日のリストを返します。

休館日は毎週月曜日ですが、月曜が祝日あるいは振替休日の場合は次の日にな ります。そして3/25〜3/31は年度末の整理日です。

このモジュールはA市図書館でしか通用しない汎用性のないモジュールです。 だからもっと汎用性のある再利用可能なモジュールにすることを考えましょう。 例えば次のようにです。

  • 休館日は月曜日だけではなく任意の曜日にできるようにしよう

  • そもそも、休館日を「毎週」ではなく「隔週」とか「毎月1 回」といった他の方法でも設定できるようにしよう。

  • 週とか月といった単位ではなく、外部の関数でアルゴリズム を自由に与えられるといいね

  • 休館日が祝日の場合に次の日にするかどうかも設定できるよ うにしよう

  • いや、「次の日にする」というだけではなく、代わりの日を 決める関数を外から与えられるようにしよう。

  • いや「休館日が祝日かどうか」だけでなく、どんな条件下で も自由に振り替えができるようにしよう。

  • 年度末の整理日も好きな期間に変えられるようにしよう。

  • いや、期間だけでなく、どんなパターンの整理日にもできる ようにしよう。

様々な意見を集約して、どんな図書館の休館日でも、いやどんな所の休館日に も対応できるとても汎用的なモジュールができました。このモジュールの動作 はこうです。

指定された2つの日付の間にある休館日のリストを返します。

休館日は「毎週」でも「毎月」でもあるいは不規則でも、どんなパターンであっ てもかまいません。そしてその休館日は別の日に振り替えられることもありま す。そしてその他にも任意の日が休みになります。

さあどうでしょう?非常に汎用性の高いモジュールができたのは確かです。し かしこんなものが役に立つでしょうか?こんな「汎用」モジュールをA市図書 館の休館日に合わせようとすると、結局一から作った方が早いという結果になっ てしまいます。

「この例は極端だ。汎用性/再利用性を追求しすぎただけだ。」という意見は もっともです。その通りです。しかし、どこで止めておくべきだったのでしょ う?他にどこで使うかもわからないのにその基準を決めることができるでしょ うか?どこかで止めようにも止める基準がないのです。

ブラックボックス化

上の例では根本の発想が間違っています。既にあるモジュールを持ってきて汎 用に/再利用可能にしようと考えたから起きたのです。これが冒頭で言った 「再利用しようとする」事の弊害です。

再利用しようとしてはいけません。正しい分析をしましょう。例えばこの場合 では、「A市の「図書館「休館日」」」を返すモジュールを作ればいいのです。 つまり、「休館日」モジュールを作って、それをもとに「図書館休館日」モジュー ルを作り、そこから「A市の図書館休館日」モジュールを作ればいいのです。

まず休館日を考えましょう。毎週○曜日と決まっていてそれが祝日だったら次 の日に振り替えられる、というのがごく普通の「休館日」でしょう。もちろん そうでない特殊な休館日もあるかもしれません。しかしそんな特殊なケースは はなから考えに入れなければいいのです。汎用性も再利用性も考える必要はあ りません。次のように定義してしまえばいいのです。

ここで言う『休館日』とは、毎週決まった曜日に休館し、もしそれが祝日だっ たら次の日に振り替えられるような日のことである。

こう宣言すると、もしかしたら「言葉の使い方がおかしい。それは休館日の正 しい定義じゃない。」とか「それにあてはまらない休館日もあるだろう」と言 う人がいるかもしれません。確かにその通りです。しかしここで折れて「『休 館日』とは、館が休みの日のことである。」と定義し直してしまって はいけません。これだと結局何も言っていないことになります。汎用性を追求 した結果意味のない定義になってしまうのです。

代わりにこう定義しましょう。

『iwatam式休館日』とは、毎週決まった曜日に休館し、もしそれが祝日だっ たら次の日に振り替えられるような日のことである。

「iwatam」のところには自分の名前を勝手に入れればいいのです。これで誰も 文句を言えなくなります。この定義ができれば、後は同じようにやっていけば いいのです。整理日を入れた「図書館休館日」を定義し、そしてさらに整理日 や曜日の具体的な日付を入れた「A市図書館休館日」を定義すればいいのです。

この言葉の定義こそが「ブラックボックス化」です。長い文章や概念や関数や プログラムコードを一つの箱に収めて封をしてしまい、その箱に勝手に名前を つけてしまうのが「ブラックボックス化」の意味するところなのです。箱の名 前というのは「識別子」です。箱が区別できれば別に名前でなくても番号でも 何でもいいのです [1]

いったんブラックボックス化してしまったら、その中身についてとやかく言っ てはいけません。もう蓋を閉じてしまったのですから。箱を開けてもいけませ んし箱の中身をいじることもできません。もし「ああ、この定義が『毎週』 ではなく『隔週』だったら今回のプロジェクトに使うことができたのに」と思っ ても、既に決めてしまった「iwatam式休館日」の定義を変えてはいけないので す。その場合は「iwatam式休館日2」 [2] という新しい言葉を作って、そこに隔週休館日の定義を放り込めばいいのです。

この意味では「iwatam式休館日」という定義には「休館日とは館が休みの日で ある」という一般的な休館日の定義ほど自由度がありませんし再利用性も 低くなります。しかしより意味のある事を言っているのはどちらでしょうか?

再利用より正しい設計

ホワイトボックスとブラックボックスの違いを文字通り箱に例えてみましょう。 ホワイトボックスは何でも入る大きな段ボール箱で、ブラックボックスはCDを 入れるCDラックに例えることができるでしょう。

大きな段ボール箱にはCDもビデオテープもおもちゃも衣類も何でも入ります。 それに比べてCDラックにはCDしか入りません。より再利用性が高いのは段ボー ル箱の方ですが、実際にはCDラックの方が高い価格で売られています。なぜ人 は何でも入る段ボールよりCDしか入らないCDラックの方に高いお金を出すので しょう?それは、CDしか入れられない代わりにCDを入れるのが非常にやりやす いからです。人はCDラックにビデオテープやおもちゃを入れる機能なんて要求 していないのです。単にCDが入れば用は足りるのです。

使う側の事を考えないで単に再利用性だけを考えると、段ボールの方が便利で いいということになってしまいます。「CDを入れる必要がなくなったら今 度は衣服も入れられる。なんて素晴らしいアイディアなんだ」と自画自賛しま す。そしてCDを入れるケースが欲しくなると、CDラックの仕切りをわざわざ切 り取って単なる箱にしてしまいます。単なる箱の方が何でも入れられて良いわ けですから。

そういう人に限って、部屋の片隅に箱の山が使いもしないまま積み上げ られているなのです。そして箱の山をひっかき回して「うーん、ビデオテー プを入れるにはぴったりの大きさの箱がないなぁ」と言ってはまた別の箱を買っ てくるのです。部屋の片隅に積んである箱の山を見て「俺は箱の資産をたくさ ん持っている」とご満悦ですが、実際それを使ったためしはないのです。

本当はそうではありません。CDを入れるケースが欲しいけどCDラックがない。 こんな時に適当な大きさの箱を買ってきて自分で間仕切りを入れてCDラックに するのです。こちらが正しい手順です。


  1. ここでふとオブジェクト指向が出てきました。ブラックボックスというのはすなわちオブジェクトです。 ↩︎

  2. 意味不明のどうしようもない名前ですが、名前というのは単なる識別子だからこだわる必要はないのです。 ↩︎