知識を得るのは頭でっかちになるためじゃなくて、自分で書いた文書に疑問を持てるようになるため

レビューをしていて、ある時期までは、

「なぜ、ワタシが初見で文書を読んで疑問に思うことをこの文書を書いたエンジニア当人は疑問に思わないのか。」

と不思議でした。ワタシがどうのこうの、ではなく、この文書を書いたエンジニア自身が想い、考えた文字を書き起こした文書に抜けがあるとか、整合性が取れていないとか、若しくは、矛盾があるとか、そう言った類のことを、です。文書をレビューするこちらとしては「書いた本人が一番わかってるんでしょ？」と思いながら読みますから、当然、対面でレビューをするときには「なんでこうなっているの？」って聞くわけです。で、答えがどうも覚束ない。

またあるとき、やっぱりレビューをしていて不明点を質問をすると、どうにも要領を得ない。「いやいや、書いたのアナタじゃん？」と直接的には突っ込みませんが、やっぱり聞くんですけどそれも要領を得ないときがある。

どちらのケースでも、エンジニアの経験年数はバラバラだし、どこの技術エリアと言うこともないのです。で、あるとき、これまた別の人に「この文書のやつさぁ、どこで経験したのがベース？」って聞いたんですね。そうしたら、「言われて(指示されて)やったことはあったけど、自分で考えたのは今回が初めて。」なんですと。「じゃあ、勉強した？」と訊いたら、ソレもしていない。それを聞いて「そういうことかー！」と一人で納得したんですね。

で、何かと言うと、要領を得ない、書いた本人がわかっていない文書を書いていたケースは、その書いている文書を書くための経験は少ないし、その経験を支える知識も少ない、ということでした。

そういう結論に至ると、改めて見えてくるものがあるわけです。まず、前提知識はなくて経験も少ないと自分の経験だけをよりどころに書くので俯瞰しようがないのですね。だから、疑問を持つことができない、と。

経験を積めば、自分の中にナレッジを持てるようになるので随分ましには成りますが、それでもやっぱり経験則でしかないので偏るのは仕方がないことです。そこで自分が作った文書を俯瞰してみることはできても、経験していることにしか疑問を持つことができない。コレも仕方がないことです。

では、自分が書いた文書に対して疑問をどうしたら持ているか、ですが。それは比較する対象がなければズレを発見するのは難しいです。文書の論法なら、論法を知らないとその観点での矛盾は見つけにくい。同じように整合性ならそうした技術を知らないと書き物が意図したことを言い表せているかどうかを差異を認識することは難しい。

差異を知覚するための疑問をもつためにすることは、ずれを知るためのテンプレート、知識と比較することなのです。比較できるから違いが分かり、違いがわかるから疑問が持てるようになる。

知識は頭でっかちになるために取り入れるモノではなく、例えば疑問を持つために得るモノであると考えるとまた一つ違う視点で取り入れられるのではないかと思うのです。