シリーズ記事
- SE約８年経験して重要だと思った仕事のスタンス（前編）←今回
- SE約８年経験して重要だと思った仕事のスタンス（後編）
この記事のざっくり内容と対象読者
文系出身でSEとして働きはじめるが無能過ぎて死にたいと思っていた私が、この業界で約８年以上働いていて、自分の仕事の能力が上がったキッカケになったと思う仕事のスタンス・考え方について共有します。
また、一緒に仕事をしてきた他のメンバーを見ていて仕事ができる人、できない人の違いについて気づいた点を共有します。
SEの仕事に慣れていない方、新人〜３年目くらいの方
自分なりの答えを出す
自分がやっていること全てに自信がなかった
私が新人の時に身を持って学んだことです。
私は文系出身で大学時代もPCなんてレポートでWord使うかニコニコ動画見るかくらいでしか触ったことがなく、入社後の研修でもJavaの入門書の６割程度しか理解していませんでした。
そんな中、自社の先輩のいない客先へ出向。
お客さんは、他社の新人なんか育てる気などほとんどありません。
自分のやってること、仕事の進め方、考え方、成果物が正しいのかさっぱりわからず不安で仕方ありませんでした。
躓いても、何をすれば良いか検討もつかない。
先輩がやった方が正しいし早いよなー。
そんな考えを持って仕事をしていました。
考えを改めるキッカケ
そういう考えを持っていて、私は自分でロクに考えも調べもせず、常駐先の先輩のところへ質問しに行きまくっていました。
そうするとどうなるか
確実にうざがられます
先輩が迷惑そうにしているのが目に見えてわかるようになり、
あ、このままじゃダメだと自分を改めることにしました。
どう直したか
自分で調べて考えるようにしました。
といっても、仕事は時間が無限にあるわけではありません。
また、自分で解決できる力もほとんど持っていません。
そこで、まずはタスクを与えられた時、締切を確認するようにしました。
そこから、ざっくり何時までにどこまで終わってないといけないかメモしました。
もちろん、最初から正しい見積もりなんかできません。
それでも、ざっくり時間を決めることによって自分で考えて調べても良い時間を制限させます。
これ以上考えていたら間に合わないと思った時や、タスクにとりかかる前に進め方、方向性を確認したい時にだけ質問するようにしました。
質問の仕方がとても重要
質問をする前に、必ずメモ帳で文章化するようにしました。
自分の中で整理せずに質問にいくと、相手にとって不要なことを伝えたり、何が言いたいのかわからない状態になったりして無駄に相手の時間を奪うことになりがちです。
- 自分は具体的に何がわからなくて進められないのか
- 自分はどこまで調べて、こう考えたのだが、それで問題ないか
- この理解・認識で正しいのか
ここまで整理してから、質問を持っていくようにしました。
また、質問を受ける側の人はたいてい忙しいことが多く、当時の私のような能力の低い新人にあまりかまってあげる時間はありません。
能力の低い人に任せる仕事は優先度が低いことも大半です。
日本人らしい精神論ぽく聞こえてしまうかもしれませんが、必ず
「今お時間よろしいでしょうか」
と確認してから質問するようにしました。
そうするようにしてから、明らかに先輩の態度が柔らかくなっていくのがわかりました。
この「文章で整理してから質問する」は、質問に行くとよくウザがられると感じている人にオススメです。
自分に仕事が任されている意味
新人の自分より先輩の方が詳しいし正解を知っている。
それでも先輩は別の仕事があるので自分に割り振ってきます。
それなのに、なんでもかんでも１から１０まで質問していては自分に仕事を任せた意味がありません。
「自分で調べるより○○さんに聞いた方が早いよね♪」
そんなことを言って他人の作業の手を止めまくっていた人もいました。
その人はもちろんウザがられて契約を切られました。
また、ベテランのエンジニアだろうと全知全能な人は滅多にいません。
先輩の方が知っていると思いがちですが、与えられたタスクについて細かく調べたりしているうちに、新人の方が他のベテランエンジニアより詳しくなることも普通にありえます。
「○○については彼がやっていたから彼に聞こう。」
その彼も１〜２週間くらいしかその仕事をやっていなくても、こうやって頼られていくことはよく起こります。
特にこのIT業界では普通のことだと思います。
無駄に自分を卑下したり周囲の人を神格化することなく、この中で誰より１番詳しくなってやろう！という気持ちでやることが重要です。
仕事に正解はない
新人の時はよく勘違いしていましたが、レビュアーは全てを完璧に理解できないですし、自分の成果物を隅々まで確認することはできない人がほとんどです。（極稀に細部まで確認してくれる人もいますが）
自分で調べて、考えて、成果物は自分なりの根拠を持って作りあげる。
なぜ、そう設計したのか？なぜ、そのようにコードを書いたのか？を説明できるようになるまで理解する。
レビューの時に「こうした方が良いのでは？」と言われても、「自分は○○だからこっちの方が良いと判断したのでこうした。」と意見できるまでできたら素晴らしいです。
※もちろん相手の意見もちゃんと聞き入れる。何も考えずにただ先輩がそう言っていたからそうしたはダメ。
チームで決め事が作られていればそれを守るだけで、成果物に正解はないのだから、後は自分で正しいと思うものを作って自信を持ってあげるだけです。
自分の理解が不安だと思うものは、先程記載した通り整理して質問していけばだいたいの人は優しく教えてくれるはずです。
自分の成果物は自分が責任を持つ意識
ここまで書いたことは割と基本的なことですが、意外と業界歴１０年くらい経歴のある人でもできてない人がたまにいます。
自分でデバッグもせずググりもせず、何のエラーかも伝えずに、ただエラーが出ましたとだけ言ってくる人。
私より年齢も経歴も等級も上なのに、「自分はこの技術初めてだから、自分の書いたコードが問題ないか全体的に確認してください。」と、タスク山盛りで締め切りに追われている私の作業の手を何度も止めてお願いしてくる人もいました。（私もその技術初めてやってるのに）
具体的にどこがどう自信がないから相談に乗って欲しいという依頼や、ここはチームで統一すべきだと思うがどうだろうか？という提案であれば問題ありません。
ただ単に自分の成果物に自信がないから全部見てくれは責任を他人に押し付けてるだけです。その人に仕事を任せてる意味がありません。
こういう人はメンバーから一緒に仕事したくないと思われ、関係性が築けず本人も仕事がやりにくくなります。
この記事で書いてあることができていれば、まずは社会人偏差値はマイナス１００から４５くらいにはなると思います。
続きは別記事で書きます
コメント