小手先のテクニック、ノウハウだけでなく、それを生み出したロジック、土壌に目を向けないといけないなと思う昨今

小手先のテクニック、ノウハウ

小手先のテクニック、ノウハウは、すぐに取り入れることができるし、すぐに役に立つ。
目の前の問題を解決してくれる。

プログラミングでいえば、エラーメッセージでググると出てくる情報。
そこに書いてある解決法を試してみれば、運が良ければ問題は解決して、次の段階に進める。

ロジック、土壌

それを生み出したロジック、土壌というのは、「なぜ」の領域。

プログラミングでいえば、エラーメッセージでググると出てくる情報において、「なぜ」そこに書いてある解決法で、問題が解決したのか。
なぜそのエラーメッセージが発生したのか、その意味するところはなんなのか。

また、そのエラー解決方法を書いた記事の人は、どういうロジックで、その解決方法を導き出したのか。
そのロジックを構築する前提として、どういう知識を持っていたのか。

ロジック、土壌に目を向けないとなと思う昨今

そういうバックグラウンドを想像したり考えたりして、調べて身につけて。
次に自分が関連するエラーメッセージに出会ったときには、同じようにロジックを組み立てて解決策を見いだせるようにならないとなと思う昨今。

小手先のテクニック、ノウハウは上述したとおり、すぐに取り入れることができて、すぐに役に立ってくれるんだけど、応用が効かない。

一方で、ロジックや土壌となる知識は、習得には時間がかかる。
加えて、なかなか使いこなすにもこれまた時間がかかる。
でも、一度習熟すると応用が効いて、後々レバレッジをかけれるように思う。

小手先のテクニックやノウハウでも解決や対処はできるけど、ずっとこれに頼りっぱなしだと、延々と場当たり的な対処を続けることになりそう。

今回はプログラミングを例として出したけど、それに限らず、

• ツールを導入するとか
• 他社の成功事例を取り入れるとか
• 本を読むとか
• 他人の考えや行動を取り入れて真似てみるとか

にも同様に言えるんじゃないかなと思う。

先日LINEのテクニカルライティングについての資料を読んだ。
engineering.linecorp.com
ここで共有されているノウハウも価値のあるものだったんだけど、それよりも、その礎となった「読む人の立場に立って、読みやすい文章を書く」という考え方がヒシヒシと伝わってきて、そちらに強く感銘を受けた。
この考え方が土台にあって、その結果として、このノウハウが生まれたんだろうなと。

すぐに役立つノウハウばかりに目を奪われるではなくて、なぜそういう結論に至ったのかという過程にも目を向けていきたい。