教える側も教わる側も押さえておきたい心構えとかの引用
自分もエンジニアとして働き始めて5年目とかになるので、それなりに周りや新人を目にする機会はあって、「なんでこんなことになっちゃうんだ」とか「コイツ今までどうやって生きてきたんだろう」とか思うことがある。それと同時に、「そういうヤツもいると分かっておきながら、どうして自分はうまくそいつをコントロールできないんだろう」とか反省することもある。
そんなワケで、「新人はできたら自分からこういう風になってね」という願いと、「そうは言っても無理だろうから、上司はこうしていこうね」という対策を、様々な記事から要点を引用してまとめてみる。
心構えや力不足を指摘しても、人は成長しない。
具体的な行動に注目してそれを習慣化させる。「悩む」と「考える」を分けていく
マインドは伝わらない。アクションは伝わる。気持ちとか努力とか心構えを指導しても効果は出ない。そんなことをするくらいだったら「意味が分かるようになるまで黙ってコレを続けろ」と行動を指示した方がまだマシ。
「悩む」と「考える」の違いは特に重要。
自分の中での技術的な当たり前は相手にとっての当たり前ではない。
トラブルシューティングの方法は喜んで教えましょう、教えましょう。
「自分でやった方が早い病」に陥らないようにしましょう。
仕事を振る時、「到達点 (= 目標であり、成果物の定義や粒度)」は正確に伝えるが、そこに到達するための具体的な方法はあまり指示しない方が良い。
コードを深追いする深さが、プログラマの成長限界をどこにしてしまうかという基本的なパラメータではないか
体系的知識を身につける
プログラミングの基礎から勉強中の人は、自分が書くことに精一杯だが、本当は「正しく読む力」が大事で、コードリーディングの数をこなさないといけない。
個人的な好奇心や興味をベースに勉強や仕事をすると、知識や能力に偏りが出て、基礎が出来ていない人間になっていくので、体系的に知識を身に着けようとする姿勢は大事。OJT の場合、悪い「現場主義」になりがちなので、「現場ルール」と「世間一般的な知識」を区別して教え、できれば書籍などを紹介して一般的な知識も吸収させるようにしたい。
- 言い訳を口に出さない
- 逃げ道は、心の奥底にしまっておくもので、普段から考えない
- 当事者意識を持つ
- 保守性を重視する
- 「そもそも」から考える癖をつける
- 作っている本人が「なぜこう書いたのか？」を説明できない部分があってはいけない
- 作業の前にToDoリストを作れ
- 自分の案件だけすれば良いという訳ではなく、チーム全体で成果を出す
- ただ厳しく接するだけではなく、「自分はできるんだ」という成功体験を味わわせる
README.rst を書く
- まず最初に何がしたいのか、どんなことをしたいのかを書く
- 概要、ゴール、実装方法、使用ライブラリ、ToDo などを書いていく
- そして README.rst に擬似コードを書き始める
「ぼく内気なんで、うまく話せないんです」じゃねえ。報告も仕事なんだよ、言い訳してんなら死ね。
はじめのうちは1h〜1.5h毎に上長に進捗を報告しよう
これ必須。「今何をしています」「さっきからコレを順調に続けてます」は何も問題がなくても定期的に言う。「困ったことが出てきました」は5分調べて分からなかったらまず共有する。
この仕事をしていてよく思うのですが、たとえ些細なことでも絶対的な正解なんてのは存在しないです。
あるのはその時に選べる選択肢と、その選択肢を選んだときのメリット/デメリットです。 さらに言えば、そのメリットとデメリットも状況によって大きく変わりますし、正確に予測することは先輩社員でも困難です。学校の勉強のように「正解を教える」ということは先輩社員にもできないのです。
ググっても絶対出てこない問題（社内特有のルールやシステムなど）についての質問は大歓迎です。
調べても時間の無駄になることはわかっているので、これは社内特有のものだと判断したらすぐに聞いてください。
特有なのかどうかが判断できない場合もやっぱり聞いてください。一般的な内容だった場合は「ググってね」で終わるだけなので。日々、少しでも多くの情報を頭に入れ、それを自分の頭で解釈し、実験し、失敗し、試行錯誤をしながら、仕事をする上での最適な判断を下す力を鍛えるのが良いと思っています。
「この場合はこれが正解」ではなく、「こんな状況でこういう前提があって今こちらにはこんなカードがあるから、今とるべき行動はこれだろう、そうするとこんな結果が予測できるので、そうなったら今度はこうしよう」という考え方です。
おそらくこの考え方は机に向かって生真面目に本を読んで内容を覚えるだけでは身につきません。仕事やブログ等で考えを伝えて議論することで、他の人の思考回路を盗んでくる努力も必要です。
唯一の答えを暗記することが勉強だと思ってきた新人さん方は、会社は学校じゃない、学校で求められたことは要らない、というパラダイム・シフトを早めにして欲しい。
個人的には、同期と連れションに行く習慣はなくした方が良いと思う。仲良しグループじゃないから。
- どうでもいいことほど、早くやる
- ビジネス的な言い回しをちゃんと使う
ビジネス的な言い回しは本当に重要。いつまでもビジネス文書、ビジネスメールが書けそうにない人材は上司も昇進させられない。
コレに関しても、社内ルール・現場ルールも数多くあるし、唯一の正解があるものでもないので、沢山の知識を日々吸収していって、TPO にあわせて都度最適なカードを選ぶしかないこと。
- ドキュメントを必要最低限整備する
- エラーログと常に向き合う
- 技術を知ったつもりにならない
- アウトプットをクセ付ける
- 誰のために、何のために働いているかを考える、分かろうとする
- なぜ／どうしてを考える
いきなりコードを書き始めるのは止めましょう。絶対に書き直す事になります。時間がもったいない。
仕様をまとめましょう。Taskを細かく分解+時間の見積もり
不確定要素を把握する力
格言・名言の類は、自分を鼓舞するためには有用だが、他人に押し付けて「お前もこうしろ」という使い方をするのは効果が出ない。
みんなに知ってもらいたいと思うけど、自分から知りたくて知ろうとした人でない限り、こうしたありがたいお言葉は残念ながらその人には響かない。
ご自身のためになれば、と。