わからないことを聞けることはすごいのよ
前にプロジェクトチームの中に若手のエンジニアがいたんですね。おじさんエンジニアばかり相手にしていると若いエンジニアがいるだけで雰囲気も変わるし、何より新鮮味がありますよね。
プロマネやマネージャの立場であれば、コスト的にペイできるなら顔見知りのおじさんエンジニアの方が楽です。アウトプットのレベルは知っているし、進捗もこのくらいでやってくれるだろうと見切りができるので。
もちろん、アウトプットのレベルはプロジェクトの品質要求にこれだけ足らないだろうからそこは手間を掛けなきゃとか、進捗もこのタイミングで借金取りのように催促を始めなきゃという手間はあったとしても、確保できるものがやる前から担保できるから、総合的に楽なんですよ。
おじさんエンジニアのウィークポイントは健康。これさえトラブらなければ問題ないですね。数年おきに何かしら健康トラブルを起こすおじさんもいますが、年齢的なものもあるのでそこはそういったリスクはテイクしておくのがお作法ではあります。
わからないことと理解できないこと
おじさんエンジニアが楽だというところの一つに、わからないこと、理解できないことを聞いてくれることがあるのですよ。
これとても大事なことです。要件を聞いて、適用技術に当てはめるとどうなるかを考えてくれているということです。頭の中でどうなるかをシミュレーションして何か引っかかったり、持っている経験知と突合してそんなのやったことないぞ、とか。
お仕事なのです。テストではないのです。
だから、わからないことはわからないと言わないと作業が進捗しません。だから、わかる人にどうしてその要件からこの仕様になったとか、アーキテクチャ的におかしいぞ、なぜそれでいいのか、的なことを疑問に思うだけで十分すごいことです。
そして、それをそのまま流さないところがもっと偉い。
仕事を終わらせようという意思が感じられますよね。だって、そのままわからないことを放置したら、後になって文句を言われるわ、リカバリしなきゃだわっていいこと何一つないんですから。
わからないことを理解する
今時の若いエンジニアの方が能力的に優秀な方が多いと思うんですよ。よく勉強ができる。だから、理解できるお膳立てが揃っていれば吸収するスピードはめちゃ早いです。
これ、実例がありまして。
若いエンジニアにある業務をスキトラするときに工夫をしたことがありまして。
初めて経験する業務、その業務に必要な知識は事前に参考分野のキーワードを教えて時間があったら読んでおいてくらいで振っておいたけれど、実際読んで理解してきたかは怪しい。真面目だから読んではきたかもしれないけれど。
joinしたらすぐに適用技術や手順を教えたくなりますよね。期待するパフォーマンスをできるだけ早く発揮して欲しいから。
でも、細かなことは一番最後にしました。そんなの数こなせばできるようになる素地はあるはずなので。
最初に手をつけたのは、考え方、方針、判断基準といった作業を進める上での行動規範になるイズム的なものから何度か繰り返した後に実務の仔細を覚えてもらいました。
プロシージャから入ると公式で回答をいきなり解いちゃうんですよね。勉強できるので。でも、お仕事上の特性もあって、それでは判断を間違える危険性があるのでそうしないために、行動規範的なところから。
最初のアウトプットはそうした行動規範と一致しているかでいいところ、やりなさいと拙いところを指摘します。そうしないと結果が違うものになるので。
そうした経緯で始めてもやっぱり理解できないこと、消化できていないことがあるんですよ。それを放置しようとする。若しくは、放置しようとしていることに気づいていない。そこを繰り返し指摘をするのです。そのままで進んでしまうと間違いをしてしまうよ、と。
結果的に本人が優秀だったから、期待するように作業をできるようになったので、わからないことを放置することが間違いを犯すなら、そうしないためにわからないことを聞けるように周りが環境を作るのは大前提だし、わからないことを聞けるということはやっぱりすごいことなんですよ
仕事を理解しようとしていることがわかるので。
なので、薄っぺらい合いの手でわかりました的なレスポンスをすると全くもってわかってないなと思っているんですよ。こちらは。
