※個人的なポリシーをまとめています。 問題解決の際、 リスクのない解決法なんてめったにありません。 関連事項の多い複雑な問題であればあるほど、 解決法もリスクを帯びるでしょう。 A という問題があって、 X, Y, Z という三つの解決法候補があるとします。 「X では A は解決できるけど別の問題が発生するから X はダメだ」 どこかに論理的な間違いがあります。 X で別の問題が発生するのは事実かもしれません。 でも、A を解決するのに X がダメかどうかはまだ不明です。 多くの場合、銀の弾丸はありません。 つまり、X も Y も Z も何かしら別の問題を発生させる、 ということも珍しくはありません。 こういったとき、以下のポイントを忘れてはならないでしょう。 o 発生する問題がどの程度困る問題なのか、解決不能なのか o 他の解決法で発生する問題よりも軽度なものなのか o 他の解決法でも同じような問題が発生しないのか o 何も手を打たないのとどっちの方が深刻な問題なのか 例えば、X で別の問題が発生して Y では何も発生しないとしても、 X で発生する問題が実はたいしたことなく、 X で得られる効用の方が Y で得られる効用より大きいのであれば、 実は X の方が最適です。 また、X で別の問題が発生して、 実は Y でも Z でも似たような問題が発生するのであれば、 そもそも X に限らず議論すべき問題です。 場合によっては、どの選択肢のリスクも回避し得ないかもしれません。 ある程度のリスクを背負ってどれかを選ぶことも、 なきにしもあらずです。 「程度」や「ニュアンス」を無視した言葉だけの論理(二次元の論理)で 考えてしまうと、ついつい感覚で捉えることを忘れてしまいます。 正の部分、負の部分を立体的に捉えて総合点で比べる のを忘れてはいけません。 もちろん、X にリスクがあること自体を突き止めるのも大事です。 そして、それに対する分析とアプローチを忘れてはいけません。 逆に言うと、それをしっかりやれば十分選択肢になり得るのです。 そもそも解決法は単一とも限らないため、X の安易な切り捨ては危険です。 // 一つの問題に対する解決法は単一とは限らない http://d.hatena.ne.jp/jflute/20110215/solutions そういったことを意識せず、簡単に X を捨ててしまうのを よく見掛けますが、それはとてももったいないことです。
生活の中での話を例にして、 環境保護(地球温暖化)という問題があるとします。 その中でエコバッグを利用してビニール袋の利用を 削減しようというアプローチがあります。 ここでは、エコバッグが環境保護に確実に効果があると仮定します。 このエコバックという解決法、万引きをわかりにくくさせてしまう という別の問題が発生することがあるようです。 じゃあ、エコバッグはダメかと言ったらそうではありません。 どの程度の万引き発生の増加率なのか、 ちょっとした工夫で対策できないか、 そもそもエコバッグに限らず、 万引きは既に存在する大きな問題なので、 根本的な解決のアプローチをしてみてはどうか、 など幾らでも思考の余地はあります。 その思考なしに簡単に解決法を捨ててしまうのは、 あまりにもったいない。 せっかくわかりやすい生活の中の話をしているのになんですが、 DBFluteを採用するとアーキテクトに負荷がかかる、 という問題が発生します。 じゃあ、DBFluteはダメかというかというとそれはまだわかりません。 アーキテクトに勉強する時間を与えたり、 若い人に勉強がてらアーキテクトの手伝いをさせたり、 他の人でもできるアーキテクトの仕事を別の人に振ったり、 DBFluteの利用する機能を限定したり、 そういったちょっとのマネジメントの工夫で 解決できるかもしれません。 そもそもアーキテクトが頑張ることで得られる効用があるわけで、 そこにアプローチをせずに利用するとDBFluteを使う意味を 半減させる可能性がありますし、そのあたりを理解せずにDBFluteの 採用を見送ると、もったいない判断をしてしまう可能性もあります。 少なくとも問題の一面だけを見て判断してしまうのは早計と言えます。 別のO/Rマッパを使っても似たような同じ話にもなりがちですし、 違った別の問題を発生させることもあります。 それぞれの良いところ悪いところの分析をしっかり深めて、 立体的に捉えて総合点を比較して選ぶのが良いのです。
と、自分が色々なことを議論するときに忘れないように していることであり、できなかったときもあったかなと、 反省の念もこめて今後のためにここに記す。