ドイツの宰相ビスマルクの有名な台詞に曰く:
愚者は経験に学び，賢者は歴史に学ぶ
しかし，失敗学的な見地で言うなら，経験＝失敗から学ぶことができるなら，賢者とは言わないまでも，愚者という程でもありませんので:
愚者は経験を活かさず，凡夫は経験に学び，賢者は歴史に学ぶ
といったあたりが妥当ではないでしょうか。
前回までの解説は，自身の失敗経験を如何にして活用するか，という点に着目したものでしたが，今回は歴史＝他者の失敗経験から学ぶ方法について，ソフトウェアパターン（software pattern）を題材に説明します。
ソフトウェアパターンにおける失敗「考古」学
よくあるつまずき
デザインパターン（design pattern）に代表されるソフトウェアパターンは，「ベストプラクティス」（best practice）という言い方に象徴されるように，一般には「成功事例」として捉えられる状況が多いように思われます。
その一方で，第1回で述べたような成功体験の限界故なのか，ソフトウェアパターンを「難しい」とか「役に立たない」と評する人が少なくありません。
特に，まだそれほど開発経験を積んでいない人が，ソフトウェアパターンを学習した際に漏らす感想の多くは:
というものが多いように思われます。
彼らの話を聞いてみると，どうやらソフトウェアパターンを，「この場合は，こうしなさい」というような，ルール集やガイドラインのように捉えているようなのです。
パターン定義において，目に付き易く，いかにも「ベストプラクティス」っぽい部分だけを捉えれば，ルール集やガイドラインに見えてしまうのは，確かに止むを得ないかもしれません。
しかしそれでは，非常に浅い理解しかできません。
「パターンを適用しない」状況を考えてみる
ソフトウェアパターンの定義には，そのパターンによって解決される問題の記述が必ずあります。
言い換えるなら，そのパターンを適用しない場合の失敗例が必ず記述されている，ということです。
たとえば，デザインパターンの1つ，Observerパターンと呼ばれるパターンの場合，パターンを適用しない場合には以下の様な問題が発生することが，「動機」において記述されています。
- 再利用性の低下
- GUI 部品のような，本来汎用性を求められる要素は，表示対象となるデータオブジェクトを固定した場合，他の表示対象への適用が難しくなるため，再利用性が著しく低下してしまいます。
- 表現形式選択の制限
- 表示を行うGUI部品と，表示対象となるデータモデルの関係が固定的になっている場合，任意の表現形式（例：棒グラフ・円グラフ・折れ線グラフ）を選択したり，単一の表示対象データモデルに対して複数の表現形式を関連付けたりといった，表現形式選択の自由度を制限してしまいます。
このような失敗事例は，まさに「パターンを適用する理由」を端的に表していますので，パターンを理解する上で非常に有効な示唆を与えてくれることでしょう。
