17
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

ZOZOテクノロジーズ #5Advent Calendar 2019

Day 19

エンジニア未経験者が、メンティとして意識して良かった3つの事

Last updated at Posted at 2019-12-19

この記事は ZOZOテクノロジーズ #5 Advent Calendar 2019 19日目の記事です。
昨日は、@hmsnakrさんのVSCodeでのSQL Server(MSSQL)の開発でした。

前書き

エンジニア未経験でサーバーサイドの担当部署に異動し、現在2年目になります。
未経験時にメンターを付けて頂き、OJTで業務をしてきた中で、「メンティとして意識すると、開発・相談・質問がしやすくなった事」を3点にまとめました。
個人的な経験がベースの内容となっていますが、以下のような方の参考になればと思います。

・エンジニア未経験で入社/部署異動した方
・OJTでエンジニア業務をスタートした方

①書きたい処理を日本語で書く

book_sakubun_kodomo.png

コードを書くこと自体に慣れていないうちは、「こういう処理を書きたい→そのままコードとして書く」というやり方自体に手間を取られます。初めは処理の型や定型文の蓄積がないので、頭の中だけでは「想定の処理→コードに落とし込んだ記述」への変換がしにくいためです。
なので、【コードを書くこと】に慣れない間は、**「まず書きたい処理を日本語で書く→それをコードに翻訳する」**という意識で書き方を分解すると、コーディングへの心理的な抵抗が少なくなり、手を動かしやすくなると思います。

イメージとしては、下記のような形です。このベタの日本語を、コードに置き換えていくイメージです。

もし、明日晴れだったら
    自転車で行く
もし、明日雨だったら
    傘をさして徒歩で行く
上記以外
    徒歩で行く

上記のようなやり方をすることで、自分の理解を日本語でアウトプット出来ているため、開発に詰まった時も、自分の理解レベルを可視化した状態 でメンターへの相談・質問をする事ができます。「一体どこでつまっているのか?」が見える化されているので、メンターとのコミュニケーションも円滑になります。自分にとっても、「いま何が分からないのか分からない」という混乱した状態を避けやすくなります。

②質問は選択式にする

wakaremichi_man.png

開発や仕様調査に詰まった際に、「~が分からない」という【状態】をそのまま相談すると、「どこまで分かっていて、どこからが分かっていないのか?」という理解レベルの共有が難しくなります。

そのため、「AとBという処理を考えたが、どちらがベターか?」「この仕様はAという理解、Bという理解、どちらの方が正しいか?」「~という課題があるので、~を対策をしたいと思うが、良いか?(Yes or NO)」という選択式の質問として疑問を分解できていると、「自分の理解レベルを共有」+「メンター側の考えや選択時の基準」を引き出しやすくなります。
また当たり前ですが、メンターはメンティの質問や相談の他にも、並行で業務をしています。そのため、メンターの思考のリソース+時間を余計に奪わないという意味でも、質問を整理→選択式にするメリットはあると思います。

③素直に分からないと伝える(自力の調査時間を設定の上)

kyosyu_man.png

3つの中で、この点が一番大事だと思います。
開発や調査内容によっては「そもそも何がなんだか分からない。。」という状態になる場合もあります。その場合、①のように理解を日本語で書き出すこと、②のように選択式に洗い出すことが難しくなります。今まで全く触ったことのない機能の改修や、新規案件で要件の作成から関わる場合、上記のような 「理解のスタートとなる地点が分からない」 という状態になりやすいです。

そういった際は、自力で調査・理解する時間に 30分 の制限を設けます。この時間をオーバーしても分からない時は、それ以上調査しても、自力では理解できない可能性が高いです。そもそもの調査のスタート地点が間違っていたり、押さえるべき要件が抜けていたりします。そういった時は、メンターなど他人の目を一度借り、軌道修正をした方が良い場合が多いです。

仮に自分が大規模プロジェクトの一部ファイルの開発にアサインされた際、上記のような修正を挟まなかったとすると、
・プロジェクト全体に関する理解不足を解消しないまま進む
・終盤で理解不足による開発不足が発見される
・関わっている人の開発タスクにマイナスの影響を及ぼす
という、避けたい事態に陥ります。

上のような状況を防ぐ意味でも、
1:制限時間を設けた上で理解(分解)する
2:理解できない時は、メンター(場合によってはプロジェクの責任者)に素直に分からない状況を伝える
3:メンターから貰ったフィードバックを、理解できるレベルまでテキストベースに落とし込み、共有・内容確認して貰う
という流れが効率的だと思います(蛇足ですが、テキストに落とし込むのは、①と同じく自分の理解を可視化・共有しやすくするためです)。
「そもそも~という事が分からなくて困っている」と素直に伝える勇気も、エンジニア経験の浅いメンティには、大事な意識だと思います。ちなみにメンターと朝会や夜会を設定→その日の疑問点等をまとめて話す時間があると、上記のような相談もしやすくなると思います

参考サイト

・イラスト
https://www.irasutoya.com/

17
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?