orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

人に教えているときに感じたこと

f:id:orangeitems:20201030122206j:plain

 

ある要件「Z」を実装したいとします。

しかし「Z」を実装するのははじめてで、いろいろと調査をしなければならず、かなりの時間をかけてたどり着くことになります。

ここは最終地点だと思ったら実は全然違うところで、はじめからやり直す羽目になったりもします。

何しろ、未知のことに手を出すと迷宮に入り込みます。もしかしたら「Z」なんて無理なんじゃないかと思うこともあります。一度諦めるも、方法が見つかり再度トライしたりもします。

そうやって、やっと、たどり着きます。

 

さて、「Z」の実装の仕方を他人に教えるとします。

こうやって、こうやってやればいいんだよ、と。

10分もあれば説明できてしまいました。

教わるほうは楽ですよね。最短距離を理解します。それだけ理解すれば「Z」の実装ができるようになるのです。

でも、私は数日迷宮に入り込み、違う道も含めてたくさんのパターンを知りました。

教えてもらうほうがいいのか。自分で見つけ出す方がいいのか。

 

どうもこうも教えているときに思うのが、なぜそうしなければいけないのか、という部分が大きく抜けることです。

だって、教わる側に取ってみたら、最短距離だけ知っておけば、逸れた道でどんなダメなことが待っているかなんて知る必要がないでしょう?。

数学で言えば公式のようなもので、丸暗記してしまえば、なぜその公式が導いてくれるかなんて、極論、知る必要がないのです。

スマートさで言えば、そのプロセスだけ丸暗記すれば、もっと言えばその手順書さえ手に入れてしまえば、「Z」のスキルを習得したも同然です。

 

これ、技術習得における大事な部分があると思っています。

やっぱり、要点だけを追いかけていくと、丸暗記になってしまう恐れがあります。

その方法を見出すまでに、いろんな試行錯誤があり、ダメなパターンをたくさん試します。ダメなパターンをインプットしたときに、ダメなアウトプットを見て体感する。

そうすると、要件以外のたくさんの反応を知識として身に付けられます。新しい何かが起こった時に、例えば「Y」を実装しなければいけなくなったとき、いろんなダメパターンは頭に入っていますから、「Z」のときよりも相当素早く目的地につけます。

しかし、「Z」へのプロセスしか知らない人は、それ以外は迷宮です。

最短しか知らない人、たくさんのルートをたどって苦労した人、次の仕事で大きく差がついています。

そして、同じ仕事に従事しているメンバー同士でも、長い歳月を経ると、目に見えて大きな差を生んでいくのではないか、と考えています。

 

技術者にも2パターンあって、

①手順書や技術情報がないと何もできない人
②手順書や技術情報がなくとも、いろいろ調べてその結果を手順書や技術情報にまとめられる人

大きくこの2つに分かれます。

①か②か、なんてはっきり分かれず、分野や役割にも影響を受けますが、同じ組織にいても立ち方が違うな、と思うことはあります。

人に教わってばかりいて自分からは何もしない、主体性のない人は①になっていきがちです。「やり方を教わっていないからできません」と平気で言うようになったらもう手が付けられません。

人にいくら教えても手ごたえがないときは、おそらく①を許容してしまっているからかもしれません。教え上手の周りが、いつのまにか主体性を無くし、情報が降ってくるのを待ってるだけの人ばかりになっていませんでしょうか。

 

と、ここ最近、未知の分野に仕事でチャレンジしていて、その結果が出てきたので周りのメンバーに教えながら、「あれ、10分で説明できたけど、本当に大事なことはもっとありそうだな」と感じたので感想をまとめてみました。

私が動かないと周りのメンバーが丸暗記ばかりで未知のスキルを習得しないのであれば、なんと機能不全なのか。教えても教えても、もっと差が広がっていくばかりではないか、と。

この、主体性ばかりは人に教えられることではないので、ぜひ、読者の方には②、つまり未知に飛び込み迷子になりながら、何とかゴールにたどり着くような戦士になっていただきたいと思うのです。