それはそうと、しんざきは元々DBを中心としたITエンジニアではあるのですが、最近は技術的な仕事というより、コンサル的な立ち位置でお客様に接することが増えています。色んな人が色んな部署で抱えている課題について、もっともマシな解決法は何かを考えて提案する、というような仕事です。
そこでつくづく思うのは、「ぱっと答えが出るような問題なら、そもそも自分は呼ばれてない」ということなんですよね。
技術者としては、自分の技術知識でぱぱっと課題の解決法を見つけて、ぱぱっと解決してお客様を喜ばせたい。実際、例えば課題が「システムの特定機能がやたら遅い」というようなわかりやすい内容であれば、「あーこれINDEX当たってないっすね」とか言いながらチューニングするだけで話は済むんですが、今日びその程度の話ならDB標準のチューニングアドバイザが一瞬で見つけて、解決法までセットで指摘してくれます。
ただ、実際お客様が悩んでいるのは、遥かに複雑な色んな課題の集合体で、調べないといけないことや考えないといけない要素がやたら多いどころか、そもそも「最適な回答」自体が存在しなかったりします。何かをとったら何かを捨てることになり、「Aがいい」という人がいれば「Bがいい」という立場もあり、そんな中で散々悩みつつ、色んなバランスをとりながら「これが一番マシでは？」という妥協点を探り出していく。
そういう状況で禁物なのは、「わかりやすい結論に飛びつく」ことです。
ちょっと考えれば出てくるような結論で話が終わるなら、誰かがとっくにやっている。もちろん、「明確な解決法」がある課題だって中にはあるんですけど、それでもどこかに埋まっている罠があったり、その選択肢をとれなかった理由があったりする。だからこそ、すぐに結論を出したい誘惑に耐えて、あれは大丈夫かこれは問題ないかと、脳みそに汗をかいて色んな要素を埋めていかないといけない。
その辺のバランスをとりながら進めるのは毎度大変なんですが、なんとか仕事を進める中で、「分からない状況に耐える能力」というのは大変重要だなーと。それが明確に言語化できただけでも、ネガティブ・ケイパビリティという概念に改めて触れられた意義はあったし、一方このネガティブ・ケイパビリティをどう育てるか、あるいは部下や自分の子どもにどう伝えていくか、なんてことも考えているところなんです。
「世の中そんなに簡単に解決することばかりではない」という基本認識は本当に重要で、だからこそ「分からない」ことを一旦「分からない」ままにしておいて、本当に妥当な選択肢が見つかるまでじっと耐える、ということが大事になってくる。