読者です 読者をやめる 読者になる 読者になる

This is a Pen

プログラミングとITと日記

「いい加減が新人から抜けだせよ、迷惑しかかけてねぇよ」 エンジニア的心構えその1

雑記 Diary 心構え

f:id:pierrot-nose:20160913231123j:plain

家に帰るたびに、上のサルみたいな面してませんか?
新人癖みたいな「それ」 、まだ残ってませんか?


職場で同じミスを繰り返したり、
ちょっと気をつければ気づくのに凡ミス連発。


物事をちゃんと理解せず、頭がパニックなのに助けを求めに行かない。
頭の整理ができない、質問できない。


設計ができない(これ大事)
技術そのものへの理解が怪しい
主にアーキテクチャとか、処理の読解力。


私自身、さいきん職場でミスを連発していたこともあり
「これ・・新人レベルだなぁ、くそだわぁ」
っと思ったこともあり、よくありふれたことを書いていきます。



質問する理由を知る


「他に何か質問ありますか?」

経験上、この言葉聞いた直後に私は質問をしたことがない。
そしてもちろん、後々になって後悔するのは・・9割は確実。


初めて知る「もの」とか、あまり普段から遭遇しないそれらの「機会」の中で
上の言葉に対して・・私だけでなくきっと他の人も質問できなかったはず。そう思いたい


その理由は簡単で
「わかっていないから」
「当事者として、そのイメージができていないから」


面接の場面に当てはめるとわかりやすいかもしれない
一通りの会社説明を受け、それなりの質問や答えを交え合う。
そして最後に「質問ありますか?」の拷問。
一晩で会社概要を覚えた、適当な人だったら8割は質問しないでしょう。

当たり前だよね、わからないし、イメージできないもん。
もしちゃんとできる人が質問しようならばきっと
「どういう基準で人事評価をしているのでしょうか?」とか
より具体性を持った質問ができるはず。


エンジニアも全く同じで、仕様を一通り読んで。
説明を受けて、「わからないことありますか?」

・・・・・・・
・・・・


ってならないように、ちゃんと話の中でメモとったり
少しでもわからなかったら話をちょっと遮ってでもいいからわからないことを伝えよう

質問がないのは、理解できていないのもあるけど
話の中で置いてけぼりにされて、頭が追いついていない証拠。
それを放置しなければ、その追いてかれた時点で質問はできるでしょうが

聞かなきゃわからねぇって!

質問される側を知る

部下を持つ人、管理する人はわかるはず
下の人達にはどんどん質問に来てほしい。
もちろん手が開いてる時や、よっぽどいそがしくなければだけど

上司からしたら
「本当にわかってるのかな?」
「質問なさすぎて逆に不安なんだが・・」

な気持ちなもの。
まぁそれもそのはず、上司はスケジュールだとか全体的なことを見てることが多く
部下に任せた仕事が終わりにさしかかり


「こういう実装だと思ったので、こういうふうに作ってみました。」

それが完璧ならまだしも、そうでなかったら。
工数をかけて作ったそれが、実はダメでしたー。
作り直しはいくら何でも遅すぎるケースになる。


そういう事態、上司の不安の払拭も
認識合わせとしても質問する・・というか会話が大事。
質問は名前だけで大事なのは認識合わせなんだけども。

「ここはこういう風な認識で、これからこういう作りをしていきますがどうでしょうか?」
「ここはこうで、あれはこうで。間違っていませんか・・?」


書き出してみると思うが、質問と認識合わせを飛び越えてもはや相談だな。


凡ミスをする一番の理由

単純すぎるけど、誰でもなりえるそれは


緊張感がない
見られてる意識がない


これだけ。

心当たりある人は、そーっと手を胸に当てて人呼吸。
危機感を持って仕事してください。

そいつらはきっとただの誤字脱字、処理判定違い。
日付書き間違え。単なるコピペ
余裕かましてる時、単純作業化してるときにそいつらはやってくる。
気を引き締めるべし。

ピンポイントで問題を見るな

何か問題が起きた時、よく説明をさせられる
頭から最後まで、話せる?

説明できないのならそれはピンポイントでしか問題を見ていないから。
問題の前後を見ていないから、問題の流れを見ていないから。


これはソースも同じで

if ( 定数 == なんちゃらDTO.何かの値A || 定数 == なんちゃらDTO.何かの値B ) {
    //何かの値Aが定数と等しい または 何かの値Bが定数と等しい 場合
  処理①
  処理②
  変数A = 変数Ab
  if ( 定数 == なんちゃらDTO.何かの値C && 変数A != null ) {
        処理③
    } else {
        処理④
    }
} else {
    処理⑤
}

障害内容:処理③に入らない。

きっと簡単な処理で、ひと目で説明できるものでも
これだけの情報じゃ問題解決はできない。


「なんちゃらDTOはどこで何を入れてんの?どこからとってるの?」
「そこの入れてる処理は見たの?」
「あの変数Abは何が入ってるの、ちゃんと変数Aに値入ってるの?」


なんて言われたら終わり。
結局見ていないと一緒。  

問題の前後を見ること。そしてなにより、
誰に突っ込まれても大丈夫なぐらい手を尽くして理解すること
自分で論理的に説明できること

上で解決しなかったら、それこそ質問しろ。
相談しろ、実践できれば絶対に早く解決するはずだから。



手ぶらで行くな、ノープランで行くな!


何かに躓いたり、問題にぶち当たるとき
だいたい混乱したり、物事が整理できなくなってしまう


深呼吸し、自分がわからなくなってきた「ポイント」までを整理しよう。
わからない事がいったいなんなのかの状態で誰かに聞いても
お互いのストレスがたまるだけ。
相手も常に時間があるわけではないはずなのでそういうところにも   
気をまわしてみよう。


弱さを自覚する。恐怖を乗り越える。

残念ながら、自分はいまだに「恐怖」する心を持っています。
長年の引きこもりや、対人関係が苦手だとか、体育会系出身で上の人たいして恐怖をいだいてるとかが原因じゃないです。

  • 質問するのをためらう
  • 一人で悩む時間はだいたい20分以上かかる
  • 自分から率先して「報告」しにいけない
  • 自分の道を突き進む、視野が狭くなる

1個でも当てはまったら、もう要注意というより限りなくアウトです
少なくとも現場で考えてしまえばそれは無駄な時間であって何も生まないのです。

ミスだったり、失敗は怖いけど
それをのちのちに全部引きずってあとから指摘されて取り返しのつかないことのほうが
遥かに怖いものです。

天秤にかけるべき。
今の一瞬か、後々大失態を巻き起こすミスか。

最悪、リーダー、上司に迷惑をかけるくらいの気持ちで挑む
新人1年目なら許されるだろう・・2年目は・・まぁ うん。



こうやって書いていると、エンジニアというか
この業界は忙しいなあ。

技術ももちろんだけど、対人力だとか仕事力がすごく大事。
すごく大事(大事なことなのd

それでは!ちゃお!

Related Posts Plugin for WordPress, Blogger...