对日开发时一些经验

コミュニケーションスキル

新人に一番身につけて欲しいのはコミュニケーションスキルです。

また、私の考えるコミュニケーションスキルとは相手の意見を正しく理解出来て、自分の意見を正しく相手に伝えることができる能力で、この能力がないと先輩が助けてあげることすら出来ません。

質問力

---

新人には質問力を身につけて欲しいです。具体的には以下のようになります。

15分悩んだら質問をする

新人に自力で考えさせることも大切ですが、素早く見切りを付けて質問出来る能力が必要だと感じました。

「困ったらすぐに質問してください」くらいの指示だと、(自分なりにすぐに質問しているつもりでも)半日くらい平気で悩んでいるので、「15分悩んだら必ず質問する」というルールを決めて、質問すること自体に慣れる方が良いかなと思います。

事実と意見を分ける

「何を確認したところ、どうなった」という事実を整理し伝える能力が必要だと感じました。

新人たちの質問を聞いていると、「こうなっている気がする」という意見を「こうなっています！」という事実として伝えてくることが多発しました。

例えば、実装中に思い通りの挙動にならない時に「このメソッドが実行されていません」と私に伝えてくるも、そのメソッドにデバッグコードを仕込んで確認すると他の箇所でエラーが発生していたということが多々ありました。

質問の経緯を明らかにする

質問に至った経緯を話せる能力が必要だと感じました。

「Aという機能を実装し、次にBという処理を実装しています。その中で○○というエラーが発生し、その解決策が分からないです。試したことは…」のような質問が出来ると良いと思います。

新人の中には「○○というエラーが発生し、その解決策が分からないです！」という質問をしてくる人がいます。この質問の方法では、エラーの前の処理が不要である可能性すらあります。

質問に至った経緯を話すことで先輩からより良い解決策を引き出すことが出来ます。逆に、「○○というエラーが発生し、その解決策が分からない」という質問では、エラーの解決方法しか伝えることができません。

文章力

---

新人には文章力を身につけて欲しいです。具体的には以下のようになります。

結論から書く

文章だけでなく口頭でのやりとりでも同様ですが、結論から書く(伝える)ことができると良いと思います。

「私はこれから○○についての質問(報告)をします」と結論を宣言してくれると、聴く側も脳を質問の解決のために最適に使うことが出来ます。

0から順にストーリー仕立てで説明されると、聴く側は重要な点が分からず一言一句聴き逃さないように聴く必要があるので、とても疲れます。

読みやすい文章を書く

段落や改行を意識して読みやすい文章を書くことができると良いと思います。

全く改行されていない文章はただの文字の羅列で非常に読みにくく、段落や改行を用いて意味のある単位で文章を分割することで読みやすくなります。

特に昨今はリモートワークの増加により質問や報告を文字でする機会が増えており、読みやすい文章を書くことは今まで以上に重要なスキルになると思います。

プログラミングスキル

---

個人的な意見ですが、新人にそこまでのプログラミングスキルは期待していません。すでに紹介した能力さえあれば業務を進める上では概ね問題ないと思います。

しかし、最低限のプログラミングスキルは必要です。

基本的なプログラミングスキル

if文、for文、変数、配列などを理解しており、とりあえずプログラムを動かせることができると良いと思います。

また、最近のプロジェクトではフレームワークを使用することが多いので、オブジェクト指向についての深い理解は不要であると思います。

ただ、他の人の書いたソースコードを読む機会が多いので、そのコードを読むためには「サービスクラスからメソッドを呼ぶ方法」くらいの知識は必要です。

とは言うものの、研修期間を含め1年間プログラミング業務を行なっていればこれくらいの知識は付くと思います。

アルゴリズムについての理解

様々なアルゴリズムがあることを知っていると良いと思います。

例えば、配列から値を探索するには線形探索だけでなく二分探索や三分探索などの様々なアルゴリズムがあるので、状況によって選ぶべきアルゴリズムが異なることを知って欲しいです。

状況によって選ぶべきアルゴリズムが異なることさえ知っていれば、より良いアルゴリズムやより簡単なアルゴリズムを調べることができます。また、調べることさえできれば、先輩に相談しながら実装することも出来ます。

優秀な新人は自力でのアルゴリズムの実装に挑戦してほしいですが、並の新人も様々なアルゴリズムがあって状況によって選ぶべきアルゴリズムが違うことは少なくとも理解して欲しいです。

業務の進め方

---

新人の内は業務の進め方についても先輩から指導が入るはずですが、言われた通りに業務を進めるだけではつまらないと思います。
従って、より効率的な進め方がないか考える能力がまずは必要です。

作業のゴールの合意を取る

作業のゴールの合意の取れていない状態で進めると痛い目を見るため、事前にゴールの合意を取れると良いと思います2。

例えば、実装タスクでは以下のようにゴールは様々であり、提示されている期限でどこまでやるべきかを理解しないと作業の遅延に繋がります。

(1)プログラムが動けば終わり
(2)ソースレビューが通れば終わり
(3)ユニットテストの実装をすれば終わり

他にも調査系のタスクであれば以下のようにゴールは様々で、ゴールによって調査の観点やまとめ方が変わってきます。

(1)お客様に説明する
(2)内部向けに説明をする

作業をイメージする

ゴールの合意と似ていますが、実際に行う作業をイメージしてから作業に着手できると良いと思います。

とりあえず着手して分からなかったら質問をする人が新人には多いです。初めのうちは実際に行う作業をイメージするのは非常に難しいですが、日々の積み重ねで少しずつできるようになると思います。

正しくツールを使用する

気合でどうにかしようと考える人が新人には多いですが、正しくツールを使用して楽をできると良いと思います。

例えば、コードレビュー時にコーディング規約違反で指摘を受けるようであればエディタのオートフォーマット機能を使用すれば良いですし、作業に集中しすぎて質問が遅れるようであればアラームをセットすれば良いです。

「頑張って気をつけます！」という考えは精神的に疲弊しミスも誘発するので一番危険なので、楽に効率的に進めるためにツールを調べるのも良いと思います。

正しく進捗を報告する

チームで仕事をしていれば自分のタスクの進捗を報告する機会は多いと思いますが、正しく進捗を報告できる新人エンジニアは少ないと感じました。

「進捗は80%です！」や「ちょっと遅れていますが、残業すれば取り戻せます。」のような自分の感覚だけを元にした進捗報告では正しい進捗報告とは言えません。
報告を受けた側としては「80%と言える根拠は？」「ちょっとって具体的には何時間分？」という疑問が残ります。

例えば実装タスクであれば
「実装すべき処理が10個あり、その内8処理の実装が終わったので進捗は80%です。」
「今日までに8処理の実装を終えている予定でしたが、まだ7処理しか実装が完了していないので、少し遅れています。今までのペースだと1処理の実装に2時間ほど掛かっているので、今日1~2時間残業すれば遅れを取り戻せそうです。」
のように定量的な報告ができると良いと思います。

もちろん、上記の例で言えば実装すべき処理の中には実装が簡単な処理や時間がかかる処理があるはずなので
8/10処理実装が終わったから進捗80%、という単純なものではないのですが
「なんとなく80%くらい」という報告より遥かに良いです。

さらに言えば、上記のように進捗報告を行うためにはタスク開始時にそのタスクの全量を把握する必要があります。
最初のうちは上司や先輩に相談しながらタスクの全量把握して良いと思います。
慣れてきたら自分で全量を把握し、「ここは大変そうだから先に対応してしまおう」などの工夫ができるようになるとより良いと思います。

转载于：https://qiita.com/Megane-kazuma/items/8724b4da563516733c1b