※個人的なポリシーをまとめています。 問題解決の際、問題を完全解決する必要があるとは限りません。 完全解決できるに越したことはありませんが、 問題は一つとは限らず、 一つの問題に対する完全解決の追求が全体としてみたときに 効率的かどうかは議論の余地があるでしょう。 A という問題があって、X, Y, Z という三つの解決法候補があるとします。 「X は A を完全解決できないから X はダメだ」 どこかに論理的な間違いがあります。 X が A を完全解決のは事実かもしれません。 でも、A を解決するのに X がダメかどうかはまだ不明です。 多くの場合、銀の弾丸はありません。 そもそも A に大して完全解決が必要なのかどうか、 そこの前提を疑ってみる余地があります。 完全解決が求められる重要度の高い問題、キラー問題なら別ですが、 問題のタイプによっては、 「80点の解決できれば十分」 という場合もあります。 完全解決できるに越したことはないですが、 残りの20点を埋めるのに膨大な時間とコストが掛かるのであれば、 あまり現実的ではありません。 また、それまでの80点よりも残りの20点を完全に埋める方が コストが掛かるということも珍しくありません 学生の頃のテストでも80点はある程度の勉強で比較的簡単に取れても、 必ず100点を取る、っていうのはものすごいエネルギーの要ることです。 勉強であればそれ自体価値の高い行為ですが、 ビジネスの現場では非効率であると判断される場面もあります。 問題は一つとは限りません。 大抵の場合、複数の問題を抱えているもので、 かつ、リソースが限られていて時間とコストに余裕のある状況は珍しい。 一つの問題に全力を注いでいる場合ではないのです。 そういうことから、X でも十分 A を解決するための 選択肢となり得る可能性があります。 もし、Y が完全解決ができる解決法だったとしても、 X には 別の問題 B を解決するための解決法も兼務できる特性を 持っていたら、かつ、Y は他の問題では全く機能しない解決法で コストも掛かる、そういう場合であれば、 X の方が全体からみたときに良い選択肢であるかもしれません。 X で解決できない A の残った課題はほとんど実際問題にならない、 許容できるレベルの話である、というならとても現実的です。 また、X で完全解決できなくても、 A を完全解決するための一つの役割を担うかもしれません。 A を完全解決する解決法は単一とは限りません。 存在する他の問題、時間とコストなどとのバランスを考慮して、 総合的なアプローチをしていくことが大事なのです。 // 一つの問題に対する解決法は単一とは限らない http://d.hatena.ne.jp/jflute/20110215/solutions そういったことを考慮せずに、 単に完全解決できないって部分に着目して簡単に X を 捨てるのをよく見かけますが、それはもったいないことだと。
生活の中での話を例にして、 燃やすゴミの日をよく忘れてしまうという問題があるとします。 忘れた直後は、 「ああ今度こそは絶対に忘れないように」 と意気込みますが、 いざ次の燃やすゴミの日が来たらまた忘れてしまうものです。 すると、ゴミの入ったゴミ袋がどんどん家の中に溜まっていくのです。 一週間二週間と溜まっていくと、幾ら袋に入れているとはいえ臭いが... そんな状態でまた忘れて、 「どうせまた次も忘れるさ、全くこの先が思いやられるぜ」 と切ない気持ちにもなってくるものです。 そんな問題を解決するために、 カレンダーに燃やすゴミの日のチェックを入れて、 その日カレンダーを見た時は思い出すようにします。 これで、出し忘れることもない、いや、必ずしもそうではありません。 カレンダーを見る習慣がそもそも染み付いてない可能性もあります。 とはいえ、全くカレンダーを見ないわけでもない。 ときおり眺めるくらいならある。 言えることは、 少なくとも何もアプローチしなかった場合に比べて、 燃やすゴミを出し忘れることは減るでしょう。 それで十分です。 それまで、二回分三回分と溜まる可能性が高かったのが、 二回分溜まるのは稀な状態とまでなって、 ただの一回分が溜まってるくらいなら ほとんど精神的・嗅覚的にも影響はありません。 燃やすゴミの日を絶対に忘れない仕組み作りをする必要はないのです。 その忘れる頻度が減る解決法が低コストでできるならそれでOKなのです。 絶対に忘れないようにするために高いコストを掛けて仕組み作りをする 必要はないし(いったいどんなことを!?)、対費用効果が悪過ぎます。 年に何回か少ない頻度で二回分三回分溜まるのはご愛嬌ということで。 もっと正確に分析すると、問題の本質は "忘れること" でもなく、 "ゴミが溜まること" でもなく、"頻繁に忘れて溜まってしまうこと" と言えます。"頻繁に" っていう部分だけを解決してあげればいいだけ。 ある程度の発生は大問題にはならないので許容する、そういった割り切り。 問題分析の際は、"程度" というベクトルを忘れてはいけません。 せっかくわかりやすい生活の中の話をしているのになんですが、 DBFluteには、DB変更に強いという特徴が備わっています。 でも、DBFluteでDB変更の問題が完全解決するわけではありません。 厳密には「ある程度」解決する、というニュアンスになるでしょう。 そして、それで十分過ぎるほど価値の高いことです。 多くのDB変更に対して効果を発揮することで、その分、 DBFluteがアプローチできない複雑なDB変更に対する 人が行う作業に集中して頂ければと思います。 もちろん、問題の性質的に中途半端な解決が許されないものも あるでしょう。逆に言うと、問題の性質をしっかり捉えれば、 完全解決とはならない解決法も十分な候補となるわけです。 繰り返しですが、そもそも解決法が単一とは限りませんしね。
と、自分が色々なことを議論するときに忘れないようにしていることであり、 できなかったときもあったかなと反省の念もこめて今後のためにここに記す。
