ドイツの宰相ビスマルクの有名な台詞に曰く:
しかし、失敗学的な見地で言うなら、経験＝失敗から学ぶことができるなら、賢者とは言わないまでも、愚者という程でもありませんので:
愚者は経験を活かさず、凡夫は経験に学び、賢者は歴史に学ぶ
といったあたりが妥当ではないでしょうか。
前回までの解説は、自身の失敗経験を如何にして活用するか、という点に着目したものでしたが、今回は歴史＝他者の失敗経験から学ぶ方法について、ソフトウェアパターン（software pattern）を題材に説明します。
ソフトウェアパターンにおける失敗「考古」学
よくあるつまずき
デザインパターン（design pattern）に代表されるソフトウェアパターンは、「ベストプラクティス」（best practice）という言い方に象徴されるように、一般には「成功事例」として捉えられる状況が多いように思われます。
その一方で、第1回で述べたような成功体験の限界故なのか、ソフトウェアパターンを「難しい」とか「役に立たない」と評する人が少なくありません。
特に、まだそれほど開発経験を積んでいない人が、ソフトウェアパターンを学習した際に漏らす感想の多くは:
書いてあることは覚えたが、どのように使ったら良いのかわからない
というものが多いように思われます。
彼らの話を聞いてみると、どうやらソフトウェアパターンを、「この場合は、こうしなさい」というような、ルール集やガイドラインのように捉えているようなのです。
パターン定義において、目に付き易く、いかにも「ベストプラクティス」っぽい部分だけを捉えれば、ルール集やガイドラインに見えてしまうのは、確かに止むを得ないかもしれません。
しかしそれでは、非常に浅い理解しかできません。
「パターンを適用しない」状況を考えてみる
ソフトウェアパターンの定義には、そのパターンによって解決される問題の記述が必ずあります。
言い換えるなら、そのパターンを適用しない場合の失敗例が必ず記述されている、ということです。
たとえば、デザインパターンの1つ、Observerパターンと呼ばれるパターンの場合、パターンを適用しない場合には以下の様な問題が発生することが、「動機」において記述されています。
- 再利用性の低下
- GUI 部品のような、本来汎用性を求められる要素は、表示対象となるデータオブジェクトを固定した場合、他の表示対象への適用が難しくなるため、再利用性が著しく低下してしまいます。
- 表現形式選択の制限
- 表示を行うGUI部品と、表示対象となるデータモデルの関係が固定的になっている場合、任意の表現形式（例：棒グラフ・円グラフ・折れ線グラフ）を選択したり、単一の表示対象データモデルに対して複数の表現形式を関連付けたりといった、表現形式選択の自由度を制限してしまいます。
Observer パターン定義において、上記2つの問題点は共に（Observer パターンの導入による）「構成要素間の抽象的結合」により解消される問題としていますが、イメージのしやすさを優先して、具体的な問題点を列挙しています。
このような失敗事例は、まさに「パターンを適用する理由」を端的に表していますので、パターンを理解する上で非常に有効な示唆を与えてくれることでしょう。
「前提条件が異なる」状況を考えてみる
ソフトウェアパターンは万能の特効薬ではありません。そのパターンを適用する場合に必要とされる「前提条件」や、適用した場合の「トレードオフ」（たとえば性能と資源消費）が存在する方が一般的です。
言い換えるなら、前提条件やトレードオフを無視してパターンを適用すれば、それは即ちそのパターンにとっての失敗事例になる、ということです。
たとえば、先述したObserverパターンの場合、以下のような状況では、「監視主体」「監視対象」の間で直接関連付けを行うよりも、Mediatorパターンを適用するのが妥当とされています。
- 「監視主体」「監視対象」の数が多い
- 「監視主体」「監視対象」がそれぞれM個、N個存在する場合、それぞれが個別に直接監視を行うならば、M x N 本の伝達パスが必要となります。
- 5 x 5 程度ならまだしも、10 x 10 を超えるような場合、保守性・性能等の劣化が予想されます。
- 一貫性が必要な場合
- たとえば、フォント選択ダイアログにおける「フォント」「サイズ」「修飾」選択のためのGUI部品やプレビュー表示のようなケースでは、各部位がバラバラに動作すると、機能としての一貫性が保てません。
- ある「フォント」は特定の「サイズ」でしか表示できないかもしれませんし、
強調や下線といった「修飾」をサポートしていないかもしれません。
- このような場合、個々の「監視対象」（GUI部品）の状態から導かれる「フォントの選択」状態を管理するだけでなく、必要に応じて「監視対象」にフィードバックする（例：選択できない項目の非表示等）といった、一貫性管理が必要になりますが、個別の情報伝達が主体のObserverパターンはこの用途には不向きです。
「パターンを適用する理由」はパターンにとっての成功体験ですから、失敗学的に見た場合、それだけでは不十分です。
失敗学の提唱者である畑村氏は、その著書『失敗学のすすめ』において、真のリーダーと偽のリーダーの違いを、登山の例を用いて以下のように説明しています。
優秀なリーダーは順調に山を登っていく間も
「雨が降ったらここは危ない」
「ここは道が細いから危ない」
「ここは転落の危険がある」
などと、常に危険を想定した観察を行っているものです。一方の偽リーダーの方は、そんなことなどなにひとつせず、
「オレは頂上まで行ったけど大したことはない。山なんてこんな程度だよ。」
と、すべてを理解したつもりになって豪語するだけでしょう。
ひとたび悪天候に見舞われた際には、上記の様な偽リーダーは右往左往するしか無いことは想像に難くないですが「パターンを適用する理由」あるいは「パターンの適用方法」だけを知っている状態と、偽リーダーは非常に似ているのではないでしょうか。
ありがたいことに、ソフトウェアパターンの失敗例は、遭難よりも(通常は)低コストに再現することができますから、どうしても臨場感を持って想像できないのであれば、実際に失敗例と言われるプログラムを書くことで、臨場感を持つというのもひとつの手です。
参考資料紹介
今回は、他者の失敗／歴史に学ぶ上でのお勧め資料を紹介したいと思います。
「失敗に学ぶものづくり」
『失敗に学ぶものづくり』は、異なる分野の第一線で活躍する語り手による失敗体験談を集めたものです。
第一線で活躍する方々による体験談は、どれも臨場感に溢れたもので、一読の価値があります。
「失敗の本質―日本軍の組織論的研究」
『失敗の本質 ― 日本軍の組織論的研究』は、太平洋戦争時の日本軍の戦略・組織的問題を研究したものです。
失敗事例そのものとしても興味深いものがありますが、失敗から学ばないことがどれだけ損失を生むのかを知ることができる、という点でも興味深いと思います。
ただし、軍隊編成の名称と規模がわからないと、規模的な面で実感が湧かないのが玉に瑕といったところでしょうか。
おわりに
エンジニアの立場から見た失敗学の活用について、5回に渡って説明をさせていただきましたが如何でしたでしょうか？
失敗学は、昨今注目度が高まりつつある非常に有用な考え方ではありますが、決して万能の特効薬ではありません。
何より、自身の失敗と向き合うことができない限り、どんなに失敗学について詳しくなったとしても、決して効果を得ることはできませんから、人によっては他の方法論よりも厳しい印象を受けるかもしれません。
しかし、余程の才能(運も含みます)に恵まれない限り、全く失敗すること無しに事を成し遂げる、ということは有り得ません。
つまり、誰もが失敗しているわけですから、失敗を（必要以上に）恥じる必要はありませんし、失敗から学ぶことができる折角の機会を無駄にするのは非常にもったいないと言えます。
本特集が、失敗を振り返る契機を作る一助になれば幸いです。
