なんとなく良い方法を提案されることがある。
「こっちの UI の方が良いと思う」
「新しいデザインにしましょう」
「あれもやった方がより良さそう」
感覚的になんとなくその方が良さそうというのはあるが、根拠が「そっちの方がいいから」であるうちは賛同できない。例えばデザインの話で言うと、良かれと思ってやった変更が不評なこともあるし、実は意図的にそうなっているのを知らずに壊してしまうこともある。あるいは、良くなるかもしれないが既に満足度が高くて必要のない変更かもしれない。
限りあるリソースを無駄にしないために「問題を解決する」ことにフォーカスして考えたい。
「そっちの方が良い」のであれば現状の問題になっている点は何か？ホームページに「明るい雰囲気の画像を置きたい」のは「暗い雰囲気を感じる」からであり、例えば採用に応募しにくいなどの実害が生じるのが問題だということになる。できれば本当にそうなのかを A/B テストなどで計測できれば良いが、難しい場合は仮説でも構わない。
問題が解決するならば、その分だけ確実に前に進むとわかる。かっこ悪い UI でも実際に問題になっていないのであれば放置でいい。逆に今は大した問題になっていないが問題が起きた時に甚大な被害を及ぼすなら優先度を上げて対応するといった判断もできる。フィーリングで「もっと良くしましょう」だと本当に意味のある仕事か分からないし、提案者の好みの問題で手を動かさないといけないのはモチベーションも下がってしまう。「良くしたい」と思うのは、提案者が無意識に問題だと感じていることがあるのだろう。だが、その問題は言語化してみると実は大した問題ではなかったり的外れであることも多い。
ことをややこしくするのが、「漠然とした問題」に対する「複数の問題を同時に解決するツール（方法論）」の存在だ。漠然とした問題は A, B, C に分解され、ツールが解決する問題は B, C, D, E, F だ。大抵は分解するところまでいかず「なんとなく不満を抱えている現状よりは良くなるんじゃないか」ということで導入を検討するが、意外と大変で頓挫するか、導入されたがどうもしっくりこないとモヤモヤを抱えるかになる。問題が分解できていれば、 A, B, C それぞれを解決するミニマムなツールを導入することもできるし、ツールの機能を部分的に導入した上で A だけは運用でカバーということもできる。
と、ここまでは問題を分析してピンポイントで解決することでコスパを良くしたい話。一方で、問題と一対一対応しないがとにかく手段を使ってみた方がいい場合がある。見えていない問題が発掘される可能性が高い場合や、手段が提供するメリットが見えていない場合だ。それらが世の中に広く浸透しているノウハウであれば、現在地が「守破離」の「守」である場合、と言い換えることもできる。
例えば、 SVN を使っている現場に Git を導入するとする。Git を使いこなす人々は「ブランチが手軽に切れるのがメリットだ」と言うが、 SVN しか使ったことのない人には何のことか良く分からない。ここで現場の人は「今の SVN の運用で何も問題は起きていない」と提案をつっぱねることもできるし、「問題を丁寧に分析した結果、３つの問題があり、 Git はその１つしか解決してくれない」と言うこともできる。が、同時に今見えていない問題を認識していないこともあるし、提案者の語らない Git のメリットもあるかもしれない。つまり、体験や学びが得られる期待値が高い場合は、試してみた方が長い目で見て得になることがある。
前半で「問題解決」にフォーカスすること、後半でそれに対しての反例を挙げたが、両立する話ではあると思う。リソースの少ない中で行き当たりばったりな方法を試す余裕はないが、一方で学びを目的として中長期的な戦略を取るのはアリ。「学びが得られず組織が硬直する」というのも問題の一つなので、それを解決することに対して意識的であれば、行き当たりばったりな解決とは違うし、仮説・検証もできる。
話が大きくなってしまったが、まず問題を定義してから解決したいし、言語化されていない問題を「なんとなく良くなるであろう方法」で解決するのを避けたい、という話でした。
