ドイツの宰相ビスマルクの有名な台詞に曰く:

しかし，失敗学的な見地で言うなら，経験＝失敗から学ぶことができるなら，賢者とは言わないまでも，愚者という程でもありませんので:

といったあたりが妥当ではないでしょうか。

前回までの解説は，自身の失敗経験を如何にして活用するか，という点に着目したものでしたが，今回は歴史＝他者の失敗経験から学ぶ方法について，ソフトウェアパターン（software pattern）を題材に説明します。

ソフトウェアパターンにおける失敗「考古」学

よくあるつまずき

デザインパターン（design pattern）に代表されるソフトウェアパターンは，「⁠ベストプラクティス」（⁠best practice）という言い方に象徴されるように，一般には「成功事例」として捉えられる状況が多いように思われます。

その一方で，第1回で述べたような成功体験の限界故なのか，ソフトウェアパターンを「難しい」とか「役に立たない」と評する人が少なくありません。

特に，まだそれほど開発経験を積んでいない人が，ソフトウェアパターンを学習した際に漏らす感想の多くは:

というものが多いように思われます。

彼らの話を聞いてみると，どうやらソフトウェアパターンを，「⁠この場合は，こうしなさい」というような，ルール集やガイドラインのように捉えているようなのです。

パターン定義において，目に付き易く，いかにも「ベストプラクティス」っぽい部分だけを捉えれば，ルール集やガイドラインに見えてしまうのは，確かに止むを得ないかもしれません。

しかしそれでは，非常に浅い理解しかできません。

「パターンを適用しない」状況を考えてみる

ソフトウェアパターンの定義には，そのパターンによって解決される問題の記述が必ずあります。

言い換えるなら，そのパターンを適用しない場合の失敗例が必ず記述されている，ということです。

たとえば，デザインパターンの1つ，Observerパターンと呼ばれるパターンの場合，パターンを適用しない場合には以下の様な問題が発生することが，「⁠動機」において記述されています。

再利用性の低下

GUI 部品のような，本来汎用性を求められる要素は，表示対象となるデータオブジェクトを固定した場合，他の表示対象への適用が難しくなるため，再利用性が著しく低下してしまいます。

表現形式選択の制限

表示を行うGUI部品と，表示対象となるデータモデルの関係が固定的になっている場合，任意の表現形式（例：棒グラフ・円グラフ・折れ線グラフ）を選択したり，単一の表示対象データモデルに対して複数の表現形式を関連付けたりといった，表現形式選択の自由度を制限してしまいます。

このような失敗事例は，まさに「パターンを適用する理由」を端的に表していますので，パターンを理解する上で非常に有効な示唆を与えてくれることでしょう。