保証された解決法なんてめったにない

※個人的なポリシーをまとめています。

問題解決の際、保証された解決法なんてめったにありません。
関連事項の多い複雑な問題であればあるほど、
解決法の効果の証明が難しいもの。

A という問題があって、
X, Y, Z という三つの解決法候補があるとします。
「X では A を解決できるとは限らないから X はダメだ」
どこかに論理的な間違いがあります。
X で A を確実に解決できるかどうか不明なのは事実かもしれません。
でも、A を解決するのに X がダメかどうかもまだ不明です。
多くの場合、銀の弾丸はありません。
つまり、X も Y も Z も確実に解決させるかどうかわからない、
ということも珍しくはありません。

その確実性をできる限りの範囲で追求するのは当然大事です。
分析を重ねて確実性のある選択肢を選ぶことが大事です。
その一方で、問題の複雑度によってはいくら分析しても
100% の保証を得られないことも珍しくないですし、
保証を得るために莫大な時間とコストを掛けて
解決法の実践がどんどん先送りされるのもそれはそれでリスクです。
科学的な根拠は?統計学的な根拠は?と追求するのが
とても大事な分野もある一方で、
どの解決法にもそのような根拠が存在し得ない状況もあります。
そのような状況でそういった根拠を
ただ闇雲に求めても何も先には進みません。

まず、大事なのは、
100% の保証がないからと言って安易に選択肢を減らさないこと
解決法は単一とは限りませんので、
議論の途中でその選択肢が別の顔をもって
一つの役割を担う可能性もあります。
解決法は単一とは限らない、という考えととても密接です。

// 一つの問題に対する解決法は単一とは限らない
http://d.hatena.ne.jp/jflute/20110215/solutions

そして、さらに大事なのは、

解決法の効果が確実になるかどうかは結局自分たちの行動次第

ということを認識し、
実践者も頑張ると同時に周りもそれを支援すること。
その中で確実性を上げる効果を上げるために必要なものを見つけて、

実践しながら解決法を育てていくこと

どの解決法を選んでも、どれだけ事前分析を進めていても、
これが求められます。
逆に、それを理解せずに実践すると、
どの解決法を選んでも成功しない可能性も。

そういったことを意識せず、簡単に X を捨ててしまうのを
よく見掛けますが、それはとてももったいないことです。
生活の中での話を例にして、
環境保護(地球温暖化)という問題があるとします。
その中でエコバッグを利用してビニール袋の利用を削減しよう
というアプローチがあります。
エコバッグに確実に効果があるかどうか、よく議論になりがちです。
CO2の削減という面だけの評価項目だけでも計算が非常に複雑であり、
間接的な効果などを加えると評価項目は一つとは限らないため、
効用というのはなかなか単純な物差しでは測れないものです。

// 解決法の評価項目は単一とは限らない
http://d.hatena.ne.jp/jflute/20110306/items

そもそもエコバッグだけで環境保護の問題のすべてを
解決しようとしているわけではありませんし、
それができる解決法が他にあるとは限らないし。

// 一つの問題に対する解決法は単一とは限らない
http://d.hatena.ne.jp/jflute/20110215/solutions

そして、
エコバッグに微量ながら確実に効果があると仮定しましょう。
微量だからほとんど無意味なのかどうか?
それは実践者次第です。
また、それを支援する、促進する世の中の環境次第です。
エコバッグを使ってビニール袋の削減をしてる人はほんのわずか、
また、それを推し進めているお店もほんのわずか、
当然ながら効果は低いでしょう。
それを大勢の人がやる、大勢の人がやりやすいような仕組み作り、
これができれば効果は高くなるでしょう。

解決法は育てるものです

せっかくわかりやすい生活の中の話をしているのになんですが、
DB変更という問題に対して DBFlute は、
自動生成によるタイプセーフ実装や2Way-SQLの一括テストなど、
様々なアプローチでDB変更に強いという特徴を持っています。
でも、科学的・統計学的に根拠があるわけではありません。
DB変更に強くなるためにはこういった機能が必要だという、
作者の経験をもとにしたボトムアップな設計の結果です。

試しに100人動員して10プロジェクトを
一年間やってみてDB変更に強かったかどうか検証、
なんてことは誰もできません。
ソースも仕様も仕組みも公開されていますから、
利用者がそこから自分なりに判断すればよいこと。
あえて言うなら、実際に利用された方が
「DB変更の便利だった」と言ってくれるのが
唯一の統計学的な根拠かも。

また、DB変更というのは多様で複雑な問題であるため、
その効果を確実なものにするには、
DBFluteの機能をDB変更に強いという特徴を
最大限に活かす利用方法が求められます。
例えば、
DB変更によるテストデータの変更をしやすいように
ReplaceSchema をしっかり使うとか、
外だしSQLへの影響をチェックするのに
OutsideSqlTest を定期的に実行するなど、
機能だけあっても使っていなければ無意味です。

また、業務上の潜在的な影響などは、
DBFlute でもチェックできませんので、
JUnit単体テストなどで検知できるようにするとか、
そもそもDB変更の内訳をDB設計者自身ができるだけ
明確にしてディベロッパーへの通知を円滑にするとか、
(DBFlute はそれ自身を HistoryHTML や SchemaHTML で支援)
それぞれの解決法が互いに補完し合うアプローチも必要になります。

DB変更という問題に対する解決法はやはり単一ではなく、
総合的にアプローチする必要があるものです。
DBFluteは、その一つとして大きな役割を担うための機能を
備えている、言ってしまえばただそれだけであり、
それがとても重要なのです。

仕様変更という問題に対して、
Javaを使ったからオブジェクト指向になって変更がしやすくなる、
ってわけじゃなく、そのように意識して実装しなければ無意味だし、
オブジェクト指向をフル活用したからってそれだけで
仕様変更は怖くないってわけではありません。
Eclipse を使ったからと言って必ずしも実装が
速くなるわけではありません。
ただ、速くするための支援ツールとしてとても優秀です。
使えば使うほど熟練度も増し、解決法は育っていきます。
問題が複雑であればあるほど、
保証された解決法などありえないものです。
幾つかの解決法とのコラボレーションが求められると共に、
その解決法を活かすかどうかも実践者とそれを支援できる
位置にいる周りの人次第と言えます。

解決法に対する疑問点なんかは挙げようと思えば幾らでも出せます。
もちろん、疑問点を挙げることは重要ですが、挙げるだけ挙げて、
どの解決法にも到達せずに時間だけが進んでいくのも問題ですし、
その疑問点自体の "温度" を吟味せずに安易な判断材料としてしまうと、
ただのノイズとなってしまいます。
保証された解決法がめったにないと同じく、
リスクのない解決法もしかりです。

// リスクのない解決法なんてめったにない
http://d.hatena.ne.jp/jflute/20110303/hasrisk
先ほども出てきたお決まり文句
「科学的・統計学的な根拠はあるのか?」
という言葉は、
時に裏にある感情や主張を代弁した拒否を示すことがしばしばあります。
今回紹介した「保証された解決法なんてめったにない」
をよくわかっていながらこの言葉が発せられるというときは、
そういった表面の論理とは違った別の論理(感情や主張)が
存在する可能性があります。

そう言う場合、解決することが目的ではなく、
拒否することが目的になっているため、
建設的な議論を進めるのが非常に困難になりがちです。
そういうときは表に出ている利害だけを説いても
なかなか平行線になりがちなため、
前後関係やニュアンスなどを考慮した感覚的な洞察を研ぎすませて、
その真意を紐解いて角度を変えたアプローチをしていく必要が...
あるでしょう。
と、自分が色々なことを議論するときに忘れないようにしていることであり、
できなかったときもあったかなと反省の念もこめて今後のためにここに記す。